Hi,
I wanted to try out packet injection with my ipw3945 card, and was
thrilled that there are patches by Andy Green for mac80211 that should
make everything that is needed for this possible.
So I patched 2.6.23-rc3 with wireless-git's everything branch, but when
attemting to inject, Andy's packetspammer (and aireplay -9
from aircrack-ng 1.0-dev) hung.
After reporting this to him and several mails I switched on debugging
flags, and modprobed iwl3945 with 'debug=0x43fff', ifconfig then oopsed:
modprobe iwl3945 debug=0x43fff
iwconfig wlan0 mode monitor
ifconfig wlan0 up
--- OOPS --- (see attachment)
When omitting the debug parameter, ifconfig succeeds but the injection
tools then hang. SysRq lets me reboot the system, as you can see in the
syslog excerpt I provided.
I attached the .config I am using, the system in question is a Dell
Inspiron 9400, running Gentoo Linux. Before attempting any of this, all
unused processes were killed, leaving only udev, metalog and vixie-cron.
And yes, I know it says the kernel is tainted, because of the nvidia
module. Say so and I'll try again without it, but quite frankly, I
don't think that makes a difference...
uname -a:
Linux doppelhertz 2.6.23-rc3 #2 SMP PREEMPT Wed Aug 29 03:06:47 CEST
2007 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel
GNU/Linux
Thanks in advance for your help,
Robert
--
post tenebras lux, post fenestras tux
-------------------------------------
ICQ: 128315405
MSN: [email protected]
Jabber: [email protected]
Somebody in the thread at some point said:
> On Thu, 2007-08-30 at 15:17 +0100, Andy Green wrote:
>
>> There is *a* device. There are multiple logical network interfaces that
>> are bound to that device. I can spawn five logical network interfaces
>> and still only have one device. NM thinks I spawned five devices: that
>> behaviour can be improved (by de-aliasing them via /sys or whatever I
>> don't mind).
>
> No, it can't really do that because you may actually want NM to control
> multiple virtual interfaces if your hardware supports multiple STA
Well if for whatever reason you can spawn multiple logical network
interfaces in the stack, as you can, NM should generically be aware that
aliases exist it seems to me.
If a device can handle two associations simultaneously (with two
radios?), which I take the "multiple STA" to mean, maybe it should
present as two wiphys and NM can take the hint from that?
-Andy
On Wed, 2007-08-29 at 20:52 +0100, Andy Green wrote:
> No, there's no general problem. I just cooked current wireless-dev
> everything and am running it on this Compaq nx7400 with a 3945 chip, it
> has just sent 100,000 packetspams while pinging warmcat.com over an
> associated connection, the injections verified on another box with a zd1211.
Right here is the difference, Robert didn't have a normal STA interface
up at the same time. FWIW, the NULL mac address thing is about to change
for the filter flags once a few people review that patch.
johannes
On Thu, 2007-08-30 at 15:42 +0100, Andy Green wrote:
> Well if for whatever reason you can spawn multiple logical network
> interfaces in the stack, as you can, NM should generically be aware that
> aliases exist it seems to me.
It could be aware of that, but I don't think it helps.
> If a device can handle two associations simultaneously (with two
> radios?), which I take the "multiple STA" to mean, maybe it should
> present as two wiphys and NM can take the hint from that?
No, no can do. You must be on the same channel etc. so it really is just
a single wiphy, but the card can allow multiple associations. It's not
possible with any drivers right now but I'm fairly sure we can add
support for that to b43 (if only with some microcode changes)
I think that NM should probably just ignore non-STA mode interfaces
completely.
johannes
On Thu, 2007-08-30 at 15:17 +0100, Andy Green wrote:
> There is *a* device. There are multiple logical network interfaces that
> are bound to that device. I can spawn five logical network interfaces
> and still only have one device. NM thinks I spawned five devices: that
> behaviour can be improved (by de-aliasing them via /sys or whatever I
> don't mind).
No, it can't really do that because you may actually want NM to control
multiple virtual interfaces if your hardware supports multiple STA
interfaces. NM should probably just be taught to not change the mode of
an interface all the time unless explicitly requested by the user.
Normal users will never have monitor interfaces. Hence, NM could display
monitor interfaces as "moni0 (monitor mode)" and only when you click on
them it asks "put into managed mode?" or something.
johannes
On Thu, 2007-08-30 at 16:51 +0200, Johannes Berg wrote:
> On Thu, 2007-08-30 at 15:42 +0100, Andy Green wrote:
>
> > Well if for whatever reason you can spawn multiple logical network
> > interfaces in the stack, as you can, NM should generically be aware that
> > aliases exist it seems to me.
>
> It could be aware of that, but I don't think it helps.
>
> > If a device can handle two associations simultaneously (with two
> > radios?), which I take the "multiple STA" to mean, maybe it should
> > present as two wiphys and NM can take the hint from that?
>
> No, no can do. You must be on the same channel etc. so it really is just
> a single wiphy, but the card can allow multiple associations. It's not
> possible with any drivers right now but I'm fairly sure we can add
> support for that to b43 (if only with some microcode changes)
So that's a b*tch and a half to deal with, when there are multiple
devices that actually share certain properties (like frequency). That's
what's happening with libertas for OLPC, and it's not easy to coordinate
between the devices because there's no standard way for each device to
say "I share X, Y, and Z with device A". It would be quite a bit easier
if NM could figure out exactly what attributes would be shared.
For libertas, everything is shared except for SSID, mode, bitrate, and
possibly encryption settings. Frequency is shared, yet they are two
completely separate WEXT interfaces. Not fun.
> I think that NM should probably just ignore non-STA mode interfaces
> completely.
Right; can somebody attach an 'lshal' run that shows at least one
STA-mode interface and one non-STA-mode interface? Send it to me
privately since I want the whole thing, not just the bits for the
net.interface object only.
I don't plan on making NM talk to hostapd to do master mode on an
interface for a really, really long time, if ever. That's better left
to other tools. As long as a STA interface _is_ a STA interface (and
doesn't have other properties like "monitor"/"raw") then this will work
fine.
Dan
On Wed, 2007-08-29 at 20:52 +0100, Andy Green wrote:
> Somebody in the thread at some point said:
>
> > I'm believe that there are still other places where iwlwifi isn't
> > ready to inject packages into the network though. Would need some
> > work.
>
> No, there's no general problem. I just cooked current wireless-dev
> everything and am running it on this Compaq nx7400 with a 3945 chip, it
> has just sent 100,000 packetspams while pinging warmcat.com over an
> associated connection, the injections verified on another box with a zd1211.
>
> If I run NetworkManager though, it deassociates me after ~60 injections.
> With NM turned off it is fine.
>
> BTW NetworkManager-0.6.5-7.fc7 also still tries to do its thing with
> thinking the virtual interface is a second physical device, pushes it
> into Managed, presents it as a second device on the UI, etc. NM should
> check and see if the network interface resolves to the same wiphy down
> /sys and not do those things to virtual interfaces not in Managed already.
No, NM shouldn't be touching /sys at all. That's HAL's job. If there's
a device out there that's an 802.11 device, NM will attempt to control
it. I don't really see why that's wrong. What's more wrong is
representing the same underlying device with separate _wireless_
devices. Normally (atheros, airo) drivers that have "special"
interfaces set other bits on them so they get ignored. This sucks
though, the raw 802.11 stuff should go through other channels, not have
to create a completely separate device.
I assume what you'd like to do is have NM ignore the fact that you just
turned on some sort of "raw" mode on the device. Unfortunately, WEXT
doesn't give us the flexibility to OR the modes. Ideally
"raw"/"monitor" would just be attributes of the device that wouldn't
really affect it's normal operation.
WRT the disconnection, please run 'iwevent' during your packet injection
runs and see if the driver sends you an SIOCGIWAP event filled with
zeros, meaning that the driver disconnected you. Also please run a few
'iwlist ethX scan' commands about 30 seconds or more apart during that
run, and see what the 'iwevent' says. My suspicion is that doing scans
during the injection while associated makes the card hiccup, causing NM
to notice the disconnection event and kill the connection (rightly so).
Dan
> One thing though... I am associated on a WPA network when I run these
> tests... is that the case for Robert I wonder?
>
> -Andy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Somebody in the thread at some point said:
> I'm believe that there are still other places where iwlwifi isn't
> ready to inject packages into the network though. Would need some
> work.
No, there's no general problem. I just cooked current wireless-dev
everything and am running it on this Compaq nx7400 with a 3945 chip, it
has just sent 100,000 packetspams while pinging warmcat.com over an
associated connection, the injections verified on another box with a zd1211.
If I run NetworkManager though, it deassociates me after ~60 injections.
With NM turned off it is fine.
BTW NetworkManager-0.6.5-7.fc7 also still tries to do its thing with
thinking the virtual interface is a second physical device, pushes it
into Managed, presents it as a second device on the UI, etc. NM should
check and see if the network interface resolves to the same wiphy down
/sys and not do those things to virtual interfaces not in Managed already.
One thing though... I am associated on a WPA network when I run these
tests... is that the case for Robert I wonder?
-Andy
On Thu, 2007-08-30 at 12:16 -0400, Dan Williams wrote:
> So that's a b*tch and a half to deal with, when there are multiple
> devices that actually share certain properties (like frequency). That's
> what's happening with libertas for OLPC, and it's not easy to coordinate
> between the devices because there's no standard way for each device to
> say "I share X, Y, and Z with device A". It would be quite a bit easier
> if NM could figure out exactly what attributes would be shared.
>
> For libertas, everything is shared except for SSID, mode, bitrate, and
> possibly encryption settings. Frequency is shared, yet they are two
> completely separate WEXT interfaces. Not fun.
Yeah, I can see how that's tough. However, this is where the wiphy comes
in handy, it's fairly well defined which properties are shared if the
devices are linked to a single wiphy.
> Right; can somebody attach an 'lshal' run that shows at least one
> STA-mode interface and one non-STA-mode interface? Send it to me
> privately since I want the whole thing, not just the bits for the
> net.interface object only.
Sent.
> I don't plan on making NM talk to hostapd to do master mode on an
> interface for a really, really long time, if ever. That's better left
> to other tools. As long as a STA interface _is_ a STA interface (and
> doesn't have other properties like "monitor"/"raw") then this will work
> fine.
Yeah, that's what it should be.
johannes
Somebody in the thread at some point said:
Let me say first I started using NM to control my wireless device for
the first time because it does a nice job aside from this issue.
>> BTW NetworkManager-0.6.5-7.fc7 also still tries to do its thing with
>> thinking the virtual interface is a second physical device, pushes it
>> into Managed, presents it as a second device on the UI, etc. NM should
>> check and see if the network interface resolves to the same wiphy down
>> /sys and not do those things to virtual interfaces not in Managed already.
>
> No, NM shouldn't be touching /sys at all. That's HAL's job. If there's
> a device out there that's an 802.11 device, NM will attempt to control
> it. I don't really see why that's wrong. What's more wrong is
There is *a* device. There are multiple logical network interfaces that
are bound to that device. I can spawn five logical network interfaces
and still only have one device. NM thinks I spawned five devices: that
behaviour can be improved (by de-aliasing them via /sys or whatever I
don't mind).
You can spawn logical network interfaces like this:
# echo -n mon0 > /sys/class/ieee80211/phy0/add_iface
> I assume what you'd like to do is have NM ignore the fact that you just
> turned on some sort of "raw" mode on the device. Unfortunately, WEXT
> doesn't give us the flexibility to OR the modes. Ideally
> "raw"/"monitor" would just be attributes of the device that wouldn't
> really affect it's normal operation.
Well I just sent the logical network interface I created to normal
iwconfig-type "Monitor Mode". The original logical interface wlan0
remained where it was, in Managed (and associated).
> WRT the disconnection, please run 'iwevent' during your packet injection
> runs and see if the driver sends you an SIOCGIWAP event filled with
> zeros, meaning that the driver disconnected you. Also please run a few
> 'iwlist ethX scan' commands about 30 seconds or more apart during that
> run, and see what the 'iwevent' says. My suspicion is that doing scans
> during the injection while associated makes the card hiccup, causing NM
> to notice the disconnection event and kill the connection (rightly so).
15:09:44.953794 wlan0 Set Encryption key:off
15:09:44.957503 wlan0 Set ESSID:off/any
15:09:45.495921 wlan0 New Access Point/Cell address:Not-Associated
15:09:50.085765 wlan0 Scan request completed
15:09:50.086194 wlan0 Set Mode:Managed
15:09:50.086496 wlan0 Set Frequency:2.437 GHz (Channel 6)
15:09:50.086890 wlan0 Set ESSID:"froh"
15:09:50.091016 wlan0 Custom driver event:ASSOCINFO(ReqIEs=...
RespIEs=...)
15:09:50.091053 wlan0 New Access Point/Cell address:00:11:50:AD:CE:38
15:09:53.698725 mon0 Set Mode:Managed
15:09:53.754515 mon0 Set ESSID:""
15:09:53.754580 mon0 Set Encryption key:off
15:09:53.754686 mon0 Set Mode:Managed
Remember mon0 and wlan0 are the same physical device... mac80211 cannot
deliver on having two logical network interfaces in Managed on the same
radio.
wlan0 IEEE 802.11g ESSID:"froh"
Mode:Managed Frequency:2.437 GHz Access Point: 00:11:50:AD:CE:38
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:... [2]
Link Quality=96/100 Signal level=-31 dBm Noise level=-70 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
mon0 IEEE 802.11g ESSID:""
Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I can't get it to deassociate on injection any more, despite I did it
several times last night and didn't reboot since... sorry. Injection is
working fine even with NM up at the moment. The other difference from
last night is that then NM listed the scanned APs twice in the UI, now
it lists them once with an empty section header for what is presumably
the mon0 interface of the same title as the first interface.
-Andy
The reason for the oops is (almost certainly) that iwlwifi
wants to print the mac address.
7568 IWL_DEBUG_MAC80211("enter - id %d, type %d, MAC " MAC_FMT "\n",
7569 conf->if_id, conf->type, MAC_ARG(conf->mac_addr));
conf->mac_addr which is set to NULL before calling add_interface.
in ieee80211_start_hard_monitor
So this will not occur when you don't enable debug. And we should proba=
bly
check for that
In case you don't enable debug, iwlwifi will exit iwl_macc_add_interfac=
e
in the next if statement..
I'm believe that there are still other places where iwlwifi isn't
ready to inject packages into the network though. Would need some
work.
=46or the record, it would have been nice if you had copied the "oops"
in the mail. And that you had tested it on an untainted kernel...
some people really hate that otherwise ;-)
ian
Robert F=FChricht wrote:
> Hi,
>=20
> I wanted to try out packet injection with my ipw3945 card, and was
> thrilled that there are patches by Andy Green for mac80211 that shoul=
d
> make everything that is needed for this possible.
>=20
> So I patched 2.6.23-rc3 with wireless-git's everything branch, but wh=
en
> attemting to inject, Andy's packetspammer (and aireplay -9
> from aircrack-ng 1.0-dev) hung.
>=20
> After reporting this to him and several mails I switched on debugging
> flags, and modprobed iwl3945 with 'debug=3D0x43fff', ifconfig then oo=
psed:
>=20
> modprobe iwl3945 debug=3D0x43fff
> iwconfig wlan0 mode monitor
> ifconfig wlan0 up
> --- OOPS --- (see attachment)
>=20
> When omitting the debug parameter, ifconfig succeeds but the injectio=
n
> tools then hang. SysRq lets me reboot the system, as you can see in t=
he
> syslog excerpt I provided.
>=20
> I attached the .config I am using, the system in question is a Dell
> Inspiron 9400, running Gentoo Linux. Before attempting any of this, a=
ll
> unused processes were killed, leaving only udev, metalog and vixie-cr=
on.
> And yes, I know it says the kernel is tainted, because of the nvidia
> module. Say so and I'll try again without it, but quite frankly, I
> don't think that makes a difference...
>=20
> uname -a:
> Linux doppelhertz 2.6.23-rc3 #2 SMP PREEMPT Wed Aug 29 03:06:47 CEST
> 2007 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel
> GNU/Linux
>=20
> Thanks in advance for your help,
> Robert
>=20