Bug#382314: [pkg-wpa-devel] Bug#382314: Need to scramble wpa-psk? Apparently yes, but not obvious
Hi Eduard,
On Thursday 10 August 2006 18:46, Eduard Bloch wrote:
Package: wpasupplicant
Version: 0.5.4-5
Severity: normal
Hello,
I was using previous versions of wpasupplicant (before ifupdown
integration) with a self-made conf file containing a preshared key.
Relevant contents:
eapol_version=1
ap_scan=1
fast_reauth=1
network={
ssid=secret
psk=longsecret
# long ascii psk copied from the windows client
priority=5
}
That worked fine, wpa_supplicant was started manually and I had no
complaints. But then came the ifupdownisation, I tried to follow
README.Debian.gz and README.modes.gz and it still did not work. There
was no usefull debug information in the logs either (as usual, sorry :-( ).
Just the usual game link, few lost pakets, link lost, multiple times.
It was not obvious to me what was wrong. I integrated the values from
the mentioned config file with wpa- prefixes in the interfaces file.
Then I decided to play with the tools mentioned in README.modes.gz, I
used wpa_passphrase, passed my essid and the old psk to it and it threw
me some new key inside of a config section. When I added this new key
as wpa-psk in the interfaces file, it worked.
Your key is a plaintext passphrase; did you wrap it in quotes like:
wpa-psk passphrase
or use the special wpa-passphrase option:
wpa-passphrase passphrase
or did you do:
wpa-psk passphrase
?
Honestly, WTF? What is the difference? Manpage of wpa_passphrase does
not explain ANYTHING (like where and why I need to generate this key).
It displays a config section which differs from my old one... why? The
old one works when the config is supplied with -c configfile, why does
the same passphrase not work as wpa-psk variable?
I can only ASSUME that the programers decided to switch from a plaintext
pass phrase to a scrambled form. But in this case, DOCUMENT THE CHANGE
ON VISIBLE PLACES. Sorry, that's the minimum requirement for
user-friendlines.
Please advise how we can help improve user friendliness without using
provocative language. However, I can understand your frustration, I once had
similar experiences with this very piece of software (and its lack of user
friendliness).
I will do, to the best of my ability, what is required to enhance the
user-friendliness quality of wpasupplicant, but first the problem areas need
to be clearly identified. What specifically is required to satisfy your
experiences with wpasupplicant?
Are you frustrated at our ifupdown.sh program and documentation? Or the
upstream documentation? Or both?
Would you like us to better explain the purpose/advantage of generating a
hexadecimal psk in our documentation? Would you like us to discuss this with
upstream and make sure the upstream manpage/docs are more clear about why
wpa_passphrase is useful?
Here is an extract from README.modes that attempts to explain the assumptions
that our ifupdown.sh script makes:
quote
Notes About Managed Mode
...
The wpasupplicant ifupdown script makes assumptions about the 'type' of input
that is valid for each option. For example, it assumes that some input is
plaintext and wraps quotation marks around the input before passing it on
to wpa_cli, which then adds the input to the network block being formed via
the wpa_supplicant ctrl_interface socket. This can be a point of confusion,
and
something that has tricked more than a few people in the past. For example:
# Invalid, wpa-ssid expects unquoted plaintext ssid's only
# If you need to use a hexadecimal ssid, please supply a
# wpa_supplicant.conf, and use the 'wpa-conf' option.
wpa-ssid hostpot12345678
# Valid, unquoted plaintext string
wpa-ssid hostpot12345678
# Invalid, wpa-psk expects hexadecimal strings only
wpa-psk plaintextpassword
# NOTE: wpa-psk will accept a plaintext string enclosed in quotation
# marks this is equivalent to the 'wpa-passphrase' option
wpa-psk plaintextpassword
# Invalid, wpa-passphrase accepts only plaintext strings, as it
# automatically quotes the input
wpa-passphrase invalidinput
# Valid, unquoted plaintext string
wpa-passphrase validinput
/quote
Do we make poor assumptions? Are our assumptions not clear enough to
understand?
Thanks, Kel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382314: [pkg-wpa-devel] Bug#382314: Need to scramble wpa-psk? Apparently yes, but not obvious
#include hallo.h * Kel Modderman [Sat, Aug 12 2006, 07:39:31PM]: Hi Eduard, Then I decided to play with the tools mentioned in README.modes.gz, I used wpa_passphrase, passed my essid and the old psk to it and it threw me some new key inside of a config section. When I added this new key as wpa-psk in the interfaces file, it worked. Your key is a plaintext passphrase; did you wrap it in quotes like: wpa-psk passphrase I have not used quotes since there we nothing but ascii letters/numbers. And even then, README.notes explcitely says without quotes. or use the special wpa-passphrase option: wpa-passphrase passphrase Oh, yes, that is the option I needed in fact. Why have I not discovered it before? Simply because the first example in README.notes does not contain it and the difference is not obvious. I guess this is not obvious from your point of view, but you know all the details but a NEW USER does not. So, I suggest that wpasupplicant warns if the psk does not look like a hexadezimal string! This is a simple method to catch such cases. And that an error message appears, aka becomes _visible_ in the output, saying what happened, something like: PSK KEY CHECK FAILED (psk with non-hexadecimal chars, confused with passhrase?) CIPHER NEGOTIATION FAILED (missing cipher driver) And at least Debian's documentation clearly distinguishes between the key and the key (err, psk used for psk mode vs. passphrase). I can only ASSUME that the programers decided to switch from a plaintext pass phrase to a scrambled form. But in this case, DOCUMENT THE CHANGE ON VISIBLE PLACES. Sorry, that's the minimum requirement for user-friendlines. Please advise how we can help improve user friendliness without using provocative language. However, I can understand your frustration, I once had similar experiences with this very piece of software (and its lack of user friendliness). Okay, see my attached patch for Debian docs. In addition, I have the suggestion for upstream to print clearly visible error messages with advices for users instead of hidding them somewhere in the debug logs which you can get with -d only and which you need to filter with your mind from different internal log noise. And I suggest to change the manpage of wpa_passphrase: | wpa_passphrase - Set WPA passphrase for a SSID Wrong. It does not set anything. It just generates a config snippet AFAICS. Better: generates WPA-PSK configuration for a SSID/passphrase pair. To OVERVIEW, add an explanation sentense: The passphrase and SSID are scrambled to generate a hexadezimal representation of the preshared key. I will do, to the best of my ability, what is required to enhance the user-friendliness quality of wpasupplicant, but first the problem areas need to be clearly identified. What specifically is required to satisfy your experiences with wpasupplicant? Are you frustrated at our ifupdown.sh program and documentation? Or the upstream documentation? Or both? Well, both. Your documentation is good, but a bit hard to overview. See below. About upstream docs, it is not user-friendly. Look at the manpage of wpa_supplicant. There is a quick-start chapter, but how long do you need to actually find that quick-start chapter? I would do following changes (no idea whether you or upstream would like to do that)... wpa_supplicant: OVERVIEW. Three screens, far too long. Full of technical details that only few users need to know in that depth. Hard to extract the information that you need for initial configuration. I would move the chapter to the bottom and rename it to TECHNICAL OVERVIEW. Or maybe moved to wpa_background manpage. For a normal setup, I would begin with an OVERVIEW chapter with just few sentenses: | wpa_supplicant is a helper application used to establish secure | connection trough wireless interfaces using an encryption mechanism | known as WPA (a variant of IEEE 802.1X standard). wpa_supplicant | supports various WPA modes: the simple mode with a preshared key (aka | WPA-PSK or WPA-Personal), WPA with user authentication (EAP, see | TECHNICAL OVERVIEW for details). | | From application view, wpa_supplicant is a background daemon, watching | the state of an interface and communicating with the peer about WPA | related issues. | | Several WiFi drivers on Linux and BSD do support WPA encryption: hostap, | hermes, madwifi, atmel, wext (generic, recommended), ndiswrapper, | broadcom, ipw, wired, bsd (generic, recommended), ndis. See SUPPORTED | DRIVERS below for detailed explanation. SUPPORTED FEATURES. Three screens listing every submode. Do I want to read all that (unless I have trouble?)? Not really. The ones who care will find that information either way. I would move the chapter to bottom, together with TECHNICAL OVERVIEW. AVAILABLE DRIVERS and SUPPORTED DRIVERS - merge those chapters and move the result to somewhere below COMMAND LINE OPTIONS. There is duplicated information.
Bug#382314: [pkg-wpa-devel] Bug#382314: Need to scramble wpa-psk? Apparently yes, but not obvious
On Saturday 12 August 2006 22:40, Eduard Bloch wrote: #include hallo.h * Kel Modderman [Sat, Aug 12 2006, 07:39:31PM]: Hi Eduard, Then I decided to play with the tools mentioned in README.modes.gz, I used wpa_passphrase, passed my essid and the old psk to it and it threw me some new key inside of a config section. When I added this new key as wpa-psk in the interfaces file, it worked. Your key is a plaintext passphrase; did you wrap it in quotes like: wpa-psk passphrase I have not used quotes since there we nothing but ascii letters/numbers. And even then, README.notes explcitely says without quotes. or use the special wpa-passphrase option: wpa-passphrase passphrase Oh, yes, that is the option I needed in fact. Why have I not discovered it before? Simply because the first example in README.notes does not contain it and the difference is not obvious. I guess this is not obvious from your point of view, but you know all the details but a NEW USER does not. Yes, I agree. Thanks for reading the doc and providing such feedback. It will be improved now, according to your recommendations (as a result of your frustration ;-). And of course you are right, I _do_ know the internals, and I _completely_ rely on the feedback of NEW users, such as yourself, to improve the docs. So, I suggest that wpasupplicant warns if the psk does not look like a hexadezimal string! This is a simple method to catch such cases. And that an error message appears, aka becomes _visible_ in the output, saying what happened, something like: PSK KEY CHECK FAILED (psk with non-hexadecimal chars, confused with passhrase?) CIPHER NEGOTIATION FAILED (missing cipher driver) Ok, will look into it. Sorting hex strings from plaintext is not totally trivial, but string lengths can provide a good indication of what to expect in terms of input. String lengths should be checked for regardless of this exact problem in any case . . . And at least Debian's documentation clearly distinguishes between the key and the key (err, psk used for psk mode vs. passphrase). Okay, if the current attempt to explain the pitfalls did not catch you, then it can be improved. I can only ASSUME that the programers decided to switch from a plaintext pass phrase to a scrambled form. But in this case, DOCUMENT THE CHANGE ON VISIBLE PLACES. Sorry, that's the minimum requirement for user-friendlines. Please advise how we can help improve user friendliness without using provocative language. However, I can understand your frustration, I once had similar experiences with this very piece of software (and its lack of user friendliness). Okay, see my attached patch for Debian docs. Yep, simple and mergable diff, thanks. In addition, I have the suggestion for upstream to print clearly visible error messages with advices for users instead of hidding them somewhere in the debug logs which you can get with -d only and which you need to filter with your mind from different internal log noise. And I suggest to change the manpage of wpa_passphrase: | wpa_passphrase - Set WPA passphrase for a SSID Wrong. It does not set anything. It just generates a config snippet AFAICS. Better: generates WPA-PSK configuration for a SSID/passphrase pair. To OVERVIEW, add an explanation sentense: The passphrase and SSID are scrambled to generate a hexadezimal representation of the preshared key. Okay, I'll queue that in my trivial patches for upstream list. I will do, to the best of my ability, what is required to enhance the user-friendliness quality of wpasupplicant, but first the problem areas need to be clearly identified. What specifically is required to satisfy your experiences with wpasupplicant? Are you frustrated at our ifupdown.sh program and documentation? Or the upstream documentation? Or both? Well, both. Your documentation is good, but a bit hard to overview. See below. About upstream docs, it is not user-friendly. Look at the manpage of wpa_supplicant. There is a quick-start chapter, but how long do you need to actually find that quick-start chapter? I would do following changes (no idea whether you or upstream would like to do that)... wpa_supplicant: OVERVIEW. Three screens, far too long. Full of technical details that only few users need to know in that depth. Hard to extract the information that you need for initial configuration. I would move the chapter to the bottom and rename it to TECHNICAL OVERVIEW. Or maybe moved to wpa_background manpage. For a normal setup, I would begin with an OVERVIEW chapter with just few sentenses: | wpa_supplicant is a helper application used to establish secure | connection trough wireless interfaces using an encryption mechanism | known as WPA (a variant of IEEE 802.1X standard). wpa_supplicant | supports various WPA modes: the simple mode with a preshared key (aka | WPA-PSK or WPA-Personal), WPA
Bug#382314: Need to scramble wpa-psk? Apparently yes, but not obvious
Package: wpasupplicant
Version: 0.5.4-5
Severity: normal
Hello,
I was using previous versions of wpasupplicant (before ifupdown
integration) with a self-made conf file containing a preshared key.
Relevant contents:
eapol_version=1
ap_scan=1
fast_reauth=1
network={
ssid=secret
psk=longsecret
# long ascii psk copied from the windows client
priority=5
}
That worked fine, wpa_supplicant was started manually and I had no
complaints. But then came the ifupdownisation, I tried to follow
README.Debian.gz and README.modes.gz and it still did not work. There
was no usefull debug information in the logs either (as usual, sorry :-( ).
Just the usual game link, few lost pakets, link lost, multiple times.
It was not obvious to me what was wrong. I integrated the values from
the mentioned config file with wpa- prefixes in the interfaces file.
Then I decided to play with the tools mentioned in README.modes.gz, I
used wpa_passphrase, passed my essid and the old psk to it and it threw
me some new key inside of a config section. When I added this new key
as wpa-psk in the interfaces file, it worked.
Honestly, WTF? What is the difference? Manpage of wpa_passphrase does
not explain ANYTHING (like where and why I need to generate this key).
It displays a config section which differs from my old one... why? The
old one works when the config is supplied with -c configfile, why does
the same passphrase not work as wpa-psk variable?
I can only ASSUME that the programers decided to switch from a plaintext
pass phrase to a scrambled form. But in this case, DOCUMENT THE CHANGE
ON VISIBLE PLACES. Sorry, that's the minimum requirement for
user-friendlines.
And if I am wrong with this assumption then there is a bug,
wpa_supplicant does not buy the same psk as in the config file specified
with -c.
Eduard.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages wpasupplicant depends on:
ii libc6 2.3.6-18 GNU C Library: Shared libraries
ii libncurses5 5.5-2 Shared libraries for terminal hand
ii libreadline5 5.1-7 GNU readline and history libraries
ii libssl0.9.8 0.9.8b-2 SSL shared libraries
Versions of packages wpasupplicant recommends:
pn dhcp3-client none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
