Subject: Re: ural patch
To: None <current-users@NetBSD.org, tech-kern@NetBSD.org, sam@errno.com>
From: Sam Leffler <sam@errno.com>
List: tech-kern
Date: 07/07/2006 07:25:27
David Young wrote:
> On Thu, Jul 06, 2006 at 04:11:57PM -0700, Sam Leffler wrote:
>> Matthias Drochner wrote:
>>> kiyohara@kk.iij4u.or.jp said:
>>>> Matthias has tested ural on i386.  He said, "I'm quite happy with the
>>>> ural driver now."  
>>> Yes, it is the first time that the driver is really usable for me.
>>> There are some minor problems still as there are the wrong
>>> rxrate reporting to "radiotap" bpf listeners, and there are
>>> problems with monitor mode as Sam Leffler wrote in another mail.
>>>
>>> For now, I'd suggest to comment out the rxrate reporting as
>>> this just creates misleading information.
>> Yes, I've got several monitor mode fixes for ural/ral.  I also recently
>> circulated packet injection changes for comment to freebsd users; if
>> anyone is interested take a look at
>>
>> http://www.freebsd.org/~sam/tx80211
>>
>> There's a kernel patch that should port over easily and a bunch of tools
>> that are mostly from Andrea Bittau.
> 
> Please, use a different DLT than radiotap's (DLT_IEEE802_11_RADIO)
> to inject non-radiotap headers.

There are no radiotap equivalents to most of the contents of struct
ieee80211_bpf_params.  Also, you want the received bpf events to include
the radiotap headers so this is most natural IMO.

> 
> When I made a similar patch for a customer, I added to bpf a bpfattach3()
> call that sets a new bpf_if member, bif_output, to ieee80211_output().
> I made ieee80211_output() grok both AF_UNSPEC and pseudo_AF_HDRCMPLT,
> which is sometimes handy.  I probably cannot open-source the patches
> any time soon, *sigh*.

Guess whomever gets code out first gets the DLT, eh?  Seriously, using
if_output is a better choice IMO.  The problem is the backpointer to the
net80211 state with the existing data structures.  With the virtual ap
stuff I did there is no issue; ieee80211_output is invoked naturally and
the only additional logic required is the glue down to the drivers so
they know to use the user-supplied parameters intead of the normal tx
path.  AF_HDRCMPLT is implict in DLT_IEEE802_11_RADIO.

FWIW I originally did this stuff jan 05 w/ the vap code for testing
purposes.  Andrea is more interested in using it to do user-mode 802.11
protocol stuff a la vap's but that requires more involved changes I'm
trying to avoid.

	Sam