Bug 243585
| Summary: | knetworkmanager hangs at 28% using bcm43xx driver | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Hackmeyer <cbhackmeyer> | ||||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 7 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 0.6.6 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-04-22 18:59:13 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Chris Hackmeyer
2007-06-10 08:16:57 UTC
Created attachment 156662 [details]
dmesg after several attempts to connect using interface wlan0 (the Broadcom card) and knetworkmanager
can you try using the nm-applet application? I suspect this is NetworkManager related and not knetworkmanager related. knetworkmanager is just the client side. Right - I'll try that later today and let you know how it goes. You were right. I tried nm-applet and got exactly the same result. I'll go ahead and change the component to NetworkManager. I've played around with this a bit more after having some trouble with the bcm43xx_mac80211 driver itself after a recent kernel update. After getting the driver working again, I'm still having the same problem with NetworkManager. Looking through /var/log/messages, I found that it is apparently failing while trying to associate with the router. This is odd, since the interface still associates just fine with the router as long as it is configured manually with ifconfig, iwconfig, dhclient, etc., and in fact I am sending this using the manually configured interface right now. You should be able to see where it fails (and then where I succeed in connecting manually) near the end of /var/log/messages, which I'll attach. Created attachment 157724 [details] /var/log/messages My most recent failed attempt at connecting with knetworkmanager starts at Jun 24 16:20:24. Note that it fails at 16:20:45, saying that association took >20s. Then, near the very end of the file, you can see where I use iwconfig to manually set the essid and use dhclient to get an ip address, which worked fine. This bug is a duplicate of bugs 242338, 242585, 243097, 243487, 244529, and 245084. It' obviously a problem for many users. The fix posted on fedora-list by John W. Linville here: https://www.redhat.com/archives/fedora-list/2007-June/msg01009.html doesn't work (at least for me, and, I suspect, for many others). Please pay attention to this bug. I think it's a NetworkManager problem. Actually, after more experimentation with using different firmware versions, I have discovered that my problem may have more to do with the driver than I originally thought. Briefly, I had installed ndiswrapper a while back and apparently it had written an 'alias wlan0 ndiswrapper' or something along those lines to /etc/modprobe.d/ndiswrapper, so evidently ndiswrapper was loading without my knowledge each time I did ifconfig wlan0 up, hence my success getting the card to work only from the command line. Stupid me... Interestingly, even after verifying that the ndiswrapper module has been removed, and then loading bcm43xx_mac80211, I can still associate with the router (sort of, at least from the command line), but dhclient wlan0 just sits there and times out, so I can't get an IP address. I'm not sure why this happens, but I've noticed two things that may be relevant. First of all, when I load the bcm43xx_mac80211 module, the following line comes up in /var/log/messages: localhost kernel: bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=36, tgt=120). Disabling TX power adjustment . I have also noticed this appearing on startup. Perhaps more significantly, I get this in /var/log/messages as soon as I issue the dhclient wlan0 command: localhost dhclient: wmaster0: unknown hardware address type 801 I suspect that this is significant because it is dhclient that doesn't work when using the native driver, and this line appears ONLY when using that driver. If I use ndiswrapper, it doesn't appear, and I can get an IP address. One other item that is perhaps significant (although I have always had this problem with the bcm43xx family of drivers) is that iwconfig wlan0 gives nonsensical readings for the signal strength (like Link Quality = 211/146). I really think the problem has something to do with the "unknown hardware address type 801" message, though. I just don't know enough about how the kernel handles wireless devices to make sense of that message. I wonder if anyone else who is having similar problems has observed this... So what do you think Mr. Aillon? Is this still possibly a NetworkManager issue, or does it need to be reassigned yet again? Actually, after more experimentation with using different firmware versions, I have discovered that my problem may have more to do with the driver than I originally thought. Briefly, I had installed ndiswrapper a while back and apparently it had written an 'alias wlan0 ndiswrapper' or something along those lines to /etc/modprobe.d/ndiswrapper, so evidently ndiswrapper was loading without my knowledge each time I did ifconfig wlan0 up, hence my success getting the card to work only from the command line. Stupid me... Interestingly, even after verifying that the ndiswrapper module has been removed, and then loading bcm43xx_mac80211, I can still associate with the router (sort of, at least from the command line), but dhclient wlan0 just sits there and times out, so I can't get an IP address. I'm not sure why this happens, but I've noticed two things that may be relevant. First of all, when I load the bcm43xx_mac80211 module, the following line comes up in /var/log/messages: localhost kernel: bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=36, tgt=120). Disabling TX power adjustment . I have also noticed this appearing on startup. Perhaps more significantly, I get this in /var/log/messages as soon as I issue the dhclient wlan0 command: localhost dhclient: wmaster0: unknown hardware address type 801 I suspect that this is significant because it is dhclient that doesn't work when using the native driver, and this line appears ONLY when using that driver. If I use ndiswrapper, it doesn't appear, and I can get an IP address. One other item that is perhaps significant (although I have always had this problem with the bcm43xx family of drivers) is that iwconfig wlan0 gives nonsensical readings for the signal strength (like Link Quality = 211/146). I really think the problem has something to do with the "unknown hardware address type 801" message, though. I just don't know enough about how the kernel handles wireless devices to make sense of that message. I wonder if anyone else who is having similar problems has observed this... So what do you think Mr. Aillon? Is this still possibly a NetworkManager issue, or does it need to be reassigned yet again? The issues described in this bug report seem to have basically been resolved by the latest kernel update as of 07-20-2007. I'm still having some issues with the driver, but they are not related to this bug. So as far as I'm concerned, case closed. closing per comment #10 |