On Thu, Feb 06, 2014 at 04:28:21PM -0500, Brian Curran wrote: > On Thu, Feb 06, 2014 at 09:29:37AM -0500, Brad Smith wrote: > > On 06/02/14 9:25 AM, Alexey Suslikov wrote: > > >Brian Curran <brian <at> brianpcurran.com> writes: > > > > > >>>when it stops passing traffic, does issuing "ifconfig urtw0 scan" help? > > >>> > > >> > > >>I test this just now and it seemed to help, although I only started > > >>seeing ping replies about 10 seconds after issuing the scan. There is > > >>a similar small delay, though usually not as long, when bringing the > > >>interface down then up. > > >> > > >>Also maybe of note is that the status of the interface as reported by > > >>ifconfig remains "active" when it is not receiving any traffic. > > > > > >I have urtwn(4) which also experience intermittent stops > > >with some Access Points (not all). > > > > > >Looks like it is common problem for urtw(4) and urtwn(4). > > > > and rsu(4). > > > Does anyone have any idea as to how this might be troubleshot further?
I've also seen device timeouts very occasionally, with urtwn(4). I have no known way to reproduce it at will though. Can you record netstat -W urtw0 output please, and netstat -I urtw0? Perhaps there is a particular counter that keeps increasing when the network stops working? If so, that might lead us further towards the cause of the problem. It sounds like either the TX (transmit) or RX (receive) path is dying. It would be nice to know which is dead. If you can run tcpdump on the AP or a third host in monitor mode, please check if you see the client sending frames to the AP, and if you see incoming frames from the AP on the client. On OpenBSD, if you see incoming frames with tcpdump -y IEE802_11_RADIO and perhaps tcpdump -y IEE8021_11 which then don't show up in regular tcpdump, this means the driver is dropping incoming frames and doesn't pass them up to the net80211 stack. Knowing whether this is the case might also give us clues for further diagnosis. If you don't see any incoming frames then the USB framework might not be passing frames to the driver. I'm not sure how to debug the USB stack for this kind of problem but perhaps someone else can fill in information about this. systat and vmstat -iz output might help to see if perhaps the USB host controller is getting interrupts on incoming frames that don't get translated upwards to corresponding interrupts in the wifi driver. If you don't see any interrupts on the client at all when you send broadcast frames (e.g. arp requests) from the AP then the hardware in the wifi USB stick might bave problems seeing frames, perhaps due to interference, overheating, or misconfiguration by the driver. If switching to another channel makes a long term difference then it is probably interference. You did disable any nearby microwave ovens and bluetooth devices, right? Note that even if some other wifi devices work fine in the face of interference that doesn't mean a small USB stick will work fine as well. However, so far I believe it's more likely an error in OpenBSD than anything else. Also please use 'ifconfig urtw0 debug' while investigating, and watch the dmesg (or /var/log/messages) for suspicious output.
