Re: Doesn't reconnect to wifi after resuming from suspend
On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote: > On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 fritz > box). > > With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) > > When automatically reconnecting to 5GHz after resume half of the time the > connection fails and retries indefinitely. It seems to fail more when moving > the laptop to another location in house while it sleeps (so the list of > visible networks actually changes). > > When this happens it is almost impossible to reconnect manually. > > (what works sometimes is disconnecting the connection that is building, > disable the wifi, enable again, wait a bit then manually connect to the > other (2.4GHz) AP) > > Strangely: disabling autoconnect on resume and then manually connecting > always works. > > Other strange thing: Another machine (NUC with intel wifi and same kubuntu > 14.10) always works. > > To me, it seems to be some interference between rescanning and connecting. > > I have no idea what is the difference in the state machine when > autoconnecting vs. manual. > > I've provided log's on bugzilla > https://bugzilla.gnome.org/show_bug.cgi?id=726121 I updated the bug with some thoughts after looking at the logs. It looks to me like the issues are exclusively driver and/or supplicant problems. In the failed automatic log, the access point and the device don't agree on state, so the access point rejects the device. That starts a reconnect attempt which then apparently fails at the driver level because the AP never responds to teh driver's association attempts. Later on, the supplicant enters the scanning state but has to time that out because the driver never notifies the supplicant that the scan has finished. Even later, the supplicant screws up by trying to associate with 00:00:00:00:00:00 and then it simply falls over. One thing you could do is try to set up a resume-time script that just does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your issues; if so then it's usually an indication of driver bugs. Given that iwlwifi works fine on the machine, I think the issues are specific to the ath9k driver, and not the mac80211 stack (which iwlwifi also uses). Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager 1.2 planning process
Hi, DanW, thaller, jklimes, lrintel and I have gone through a big list of things we need to work on, things we'd like to work on, thinks we'd love to have but may not have time to work on, etc, and put it all up here. It's not set in stone but a starting point for the 1.2 cycle: https://wiki.gnome.org/Projects/NetworkManager/12FeaturesPlanning If anyone has suggestions, questions, wants things clarified, things they would like to claim or work on, lets start that discussion here. What do you think? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Add WPS information parsing in foreach_property_cb
Yes, I really need some instructions to decrease the time for understanding the behavior between NM and wpa_supplicant. In my plan, I will try to add the easiest scenario first: i. press the pbc on AP ii. NM trigger scan to know the AP is ready for WPS via PBC method iii. NM trigger the wpa_supplicant to start the PBC action vi. the connection between STA(NM) and AP is constructed With the WPS patch in the first email, I believe that if the user trigger a scan in NM after the pbc of an AP is pressed, NM will know there is an AP ready for WPS. But in iii), I don't know when the user select an AP to connect on the nm-applet, where is the corresponding function call in NM. I am trying to figure out the flow of triggering the wpa_supplicant to connect to the selected AP from NM. BTW, I think I must modify network-manager-applet for testing WPS, but I also met some problems while building network-manager-applet. I already built and installed NetworkManage 1.1.0 obtained from git master branch. When I want to build network-manager-applet, some errors shows as below. I found that these function prototypes in NetworkManager were controlled by "NM_AVAILABLE_IN_0_9_10" But the version of NM I installed was 1.1.0, it's even newer than 0.9.10, I don't know why these errors occurred. " make[4]: Entering directory `/home/awkjiang/temp/network-manager-applet/src' CCLD nm-applet nm_applet-applet.o: In function `get_device_class': /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined reference to `nm_device_team_get_type' nm_applet-applet.o: In function `applet_find_active_connection_for_device': /home/awkjiang/temp/network-manager-applet/src/applet.c:1420: undefined reference to `nm_active_connection_get_vpn' nm_applet-applet.o: In function `get_device_class': /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined reference to `nm_device_team_get_type' /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined reference to `nm_device_team_get_type' /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined reference to `nm_device_team_get_type' /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined reference to `nm_device_team_get_type' /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined reference to `nm_device_team_get_type' nm_applet-applet.o:/home/awkjiang/temp/network-manager-applet/src/applet.c:280: more undefined references to `nm_device_team_get_type' follow nm_applet-applet-dialogs.o: In function `info_dialog_add_page_for_vpn': /home/awkjiang/temp/network-manager-applet/src/applet-dialogs.c:854: undefined reference to `nm_active_connection_get_ip4_config' /home/awkjiang/temp/network-manager-applet/src/applet-dialogs.c:870: undefined reference to `nm_active_connection_get_ip6_config' nm_applet-applet-device-vlan.o: In function `find_device_by_mac': /home/awkjiang/temp/network-manager-applet/src/applet-device-vlan.c:65: undefined reference to `nm_utils_hwaddr_ntoa_len' collect2: error: ld returned 1 exit status make[4]: *** [nm-applet] Error 1 make[4]: Leaving directory `/home/awkjiang/temp/network-manager-applet/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/awkjiang/temp/network-manager-applet/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/awkjiang/temp/network-manager-applet/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/awkjiang/temp/network-manager-applet' make: *** [all] Error 2 " > On Tue, Jan 27, 2015 at 11:43 PM, Dan Williams wrote: >> On Sun, 2015-01-25 at 21:36 +0800, Awk Jiang wrote: >>> Hi all, >>> >>> I start working on adding WPS function into NM. At the beginning, I >>> add the WPS information during foreach_property_cb as the patch. >>> >>> Because I am foreign to contribute code in community, please feel free >>> to give me any suggestion. Thanks. >> >> This looks good, thanks! Do you need/want some pointers on where to go >> from here? >> >> Dan >> ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
LACP Active Mode
Greetings, Is it possible for Network Manager to become the active aggregator in an 802.3ad link? I am attempting to enable LACP between a host machine and an HP Procurve switch that only appears to work as the passive end of an aggregate. My system contains the following pertinent bits: kernel-3.18.3-201.fc21.x86_64 NetworkManager-0.9.10.1-1.4.20150115git.fc21.x86_64 iputils-20140519-4.fc21.x86_64 -- Dan Mossor, RHCSA Systems Engineer at Large Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
Dan Williams wrote: > On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote: >> On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 >> fritz box). >> >> With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) >> >> When automatically reconnecting to 5GHz after resume half of the time the >> connection fails and retries indefinitely. It seems to fail more when >> moving the laptop to another location in house while it sleeps (so the >> list of visible networks actually changes). >> >> When this happens it is almost impossible to reconnect manually. >> >> (what works sometimes is disconnecting the connection that is building, >> disable the wifi, enable again, wait a bit then manually connect to the >> other (2.4GHz) AP) >> >> Strangely: disabling autoconnect on resume and then manually connecting >> always works. >> >> Other strange thing: Another machine (NUC with intel wifi and same >> kubuntu 14.10) always works. >> >> To me, it seems to be some interference between rescanning and >> connecting. >> >> I have no idea what is the difference in the state machine when >> autoconnecting vs. manual. >> >> I've provided log's on bugzilla >> https://bugzilla.gnome.org/show_bug.cgi?id=726121 > > I updated the bug with some thoughts after looking at the logs. It > looks to me like the issues are exclusively driver and/or supplicant > problems. In the failed automatic log, the access point and the device > don't agree on state, so the access point rejects the device. That > starts a reconnect attempt which then apparently fails at the driver > level because the AP never responds to teh driver's association > attempts. Later on, the supplicant enters the scanning state but has to > time that out because the driver never notifies the supplicant that the > scan has finished. Even later, the supplicant screws up by trying to > associate with 00:00:00:00:00:00 and then it simply falls over. > > One thing you could do is try to set up a resume-time script that just > does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your > issues; if so then it's usually an indication of driver bugs. Given > that iwlwifi works fine on the machine, I think the issues are specific > to the ath9k driver, and not the mac80211 stack (which iwlwifi also > uses). > > Dan Thanks Dan, Yes I already tried al that before reporting the bug. That's what some report (google) worked for them. First I thought it worked for me too. But alas, after these wakeup scripts automaically reconnect works sometimes, sometimes not, same as now, I agree it must have something to do with the driver, as the Intel always works. AND the same network manager (in Kubuntu 14.04) worked well, while in 14.10 not. To me it seems in 14.04 it also connected faster, so fast that when I opened the lid and passed the screen saver password I would be already connected (< 3 sec). OTOH NM state machine seems to get confused and does not recover. While when manually connect it always works. So it seems the code path on autoreconnect is different, or there is a bug in the state machine that only pops up immediately after resume. But you have a point: could it be the ath9k never notifies that the scan is ready? Would that be after a certain kernel? But I used 14.04 with kernel 3.17 (no problem) and 14.10 with 3.17 (and now 3.18) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
On 05.02.2015 20:12, Ferry Toth wrote: > Would that be after a certain kernel? But I used 14.04 with kernel 3.17 (no > problem) and 14.10 with 3.17 (and now 3.18) > See if it can help https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
poma wrote: > On 05.02.2015 20:12, Ferry Toth wrote: > >> Would that be after a certain kernel? But I used 14.04 with kernel 3.17 >> (no problem) and 14.10 with 3.17 (and now 3.18) >> > > See if it can help > https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs Thanks by I don't find my case there. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
Dan Williams wrote: > On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote: >> On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 >> fritz box). >> >> With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) >> >> When automatically reconnecting to 5GHz after resume half of the time the >> connection fails and retries indefinitely. It seems to fail more when >> moving the laptop to another location in house while it sleeps (so the >> list of visible networks actually changes). >> >> When this happens it is almost impossible to reconnect manually. >> >> (what works sometimes is disconnecting the connection that is building, >> disable the wifi, enable again, wait a bit then manually connect to the >> other (2.4GHz) AP) >> >> Strangely: disabling autoconnect on resume and then manually connecting >> always works. >> >> Other strange thing: Another machine (NUC with intel wifi and same >> kubuntu 14.10) always works. >> >> To me, it seems to be some interference between rescanning and >> connecting. >> >> I have no idea what is the difference in the state machine when >> autoconnecting vs. manual. >> >> I've provided log's on bugzilla >> https://bugzilla.gnome.org/show_bug.cgi?id=726121 > > I updated the bug with some thoughts after looking at the logs. It > looks to me like the issues are exclusively driver and/or supplicant > problems. In the failed automatic log, the access point and the device > don't agree on state, so the access point rejects the device. That > starts a reconnect attempt which then apparently fails at the driver > level because the AP never responds to teh driver's association > attempts. Later on, the supplicant enters the scanning state but has to > time that out because the driver never notifies the supplicant that the > scan has finished. Even later, the supplicant screws up by trying to > associate with 00:00:00:00:00:00 and then it simply falls over. > > One thing you could do is try to set up a resume-time script that just > does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your > issues; if so then it's usually an indication of driver bugs. Given > that iwlwifi works fine on the machine, I think the issues are specific > to the ath9k driver, and not the mac80211 stack (which iwlwifi also > uses). > > Dan I did a quick test: 1 - close the lid (suspend) 2 - open the lid (resume) 3 - login as quickly as possible (< 2sec) 4 - manually connect the wifi (<1sec) The connection then fails the same as with auto reconnect. So it looks as if the autoreconnect fails because it starts too early after resume. Might it be that it starts connecting too early because it thinks the scan is completed although it really is not? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Add WPS information parsing in foreach_property_cb
On Thu, 2015-02-05 at 22:36 +0800, Sheng-Jhih Jiang wrote: hi, > BTW, I think I must modify network-manager-applet for testing WPS, but > I also met some problems while building network-manager-applet. WPS should be added to NetworkManager (core daemon) first. It's not really necessary to add anything to nm-applet (client) at that point. > I already built and installed NetworkManage 1.1.0 obtained from git > master branch. > When I want to build network-manager-applet, some errors shows as below. > I found that these function prototypes in NetworkManager were > controlled by "NM_AVAILABLE_IN_0_9_10" > But the version of NM I installed was 1.1.0, it's even newer than > 0.9.10, I don't know why these errors occurred. "NM_AVAILABLE_IN_0_9_10" affects compilation (not linking). So, compilation works for you correctly. > " > make[4]: Entering directory `/home/awkjiang/temp/network-manager-applet/src' > CCLD nm-applet > nm_applet-applet.o: In function `get_device_class': > /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined > reference to `nm_device_team_get_type' > nm_applet-applet.o: In function `applet_find_active_connection_for_device': > /home/awkjiang/temp/network-manage these are linker errors. Apparently you try to link against an older version of libnm-util. Make sure, you link to the same version as the include headers. For example, try setting the search path for pkgconfig export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig" Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
On 05.02.2015 22:00, Ferry Toth wrote: > poma wrote: > >> On 05.02.2015 20:12, Ferry Toth wrote: >> >>> Would that be after a certain kernel? But I used 14.04 with kernel 3.17 >>> (no problem) and 14.10 with 3.17 (and now 3.18) >>> >> >> See if it can help >> https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs > > Thanks by I don't find my case there. > /etc/systemd/system/ath9k-reload.service [Unit] Description=Reload Atheros 802.11n wireless LAN cards driver After=hibernate.target suspend.target hybrid-sleep.target [Service] Type=oneshot ExecStart=/usr/sbin/modprobe -r ath9k ExecStart=/usr/sbin/modprobe ath9k [Install] WantedBy=hibernate.target suspend.target hybrid-sleep.target # systemctl enable ath9k-reload.service # systemctl suspend & RESUME # systemctl hibernate & THAW # systemctl hybrid-sleep & RESUME||THAW Does it work? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Add WPS information parsing in foreach_property_cb
hi, >WPS should be added to NetworkManager (core daemon) first. It's not >really necessary to add anything to nm-applet (client) at that point. Without the help of nm-applet to test the WPS flow, how can I confirm the WPS functionality in NM is correct? >these are linker errors. Apparently you try to link against an older >version of libnm-util. Make sure, you link to the same version as the >include headers. Thanks. I will check this. BTW, could you give me some instructions for problems belows In my plan, I will try to add the easiest scenario first: i. press the pbc on AP ii. NM trigger scan to know the AP is ready for WPS via PBC method iii. NM trigger the wpa_supplicant to start the PBC action vi. the connection between STA(NM) and AP is constructed With the WPS patch in the first email, I believe that if the user trigger a scan in NM after the pbc of an AP is pressed, NM will know there is an AP ready for WPS. But in iii), I don't know when the user select an AP to connect on the nm-applet, where is the corresponding function call in NM. I am trying to figure out the flow of triggering the wpa_supplicant to connect to the selected AP from NM. On Fri, Feb 6, 2015 at 5:56 AM, Thomas Haller wrote: > On Thu, 2015-02-05 at 22:36 +0800, Sheng-Jhih Jiang wrote: > > hi, > > >> BTW, I think I must modify network-manager-applet for testing WPS, but >> I also met some problems while building network-manager-applet. > > WPS should be added to NetworkManager (core daemon) first. It's not > really necessary to add anything to nm-applet (client) at that point. > > >> I already built and installed NetworkManage 1.1.0 obtained from git >> master branch. >> When I want to build network-manager-applet, some errors shows as below. >> I found that these function prototypes in NetworkManager were >> controlled by "NM_AVAILABLE_IN_0_9_10" >> But the version of NM I installed was 1.1.0, it's even newer than >> 0.9.10, I don't know why these errors occurred. > > "NM_AVAILABLE_IN_0_9_10" affects compilation (not linking). So, > compilation works for you correctly. > > >> " >> make[4]: Entering directory `/home/awkjiang/temp/network-manager-applet/src' >> CCLD nm-applet >> nm_applet-applet.o: In function `get_device_class': >> /home/awkjiang/temp/network-manager-applet/src/applet.c:280: undefined >> reference to `nm_device_team_get_type' >> nm_applet-applet.o: In function `applet_find_active_connection_for_device': >> /home/awkjiang/temp/network-manage > > these are linker errors. Apparently you try to link against an older > version of libnm-util. Make sure, you link to the same version as the > include headers. > > For example, try setting the search path for pkgconfig > > export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig" > > > > Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
