On Wed, Apr 08, 2015 at 01:17:01PM +0200, Stefan Sperling wrote:
> On Tue, Mar 17, 2015 at 03:36:03PM -0300, Henrique Lengler wrote:
> > My intenert falled again, but with this option I didn't received device
> > timeout, I received this:
>
> 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.
>
> Can somebody please try to provide a recipe that triggers the problem
> reliably?
>
> 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.
>
> 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.
So I said I am receiving less timeouts, thats true.
But yesterday and today again something happened, that could not be
solved by simply running 'ifconfig athn0 down up'.
This is what I received (messages from dmesg).
athn0: device timeout
athn0: device timeout
athn0: device timeout
athn0: device timeout
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x3 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0: firmware command 0x17 timed out
athn0: firmware command 0x17 timed out
The four first messages are normal, and can be solved by reseting
connections. But a new type appeared, and these I couldn't solve running
ifconfig.
When I ran 'ifconfig athn0 down up' it didn't anything, and I wasn't
able to close the process. Reboot was the only option.
I ran this (don't know if it gives good information):
# tcpdump -L
tcpdump: WARNING: snaplen raised from 116 to 160
tcnk type supported:
PFLOG
# tcpdump -y PFLOG
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
pdump: WARNING: snaplen raised from 116 to 160
--
Regards
Henrique Lengler
