net80211 and interface requests

Thu Mar 31 16:15:59 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

I'm running in ahdemo mode.  Hmm, I really don't want to busyloop the CPU, but around ~90,000 for loop assignment and comparisons for my 2.8GHz CPU yields the correct time.  If we disregard any piplining that could be occurring it would come out to around (2*90,000)/(2800*10^6) seconds.  This is about 64ish microseconds.  Now realistically FreeBSD is not a real-time OS by any means but is there some better way I can use other than spin locking the process?
-------------- 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/20110331/b7bafdc0/attachment.pgp