Re: periodic_update(): Roamed ... - msg#00300
On Tue, 2012-03-20 at 21:16 +0200, Anastas Giokov wrote: On Tue, 2009-04-28 at 09:42 -0700, Howard Chu wrote: Dan Williams wrote: On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. If you already know for a fact that certain drivers are incompatible with NM, it seems you should be documenting that in your release notes or something. Or, you should be maintaining a list of tested known-to-work drivers. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. There must be more cases than this, because there are no other APs for my card to associate to. (They're all secured with WEP or WPA, and I only have credentials for mine.) The only reason I ever see the card reassociate at all is due to NM's scanning; with that patched out it just stays associated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Pretty sure (c) is not the case here, the info from iwlist scan and iwconfig all matches. (b) won't happen in my current environment, so I can't test one way or another. (a) doesn't appear to happen when I look, but I have no idea how many scans are needed before the symptom occurs. You can run NM with: NM_ACTIVE_AP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and get a lot more info about what's happening here and why the active AP isn't found in the scan list. Any chance you can do that and post the results? Dan Since I am having the same problem, with the wl driver, I did the test and found the following in the log: NetworkManager: debug [1332269638.001163] get_active_ap(): (eth1) BSSID: 00:14:bf:09:0b:86 NetworkManager: debug [1332269638.001288] get_active_ap(): (eth1)
Re: periodic_update(): Roamed ... - msg#00300
On Tue, 2009-04-28 at 09:42 -0700, Howard Chu wrote: /Dan Williams wrote:/ / On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote:/ / Dan Williams wrote:/ / On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote:/ / Howard Chu wrote:/ / This is probably more related to the ath9k driver, but I wanted to / / start here/ / in case anyone is familiar with it. I've been seeing this for the past / / couple/ / months, and I just now rebuilt NM fresh from git and it's still / / happening:/ // / I seem to have ruled out the driver; doing a kill -9 on NetworkManager / / so it/ / doesn't have the opportunity to tear down the connection on exit, shows / / that/ / the wifi connection works perfectly once NetworkManager is gone. No/ / disassociation messages in dmesg, no pauses in ssh sessions, etc./ // / Don't rule out the driver. Does the driver always return the currently/ / associated AP in the scan list? If not, you might hit this. And the/ / driver is being stupid, because of *course* the AP you're currently/ / connected to should always be in the scan list, unless you're no longer/ / connected to it./ // / The code in NM grabs the SSID BSSID on a 6 second timer, and tries to/ / find that AP in the scan list. If it can't find it (because the driver/ / didn't return that AP in the scan list) then it reports none./ // / If that's your problem, it's a driver problem./ // / How would I check this? Should it be obvious from iwlist scan ? That / / returns/ / the current AP along with the other visible ones./ // / Also, reviewing the comments in bug 291760, this problem is not just / / isolated/ / to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, / / ipw2100,/ / rtl8187, and b43, across multiple kernel and driver revisions. As such it/ / seems unlikely to be the drivers' fault./ // / Depends; it might show up in that scan, or it might not. If you can/ / reliably get it to show up every time, that's great. But until 2.6.30,/ / mac80211-based drivers would not always return the current AP. And some/ / of the older drivers don't either, though fullmac drivers are more/ / likely to be OK there./ // /If you already know for a fact that certain drivers are incompatible with NM, / /it seems you should be documenting that in your release notes or something. / /Or, you should be maintaining a list of tested known-to-work drivers./ // / There is one window where NM wouldn't be able to find the AP; if NM just/ / did a scan, and then the card reassociates to a different AP that's not/ / in the scan list, and doesn't send an GIWSCAN event so that the AP list/ / gets pulled (ipw2x00 do this, other drivers might not), then when NM/ / goes to pull the BSSID off the card, the scan list doesn't contain the/ / current AP. What NM should be doing here is to request that the/ / supplicant grab the scan list again when it sees a BSSID it doesn't know/ / about, but that's somewhat complicated./ // /There must be more cases than this, because there are no other APs for my / /card / /to associate to. (They're all secured with WEP or WPA, and I only have / /credentials for mine.) The only reason I ever see the card reassociate at all / /is due to NM's scanning; with that patched out it just stays associated./ // / If the driver doesn't return the frequency of the BSSID in the scan/ / results, or that frequency doesn't match what the card reports from/ / SIOCGIWFREQ, then NM also can come up with (none). Check that the/ / information from an 'iwlist scan' for that BSSID matches what 'iwconfig'/ / reports when associated to that specific AP./ // / So in conclusion there are actual driver bugs; (a) not all drivers scan/ / results contain the currently associated AP in every scan, and (b) not/ / all drivers emit scan results events when they associate to a new AP/ / that's not already in the scan list, and finally (c) some drivers are/ / just busted and return wrong channel information./ // /Pretty sure (c) is not the case here, the info from iwlist scan and iwconfig / /all matches. (b) won't happen in my current environment, so I can't test one / /way or another. (a) doesn't appear to happen when I look, but I have no idea / /how many scans are needed before the symptom occurs./ You can run NM with: NM_ACTIVE_AP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and get a lot more info about what's happening here and why the active AP isn't found in the scan list. Any chance you can do that and post the results? Dan Since I am having the same problem, with the wl driver, I did the test and found the following in the log: NetworkManager: debug [1332269638.001163] get_active_ap(): (eth1) BSSID: 00:14:bf:09:0b:86 NetworkManager: debug [1332269638.001288] get_active_ap(): (eth1) SSID: 'Homenet' NetworkManager: debug [1332269638.001325] get_active_ap(): Pass #1 NetworkManager: debug [1332269638.001355] get_active_ap(): AP: 'Homenet' 00:14:bf:09:0b:86 NetworkManager:
Re: periodic_update(): Roamed ...
On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
Dan Williams wrote: On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. If you already know for a fact that certain drivers are incompatible with NM, it seems you should be documenting that in your release notes or something. Or, you should be maintaining a list of tested known-to-work drivers. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. There must be more cases than this, because there are no other APs for my card to associate to. (They're all secured with WEP or WPA, and I only have credentials for mine.) The only reason I ever see the card reassociate at all is due to NM's scanning; with that patched out it just stays associated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Pretty sure (c) is not the case here, the info from iwlist scan and iwconfig all matches. (b) won't happen in my current environment, so I can't test one way or another. (a) doesn't appear to happen when I look, but I have no idea how many scans are needed before the symptom occurs. It seems to me that blaming the driver is not particularly useful unless you can provide a procedure or script to demonstrate the driver bugs. In the meantime, that whole spectrum of drivers is out there and people are trying to use them. And except for whatever NM's undocumented expectations, those cards and drivers work fine. Since only NM causes problems, it's your responsibility to either help identify the problems so the driver writers can fix them, or make NM work despite those problems. E.g., if you know that scans return unreliable information, then *stop relying on the scan results*. Clearly the driver can tell you if it's associated or not. Assuming that the association is gone because the current AP doesn't show up in the current scan list, when you know that scans can be incomplete, is stupid. Likewise, continual scanning seems to be counterproductive. The impact it has on network throughput is significant: 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.57
Re: periodic_update(): Roamed ...
On Tue, 2009-04-28 at 09:42 -0700, Howard Chu wrote: Dan Williams wrote: On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. If you already know for a fact that certain drivers are incompatible with NM, it seems you should be documenting that in your release notes or something. Or, you should be maintaining a list of tested known-to-work drivers. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. There must be more cases than this, because there are no other APs for my card to associate to. (They're all secured with WEP or WPA, and I only have credentials for mine.) The only reason I ever see the card reassociate at all is due to NM's scanning; with that patched out it just stays associated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Pretty sure (c) is not the case here, the info from iwlist scan and iwconfig all matches. (b) won't happen in my current environment, so I can't test one way or another. (a) doesn't appear to happen when I look, but I have no idea how many scans are needed before the symptom occurs. You can run NM with: NM_ACTIVE_AP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and get a lot more info about what's happening here and why the active AP isn't found in the scan list. Any chance you can do that and post the results? Dan It seems to me that blaming the driver is not particularly useful unless you can provide a procedure or script to demonstrate the driver bugs. In the meantime, that whole spectrum of drivers is out there and people are trying to use them. And except for whatever NM's undocumented expectations, those cards and drivers work fine. Since only NM causes problems, it's your responsibility to either help identify the problems so the driver writers can fix them, or make NM work despite those problems. E.g., if you know that scans return unreliable information,
Re: periodic_update(): Roamed ...
Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. Dan Apr 17 15:40:05 violino NetworkManager:info (wlan0): supplicant connection state: group handshake - completed Apr 17 15:40:07 violino NetworkManager:debug [1240008007.001860] periodic_update(): Roamed from BSSID (none) ((none)) to 00:12:17:26:56:10 (HighlandSun) Apr 17 15:40:25 violino NetworkManager:debug [1240008025.003189] periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none) ((none)) Apr 17 15:40:31 violino NetworkManager:debug [1240008031.003983] periodic_update(): Roamed from BSSID (none) ((none)) to 00:12:17:26:56:10 (HighlandSun) Apr 17 15:41:25 violino NetworkManager:debug [1240008085.002651] periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none) ((none)) Apr 17 15:41:31 violino NetworkManager:debug [1240008091.002730] periodic_update(): Roamed from BSSID (none) ((none)) to 00:12:17:26:56:10 (HighlandSun) Apr 17 15:44:25 violino NetworkManager:debug [1240008265.002821] periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none) ((none)) The signal strength is consistently 80% or better, I'm only 10 feet from the AP and have a clear line of sight to the antenna. What is this trying to tell me? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
Alexander Sack wrote: On Mon, Apr 20, 2009 at 03:37:20PM -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. I would think that the driver doesn't like background scanning. This has been reported in launchpad bug 291760 where the initial report mentions that he network manager roames to a none bssid and back, this happens in more or less two minute which coincidentially matches the max scan timeout NM uses (120 seconds). Thanks for the reminder, I had forgotten about that bug report and the last time I had encountered this problem. As I mentioned in January (and forgot) http://mail.gnome.org/archives/networkmanager-list/2009-January/msg00107.html restoring the madwifi hack to NM/src/nm-device-wifi.c makes the problem go away for me. I've posted the patch to the launchpad bug. I.e., reverting this commit: commit 98f392b085985a75274fe02ec8aa92f4ac0d8a80 Author: Dan Williams d...@redhat.com Date: Sat Oct 11 18:32:24 2008 + 2008-10-11 Dan Williams d...@redhat.com * src/nm-device-wifi.c - (can_scan): remove old madwifi hack for not scanning while -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
Alexander Sack wrote: On Mon, Apr 20, 2009 at 06:24:33PM -0700, Howard Chu wrote: Since killing NM prevents the problem from showing up, I don't see how this can be a wpa_supplicant bug. ?? Should I add another comment to the bug report? To verify that its really the scan making your driver behave badly you could do the kill -9 trick you mentioned above and then check whether you can make your network stuck by calling the scan dbus method of wpa supplicant. Probably an iwlist scan would also trigger it while you are in that state. Maybe check that too. I tried iwlist scan but it didn't seem to break anything. It still had a noticeable effect though, as seen by ping: 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.57 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.56 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=4607 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3604 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=2604 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1604 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=604 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.54 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=1.54 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.54 ms Obviously the usual ping time is ~1.5ms; iwlist scan slows that down quite a lot. I didn't see any obvious way to send the right command to wpa_supplicant using dbus so I didn't try that yet. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Apr 17 15:40:05 violino NetworkManager:info (wlan0): supplicant connection state: group handshake - completed Apr 17 15:40:07 violino NetworkManager:debug [1240008007.001860] periodic_update(): Roamed from BSSID (none) ((none)) to 00:12:17:26:56:10 (HighlandSun) Apr 17 15:40:25 violino NetworkManager:debug [1240008025.003189] periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none) ((none)) Apr 17 15:40:31 violino NetworkManager:debug [1240008031.003983] periodic_update(): Roamed from BSSID (none) ((none)) to 00:12:17:26:56:10 (HighlandSun) Apr 17 15:41:25 violino NetworkManager:debug [1240008085.002651] periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none) ((none)) Apr 17 15:41:31 violino NetworkManager:debug [1240008091.002730] periodic_update(): Roamed from BSSID (none) ((none)) to 00:12:17:26:56:10 (HighlandSun) Apr 17 15:44:25 violino NetworkManager:debug [1240008265.002821] periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none) ((none)) The signal strength is consistently 80% or better, I'm only 10 feet from the AP and have a clear line of sight to the antenna. What is this trying to tell me? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
On Mon, Apr 20, 2009 at 03:37:20PM -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. I would think that the driver doesn't like background scanning. This has been reported in launchpad bug 291760 where the initial report mentions that he network manager roames to a none bssid and back, this happens in more or less two minute which coincidentially matches the max scan timeout NM uses (120 seconds). - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
