Re: Intermittent stops in network traffic with urtw interface
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.
Re: Intermittent stops in network traffic with urtw interface
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).
Re: Intermittent stops in network traffic with urtw interface
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). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Intermittent stops in network traffic with urtw interface
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). Also perhaps of note is that 'arp -a' hangs indefinitely while the interface isn't receiving traffic. I did notice however that I am still seeing RSTP messages from the router during the outage. The arp command returns some stuff immediately after I bring the interface down then back up. Does anyone have any idea as to how this might be troubleshot further? FWIW, this is the relevant output of 'usbdevs -v': port 4 addr 2: high speed, power 500 mA, config 1, RTL8187(0x8187), Realtek(0x0bda), rev 1.00, iSerialNumber 00C0CA753185 I've seen similar behavior on OpenBSD in years past with various wireless adapters and have never been able to solve it. I don't want to go back to Debian and iptables :(((. -Brian
Re: Intermittent stops in network traffic with urtw interface
On Thu, Feb 06, 2014 at 01:37:46PM -0800, Philip Guenther wrote: On Thu, Feb 6, 2014 at 1:28 PM, Brian Curran br...@brianpcurran.com wrote: Also perhaps of note is that 'arp -a' hangs indefinitely while the interface isn't receiving traffic. arp does IP-hostname lookups by default, which probably involve DNS. Condition yourself to use the -n option with arp. A ha, good catch. I thought I had a local DNS server configured but turns out I had a public one in resolv.conf so that explains the hang.
Re: Intermittent stops in network traffic with urtw interface
On Thu, Feb 6, 2014 at 1:28 PM, Brian Curran br...@brianpcurran.com wrote: Also perhaps of note is that 'arp -a' hangs indefinitely while the interface isn't receiving traffic. arp does IP-hostname lookups by default, which probably involve DNS. Condition yourself to use the -n option with arp. Philip Guenther
Intermittent stops in network traffic with urtw interface
Hello, I have an Alfa AWUS036H USB wi-fi adapter that I am using on OpenBSD 5.4 amd64. Problem is, sometimes as often as every 15 minutes, the only way to get the interface to pass traffic is with 'ifconfig urtw0 down ifconfig urtw0 up'. I've monitored the traffic with tcpdump to look for a pattern as to when it stops passing traffic, but I have not been able to find one. At the tail of dmesg output the following messages are repeated: usb_insert_transfer: xfer=0x80568000 not busy 0x4f4e5155 urtw0: could not send frame: INVAL I am getting a 70-80 dB signal according to ifconfig, which is not ideal, but should by no means be unusable. I have used the interface with media set to DS1 mode 11g and OFDM54 mode 11g, with the same behavior. I am using WPA2-PSK to authenticate to the access point (a Verizon router). dmesg.boot has the following lines for the device: urtw0 at uhub0 port 4 Realtek RTL8187 rev 2.00/1.00 addr 2 urtw0: RTL8187 rev 0x04, RFv2, address 00:c0:ca:75:31:85 urtw0 at uhub0 port 4 vendor 0x0bda RTL8187_Wireless rev 2.00/1.00 addr 2 urtw0: RTL8187 rev 0x04, RFv2, address 00:c0:ca:75:31:85 urtw0: expect 0xe6!! (0xd2) Is there any way in which I can troubleshoot this? It's becoming a bit frustrating, but I'd like to keep using OpenBSD! I'm a bit lost at this point as to how to approach this issue further, so hopefully someone may be able to point me in the right direction. Let me know if any additional information would be of help. Thanks! -Brian
Re: Intermittent stops in network traffic with urtw interface
Brian Curran brian at brianpcurran.com writes: Hello, I have an Alfa AWUS036H USB wi-fi adapter that I am using on OpenBSD 5.4 amd64. Problem is, sometimes as often as every 15 minutes, the only way to get the interface to pass traffic is with 'ifconfig urtw0 down ifconfig urtw0 up'. I've monitored the traffic with tcpdump to look for a pattern as to when it stops passing traffic, but I have not been able to find one. when it stops passing traffic, does issuing ifconfig urtw0 scan help?
Re: Intermittent stops in network traffic with urtw interface
On Wed, Feb 05, 2014 at 10:51:19PM +, Alexey Suslikov wrote: Brian Curran brian at brianpcurran.com writes: Hello, I have an Alfa AWUS036H USB wi-fi adapter that I am using on OpenBSD 5.4 amd64. Problem is, sometimes as often as every 15 minutes, the only way to get the interface to pass traffic is with 'ifconfig urtw0 down ifconfig urtw0 up'. I've monitored the traffic with tcpdump to look for a pattern as to when it stops passing traffic, but I have not been able to find one. 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.
