On Fri, Jul 07, 2006 at 07:25:27AM -0700, Sam Leffler wrote:
> 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.

Add them; radiotap is an extensible format.  ieee80211_bpf_params is not.

> > 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?

No.  The DLT is expressly reserved for radiotap, BSD's extensible 802.11
radio information header.  Your injection format is not extensible,
it's not versioned, and it's not radiotap.  Please, get a new DLT.

> 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.

Right, I am using the VAP code.  That's a good point about the old code,
I hadn't thought about the considerable differences.

> AF_HDRCMPLT is implict in DLT_IEEE802_11_RADIO.

Maybe your understanding of AF_HDRCMPLT is different from mine.
In my implementation (which was actually for DLT_IEEE802_11, but the
same argument applies), AF_UNSPEC added the BSSID & SA to the frame,
paralleling other DLTs; pseudo_AF_HDRCMPLT did not, also paralleling
other DLTs.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933