IWN performance very bad with 10.0-RC5

Asked by 7 months ago
Since upgrading my system to 10.0-RC# and now 10.0-RC5, by wireless performance has severely degraded. iwn0 [ at ] pci0:3:0:0: class=0x028000 card=0x13118086 chip=0x00858086 rev=0x34 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6205 [Taylor Peak]' class = network Throughput is down sharply for TCP file transfers (sftp) between it and a local, wired system. Under 9.2-STABLE I was getting about 23 Mbps. With 10.0-rc5, I get about 11M. Testing also shows occasional, short circuit drops, under half a second each. Once in a while under 10.0-rc3 I would see the link drop and stay down. restarting the interface (service netif restart restart) would restore the link. I just upgraded to 10.0-rc5 this afternoon and have not seen the hang to this point, but this only happened every couple of days. I just noticed that the interface is running '11g' and not 'n'. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether a0:88:b4:c6:ad:28 inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g status: associated ssid babcom channel 6 (2437 MHz 11g) bssid 00:26:b8:67:c3:2d country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 15 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL Any idea of the problem or what information I could provide?

Your Answer

Name:
Reply:

All Answers

Answer by 7 months ago
Hi, On Fri, 10 Jan 2014 21:02:36 -0800 it seems that I have the same hardware and the same problem. While a device using run can connect to my access point without problems, iwn is not able to connect anymore. But, it connected earlier without any problems to other access points. iwn never hangs in my case, it is simply not able to connect. Successfully initialized wpa_supplicant wlan0: Trying to associate with 90:61:0c:13:36:fe (SSID='Sumarni' freq=2437 MHz) wlan0: Associated with 90:61:0c:13:36:fe wlan0: CTRL-EVENT-DISCONNECTED bssid=90:61:0c:13:36:fe reason=0 wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Some Name" auth_failures=1 duration=10 With the same configuration, run0 connects without problems. How could I help to fix this problem? Erich
Answer by 7 months ago
Hi, diff the drivers between 9.x and 10.x; not much has changed. Try running the 9.x sys/dev/iwn in 10.x, and make sure you use the 9.x firmware. see if that fixes it. -a
Answer by 7 months ago
Quoted message by Erich Dollansky 7 months ago
Hi, On Fri, 10 Jan 2014 21:02:36 -0800 it seems that I have the same hardware and the same problem. While a device using run can connect to my access point without problems, iwn is not able to connect anymore. But, it connected earlier without any problems to other access points. iwn never hangs in my case, it is simply not able to connect. Successfully initialized wpa_supplicant wlan0: Trying to associate with 90:61:0c:13:36:fe (SSID='Sumarni' freq=2437 MHz) wlan0: Associated with 90:61:0c:13:36:fe wlan0: CTRL-EVENT-DISCONNECTED bssid=90:61:0c:13:36:fe reason=0 wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Some Name" auth_failures=1 duration=10 With the same configuration, run0 connects without problems. How could I help to fix this problem? Erich
Hi, On Fri, 10 Jan 2014 21:24:46 -0800 it was working on 10 until at least summer/fall of last year. I can't recall the precise date as I moved to cable by change. As it always worked outside, I never bothered to test. I will try to get the sources for 9. Erich
Answer by 7 months ago
Quoted message by Adrian Chadd 7 months ago
Hi, diff the drivers between 9.x and 10.x; not much has changed. Try running the 9.x sys/dev/iwn in 10.x, and make sure you use the 9.x firmware. see if that fixes it. -a
Hi, Please help dig up which change broke it. Even just test out the head iwn code from 6 months ago. Adrian On Jan 11, 2014 12:36 AM, "Erich Dollansky" erichsfreebsdlist [ at ] alogt.com wrote:
Answer by 7 months ago
Quoted message by Erich Dollansky 7 months ago
Hi, On Fri, 10 Jan 2014 21:24:46 -0800 it was working on 10 until at least summer/fall of last year. I can't recall the precise date as I moved to cable by change. As it always worked outside, I never bothered to test. I will try to get the sources for 9. Erich
Hi, On Fri, 10 Jan 2014 21:45:59 -0800 I will try. One other question. Where do I find the firmware? Erich
Answer by 7 months ago
Quoted message by Adrian Chadd 7 months ago
Hi, Please help dig up which change broke it. Even just test out the head iwn code from 6 months ago. Adrian On Jan 11, 2014 12:36 AM, "Erich Dollansky" erichsfreebsdlist [ at ] alogt.com wrote:
The iwnfw module. It has paths into share for the firmware images. On Jan 11, 2014 3:48 AM, "Erich Dollansky" erichsfreebsdlist [ at ] alogt.com wrote:
Answer by 7 months ago
Quoted message by Erich Dollansky 7 months ago
Hi, On Fri, 10 Jan 2014 21:24:46 -0800 it was working on 10 until at least summer/fall of last year. I can't recall the precise date as I moved to cable by change. As it always worked outside, I never bothered to test. I will try to get the sources for 9. Erich
Hi, On Fri, 10 Jan 2014 21:45:59 -0800 I came to a very strange result. I have iwn in the kernel since June 2012 using 10. I also have had run in the kernel of another machine since February 2011. I could not even add runfw to the kernel those days running some 8 stable. I kept it that way until now. run was always working. iwn gave problems starting between August and November of last year on my access point but still worked on other places. I used iwn to connect successfully to another wireless network mid November 2013. After adding the firmware to the kernel for both iwn and run, I could compile the kernel and iwn started to work. runfw did not break compilation. I wonder now if the iwn or run could even work without firmware or if the firmware was automatically loaded even when iwn or run where compiled into the kernel. Erich
Answer by 7 months ago
Quoted message by Adrian Chadd 7 months ago
Hi, Please help dig up which change broke it. Even just test out the head iwn code from 6 months ago. Adrian On Jan 11, 2014 12:36 AM, "Erich Dollansky" erichsfreebsdlist [ at ] alogt.com wrote:
On Sat, Jan 11, 2014 at 10:36 PM, Erich Dollansky < Some things look odd here. I had been running with crypto debug for about 15 hours when I captured the attached log. The things tha looks odd to me are two series of "AES-CCM replay detected" errors. Jan 12 00:54:03 rogue kernel: wlan0: [00:26:b8:67:c3:2d] AES-CCM replay detected tid 16 <rsc 1165, csc 1207, keyix 2 rxkeyix 65535> [rsc inc. by one 41 times until rsc = csc] Jan 12 00:54:03 rogue kernel: wlan0: [00:26:b8:67:c3:2d] AES-CCM replay detected tid 16 <rsc 1206, csc 1207, keyix 2 rxkeyix 65535> One VERY odd thing is the MAC address. It is one byte from being the address of my Verizon/ActionTec wireless router. It is the only device on my network that has an OID of 00:26:b8, but the last nibble is 28 while these errors claim a MAC ending in 2d. The setkey statements with a MAC of FF:FF:FF:FF:FF:FF also look odd to be, but I am pretty clueless about the meaning of most of the message, do it might be fine, but looks strange. During this time I have not had the network completely hang and require an interface restart. Does this provide anything useful?
Answer by 7 months ago
Quoted message by Erich Dollansky 7 months ago
Hi, On Fri, 10 Jan 2014 21:45:59 -0800 I came to a very strange result. I have iwn in the kernel since June 2012 using 10. I also have had run in the kernel of another machine since February 2011. I could not even add runfw to the kernel those days running some 8 stable. I kept it that way until now. run was always working. iwn gave problems starting between August and November of last year on my access point but still worked on other places. I used iwn to connect successfully to another wireless network mid November 2013. After adding the firmware to the kernel for both iwn and run, I could compile the kernel and iwn started to work. runfw did not break compilation. I wonder now if the iwn or run could even work without firmware or if the firmware was automatically loaded even when iwn or run where compiled into the kernel. Erich
Hi, Yup. Is this when things started getting strange? Were they okay before the replay detection kicked in? -a
Answer by 7 months ago
Quoted message by Adrian Chadd 7 months ago
Hi, Please help dig up which change broke it. Even just test out the head iwn code from 6 months ago. Adrian On Jan 11, 2014 12:36 AM, "Erich Dollansky" erichsfreebsdlist [ at ] alogt.com wrote:
This issue was solved by gonzo in r252064. run(4) requires a firmware to function. The firmware is automatically loaded if and only if you compile runfw(4) as module and run(4) compiled into the kernel. Kevin
Answer by 7 months ago
Quoted message by Kevin Oberman 7 months ago
On Sat, Jan 11, 2014 at 10:36 PM, Erich Dollansky < Some things look odd here. I had been running with crypto debug for about 15 hours when I captured the attached log. The things tha looks odd to me are two series of "AES-CCM replay detected" errors. Jan 12 00:54:03 rogue kernel: wlan0: [00:26:b8:67:c3:2d] AES-CCM replay detected tid 16 <rsc 1165, csc 1207, keyix 2 rxkeyix 65535> [rsc inc. by one 41 times until rsc = csc] Jan 12 00:54:03 rogue kernel: wlan0: [00:26:b8:67:c3:2d] AES-CCM replay detected tid 16 <rsc 1206, csc 1207, keyix 2 rxkeyix 65535> One VERY odd thing is the MAC address. It is one byte from being the address of my Verizon/ActionTec wireless router. It is the only device on my network that has an OID of 00:26:b8, but the last nibble is 28 while these errors claim a MAC ending in 2d. The setkey statements with a MAC of FF:FF:FF:FF:FF:FF also look odd to be, but I am pretty clueless about the meaning of most of the message, do it might be fine, but looks strange. During this time I have not had the network completely hang and require an interface restart. Does this provide anything useful?
Sorry, It's been a little busy the past couple of days. No, I have had only one interface losing association and not recovering since my first report. That one did not occur in conjunction with one of the crypto events. Those seem to interrupt the network for about half a second.Then it restores. Those issues still seem to crop up periodically, about twice a day. I suspect that they me be linked to volumeof network traffic , butI cannot be sure at this point. Here is the log during the failure yesterday: Jan 14 23:13:27 rogue kernel: wlan0: _ieee80211_crypto_delkey: AES-CCM keyix 0 flags 0x133 rsc 0 tsc 379793 len 16 Jan 14 23:13:27 rogue kernel: wlan0: link state changed to DOWN Jan 14 23:13:27 rogue wpa_supplicant[2669]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:26:b8:67:c3:2d reason=0 Jan 14 23:13:27 rogue kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Jan 14 23:13:27 rogue kernel: wlan0: _ieee80211_crypto_delkey: AES-CCM keyix 1 flags 0x136 rsc 411 tsc 0 len 16 Jan 14 23:13:27 rogue kernel: wlan0: _ieee80211_crypto_delkey: AES-CCM keyix 2 flags 0x136 rsc 3344 tsc 0 len 16 Jan 14 23:13:27 rogue kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Jan 14 23:13:29 rogue ntpd[1291]: sendto(199.7.177.206) (fd=25): Network is down Jan 14 23:14:22 rogue dhclient[2755]: My address (192.168.1.5) was deleted, dhclient exiting Jan 14 23:14:22 rogue wpa_supplicant[2669]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jan 14 23:14:22 rogue wpa_supplicant[2669]: wlan0: CTRL-EVENT-TERMINATING Jan 14 23:14:23 rogue wpa_supplicant[3162]: Successfully initialized wpa_supplicant Jan 14 23:14:23 rogue kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Jan 14 23:14:23 rogue kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Jan 14 23:14:23 rogue last message repeated 3 times Jan 14 23:14:24 rogue wpa_supplicant[3163]: wlan0: Trying to associate with 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) Jan 14 23:14:24 rogue wpa_supplicant[3163]: wlan0: Associated with 00:26:b8:67:c3:2d Jan 14 23:14:24 rogue kernel: wlan0: link state changed to UP Jan 14 23:14:24 rogue devd: Executing '/etc/rc.d/dhclient quietstart wlan0' Jan 14 23:14:24 rogue wpa_supplicant[3163]: wlan0: WPA: Key negotiation completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] Jan 14 23:14:24 rogue kernel: wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 65535 Jan 14 23:14:24 rogue kernel: wlan0: ieee80211_crypto_newkey: no h/w support for cipher AES-CCM, falling back to s/w Jan 14 23:14:24 rogue kernel: wlan0: ieee80211_crypto_setkey: AES-CCM keyix 0 flags 0x133 mac 00:26:b8:67:c3:2d rsc 0 tsc 0 len 16 Jan 14 23:14:24 rogue kernel: wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x6 keyix 1 Jan 14 23:14:24 rogue kernel: wlan0: ieee80211_crypto_newkey: no h/w support for cipher AES-CCM, falling back to s/w Jan 14 23:14:24 rogue kernel: wlan0: ieee80211_crypto_setkey: AES-CCM keyix 1 flags 0x136 mac ff:ff:ff:ff:ff:ff rsc 454 tsc 0 len 16 Jan 14 23:14:24 rogue wpa_supplicant[3163]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] Jan 14 23:14:24 rogue dhclient: New IP Address (wlan0): 192.168.1.5 Jan 14 23:14:24 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 Jan 14 23:14:24 rogue dhclient: New Broadcast Address (wlan0): 192.168.1.255 Jan 14 23:14:24 rogue dhclient: New Routers (wlan0): 192.168.1.1 I have found a problem with my AP configuration that was the cause of the performance issue, so that is not related to FreeBSD and is now fixed. Thanks, Kevin
Answer by 7 months ago
Quoted message by Adrian Chadd 7 months ago
Hi, Yup. Is this when things started getting strange? Were they okay before the replay detection kicked in? -a
Hi, So does it still pause with traffic? Have you disabled bgscan? -a
Answer by 7 months ago
Quoted message by Adrian Chadd 7 months ago
Hi, Yup. Is this when things started getting strange? Were they okay before the replay detection kicked in? -a
Yes, it does. Just did so. After the issues I had in the past with bgscan, I should have done it already. I'll know by tomorrow whether it made a difference. Kevin