Subject: Re: ural patch
To: None <current-users@NetBSD.org, tech-kern@NetBSD.org, email@example.com>
From: Sam Leffler <firstname.lastname@example.org>
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:
>>> email@example.com 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
>> 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.