Running wlaninject on FreeBSD 8.0-RELEASE using a Intel 39345ABG card gives a kernel panic. The driver I'm using is wpi, and this is probably a driver bug. wlaninject => http://svn.freebsd.org/viewvc/base/release/8.0.0/tools/tools/net80211/wlaninject/wlaninject.c?view=log Some results running the tool: With length 1 to 5 -------------------------------- #wlaninject -l 1 .. wlaninject: writev(): Message too long -------------------------------- With length 6 to 9 -------------------------------- #wlaninject -l 6 .. wlaninject: writev(): Input/output error -------------------------------- With length >= 10 it gives the kernel panic. The core dump with backtrace is appended. Fix: Patch attached with submission follows: How-To-Repeat: #wlaninject -l 10
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Hi, The issue here is that you've tried to use wlaninject with a VAP in sta mode. As soon as wlaninject tries to set up the interface, net80211 will start to do a scan which means constant channel switches until it finds something to associate. wlaninject itself is not aware of that and happily injects frames no matter what the current channel state is, as the above trace shows, you hit a point where no channel is set between 2 scan interations. wlaninject is supposed to be used with VAPs in ahdemo mode and wpi(4) does not support that mode. Therefore I tend to close this PR. -- Bernhard
On Monday 20 December 2010 15:10:02 Bernhard Schmidt wrote: > Hi, > > The issue here is that you've tried to use wlaninject with a VAP in sta > mode. As soon as wlaninject tries to set up the interface, net80211 will > start to do a scan which means constant channel switches until it finds > something to associate. wlaninject itself is not aware of that and happily > injects frames no matter what the current channel state is, as the above > trace shows, you hit a point where no channel is set between 2 scan > interations. > > wlaninject is supposed to be used with VAPs in ahdemo mode and wpi(4) does > not support that mode. Therefore I tend to close this PR. Looking closer I might have been a bit wrong. There are several issue here.. One being that ni_chan is used in the TX path which should and can actually be replaced by ic_curchan. This will fix the panic reported above, though, this does no longer obscure other issues. For examples, we are allowed to pass in frames of arbitrary length, extremely short frames will be discarded early due to an overflow checking the length (the message to long error). But, if the length is just long enough to reach the driver it might still be shorter then the header for a 802.11 frame. This will result in another panic() in m_copydata() as we try to copy over the header to firmware.. I'll try to find a useful solution for that. -- Bernhard
Responsible Changed From-To: freebsd-net->freebsd-wireless Over to maintaner(s)
Created attachment 156112 [details] Discard frames that are smaller than header length
A commit references this bug: Author: avos Date: Thu Jun 9 13:42:19 UTC 2016 New revision: 301731 URL: https://svnweb.freebsd.org/changeset/base/301731 Log: net80211: discard an injected frame if it is smaller than header length. Do not try to pass such frames; a correct frame cannot be smaller than (the corresponding) header size. (for wpi(4) an additional check was added in r289012). PR: 144987 Changes: head/sys/net80211/ieee80211_output.c
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Fixed in r289012 (wpi(4) only) / r301731 (other drivers)