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@freebsd.org mailing list
> > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > > > > To unsubscribe, send any mail to
> > > > > > "freebsd-net-unsubscr...@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 di
