Ubuntu

softmac and network-manager cite unreconcilable differences

Reported by Matthew Garrett on 2007-04-06
18
Affects Status Importance Assigned to Milestone
linux-source-2.6.20 (Ubuntu)
Critical
Unassigned

Bug Description

Binary package hint: linux-source-2.6.20

Network-manager will often fail to associate with the network when using softmac based drivers (bcm43xx, zd1211rw). It seems that either network-manager or wpa_supplicant fails to notice that the card has associated, and so times out before reporting the connection. Attempting to reselect the network while n-m is waiting for the association generally succeeds. I'll attach logs of unsuccessful and successful attempts to connect to the same network.

Matthew Garrett (mjg59) wrote :
Matthew Garrett (mjg59) wrote :
Matthew Garrett (mjg59) wrote :

Filed against the kernel as it seems to be specific to softmac drivers (can't reproduce with mac80211), and critical as it effectively leaves these drivers useless to a standard user.

Changed in linux-source-2.6.20:
importance: Undecided → Critical
Conn O Griofa (psyke83) wrote :

I'm linking to my bug as a possible duplicate of this: https://bugs.launchpad.net/ubuntu/+source/zd1211/+bug/103366

If you try the "hackwireless" script it will help with connection issues most of the time, but of course it's not a proper fix; maybe it will help developers identify the real issue.

Tim Gardner (timg-tpi) on 2007-04-18
Changed in linux-source-2.6.20:
assignee: nobody → timg-tpi
status: Unconfirmed → In Progress
Tim Gardner (timg-tpi) wrote :

Please try this update:

cd /lib/modules/2.6.20-15-generic/kernel/net/ieee80211/softmac
sudo cp ieee80211softmac.ko ieee80211softmac.ko.old
sudo wget -O ieee80211softmac.ko http://people.ubuntu.com/~rtg/ieee80211softmac.ko-2.6.20-15.27

Either reboot or remove/insert your softmac based wireless driver using modprobe.

Conn O Griofa (psyke83) wrote :

Tim,

I tried your updated module (after depmod -a and a reboot to be safe), but the problem remains. I applied the update to my desktop using a zd1211 card, and on first boot it seemed to log in to the network successfully. I tried connecting and reconnecting to the same network manually and it worked (in fairness though, it did that before), but then it stopped associating successfully at all, just as before.

On my laptop, using the same card from the desktop, it failed to associate to the network at first boot at all, and had difficulty connecting reliably when trying to manually connect. I'm attaching dmesg output and daemon.log (I don't know where is best to get network-manager/wpa_supplicant logs, let me know if you need more).

My network ESSID is 43OGR, and Network Manager is configured to connect via WPA2-PSK/Auto(AES), and my router is a DI524 configured to accept WPA/WPA2-PSK connections. In Windows it always associates correctly, and in Linux there's no problems using the built-in wireless of my laptop (ipw2100).

Conn O Griofa (psyke83) wrote :

Here's dmesg.log, I forgot to mention: these logs are from a fresh boot after network-manager gives up trying to associate/connect to the network (it remained on two grey spheres).

Tim Gardner (timg-tpi) wrote :

conn: There is likely more then one problem, though the observable symptoms appear similar. Matthew's logs show that the wpa_supplicant/SoftMAC driver combination would not always go 'State: ASSOCIATING -> ASSOCIATED'. Your log shows that the EAP handshake is failing once in awhile, which is after association has completed.

Does wpa_supplicant ever get into a state where it never completes the EAP handshake?

Conn O Griofa (psyke83) wrote :

Tim,

I'm seeing if I can find evidence of EAP handshake fails (although to be honest I'm not sure what I'm looking for), but let me point out that in the file daemon.log I posted earlier, it logged previous connection attempts via the ipw2100-based internal card (which associate fine), and afterwards some attempts to manually connect (using nm-applet, unchecking and checking "Enable wireless" repeatedly to make it associate). I assume that the final part of that log is the "clean", uninterrupted connection attempt (in which I didn't interfere with the connection process) - sorry if that caused confusion.

The ipw2100 driver shouldn't have been causing interference, as I disabled the radio and blacklisted ipw2100 before testing.

Conn O Griofa (psyke83) wrote :

Tim,

Thanks for your patience, I'm uploading a "clean" log from the moment I insert the zd1211rw module, until the moment nm-applet fails the connection attempt with no interference from myself. No green spheres ever appeared. Disregard the previous log as it was polluted due to my fiddling with nm-applet.

In this new log, there is no successful association ("ASSOCIATING -> ASSOCIATED")*, so I assume that we're still dealing with the original issue as posted by Matthew.

*Fiddling with "Enable wireless" in nm-applet still lets it connect most of the time, which is probably why you saw successful associations in the bad log earlier.

Tim Gardner (timg-tpi) wrote :

Conn:

You can trim or clean your log before testing by:

sudo echo > /var/log/syslog

Then make the a connection attempt with the zd1211rw. Attach /var/log/syslog after you are satisfied that its not working properly. That way I won't have to differentiate between wireless cards.

Conn O Griofa (psyke83) wrote :

Thanks for the guidance Tim.

Note that the internal ipw2100-based card's radio is disabled and the module blacklisted, it shouldn't be interfering.

root@inspiron:~/softmacbug# rmmod zd1211rw
root@inspiron:~/softmacbug# echo > /var/log/syslog
root@inspiron:~/softmacbug# modprobe zd1211rw

I've attached the resulting output after nm-applet gives up the connection attempt (again, no green spheres appeared).

Tim Gardner (timg-tpi) wrote :

Conn: This is still different then Matthew's log. In your case the kernel driver is actively failing the association attempt: "WEXT: Custom wireless event: 'associating failed'", whereas Mathew's report indicates the driver never sent an association event, success or otherwise. Make really sure you don't have a configuration problem by going back to a simple open authentication scheme, then work forward from there. In the meantime I'll see if I can get my hands on one of these zd1211rw adapters.

Conn O Griofa (psyke83) wrote :

Tim,

I've created some new logs for you to check:

1. syslog_none_success.log: Router wireless security set to none - successfully connected.

2. syslog_open128wep_fail.log: Router wireless security set to WEP 128 bit, Open Authentication - failed to connect, and caused system to become unresponsive after timeout. Keyboard became unresponsive (e.g. caps lock light did not toggle), but screen and mouse remained working; however, trying to open any new applications resulted in no activity, and I could not type into the shell due to the keyboard being dead. Disconnecting the zd1211 usb device didn't help, had to hard reboot.

2a. syslog_iwconfig_open128wep_success.log: Router security same as 2) - successfully connected. Disabled networking in nm-applet, then invoked: "sudo iwconfig eth1 essid 43OGR key s:*************; sudo dhclient eth1". IP renewed address successfully with no delay, and connection worked fine.

3. syslog_wpapsktkip_fail.log: Router wireless security set to WPA/WPA2-PSK (allows TKIP or CCMP for either) - failed to connect. Chose WPA-PSK/TKIP in nm-applet's key prompt, and connection timed out with no green spheres appearing.

I hope these logs with your troubleshooting efforts, and if you need anything else, please let me know. Thanks again!

Conn O Griofa (psyke83) wrote :
Conn O Griofa (psyke83) wrote :
Tim Gardner (timg-tpi) wrote :

Conn - I'm positive the problems you are seeing with the zd1211rw are WPA related, which is not the original problem report. I'm marking this one fixed since it worked well with open authentication. Wireless support is currently getting serious attention, so the zd1211rw problems may get solved between now and the next release.

Tim Gardner (timg-tpi) on 2007-04-20
Changed in linux-source-2.6.20:
status: In Progress → Fix Committed
Tim Gardner (timg-tpi) wrote :

Fix will appear in in first Feisty update.

Changed in linux-source-2.6.20:
assignee: timg-tpi → ubuntu-kernel-team
status: Fix Committed → Fix Released

What exactly do you mean by first Feisty Update? Don't updates happen all
of the time?.... through Update Manager checking daily?

Thanx!

zeddock

On 4/23/07, Tim Gardner <email address hidden> wrote:
>
> Fix will appear in in first Feisty update.
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Assignee: Tim Gardner => Ubuntu Kernel Team
> Status: Fix Committed => Fix Released
> Target: later => ubuntu-7.04
>
> --
> softmac and network-manager cite unreconcilable differences
> https://bugs.launchpad.net/bugs/103768
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Conn O Griofa (psyke83) wrote :

zeddock,

Fixes aren't released daily, despite the frequency in which update-manager checks for them. I assume this fix will be released in the next kernel update, and the developers may wait to include other fixes with it, otherwise it's a big waste of bandwidth for everyone running Feisty.

zeddock (zeddock) wrote :

OK. Thanx for the attempted explanation. What would be my most prudent steps
to make sure I am aware of potential fixes?

TIA,

Zeddock

On 4/25/07, Conn <email address hidden> wrote:
>
> zeddock,
>
> Fixes aren't released daily, despite the frequency in which update-
> manager checks for them. I assume this fix will be released in the next
> kernel update, and the developers may wait to include other fixes with
> it, otherwise it's a big waste of bandwidth for everyone running Feisty.
>
> --
> softmac and network-manager cite unreconcilable differences
> https://bugs.launchpad.net/bugs/103768
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers