Finished: CALL FOR TESTERS Intel wireless 5100/5300 iwn(4) driver for FreeBSD

bschmidt · Jan 23, 2010

If possible try do reproduce it which some debug information, .e.g # wlandebug 0xffffffff. Also post some information about your configuration.

I've seen APs kicking idle clients, might be related.

eMxyzptlk · Jan 24, 2010

Does this driver work on 8-RELEASE or is it only 9-CURRENT?

I am running 8-RELEASE and I can't make it..

http://freebsd.pastebin.com/f5b8a8db2

bschmidt · Jan 24, 2010

eMxyzptlk said:
Does this driver work on 8-RELEASE or is it only 9-CURRENT?

I am running 8-RELEASE and I can't make it..

http://freebsd.pastebin.com/f5b8a8db2

It works with 8.0-RELEASE. Did you use the same build commands as in this post?

eMxyzptlk · Jan 24, 2010

bschmidt said:
It works with 8.0-RELEASE. Did you use the same build commands as in this post?

Yes this is what I did exactly, I am using a custom kernel with just some additions (without iwn)

here's the kernel config http://freebsd.pastebin.com/d6c4c191e

bschmidt · Jan 24, 2010

Try replacing sys/modules/iwn/Makefile with

Code:

# $FreeBSD: head/sys/modules/iwn/Makefile 179215 2008-05-22 21:53:15Z sam $

.PATH:  ${.CURDIR}/../../dev/iwn

CFLAGS+=-I${.CURDIR}/../../
KMOD    = if_iwn
SRCS    = if_iwn.c device_if.h bus_if.h pci_if.h

.include <bsd.kmod.mk>

eMxyzptlk · Jan 24, 2010

This worked for me, addning CFLAGS in the Makefile..

Thanks

LesJen · Jan 25, 2010

bschmidt said:
If possible try do reproduce it which some debug information, .e.g # wlandebug 0xffffffff. Also post some information about your configuration.

I've seen APs kicking idle clients, might be related.

This is what I got!

Code:

wlandebug 0xffffffff
net.wlan.0.debug: 0x0 => 0xffffffff<11n,debug,dumppkts,crypto,input,xrate,elemid,node,assoc,auth,scan,output,state,power,hwmp,dot1xsm,radius,raddump,mesh,wpa,acl,wme,
superg,doth,inact,roam,rate,action,wds,ioctl,tdma>

Code:

/etc/rc.d/netif restart
wpa_supplicant not running? (check /var/run/wpa_supplicant/wlan0.pid).
ifconfig: interface wlan0 does not exist
Stopping Network: lo0 em0 iwn0 fwe0 fwip0 vboxnet0 wlan0 pflog0.
lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
	inet6 ::1 prefixlen 128 

iwn0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 2290
	ether 00:16:ea:61:01:e8
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier

ifconfig: interface wlan0 does not exist
pflog0: flags=100<PROMISC> metric 0 mtu 33152
Starting wpa_supplicant.
Starting Network: lo0 em0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 0xff000000

LesJen · Jan 25, 2010

I don't know if this is useful for you! It's from the daily security output.

I've done /etc/rc.d/netif restart a few times today. It brings up the interface after it stops working, usually after around two hours.

Code:

+wlan0: received beacon from 00:21:91:02:e9:13 rssi 71
+wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
+wlan0: received beacon from 00:21:91:02:e9:13 rssi 70
+wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
+wlan0: received beacon from 00:21:91:02:e9:13 rssi 67
+wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
+wlan0: ieee80211_vap_detach: STA parent iwn0
+ifa_del_loopback_route: deletion failed
+ifa_del_loopback_route: deletion failed
+wlan0: stop running, 1 vaps running
+wlan0: ieee80211_new_state_locked: RUN -> INIT (nrunning 0 nscanning 0)
+wlan0: ieee80211_newstate_cb: RUN -> INIT arg -1
+wlan0: sta_newstate: RUN -> INIT (-1)
+wlan0: ieee80211_ref_node (ieee80211_send_mgmt:1876) 0xffffff800087e000<00:21:91:02:e9:13> refcnt 3
+wlan0: [00:21:91:02:e9:13] send station disassociate (reason 8)
+[00:21:91:02:e9:13] send disassoc on channel 1
+wlan0: _ieee80211_crypto_delkey: TKIP keyix 0 flags 0x1f3 rsc 0 tsc 43898 len 16
+wlan0: [00:21:91:02:e9:13] bss node leave
+wlan0: node_reclaim: remove 0xffffff800087e000<00:21:91:02:e9:13> from station table, refcnt 1
+wlan0: ieee80211_alloc_node 0xffffff80006ca000<00:16:ea:61:01:e8> in station table
+wlan0: [00:16:ea:61:01:e8] ieee80211_alloc_node: inact_reload 2
+wlan0: ieee80211_scan_flush
+wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0
+wlan0: _ieee80211_crypto_delkey: TKIP keyix 1 flags 0x1f6 rsc 0 tsc 1 len 16
+wlan0: _ieee80211_crypto_delkey: TKIP keyix 2 flags 0x1f6 rsc 59 tsc 1 len 16
+wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0
+wlan0: node_reclaim: remove 0xffffff80006ca000<00:16:ea:61:01:e8> from station table, refcnt 1
+wlan0: Ethernet address: 00:16:ea:61:01:e8
+ifa_del_loopback_route: deletion failed
+ifa_del_loopback_route: deletion failed
+wlan0: Ethernet address: 00:16:ea:61:01:e8

bschmidt · Jan 25, 2010

Those messages do help, though, the ones you posted are a bit too late. Before running
# /etc/rc.d/netif restart
next time, do
# grep wlan0 /var/log/message | tail -n 100
and post that.

It will hopefully contain the reason for the issue.

On a side note, are you sure it is related to r33? What was the last revision without the issue? If you could verify that it does not happend with lets say r30, that would help a lot. You could get the exact revision with
# svn co [url]http://svn.techwires.net/svn/projects/freebsd[/url] -r30
and use the usual build commands.

LesJen · Jan 25, 2010

Here's the output you asked for!

I'll try revert to -r30 tomorrow.

Code:

Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 69
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 70
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 71
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 71
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 70
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 70
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:56:59 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:56:59 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 73
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 72
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 71
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 70
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 kernel: wlan0: received beacon from 00:21:91:02:e9:13 rssi 67
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] discard WME information element, too short, len 7
Jan 25 15:57:00 dhclient[1542]: receive_packet failed on wlan0: Device not configured
Jan 25 15:57:00 kernel: wlan0: ieee80211_vap_detach: STA parent iwn0
Jan 25 15:57:00 dhclient[1542]: ioctl(SIOCGIFFLAGS) on wlan0: Operation not permitted
Jan 25 15:57:00 dhclient[1542]: Interface wlan0 no longer appears valid.
Jan 25 15:57:00 kernel: wlan0: stop running, 1 vaps running
Jan 25 15:57:00 kernel: wlan0: ieee80211_new_state_locked: RUN -> INIT (nrunning 0 nscanning 0)
Jan 25 15:57:00 kernel: wlan0: ieee80211_newstate_cb: RUN -> INIT arg -1
Jan 25 15:57:00 kernel: wlan0: sta_newstate: RUN -> INIT (-1)
Jan 25 15:57:00 kernel: wlan0: ieee80211_ref_node (ieee80211_send_mgmt:1876) 0xffffff800087e000<00:21:91:02:e9:13> refcnt 3
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] send station disassociate (reason 8)
Jan 25 15:57:00 kernel: wlan0: _ieee80211_crypto_delkey: TKIP keyix 0 flags 0x1f3 rsc 0 tsc 43898 len 16
Jan 25 15:57:00 kernel: wlan0: [00:21:91:02:e9:13] bss node leave
Jan 25 15:57:00 kernel: wlan0: node_reclaim: remove 0xffffff800087e000<00:21:91:02:e9:13> from station table, refcnt 1
Jan 25 15:57:00 kernel: wlan0: ieee80211_alloc_node 0xffffff80006ca000<00:16:ea:61:01:e8> in station table
Jan 25 15:57:00 kernel: wlan0: [00:16:ea:61:01:e8] ieee80211_alloc_node: inact_reload 2
Jan 25 15:57:00 kernel: wlan0: ieee80211_scan_flush
Jan 25 15:57:00 kernel: wlan0: link state changed to DOWN
Jan 25 15:57:00 kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0
Jan 25 15:57:00 kernel: wlan0: _ieee80211_crypto_delkey: TKIP keyix 1 flags 0x1f6 rsc 0 tsc 1 len 16
Jan 25 15:57:00 kernel: wlan0: _ieee80211_crypto_delkey: TKIP keyix 2 flags 0x1f6 rsc 59 tsc 1 len 16
Jan 25 15:57:00 kernel: wlan0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0
Jan 25 15:57:00 kernel: wlan0: node_reclaim: remove 0xffffff80006ca000<00:16:ea:61:01:e8> from station table, refcnt 1
Jan 25 15:57:01 kernel: wlan0: Ethernet address: 00:16:ea:61:01:e8
Jan 25 15:57:01 wpa_supplicant[4171]: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
Jan 25 15:57:23 kernel: wlan0: link state changed to UP
Jan 25 15:57:28 dhclient: New IP Address (wlan0): 172.17.0.140
Jan 25 15:57:28 dhclient: New Subnet Mask (wlan0): 255.255.255.0
Jan 25 15:57:28 dhclient: New Broadcast Address (wlan0): 172.17.0.255
Jan 25 15:57:28 dhclient: New Routers (wlan0): 172.17.0.1
Jan 25 17:46:41 dhclient[4436]: receive_packet failed on wlan0: Device not configured
Jan 25 17:46:41 kernel: wlan0: link state changed to DOWN
Jan 25 17:46:41 dhclient[4436]: ioctl(SIOCGIFFLAGS) on wlan0: Operation not permitted
Jan 25 17:46:41 dhclient[4436]: Interface wlan0 no longer appears valid.
Jan 25 17:46:41 kernel: wlan0: Ethernet address: 00:16:ea:61:01:e8
Jan 25 17:46:41 wpa_supplicant[5367]: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
Jan 25 17:46:50 kernel: wlan0: link state changed to UP
Jan 25 17:46:57 dhclient: New IP Address (wlan0): 172.17.0.140
Jan 25 17:46:57 dhclient: New Subnet Mask (wlan0): 255.255.255.0
Jan 25 17:46:57 dhclient: New Broadcast Address (wlan0): 172.17.0.255
Jan 25 17:46:57 dhclient: New Routers (wlan0): 172.17.0.1
Jan 25 19:45:24 kernel: wlan0: link state changed to DOWN
Jan 25 19:45:24 dhclient[5632]: receive_packet failed on wlan0: Device not configured
Jan 25 19:45:24 dhclient[5632]: ioctl(SIOCGIFFLAGS) on wlan0: Operation not permitted
Jan 25 19:45:24 dhclient[5632]: Interface wlan0 no longer appears valid.
Jan 25 19:45:24 kernel: wlan0: Ethernet address: 00:16:ea:61:01:e8
Jan 25 19:45:24 wpa_supplicant[10526]: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
Jan 25 19:45:40 kernel: wlan0: link state changed to UP
Jan 25 19:45:45 dhclient: New IP Address (wlan0): 172.17.0.140
Jan 25 19:45:45 dhclient: New Subnet Mask (wlan0): 255.255.255.0
Jan 25 19:45:45 dhclient: New Broadcast Address (wlan0): 172.17.0.255
Jan 25 19:45:45 dhclient: New Routers (wlan0): 172.17.0.1
Jan 25 20:51:54 kernel: wlan0: Ethernet address: 00:16:ea:61:01:e8
Jan 25 20:51:54 kernel: wlan0: link state changed to UP
Jan 25 20:51:54 dhclient: New IP Address (wlan0): 172.17.0.140
Jan 25 20:51:54 dhclient: New Subnet Mask (wlan0): 255.255.255.0
Jan 25 20:51:54 dhclient: New Broadcast Address (wlan0): 172.17.0.255
Jan 25 20:51:54 dhclient: New Routers (wlan0): 172.17.0.1
Jan 25 21:39:24 kernel: wlan0: Ethernet address: 00:16:ea:61:01:e8
Jan 25 21:39:31 kernel: wlan0: link state changed to UP
Jan 25 21:39:35 dhclient: New IP Address (wlan0): 172.17.0.140
Jan 25 21:39:35 dhclient: New Subnet Mask (wlan0): 255.255.255.0
Jan 25 21:39:35 dhclient: New Broadcast Address (wlan0): 172.17.0.255
Jan 25 21:39:35 dhclient: New Routers (wlan0): 172.17.0.1

LesJen · Jan 26, 2010

Version -r30 does the same after about two hours.

Do you want me to try another version?

bschmidt · Jan 27, 2010

Hmm, the log indicates that the connection is still available. Can you do # tcpdump -ni wlan0 as soon as the connection fails? Start a ping or something, it will show you whether there is even an attempt to send packets.

If packets are transmitted, or at least tcpdump says that, # sysctl dev.iwn.0.debug=1 should print tx_done messages. If those are missing, there's definitively a driver issue.

LesJen · Jan 27, 2010

I can ping my printer but not my router! I did tcpdump, but I'm not sure how to handle the second command. I tried, if it's wrong please tell me how to.

Code:

 tcpdump -ni wlan0 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
21:30:02.038918 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 0, length 64
21:30:03.042543 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 1, length 64
21:30:04.044708 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 2, length 64
21:30:05.047747 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 3, length 64
21:30:06.051648 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 4, length 64
21:30:07.054322 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 5, length 64
21:30:08.057351 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 6, length 64
21:30:09.060399 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 7, length 64
21:30:10.063434 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 8, length 64
21:30:11.066475 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 9, length 64
21:30:12.069530 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 10, length 64
21:30:13.073433 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 8719, seq 11, length 64
21:30:16.049381 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 0, length 64
21:30:16.050023 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 0, length 64
21:30:17.054064 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 1, length 64
21:30:17.054676 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 1, length 64
21:30:18.058095 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 2, length 64
21:30:18.058753 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 2, length 64
21:30:19.062134 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 3, length 64
21:30:19.062767 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 3, length 64
21:30:20.066157 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 4, length 64
21:30:20.066771 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 4, length 64
21:30:21.070193 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 5, length 64
21:30:21.070805 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 5, length 64
21:30:22.074226 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 6, length 64
21:30:22.074839 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 6, length 64
21:30:23.078260 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 7, length 64
21:30:23.078914 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 7, length 64
21:30:24.082280 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 8, length 64
21:30:24.082884 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 8, length 64
21:30:25.086298 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 9, length 64
21:30:25.086913 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 9, length 64
21:30:26.090333 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 10, length 64
21:30:26.090950 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 10, length 64
21:30:27.094862 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 11, length 64
21:30:27.095476 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 11, length 64
21:30:28.098894 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 12, length 64
21:30:28.099534 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 12, length 64
21:30:29.102932 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 8975, seq 13, length 64
21:30:29.103539 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 8975, seq 13, length 64





 sysctl dev.iwn.0.debug=1
dev.iwn.0.debug: 0 -> 1

tcpdump -ni wlan0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
21:32:36.606504 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 0, length 64
21:32:37.610557 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 1, length 64
21:32:38.613622 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 2, length 64
21:32:39.616695 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 3, length 64
21:32:40.619753 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 4, length 64
21:32:41.622836 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 5, length 64
21:32:42.625910 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 6, length 64
21:32:43.628973 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 7, length 64
21:32:44.632033 IP 172.17.0.140 > 172.17.0.1: ICMP echo request, id 9743, seq 8, length 64
21:32:48.588427 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 9999, seq 0, length 64
21:32:48.589101 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 9999, seq 0, length 64
21:32:49.592652 IP 172.17.0.140 > 172.17.0.200: ICMP echo request, id 9999, seq 1, length 64
21:32:49.593276 IP 172.17.0.200 > 172.17.0.140: ICMP echo reply, id 9999, seq 1, length 64

bschmidt · Jan 27, 2010

Which type of router is that? FreeBSD based one? With a bridge? In case it is, check # arp -an on the router, it should show your clients IP and HW addr.

LesJen · Jan 27, 2010

It's a Dlink dir-615

bschmidt · Jan 27, 2010

To get that right, over the wireless link you can not ping the router itself but another IP behind the router?

Google says that there probably is in issue with WPA re-keying and setting "Group Key Interval Update" to lower value might help. Sounds unrelated though.

LesJen · Jan 27, 2010

Yes that is correct!

From another pc I can ping the router and there's full Internet access.

If I do a ping http://www.google.com from the wireless pc it can't resolve the address.

Anything else I can try?

iegeorgiev · Jan 28, 2010

bschmidt said:
Google says that there probably is in issue with WPA re-keying and setting "Group Key Interval Update" to lower value might help. Sounds unrelated though.

Hi,
This fixes my problem. Here is some more info.

My device is recognized as:

Code:

iwn0: <Intel(R) PRO/Wireless 5100> mem 0xf4200000-0xf4201fff irq 18 at device 0.0 on pci4

I am connecting to a router with WPA-PSK security set up.

My connection would be fine for about 5 minutes and then the internet disappears. The device is still associated and i can ping other computers on the network, but not the router or, anything outside.

doing /etc/rc.d/netif restart fixes for another 5 minutes, and i noticed when restarting that wpa_supplicant had already gone down for some reason.

After seeing your post i disabled the re-keying on the router(was set to 30 seconds) and have not had the problem for about 2 hours.

Let me know if i can help with any additional info.

LesJen · Jan 28, 2010

My problem is similar, it drops after about two hours. In the router the "Group Key Update Interval" is set to 3600 seconds. I'll try to change it and see what happens.

MellowCat · Jan 28, 2010

I get the same dropped connections after a certain interval, but I've checked my router config and there is no 'group key update' option to change.
I'm using WPA-PSK as well, on a Belkin Pre-N router.
Probably quite obsolete by now.

Thanks for any info
/K

LesJen · Jan 28, 2010

I lowerd my setting to 1800 sec (half an hour!) and I stil have the problem after about two hours!! I can see in /var/log/messages that:

Code:

PA: Group rekeying completed with 00:21:91:02:e9:13 [GTK=TKIP]

So I recon it must be something else. I'll try different settings, at the moment I'm at 900 sec. after that I'll try 7200 sec's and see what happens.

LesJen · Jan 28, 2010

Here's my findings so far! At the begining I had my setting at 3600 (one hour) and the disconnection came after roughly two hours.
I've tried with 1800 (half an hour) and the disconnection is at about one hour!! Then I tried 900 (15 minutes) and disconnection was in about 30 minutes and lastly I had 450 (7 min 30 sec) and disconnection came after 15 min.

I've now set 7200 sec (two hours) and if I'm right the disconnection should appear after four hours.

So it seems that it's the second negotiation that is not successful.

Any comments?

bschmidt · Jan 28, 2010

LesJen said:
Here's my findings so far! At the begining I had my setting at 3600 (one hour) and the disconnection came after roughly two hours.
I've tried with 1800 (half an hour) and the disconnection is at about one hour!! Then I tried 900 (15 minutes) and disconnection was in about 30 minutes and lastly I had 450 (7 min 30 sec) and disconnection came after 15 min.

I've now set 7200 sec (two hours) and if I'm right the disconnection should appear after four hours.

So it seems that it's the second negotiation that is not successful.

Any comments?

That is a very interesting fact, indeed. I try to get up with a test with which I'm able to reproduce that. Currently I not had any luck with that.

Btw, there is even a PR with the exact same issue.

LesJen · Jan 28, 2010

Btw, there is even a PR with the exact same issue.
Reply With Quote

Do you have a link?

bschmidt · Jan 28, 2010

bin/142547