Modify

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#10348 closed defect (fixed)

wifi suddenly dies on ar71xx

Reported by: fsckspam@… Owned by: developers
Priority: normal Milestone: Backfire 10.03.1
Component: kernel Version: Trunk
Keywords: Cc:

Description

This problem was introduced between 10.03.1 RC5 and RC6, AFAICT.
It is very hard to reproduce and takes several days to show up.
dmesg and logread don't show anything special. When trying to connect logread shows successful key exchange and even sending DHCP responses:

Nov 4 09:44:07 OpenWrt daemon.info hostapd: wlan1: STA xxxx IEEE 802.11: authenticated
Nov 4 09:44:07 OpenWrt daemon.info hostapd: wlan1: STA xxxx IEEE 802.11: associated (aid 4)
Nov 4 09:44:07 OpenWrt daemon.info hostapd: wlan1: STA xxxx WPA: pairwise key handshake completed (RSN)
Nov 4 09:44:09 OpenWrt daemon.info dnsmasq-dhcp[2106]: DHCPDISCOVER(wlan1) 192.168.30.142 xxxx
Nov 4 09:44:09 OpenWrt daemon.info dnsmasq-dhcp[2106]: DHCPOFFER(wlan1) 192.168.30.142 xxxx

The offer is never received on the client. I have two VAPs the first one is in the bridge in br-lan. Sniffing with tcpdump on the bridge shows that the DHCP responses are sent. Sniffing on the wlan interface which is part of the bridge doesn't show the responses:

br-lan:
09:34:17.548847 xxxx > ff:ff:ff:ff:ff:ff Null Unnumbered, xid, Flags [Response], length 6: 01 00
09:34:17.656463 EAPOL key (3) v1, len 117
09:34:17.660379 EAPOL key (3) v1, len 95
09:34:17.697299 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xxxx, length 300
09:34:17.699463 IP 192.168.20.1.67 > 192.168.20.189.68: BOOTP/DHCP, Reply, length 313
09:34:20.835224 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xxxx, length 300
09:34:20.838439 IP 192.168.20.1.67 > 192.168.20.189.68: BOOTP/DHCP, Reply, length 313
09:34:25.836109 ARP, Request who-has 192.168.20.189 tell 192.168.20.1, length 28
09:34:26.836108 ARP, Request who-has 192.168.20.189 tell 192.168.20.1, length 28
09:34:27.836104 ARP, Request who-has 192.168.20.189 tell 192.168.20.1, length 28

wlan0:
09:33:21.487961 xxxx > ff:ff:ff:ff:ff:ff Null Unnumbered, xid, Flags [Response], length 6: 01 00
09:33:21.595331 EAPOL key (3) v1, len 117
09:33:21.599263 EAPOL key (3) v1, len 95
09:33:23.837142 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xxxx, length 300
09:33:31.837691 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xxxx, length 300
09:33:44.843477 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xxxx, length 300
09:33:50.834468 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xxxx, length 300

The second wifi interface (wlan1) is not part of a bridge sniffing there yields output similar to the one for wlan0, i.e. you only see the requests. The logs shows that responses are sent there, too.

Is there anything I can do to get more information? As said this problem is hard to reproduce. I basically have to wait until it happens.

Attachments (0)

Change History (9)

comment:1 Changed 6 years ago by nbd

What kind of device are you using?

comment:2 Changed 6 years ago by fsckspam@…

I'm using a TP-Link TL-WR1043ND (Ver. 1.4).
To add to the initial report: When this happens, all wifi clients stop working. Those which already have an IP also stop. We have three smartphones which run Android and have 802.11n wifi and two notebooks with Intel 6xxx 802.11n as clients.
I have changed the router to g only and so far it seems stable. So this may be a problem with 802.11n mode.

comment:3 Changed 6 years ago by nbd

please try building latest openwrt trunk and see if the issue is still there.

comment:4 Changed 6 years ago by fsckspam@…

Built and installed trunk yesterday. Did some full-speed network traffic with iperf for 2h. So far no problems. I will report back in a few days.

comment:5 Changed 6 years ago by fsckspam@…

So far trunk works perfectly. I think backfire's wifi would have died by now.

comment:6 Changed 6 years ago by fsckspam@…

Trunk still works like a charm. :)

I must say I'm really fine with trunk, but if you want me to test backfire again, just say so.

comment:7 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

I've merged the latest version from trunk to backfire.

comment:8 Changed 6 years ago by jobarjo

Hi

I had the problem with rc6.
Is it fixed in 10.03.1?

May I ask what are the changes that were merged (svn rev number)?

Thanks

comment:9 Changed 6 years ago by nbd

Some important fixes were merged after 10.03.1, so I'd recommend using latest SVN or a 10.03.2 snapshot build.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.