net80211 and interface requests

Sat Apr 2 19:52:33 UTC 2011

On Thu, Mar 31, 2011 at 05:35:40PM +0200, Bernhard Schmidt wrote:
> On Thursday, March 31, 2011 17:14:21 Adam Stylinski wrote:
> > On Thu, Mar 31, 2011 at 03:07:15PM +0200, Bernhard Schmidt wrote:
> > > On Thursday, March 31, 2011 14:20:33 Adam Stylinski wrote:
> > > > On Thu, Mar 31, 2011 at 09:02:45AM +0200, Bernhard Schmidt wrote:
> > > > > On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > This list has helped me before so I'll email again with the hopes that
> > > > > > somebody has an answer.  All is working well with my project, however for
> > > > > > the life of me I cannot get the interface to inject the raw frames faster
> > > > > > than 11mbps.  I'm following the example given in
> > > > > > /usr/src/tools/tools/net80211/wlaninject.c, and manually specifying
> > > > > > parameters such as ucastrate, mcastrate, and mgmtrate within ifconfig.  I'm
> > > > > > putting the card into pureg mode, and yet I still can't inject any faster.
> > > > > >  I've even gone so far as to specify an ieee802211_txparam struct giving
> > > > > > values of 255 both mcast and ucast rates within the struct (and of course
> > > > > > anding them by 0xff).  I then used the ioctl call to set the flags within
> > > > > > the interface request.  Any help would be greatly appreciated.
> > > > > 
> > > > > You've set the ibp_rate0 parameter right? This one is in half-mbps, so
> > > > > a value of 108 should give you 54m. The only thing I can think of right
> > > > > now is that the device (or channel) is actually configured for 11b not
> > > > > 11g mode. Can we rule that out? Which device are you using?
> > > > > 
> > > > > > I am doing nanosleeps in between transmissions as if I don't the bpf clone
> > > > > > can't inject due to the buffer being too full.  There's probably a better
> > > > > > way of doing this, but I doubt the nanosleeps are the issue (afterall, I get
> > > > > > almost exactly 11mbps).  I should probably note I'm not doing any ACKs, this
> > > > > > is pure transmits.
> > > > > > 
> > > > > > If anybody cares enough to look at my unpolished code to get a better idea,
> > > > > > look here:
> > > > > > 
> > > > > > http://projhinternet.svn.sourceforge.net/
> > > > > > 
> > > > > > The idea is to allow unidirectional traffic so that with an FCC amateur
> > > > > > license (yes I know I'm not currently broadcasting the call sign as of yet)
> > > > > > you can broadcast unencrypted transmissions for miles (with a linear
> > > > > > amplifier spec'd to 2.4ghz).  With the license FCC part15 no longer applies
> > > > > > and you can operate just like in any other amateur band.
> > > > > > _______________________________________________
> > > > > > freebsd-net at freebsd.org mailing list
> > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > > > > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> > > > > > 
> > > > > 
> > > > 
> > > > I'm using an atheros AR2413 chipset, running in pure g mode, with also the card put into "mode 11g" and ucast, mcast, and mgmt rates set to 54.  I think the parameter for ibp_rate0 is just for setting it in the header (but I could be wrong).  Regardless I am doing this, let me give you the exact source files I'm doing this in.
> > > 
> > > Well, the ath_rate_* modules afaik do not honor the fixed rate
> > > settings. At least I've heard something about those being broken. The
> > > ibp_rate0 parameter set to 108 seems to be correct though.
> > > 
> > > No clue why that doesn't work, you may have to debug ath_tx_findrix().
> > > Adding a printf of the passed over rate and ridx should shed some light
> > > on this I guess.
> > > 
> > > > Line 38 in this file:
> > > > http://projhinternet.svn.sourceforge.net/viewvc/projhinternet/src/callbacks.c?revision=69&view=markup 
> > > > 
> > > > And the setup_if function in this:
> > > > http://projhinternet.svn.sourceforge.net/viewvc/projhinternet/src/libinject.c?revision=69&view=markup
> > > > 
> > > 
> > 
> > It turns out strange coincidences can happen.  I decided to busy loop, thinking maybe it was my nanosleep call.  And what do you know, 52Mb/sec.  Is there some sort of call I can use to probe the fd to see if the buffer has been sent yet?  
> 
> Honestly, no clue. The bpf transmit path is a bunch of ugly hacks..
> What you can try though is to enable various debug options for
> net80211 and ath to figure out what's going on, especially the bits
> for xmit.
> 
> On a unrelated side note, how is the ath/wlan0 interface configured?
> I mean, is it in sta mode or ahdemo? I guess most tests have been done
> in ahdemo mode. Also I'm sure that all frames are simply discarded if
> the device is currently scanning.
> 
> -- 
> Bernhard

After looking through what BPF has to offer, the thought has occurred to me that the example program provided under the src tree do not make proper use of bpf semantics.  Wouldn't using the bpf_tap() and related helper functions actually inject on the interface in a sleeping manner (as in wait for the interface to finish transmitting and wait for the device specific interrupt)?  Opening a Datagram socket on the interface seems a bit hackish, and it doesn't seem to obey synchronous write semantics (BPF constantly returns -1 if the device is busy for whatever reason).  

Am I wrong?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20110402/b6e742b7/attachment.pgp