Bug 3760 - WPA pre-shared must be between 8 and 63 characters long
: WPA pre-shared must be between 8 and 63 characters long
Status: RESOLVED INVALID
Product: Connectivity
WiFi
: 4.1.2 (4.2008.36-5)
: N800 Maemo
: Unspecified normal with 2 votes (vote)
: ---
Assigned To: unassigned
: wifi-bugs
:
:
: 9864
:
  Show dependency tree
 
Reported: 2008-10-01 08:46 UTC by Bani
Modified: 2010-09-22 16:47 UTC (History)
10 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Bani (reporter) 2008-10-01 08:46:29 UTC
SOFTWARE VERSION: 4.2008.30-2

PROBLEM:

When trying to connect to a WPA access point there is a validation on the
length of the pre-shared key. One of the places where I'd like to use the wi-fi
has a 6 characters key, but when I type that and click Ok it says "At least 8
characters must be entered". From my point of view validating the key is an
issue for the person setting up the access point, it shouldn't be a problem
when connecting to it.

REPRODUCIBILITY: always
Comment 1 Andre Klapper maemo.org 2008-10-01 15:21:15 UTC
The WPA-PSK specification at
http://standards.ieee.org/getieee802/download/802.11i-2004.pdf (page 166) says:
  "A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters."

So the person that runs the access point is using it out of specification.
I prefer to not change the N800's behaviour just because of specification
violations.
Comment 2 Kalle Valo nokia 2008-10-01 19:16:21 UTC
(In reply to comment #1)
> The WPA-PSK specification at
> http://standards.ieee.org/getieee802/download/802.11i-2004.pdf (page 166) says:
>   "A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters."
> 
> So the person that runs the access point is using it out of specification.
> I prefer to not change the N800's behaviour just because of specification
> violations.

I agree.
Comment 3 Bani (reporter) 2008-10-01 19:24:41 UTC
Any chance you guys could give me some directions on how I could do it myself
on my own copy? Will I need to flash my system with the whole system or would
it be possible to change just one application, what is the file, etc?
Comment 4 Andre Klapper maemo.org 2008-10-01 19:26:22 UTC
What is "do it myself"?
Comment 5 Bani (reporter) 2008-10-01 22:46:44 UTC
"Do it myself" is get the maemo code, find where the validation is and remove
these lines. I already know how to compile stuff with the scratchbox, etc.
Comment 6 Andre Klapper maemo.org 2008-10-02 12:09:52 UTC
Uhm, I myself don't know which package this is part of and whether it's open or
not, sorry.
Comment 7 Andre Klapper maemo.org 2008-10-10 18:38:25 UTC
*** Bug 2028 has been marked as a duplicate of this bug. ***
Comment 8 Gabor (Account disabled) 2009-01-10 01:13:21 UTC
Dear Developers,

Could you please suggest any workaround? I have the same problem: the access
point has a 64 character hexa code I can not enter it in the N800 (I can use it
with my Kubuntu computer).
I understand that use don't want to implement a solution to someone who does
not follow the standard, but some workaround made public would be nice.
It would be important for me.

Gabor
Comment 9 Andre Klapper maemo.org 2009-01-10 01:43:45 UTC
(In reply to comment #8)
> Could you please suggest any workaround? I have the same problem: the access
> point has a 64 character hexa code I can not enter it in the N800 (I can use it
> with my Kubuntu computer).
> I understand that use don't want to implement a solution to someone who does
> not follow the standard, but some workaround made public would be nice.
> It would be important for me.

Hack the code and recompile IF this code is open source (don't know, I must
admit).
Comment 10 Andre Klapper maemo.org 2009-12-07 20:00:49 UTC
*** Bug 6678 has been marked as a duplicate of this bug. ***
Comment 11 Jamie Lokier 2009-12-07 23:00:27 UTC
It's not standard for the *passphrase* to be 64 characters long.  That's the
length of a hex key.  Which has the *standard* length of 64 digits (256 bit
key).

Sometimes you have a passphrase, and sometimes you have a 256 bit key.
Windows Vista and Ubuntu Linux both accept such keys and just work, so it's not
that obscure a case.

I wouldn't be surprised if the 63-character limit on passphrase length were
specifically so that systems can distinguish between that and a 64-digit hex
key.  (But it might just be a coincidence).

The bug that I'm reporting, then, is the inability to enter that hex key.

I'm not sure how to proceed with this.  It's obviously a practical usage
problem to be unable to connected to a standard access point due to a trivial
UI issue - Windows and Linux have no problem connecting to the same.  Should I
create a new bug with the title "UI does not allow a 64-digit hex key to be
entered for WLAN WPA access"?

Thanks.

Side note, to the tone of comment 1 on #6678: I'm quite shocked that a serious
usability issue can be dismissed so off-handedly as "that's not standard", and
ironic as it is, in fact, standard for a hex key to be that length.  It gives
the impression of "we haven't thought about this use case, we don't care and
we're trying to keep the number of open bugs down by dismissing your problem
with the minimum of attention".  No apparent interest in solving the core
problem.  Sorry if that seems harsh, but I was quite shocked as it's the most
unhelpful 'solution' I can think of, and leaves a sense of "why bother
reporting bugs if the answer is going to be go away?".  I realise that's not
what is intended, but it came across that way because it was such a brief,
closed and dismissive response to a genuine UI issue (if not necessarily a
bug).
Comment 12 Andre Klapper maemo.org 2009-12-07 23:06:13 UTC
(In reply to comment #11)
> Should I create a new bug with the title "UI does not allow a 64-digit hex 
> key to be entered for WLAN WPA access"?

Not needed as we have bug 1002 for that. :-)

> Side note, to the tone of comment 1 on #6678: I'm quite shocked that a serious
> usability issue can be dismissed so off-handedly as "that's not standard", and
> ironic as it is, in fact, standard for a hex key to be that length.

Yes, I was completely wrong with that comment. Sorry for that.
Comment 13 Helge Hielscher 2010-01-14 12:57:14 UTC
Please fix this. At least write "Enter WPA pre-shared key (8 to 63 chars, no
hex)" in the UI. It is an awful first experience after entering 63 hex numbers
to find out that the last number does not fit.
Comment 14 Ricardo 2010-01-14 13:17:50 UTC
This bug/problem as almost 2 years, amazing.... 

I have the same problem on a N800 and a N95 8Gb.

Tested with hotspots from 3com, linksys and d-link....
Comment 15 Andre Klapper maemo.org 2010-01-14 13:24:36 UTC
Have you filed bug reports / complaints been filed against the Access Point
providers that they violate the specification
http://standards.ieee.org/getieee802/download/802.11i-2004.pdf ?
Comment 16 Timbo 2010-04-05 16:22:44 UTC
(In reply to comment #15)
> Have you filed bug reports / complaints been filed against the Access Point
> providers that they violate the specification
> http://standards.ieee.org/getieee802/download/802.11i-2004.pdf ?
> 
Whatever next Mr. Klapper!? You try to bully and belittle your 'customers' into
refraining from submitting bugs because you're too damned lazy and uninterested
to rectify matters. You can quote ALL the IEEE standards in the world to people
but doing so won't make these people's problems go away, will it now?

Here's my suggestion. Understand that MANY MANY MANY professional IT
departments utilise a 64 hex bit code - secondly, make an app or utility to
enable PAYING CUSTOMERS to connect to those networks.

I guess your reply to this will simply be to state that I should read the IEEE
standard. Well, if it is, I'll be satisfied that I was right in judgeing your
character. Go on, prove me wrong - wise up to professional people's needs and
make a work-around or utility to overcome this problem.

Remember one thing though. If people have their own wifi network at home,
they're unlikely to need to use an N900. They have their damned computer
nearby. We need it for professional reasons, to connect to corporate networks
where they take their security very seriously.

One other point. You dismissed bani outright. FYI he is one of the world's best
 programmers responsible for some of the finest applications ever.

So, are you going to help us or hinder us?
Comment 17 Andre Klapper maemo.org 2010-04-06 13:52:35 UTC
I see exactly one vote on this report which is not much if you want to convince
Nokia here (which will be hard anyway I assume) to implement workarounds for
broken routers... Feel free to vote even if it's currently INVALID.

@Timbo: I myself have no customers as I don't work for Nokia. For future
reference you might want to get your facts straight before adding unhelpful and
non-technical rants that do not belong here and only create mail for everybody.
Comment 18 Gabor (Account disabled) 2010-04-06 16:15:28 UTC
Dear Klapper,

I respect your opinion, but it seems to be a minority opinion. I agree with
others who say that when violations of some standards are widespread (which is
in accordance with my experience) it's not the standards we have to conform to
but to reality. There are numerous examples of standards which are superseded
and silently ignored - the one you seem to stick to appears to be one of these.

I even appreciate your effort to put pressure on companies neglecting
standards, but only large groups can exert such pressure. If you want to use
the N800 user group in this initiative I believe you haven't chosen the right
group. Even if we all united to support your crusade we were far too weak as
the number of N800 users is negligible compared to other systems which do
support the non-standard protocol.

I ask you not to retard the access of N800 users to these WiFi networks. But I
promise you to sign your petition if you chose a way of protesting against
protocol violations which targets the main user group of the violation.

I do not consider this bug invalid, I think this is a major bug.

Best,

Gabor

PS: I see no link to vote. Where is it?
Comment 19 Andre Klapper maemo.org 2010-04-06 16:19:44 UTC
> I do not consider this bug invalid, I think this is a major bug.

From Nokia's point of view it is INVALID. (Note that this is not necessarily my
personal opinion and note that I don't make these decisions myself.)

> PS: I see no link to vote. Where is it?

Look out for "Vote for this bug". It's above the comment text input field.
Comment 20 Gabor (Account disabled) 2010-04-06 16:48:29 UTC
(In reply to comment #19)
> > I do not consider this bug invalid, I think this is a major bug.
> 
> From Nokia's point of view it is INVALID. (Note that this is not necessarily my
> personal opinion and note that I don't make these decisions myself.)

Most bugs can be solved with programming. This bug might need an extra step:
convincing Nokia not to punish its users instead of industrial competitors.
Users suffer from this problem, but they did not cause it and can not help it.

I understand you are not the decision maker. I believe you (the contact to
Nokia here(?)) should not work on isolating the users from the decision maker
but to help communication.

1. If Nokia officially declares that it will abandon the bug fix despite the
difficulties of the users that will be a big minus for Nokia in my eyes.
2. If the representative of Nokia (you?) hinders communication and stick to an
excuse why not correct the bug it will be an even bigger minus in my eyes both
for Nokia both for its slave in the injustice.
3. If it is your private minority opinion that this bug is invalid and it was
you closing it as invalid then you abuse your position in the bug-track system
in an anti-democratic way, unusual in the free software community. If this is
the case then you are the obstacle, and the first step towards the solution is
to remove you from the way.

If you are not the decision maker, do not hinder the process in reaching a
solution.

> Look out for "Vote for this bug".
Thx.
Comment 21 Andre Klapper maemo.org 2010-04-06 16:58:18 UTC
(In reply to comment #20)
> 1. If Nokia officially declares that it will abandon the bug fix despite the
> difficulties of the users that will be a big minus for Nokia in my eyes.

This has happened already, as it is closed as INVALID. End of offtopic
discussion here please (or use email instead of this bugtracker).
Comment 22 Ryan Abel maemo.org 2010-04-06 17:02:10 UTC
(In reply to comment #20)
> 3. If it is your private minority opinion that this bug is invalid and it was
> you closing it as invalid then you abuse your position in the bug-track system
> in an anti-democratic way, unusual in the free software community. If this is
> the case then you are the obstacle, and the first step towards the solution is
> to remove you from the way.
> 

Just, fyi, bug trackers never have been (nor will they ever be) "democratic".
Comment 23 Gabor (Account disabled) 2010-04-06 17:23:27 UTC
Dear Bani, Jamie, Helge, Ricardo, Timbo,

Apparently the representatives of Nokia we are in contact with through the
bugtrack system not only do not wish to solve our problem with WPA
keys/passwords, they also did not help us finding the relevant part in the
source code, and actively try to suppress the communication about the problem.
Let's try an other way together!

Please contact me in email: maemobugs@borgulya.hu

Thank you,

Gabor
Comment 24 Andre Klapper maemo.org 2010-04-06 17:41:43 UTC
(In reply to comment #23)
> they also did not help us finding the relevant part in the source code

Gabor, when and where did you ask for this exactly before?
From a quick grep in the internal codebase I found the line
    g_object_set(widget, "max-length", 63, NULL);
in the package connui-wlan, but that package is closed source. :-/
Comment 25 Gabor (Account disabled) 2010-04-06 17:45:25 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > they also did not help us finding the relevant part in the source code
> 
> Gabor, when and where did you ask for this exactly before?
See comments 3 to 6 by Bani and you.

> From a quick grep in the internal codebase I found the line
>         g_object_set(widget, "max-length", 63, NULL);
> in the package connui-wlan, but that package is closed source. :-/
Thx.
Comment 26 Jamie Lokier 2010-04-06 19:25:18 UTC
I'm thinking the only way forward is to decompile the closed source component
and publish a binary patch. :-/

Doesn't sound very pleasant.  But if we're having IEEE quoted at us as a reason
not to interoperate with real world consumer devices...  and they can't even
acknowledge that the UI needs a clearer label.  Did it not occur to anyone that
the reason for the IEEE 63-character passphrase limit may be *intentionally* to
disambiguate from a 64-character hex key, so that either can be given.
Comment 27 Timbo 2010-04-07 02:56:45 UTC
(In reply to comment #26)
> I'm thinking the only way forward is to decompile the closed source component
> and publish a binary patch. :-/
> 
> Doesn't sound very pleasant.  But if we're having IEEE quoted at us as a reason
> not to interoperate with real world consumer devices...  and they can't even
> acknowledge that the UI needs a clearer label.  Did it not occur to anyone that
> the reason for the IEEE 63-character passphrase limit may be *intentionally* to
> disambiguate from a 64-character hex key, so that either can be given.
> 

Totally agree with you,

IEEE standards are not enshrined in law and no organisation can be held
accountable for the manner in which they implement their facilities, unless of
course, they do breach legislation.

My rant took place because I have paid in excess of £350 for a device which is
worthless to me. You talk of standards here, the idea of maemo, I was led to
believe, was to further the cause of Linux and open source. Now you tell us the
source is not, in fact, public and we are unable to utilise it in the best
manner possible for ourselves. I find it all very strange tbh.

Make the code public. Tell us the fix. You guys are all clued up here - tell
us. Surely it's not so secret that you can't? Why the heck would it be? Just
give us the fix and we'll all be off your back.

By the way vote =vote+1
Comment 28 Andre Klapper maemo.org 2010-04-07 03:06:39 UTC
(In reply to comment #27)
> Now you tell us the source is not, in fact, public

I cannot recall that Maemo was ever announced as 100% free as it never was.
Anyway, this is offtopic for this specific bug report.

> Make the code public.

See http://wiki.maemo.org/Why_the_closed_packages
Comment 29 Timbo 2010-04-07 03:33:13 UTC
I'll tell you what isn't off-topic Mr Klapper

Below you'll see extracts from your IEEE standard as listed above which you
rely upon as a reason for failure to provide a genuinie resolution to our
problem:


"Use of an IEEE Standard is wholly voluntary."

How can you suggest that a voluntary standard represents a 'limit' on the use
of a facility?



"The existence of an IEEE Standard does not imply that there are no other ways
to produce, test, measure, purchase, market,..."

And how does this enable you to suggest that network providers are operating
outside of a requirement when there clearly isn't one?

I'll ask again then, will maemo provide us with the ability to connect to a 64
hex bit server? You clearly cannot rely upon 'the satndard' as being an
enshrinement of practical useage or indeed policy.

or provide other goods and services related to the scope of the IEEE Standard."
Comment 30 Andre Klapper maemo.org 2010-04-07 05:56:42 UTC
(In reply to comment #29)
> I'll ask again then, will maemo provide us with the ability to connect to a 64
> hex bit server?

No, as far as I know Nokia does not plan this. See comment 19 or comment 21.
Comment 31 Gabor (Account disabled) 2010-04-07 13:32:12 UTC
(In reply to comment #28)
> (In reply to comment #27)
> > Now you tell us the source is not, in fact, public
> I cannot recall that Maemo was ever announced as 100% free as it never was.
> Anyway, this is offtopic for this specific bug report.
Mr Klapper,

Stop deflecting, please. Me too, I chose N800 because it has Linux on it. And
how we can fix this bug depends on how the source can be accessed. If it was
open, and you pointed out the critical code line earlier there would be a fix
around since long time ago. This is absolutely not off topic.

First I thought you belonged to the group of IT standards crusaders. Now it
seems that you attack everything that can delay the solution. I'm not sure
about your motivation, but it it very disappointing that a Nokia representative
does this.

My goal is fixing this bug. So is the goal of a number of people here.
You have already grep-ed a line of the source code, that's helpful - please
continue on that track and not on attacking those who are pondering possible
solutions.

Thanks,

Gabor
Comment 32 Andre Klapper maemo.org 2010-04-07 14:39:30 UTC
Gabor: You just continue writing things that we all know, again and again. 
I am totally uninterested why you bought your N800 as it is UNRELATED for this
specific report.
Adding comments creates bugmail for everybody that has to be read. It takes at
least my time as you don't come up with anything that has not been written here
already and that helps solving this issue.
I've asked several times here for avoiding offtopic discussions and to use
private email instead, and this was ignored.
If you continue here I will disable your account as your comments are simply
not helpful at all to get some progress here and this issue fixed.

Bugzilla is not a discussion forum but a technical bugtracker.
For offtopic discussion there is talk.maemo.org. It's definitely a more proper
place for your kind of postings: You are free to complain as much as you want
(also about my behaviour), and other people might either agree with you, or
might explain to you what Bugzilla is, what it is not, and why I am reacting
like this.

Thanks.
Comment 33 Gabor (Account disabled) 2010-04-07 15:42:31 UTC
(In reply to comment #32)
Klapper, you need not describe what you are not interested in. Let's focus on
the solution.

Let's fix this bug together.

Possible solutions:
1. Nokia/Maemo fixes the bug.
2. Nokia/Maemo opens the source of the relevant part and we fix the bug.
3. We decompile the code and make a binary patch.
4. Any other ideas?

    Ad 1. This sounds nice to me - not clear to me why Nokia/Maemo does not do
so. There is a disagreement concerning the IEEE standard vs real life practice.
Multiple users expressed preference of real life usability. Nokia was not clear
about its motivations except emphasizing the wording of the standard.
    Ad 2. This sounds nice to me again - not clear to me why Nokia/Maemo does
not do so. The http://wiki.maemo.org/Why_the_closed_packages does not mention
the critical package, connui-wlan. There are at least two users here who can
fix the bug given the source.
    Ad 3. This seems to need far more resources than the first two.
    Ad 4. I welcome CONSTRUCTIVE criticism and new ideas - which point towards
the usability of the devices also in the environments where standard 64bit
binary or non standard length keys are in practice.
Comment 34 Ryan Abel maemo.org 2010-04-07 20:58:56 UTC
(In reply to comment #33)
> Possible solutions:
> 1. Nokia/Maemo fixes the bug.
>

They've already announced their intention not to do this (right or wrong), if
you wish to continue pursuing this course of action, then this bug is not the
place to do it. :)

> 2. Nokia/Maemo opens the source of the relevant part and we fix the bug.
>

Feel free to file the request (if it hasn't already been filed), but the place
to request that is not this bug (but a new one).

> 3. We decompile the code and make a binary patch.
>

Best of luck to you, discuss it on the mailing list, Talk, or IRC, not here.

> 4. Any other ideas?
> 

Yes, please be reasonable and civil, follow Andre's repeated requests to take
any discussion off Bugzilla (as it is NOT a discussion forum).

Thanks!
Comment 35 Gabor (Account disabled) 2010-04-07 23:18:57 UTC
(In reply to comment #34)
> (In reply to comment #33)
> > Possible solutions:
> > 2. Nokia/Maemo opens the source of the relevant part and we fix the bug.
> 
> Feel free to file the request (if it hasn't already been filed), but the place
> to request that is not this bug (but a new one).

Thanks, this part of your comment was constructive. I'm surprised to learn that
at Nokia/Maemo a new bug report is the place to request making packages open
source.
Here is the request: Bug 9864
Comment 36 Andre Klapper maemo.org 2010-04-15 13:32:41 UTC
*** Bug 9930 has been marked as a duplicate of this bug. ***
Comment 37 Andre Klapper maemo.org 2010-04-27 23:26:30 UTC
Just for your information, the plan for Maemo6 (which will most likely use
ConnMan instead) when it comes to the text entry field for WPA Pre-shared key
is:
• If user enters less than 8 characters, At least 8 characters
  must be entered error is shown.
• If user tries to enter more that 63 characters, Maximum
  number of characters reached error is shown, except when
  all 63 characters are valid hexadecimal characters. In that
  case user is allowed to enter 64th hexadecimal character
  (others not allowed).
• If user tries to enter other than ASCII character, Only ASCII
  characters allowed error is shown.