Bug#382314: [pkg-wpa-devel] Bug#382314: Need to scramble wpa-psk? Apparently yes, but not obvious

[Kel Modderman]

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.