Using WEP 128-bit Passphrase, Ad-hoc connection cannot be established

Does anyone even use WEP passpharase mode? Can we just remove this?

No, WEP passphrase does get used... it's much easier to use a passphrase than the hex keys, at least ;)

This bug needs additional information in order to be debuggable. Could you please run 'apport-collect 1032433' and make sure at least WifiSyslog.txt is attached automatically. If not, please include at least an excerpt of /var/log/syslog for an attempted connection.

Thanks in advance!

Hi Mathieu,

I just tried to reproduce the issue, but was unable to. I'll get more information from Kent.

Hi,
I can still reproduce this on 12.04.1
First I setup an Ad-hoc connection with WEP 128-bit Passphrase on Computer1,
and using another computer (ComputerU) as client to connect, but the connection cannot be established, attached file is syslog on ComputerU (client).

And then I create new ad-hoc connection "test2" on computer1 using "WEP 40/128-bit Key(Hex or ASCII)", this time I can use ComputerU (client) to establish an ad-hoc connection successfully.
Attached file is the syslog of this connection.

@James,

I have asked Nara help to provide more information in comment#4 and comment#5

Looks like in both cases wpa-supplicant got past the authentication stage. Oddly, even though it should not work in the second trial, it still gets past authentication.

The problem with the first trial is that it couldn't get a dhcp lease, which makes me think it's a problem on the other machine. Would you please attach a syslog from that machine as well?

@James: please readd rls-q-incoming if you get more directions on the user's machine, and we'll deal with it. Thanks :)

Affects me too.

I was able to reproduce this using my dev laptop and a netbook, both running Precise.

I created the adhoc network on my laptop, then tried and failed to connect using the NetworkManager applet on the netbook.

I then dropped to the command line on the netbook and manually connected using wpa_supplicant. This succeeded.

Next I cranked up the logging on both NetworkManager and wpa_supplicant to prove that NM was feeding in the right keys and so forth. The keys were right, and I noticed in the output that NM thought that connection was successful and launched the DHCP client. However, those DHCP packets never reached my dev laptop (confirmed via syslog).

Now here's the weird part: I attached strace to the NM process and tried to connect via the applet, and it succeeded. Now all subsequent attempts to connect are succeeding. Even creating a new network with a different password, I can no longer reproduce this bug.

Are both machines running Ubuntu, and are they using the same version?

Can you provide the debug logs for wpasupplicant? This would likely shed more light on the problem.

Furthermore, I'd be very interested on output such as what the Android "Wifi Analyzer" app is saying about the created network, if that output is feasible to obtain. It's usually pretty good at saying exactly how the scanned/detected network is configured, and if it was correctly created as WEP-128 with a passphrase rather than using the passphrase as a hex key or something.

Because this does not block certification of systems, we are closing the bug in OEM prio for now.

Reopening the OEM priority bug, as there are some OEMs still requesting this

Test environment:
HP laptop runs ubuntu-12.04.2 as client side
ASUS laptop runs ubuntu-12.04.2 as server side.
Set password 12345 in the server side and then use client to connect the server.

If the security type is set to WEP40/128 bit Key, the result is success ( see adhoc/success/syslog.client.log & adhoc/success/syslog.server.log)
If the type is set to WEP-128 passphrase, the result is failed (see adhoc/fail/syslog.client.log & adhoc/fail/syslog.server.log)

The logs are attached in the tarball.

Franz,

12345 from the "server side" looks like a 40 bit key (8 bits per character, multiplied by 5 characters). This would explain why it's working when you use that option. In order to be completely sure that it's not a 40 bit key, would you please re-create your server environment with a WEP-128 passphrase of something like '123456'? Thank you.

More information here: https://mail.gnome.org/archives/networkmanager-list/2007-December/msg00226.html

@James,

Update log files.
I use '1234567890abc' as wep key, here are the fail logs of client/server both sides.
Note, I aslo tested the key in hex format ( 31323334353637383930616263 ), it failed too. The logs are attached.

Can we get someone to have a look to this bug, please?

Attach logs.

Config WiFi adhoc network and set WEP key to 1234567890abc.
The connection can't be established.

Logs are attached (server/client side dmesg output and syslog)

Attach syslog for client and server side.
The wpa_supplication debug output (-ddd option) is enabled.

The same issue can be reproduced on Trusty (14.04)

The attachment is the syslog on same platform but is installed with trusty.

syslog of comment #21

NM doesn't really ask for the type of key when you get to connecting to the previously-created network. It's however possible to create the connection, and then edit it from the connection editor to set "WEP passphrase" and enter in the passphrase, which will allow the connection to work.

Not sure we'll be able to land a fix for this just now, given how late in the cycle it is. I can however start figuring out how to add the feature properly and submit it for review from the upstream developers.