On Wed, Apr 08, 2015 at 01:17:01PM +0200, Stefan Sperling wrote: > Hi Henrique, > > The output you sent shows things are working fine, it doesn't > show any problem. So we're still at square 1 with this issue.
I would say that lately I am receiving less timeouts, last day I got only about one or two, it is not perfect, but the system is usable. I am suspecting about some other device connected to my network, but also think that this could also be a software problem, since I had no problem with this device on Linux. Maybe it is the capacity of it recover automatically from a fall. > Can somebody please try to provide a recipe that triggers the problem > reliably? I will look for a way to systematically reproduce this problem. > Note that a device timeout implies the device has failed to send a frame. > This could happen because: > > - there is some transmission problem with the device itself > - some USB problem is preventing transmission > - some USB problem is preventing notification of successfull > transmission to the driver > - the AP failed to ACK the frame, either because it did not receive > it (out of range, interference, ...) or because the athn device > could not receive the ACK from the AP > > Without more information it's difficult to say what's going on. > > If you're in a position to run tcpdump -y IEEE802_11_RADIO on the AP > please watch for frames sent from the USB device and try to figure out > where the frame is lost. I will look at this. > Please also see http://marc.info/?l=openbsd-misc&m=141501277608157&w=2 > which is about the same driver on PCI instead of USB. > > As long as running 'ifconfig athn0 down up' restores connectivity on USB > I have more important issues to look at and won't spend more of my time > trying to reproduce this problem unless more information is provided. This is understandable, I will try to get more information, and discover the cause. Thanks; -- Regards Henrique Lengler
