Johannes Berg wrote:
Hi Johannes -
Well, I discover in fact you need to inject starting only from the
IEEE802.11 header... and indeed that does work if you do it on the
"Management Interface". I found this from hostapd sources, since
wpa_supplicant doesn't seem to inject packets from userspace,
Never versions of wpa_supplicant should do this in the userspace MLME
part.
I was looking at 0.5.7 but it can easily be I missed it.
Looks like you're right, there doesn't seem to be a way. I always
thought this was possible.
I think you should raise this point on the mailing list again. I've
proposed doing this through nl80211 to allow extensibility of the meta
information (frame rate, ....) for an injected frame instead of
conjuring up yet another meta information framework that transports
frame across netdevs, but Michael strongly opposes the idea of
transporting frames via anything but a netdev.
Hmm, right.
I could post some code for nl80211 inject that doesn't control any meta
information yet but at least has the capability of carrying it over to
the stack.
These injected broadcasts will ultimately be used for bulk data
transfer: I have had 300kBytes/sec using the addressless file transfer
protocol on the patched wireless drivers. In such a case, it is
critical that netdev-like stuff especially select() and tx blocking down
in usermode works properly: the progress of the usermode transmission
thread must be regulated only by the driver and stack managing the
descriptors and blocking when things are getting backed up. If the
nl80211 injection "side channel" for sending packets doesn't inherit the
interface stop and start stuff in a clean way from whatever it calls
through to then it could get messy getting the netdev interfaces and the
side channel to block in sync I can imagine.
Here are a couple of ideas to consider anyway.
#1 The rate and so on metadata for the sending action has to belong
unambiguously with the payload, because multiple packet rates can be in
use at the same time as part of an anonymous selfconfiguring rate
optimization scheme, and so it would be no good selecting the injection
rate asynchronously on some ioctl or via another nl80211 api separate
from the payload.
How about for injection on the Management interface, it expects to find
a PRISM2 header prepended to the ieee80211 one and the payload, in
exactly the same format as is delivered by Monitor Mode? The PRISM2
capture header structure has a bunch of fields for things like rate and
antenna selection already. This has the satisfying aspect that you can
literally replay the whole Monitor Mode packet capture down the
Management Interface and get it to go out at the same rate.
#2 The whole management interface magic summoning hoodoo is a bit
strange compared to echo -n newinterfacename >
/sys/class/whatever/add_iface. How about regularizing the situation by
allowing one or more normal mac80211 interfaces to be added and then set
like iwconfig wmgmt0 mode Management. Perhaps it can then be possible
to associate the interface with a rate, like iwconfig wmgmt0 rate 54M or
iwconfig wmgmt1 rate 11M. Depending on which one you send your packet
to, it goes out at the rate associated with the interface. There can
still only be one real Management Interface per physical device if that
is important, the others are just thin wrappers over the single good one
to hold the rate (and antenna if possible) info. In this way there are
no new magic headers needed, it is all done as a netdev and the
situation for Management Interface creation is normalized a bit. The
drawback is that it is not quite as flexible as being able to specify
the rate and which antenna packet by packet.
-Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
