Greg Troxel wrote:
> It's nice to be able to send raw frames, but I'm not comfortable with
> the duplication of code in the output path.  With Ethernets, one could
> send raw frames, and they'd not get the usual AF/arp processsing in
> ether_output.  And, making the raw queue be first seems not quite
> right.  So I think it would be good to think about how to put raw
> packets in the regular queue and somehow not do 802.11 encap.  This
> raises issues about the use of 802.11 node structures and what should
> happen for such frames.  It also raises the question of whether the
> 802.11 encap should be happening earlier, so that frames in the queue
> are already encaped.  But given that per-node information can change,
> it makes sense to do the encap as late as possible, which is perhaps
> why it is how it is now.
> 

I've done code to send raw frames via bpf.  I stuck the frames on the 
mgt q and marked the mbufs with a flag bit to identify they were already 
encapsulated.  I think I used the bss node though that was a hack.  All 
frames in the output path should go through if_start and in ath through 
ath_tx_start.

John Bickett did some raw frame tx support for madwifi (the linux 
version) that used a header on each frame to identify the 
802.11-specific parameter state.  You might want to look at that.

FWIW this stuff is simple to do with the vap re-architecture as if_start 
passes through the net80211 layer so 802.11-specific work can be carried 
out above the drivers.

	Sam