net80211 and interface requests

[Adam Stylinski]

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

Is there any way to do this without using a kernel debugger?  It'd be really disappointing if the whole problem is a bug in the driver.  
-------------- 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/d08a766b/attachment.pgp