Ok, I was wrong since it's 63 characters. This of course is according to the
standard, but why isn't there away to enter the HEX code?

Is anybody working on this? In my eyes it's just a small enhancement of the
existing code:
 - A checkbox that says 'HEX'
 - A parameter telling the save-method to not calculate the HEX value for the
entered key, since it's already HEX

I'd still like to have this feature and I think this could be useful for others
as well.

Comment 3 Quim Gil 2008-12-28 20:06:08 UTC

Just checking: is this still an issue with the latest firmware released?

Comment 4 Andre Klapper 2009-01-02 13:38:08 UTC

(In reply to comment #3)
> Just checking: is this still an issue with the latest firmware released?

Yes, there is no HEX input option.

Comment 5 Kalle Valo 2009-01-02 15:32:19 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > Just checking: is this still an issue with the latest firmware released?
> 
> Yes, there is no HEX input option.

And most probably there never will be, at least I don't see the point of
implementing it. If someone really thinks this is a useful feature, please give
very good reasons why it should be implemented.

(Please remember that time is scarce, we simply cannot implement all ideas we
receive. And implementing a feature is not only about writing few lines of
code, it also affects UI design, testing, certifications and what not.)

In my eyes, this is not a feature, that would be nice to have but this is what
the standard says. One can use 8 to 63 ASCII characters which are used to
calculate 256 bit key or one is allowed to input the full 256 bit key inform of
64 HEX characters. I'vo only seen very few devices/programs that don't allow
HEX input.

AND: Since there is a distinction between ASCII and HEX (8-63/64) the input
field doesn't even need a checkbox. As I said before, in my opinion it should
be very simple to use HEX, because the algorithm just needs to skip the key
generation and use the value as is when it's 64 characters long. Of course it
should check for a valid HEX number before :-)

I don't see any major issues for UI design, testing, certifications etc.

Comment 7 Kalle Valo 2009-01-04 21:34:38 UTC

(In reply to comment #6)
> In my eyes, this is not a feature, that would be nice to have but this is what
> the standard says.

References please. AFAIK, Wi-Fi Alliance certifications do not test for WPA hex
key, to me that's an implication that the need for the feature is not widely
used.

Sorry to be so difficult here, but I need concrete facts to support this
feature before I will propose it to the product managers.

> AND: Since there is a distinction between ASCII and HEX (8-63/64) the input
> field doesn't even need a checkbox. As I said before, in my opinion it should
> be very simple to use HEX, because the algorithm just needs to skip the key
> generation and use the value as is when it's 64 characters long. Of course it
> should check for a valid HEX number before :-)
> 
> I don't see any major issues for UI design, testing, certifications etc.

I again see potential issues: new code needs to be tested, all the corner cases
need to be considered, regressions are possible etc. Writing code is only a
small part of a software project, unfortunately.

Comment 8 Quim Gil 2009-01-08 17:30:45 UTC

Let's resolve this as WONTFIX considering 

- Kalle's solid argumentation.
- The fact that this old enhancement request hasn't been implemented nor it is
in the current plans.

I leave the moreinfo flag, just in case you want to provide more data to
Comment #7 and eventually reopen. Thank you for your understanding.

Comment 9 Kalle Valo 2009-01-08 22:06:34 UTC

(In reply to comment #8)
> I leave the moreinfo flag, just in case you want to provide more data to
> Comment #7 and eventually reopen.

It would be really nice to know examples of devices where this feature is
supported.

(In reply to comment #9)
> (In reply to comment #8)
> > I leave the moreinfo flag, just in case you want to provide more data to
> > Comment #7 and eventually reopen.
> 
> It would be really nice to know examples of devices where this feature is
> supported.
> 

you mean, apart from Microsoft WINDOWS, TiVo, most wireless routers (especially
the Linksys 3rd parties) ?

Comment 11 Andre Klapper 2009-01-18 00:37:43 UTC

End-user devices. Not operating systems, applications or routers.

Ignoring the question of "What is the difference between a device running
windows and a device running Maemo?" or a router (which is a dedicated device)
or a PocketPC (which runs WindowsCE or WindowsMobile - both of which support
HEX key entry) ...

"devices" I know that allow the use of HEX rather than Passphrases include ...
TiVo
IPod Touch (in fact, with the IPod Touch, you can ONLY use the HEX key)
IPhone
All Windows Mobile PDA Phones (do those count as "devices" ?)

In fact, the only "device" apart from Maemo powered ones that I have used that
_don't_ support HEX entry are:
Asus Netbook (although, that is using a derivative of Xandros, which doesnt
either)
Nokia N95 Phone (and probably other Nokia PDA phones - not common in the US)
Blackberry phones (no big deal, since they have GPRS/3G capabilities anyway)

Like it or not, irrelevent of the ieee, the Practical issue, is that you are
selling a device that is supposed to work with other devices on an 802.11 based
network ... the VAST majority of WiFi devices (and that by definition includes
Windows, MacOSX, routers, and wifi printers) _DO_ support HEX key entry.

You are basically stating that unless a competitor does it first, you aren't
going to ... One has to wonder how the Nokia Internet Tablets came into
existence with that kind of logic ...

The BEST argument I can give for a reason to make this change ... "Because the
customers are asking for it" ... 
http://www.internettablettalk.com/wiki/index.php?title=HOWTO:_WPA-PSK_when_you_only_have_the_64-hexit_PSK%2C_no_passphrase
has been read over 1000 times ...
http://blog.micxer.de/blog/archives/42-How-to-use-your-existing-HEX-key-for-WPA2.html
is another example of the current work-around ...
or, you could try the "because nobody else does" (which is what created the
Internet Tablet) or try the "to work in environments where there is no
passphrase, and never was" or "to work in environments where the originial
passphrase was lost to history, and I'm damned if I'm going to change the PSK
on 3000 laptops ..." (which is the case in my company)

At worst case, what extra programming is involved ... to me it sounds really
simple ...

if PSK=[0-9A-Fa-z]{64} then 
  if authentication as hexkey success
    store hexkey
  else
    convert PSK to hexkey and try authentication
  fi
else
  convert PSK to hexkey and try authentication
fi

Why does that need a massive amount of coding? or testing? if anything, it's
easier, since if the PSK is a hexkey, and it authenticates successfully, you
don't need to calculate the hexkey from the SID and passphrase, and calculating
thousands of HMAC-SHA1 ...

@shley

@

Thanks albrandwood, that's exactly what I'm trying to say the whole time (and
why I wrote the Blog-Entry at blog.micxer.de)!! It's pretty common to have that
feature in a Wi-Fi device and as the small code snippet shows it shouldn't too
much work to implement it.

Comment 14 Aapo Makela 2009-01-21 13:35:40 UTC

Just to document the workaround which SHOULD work (if anyone needs this
urgently):

* From command line, enter:

gconftool-2 --set --type list --list-type int \
/system/osso/connectivity/IAP/<IAP ID>/EAP_wpa_preshared_key \
[<32 bytes specified in the HEX key>]

e.g. 

gconftool-2 --set --type list --list-type int \
/system/osso/connectivity/IAP/6b2522f7-a2fe-4d82-b79d-5ccd7f6ada33/EAP_wpa_preshared_key
\
[89,220,5,49,0,118,204,103,180,85,25,114,37,148,137,214,217,111,228,65,2,54,149,6,45,247,239,26,210,238,247,214]

IAP IDs you can get from GConf with

gconftool-2 --all-dirs /system/osso/connectivity/IAP

and with -R you see the contents of the subdirectories, which somewhat helps to
spot the correct IAP.

Comment 15 Andre Klapper 2009-12-10 12:06:19 UTC

*** Bug 6802 has been marked as a duplicate of this bug. ***

*** Bug 6678 has been marked as a duplicate of this bug. ***

Comment 17 Andre Klapper 2010-05-14 13:36:55 UTC

It looks like this will be fixed for Harmattan (Maemo6/MeeGo).

Sorry - I know this isn't a discussion forum, but is there any chance that I -
or someone else - could get access to the closed-source bit(s) referred to in
other reports about this bug - under NDA of course - so that I/we can fix it
(and provide it in binary form to the others)?

As it stands, I can't connect to any of the networks I use. My N900 is pretty
much a brick. Had I seen this unresolved 3.5 year old bug a week ago, I'd
currently be enjoying a (working) competitor's product. :-)

Comment 19 Andre Klapper 2010-06-02 20:16:16 UTC

(In reply to comment #18)
> could get access to the closed-source bit(s)

Please contact Nokia (and its lawyers I guess).
This bug report is not a good channel for that...

The "solution" can be found here:

http://www.internettablettalk.com/wiki/index.php/HOWTO:_WPA-PSK_when_you_only_have_the_64-hexit_PSK,_no_passphrase

It's not pretty, but it does work ...

(Or at least, it did with my N810 ...)

@

Comment 21 Andre Klapper 2012-03-24 11:47:02 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )