Johannes Berg wrote:
Hi Johannes -
I guess I'll stick with sysfs for now since the code is written already:
if I will find add_iface and so on down there then I guess it will all
work out with minor edits.
Just make sure you're running the very latest kernel with
CONFIG_SYSFS_DEPRECATED disabled (I think that's necessary, not entirely
sure). You'll notice when anything but the current CVS version of HAL no
longer displays network devices :/
I am currently using stock Fedora kernels, they have
CONFIG_SYSFS_DEPRECATED disabled already. In current FC7 development
kernels they have mac80211 in there too now. So I will mod this when it
breaks on the latest Fedora kernels.
Can I ask how stable this byzantine path I am currently following to get
a "Management interface" for tx injection is going to be? Not even
standard wireless ioctl but Private IOCTL SIOCIWFIRSTPRIV+0 opens out
into a secret garden of "PRISM2" special features... is this already in
a little black refactoring book somewhere?
Yup, it is. But there's still debate on whether it should be done
through netlink (nl80211) or some new special injection format for the
monitor interfaces like the management interface currently has.
[you can rip code from wpa_supplicant to inject frames]
Yeah that is good advice, I will look to the wpa_supplicant code,
especially since my code doesn't work yet.
Btw, here's another argument against the monitor interfaces: having them
up takes the card out of powersave mode which they should only be while
not associated, even with a userspace MLME.
It's better said "hardware promisc" than "Monitor Mode" if I understood
you. The previous patches forced hardware promisc and then filtered
for the magic packets without using Monitor mode, but that has the same
power objection.
It's mitigated a bit by only bringing the monitor interface up
automatically when the daemon starts and down when it stops, but of
course normally the daemon runs all the time. The daemon can even be
configured by the user to act differently if he wants if it sees he is
on battery. Also mitigating it is that for the largest intended usage
case, people at home communicating with neighbours, the stations are
plugged in the wall.
But if there is a better way for the stack to get unencrypted broadcasts
(that is all I really want, addr1->FF:FF:FF:FF:FF:FF packets) through to
usermode, which you would think might not actually require hardware
promisc on the hardware, then I am quite motivated to work on that.
-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
