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 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?
pgpDlfrIQFxF0.pgp
Description: PGP signature
