Hi Stefan, Many thanks for that explanation! It makes sense. You're right, some low level code is really difficult to debug!
Kind regards, Tom On 07/02/17 20:41, Stefan Sperling wrote: > On Tue, Feb 07, 2017 at 08:16:10PM +0000, Tom Murphy wrote: >> Hi Stefan, >> >> I upgraded my kernel to 24 January 2017 and every once in a while I get: >> >> athn0: device timeout >> >> I've gotten 3 of these in 12 days. Running: >> >> ifconfig athn0 down; sh /etc/netstart athn0 >> >> fixes this, but not had this on mode 11g. Could it be something in the 11n >> hostap code? >> > > This was already hapening a long time before 11n mode was implemented. > There is no reason to worry about this message if the AP works otherwise. > > Below I'm quoting my reply to this same question I wrote to somebody > else a few weeks ago, who also noted that the BUGS section of the > athn($) man page says that a device timeout "should not happen". > > [[[ > It means we asked the device to transmit a frame, and 5 seconds or so > later we still did not receive a notification from the device that it > is done transmitting the frame, as it would normally send us. > > We then assume the device is wedged and reset it. This is mostly > transparent since the upper layer interface state does not change > (or changes only briefly). > > So, it should not happen. But it does, and there's no easy way to fix > it short of debugging this stuff at a very low level, which takes a > lot of time and effort. > > The simple fact is that the driver isn't perfect. > ]]]
