Arrested Development
Hi folks -
I have a couple of outstanding patches that haven't gotten where they are going (there was a third one to do with bcm43xx radiotap frequency reporting, but that turned out to be more complex and my patch only solved it for some firmwares, so we can forget about my patch if not the problem).
First is the radiotap set that seems to be generally approved of now in try #13 form.
http://www.spinics.net/lists/linux-wireless/msg03053.html
But it doesn't get elevated to wireless-git, I know because I check the web interface for it every day like a kid waiting for Christmas. Is there something more I should be doing, or is it somehow waiting for a ripe moment in the release cycle (even to go in wireless-dev?)
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
http://www.spinics.net/lists/linux-wireless/msg02897.html
This did not receive any comment, despite it should be simple to verify it is currently broken and that this small patch fixes it, and I see other small patches acknowledged and accepted there in the meanwhile. Again, is there something more or different I should be doing?
-Andy
Quoted 4 lines · Andy Green
But it doesn't get elevated to wireless-git, I know because I check the web interface for it every day like a kid waiting for Christmas. Is there something more I should be doing, or is it somehow waiting for a ripe moment in the release cycle (even to go in wireless-dev?)
Nothing is really going on right now in wireless-dev, John is probably still catching up with old mail after vacation and OLS :)
Quoted 9 lines
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
http://www.spinics.net/lists/linux-wireless/msg02897.html
This did not receive any comment, despite it should be simple to verify it is currently broken and that this small patch fixes it, and I see other small patches acknowledged and accepted there in the meanwhile. Again, is there something more or different I should be doing?
Probably just what you did now: poke daniel/uli again.
johannes
Quoted 9 lines · Andy Green
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
http://www.spinics.net/lists/linux-wireless/msg02897.html
This did not receive any comment, despite it should be simple to verify it is currently broken and that this small patch fixes it, and I see other small patches acknowledged and accepted there in the meanwhile. Again, is there something more or different I should be doing?
It's in the queue of stuff to look at. We have a backlog of patches, due to our development server going down for a few weeks.
Thanks,
Daniel
Quoted 4 lines · Andy Green
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
Oh and if you want to jump on ahead and save me some time, answering these questions might help :)
Why isn't this needed for the softmac driver? (or is it broken there too?)
Are we really sure we need another rate conversion function? there are already a couple in the mac80211 driver, and one or 2 extra (for RTS/CTS rate programming) in the softmac driver.
Daniel
Quoted 10 lines · Daniel Drake
Quoted 4 lines · Andy Green
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
Oh and if you want to jump on ahead and save me some time, answering these questions might help :)
Why isn't this needed for the softmac driver? (or is it broken there too?)
I don't know, I only test mac80211-zd1211rw (which I have a very good experience of, by the way).
Quoted 3 lines
Are we really sure we need another rate conversion function? there are already a couple in the mac80211 driver, and one or 2 extra (for RTS/CTS rate programming) in the softmac driver.
Dunno. But you definitely need to actually call "a" rate conversion function instead of passing the wrong thing on in radiotap. If you want to use one of these other conversion functions that you know about to fix it instead, please feel free to supersede my patch that way and I will be just as happy.
-Andy
Quoted 11 lines · On 07-07-06 16:13 Andy Green wrote:
Quoted 5 lines · Daniel Drake
Quoted 4 lines · Andy Green
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
...
Quoted 3 lines
Are we really sure we need another rate conversion function? there are already a couple in the mac80211 driver, and one or 2 extra (for RTS/CTS rate programming) in the softmac driver.
I have created a commit (24b5500dc) in my Git tree that implements Andy's patch. I didn't introduce a new rate conversion function, but changed only zd_rx_rate(). The function is only used for filling the ieee80211_rx_status structure.
I have added also some more cleanup patches. One of them changes the name of all the struct ieee80211_hw pointers from dev to hw. The structure isn't a device and this has confused me more then once. I also renamed related functions accordingly. (John, these patches still need review by Daniel and should not be merged into wireless-dev right now.) I also removed fill_rt_header(). It caused a unused function warning and is not needed anymore.
You can find my zd1211rw-dev branch here:
http://deine-taler.de/git-bin/gitweb.cgi?p=zd1211rw.git;a=shortlog;h=zd1211rw-dev
and also under
git://deine-taler.de/git/zd1211rw.git
Signature · 1 line
Uli Kunitz
Quoted 9 lines · Ulrich Kunitz
Quoted 7 lines · On 07-07-06 16:13 Andy Green wrote:
Quoted 5 lines · Daniel Drake
Quoted 4 lines · Andy Green
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
...
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Are we really sure we need another rate conversion function? there are already a couple in the mac80211 driver, and one or 2 extra (for RTS/CTS rate programming) in the softmac driver.
I have created a commit (
24b5500dc) in my Git tree that implements Andy's patch. I didn't introduce a new rate conversion function, but changed onlyzd_rx_rate(). The function is only used for filling theieee80211_rx_statusstructure.
Thank Uli.
I tested current wireless-dev git + my radiotap injection try#13 set + your zd1211rw.git-24b5500dc4b7fce0ff59e722376e920d7a1e2f7e.patch which implements the radiotap rate fix.
I was able to see beacons reported as 1Mbps, but as usual with Monitor mode for me for some reason it didn't really seem to show what was actually on the air very well. This is with tcpdump.
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0
But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
I tried also
# ifconfig wlan0 promisc
but it didn't really help. Then I decided to start wpa_supplicant (this is an FC6 box so it was service wpa_supplicant start) and I got this oops:
Oops: 0000 [#1] SMP CPU: 0 EIP: 0060:[<d81f3ff7>] Not tainted VLI EFLAGS: 00010246 (2.6.22-rc7 #1)
EIP is at zd_mac_config_interface+0xc/0x35 [zd1211rw_mac80211]
eax: 00000000 ebx: d5bf10c0 ecx: d10b5d88 edx: 00000000
esi: d4b63000 edi: d10b5da8 ebp: d10b5d78 esp: d10b5d74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process wpa_supplicant (pid: 2678, ti=d10b5000 task=d17f88b0 task.ti=d10b5000)
Stack: d81f7140 d10b5db4 d81cc9ab 00000000 d5bf02e0 00000004 00000000
00000000
00000000 00000000 00000000 00000000 00000000 d5bf02e0 d5bf0b10
00000000
d10b5dbc d81cc9c3 d10b5de4 d81da82b d7127140 d77cf960 00000000
00000000
Call Trace:
[<c0405e6a>] show_trace_log_lvl+0x1a/0x2f
[<c0405f1a>] show_stack_log_lvl+0x9b/0xa3
[<c04060da>] show_registers+0x1b8/0x289
[<c04062bc>] die+0x111/0x226
[<c0614a87>] do_page_fault+0x438/0x504
[<c06133fa>] error_code+0x72/0x78
[<d81cc9ab>] __ieee80211_if_config+0xf2/0xfe [mac80211]
[<d81cc9c3>] ieee80211_if_config+0xc/0xe [mac80211]
[<d81da82b>] ieee80211_sta_start_scan+0x169/0x19f [mac80211]
[<d81da8a7>] ieee80211_sta_req_scan+0x46/0x85 [mac80211]
[<d81d6045>] ieee80211_ioctl_siwscan+0x7a/0x83 [mac80211]
[<c060d148>] ioctl_standard_call+0x1f9/0x2c5
[<c060d2c0>] wext_handle_ioctl+0xac/0x375
[<c05b1416>] dev_ioctl+0x41a/0x439
[<c05a5c79>] sock_ioctl+0x1be/0x1c9
[<c048782f>] do_ioctl+0x23/0xa3
[<c0487af8>] vfs_ioctl+0x249/0x25c
[<c0487b54>] sys_ioctl+0x49/0x61
[<c0404e26>] sysenter_past_esp+0x5f/0x99
=======================
Code: 5c 89 e5 c7 80 a4 27 00 00 01 00 00 00 5d c3 55 0f b6 12 8b 40 5c89 e5 e8 e5 f3 ff ff 5d c3 55 89 e5 53 8b 51 04 8b 58 5c 31 c0 <8a> 0a f6 c1 01 75 17 8a 42 02 0a 42 01 09 c8 0a 42 03 0a 42 04
EIP: [<d81f3ff7>] zd_mac_config_interface+0xc/0x35 [zd1211rw_mac80211] SS:ESP 0068:d10b5d74
Well I think the oops in generally interesting but actually I have never really seen the kind of view from Monitor mode that I think I should see, there should be a lot more going on under these circumstances than
# tcpdump -i wlan0 -v tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus BSD radio information header), capture size 96 bytes 17:06:50.455961 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:50.558905 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:50.660889 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:50.763876 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:50.865863 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:50.967852 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:51.070857 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11] 17:06:51.172858 1.0 Mb/s 2437 MHz (0x0480) 100dB signal 0us Beacon[|802.11]
when I am seeing that actual output over ssh on the same channel? Is it something to do with having no IP address on that (monitor mode) interface?
-Andy
Quoted 10 lines · On 07-07-08 17:22 Andy Green wrote:
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
I assume you were connected over a different interface. It appears that the code, which enables the reception of all packets hasn't been called or is wrong. Currently you will see only packets that are sent to the interface. Promiscous mode is also interesting, but shouldn't have any importance in monitor mode, which the iwconfig manual describes as passing all packets on the frequency.
Quoted 6 lines
Then I decided to start
wpa_supplicant(this
is an FC6 box so it was servicewpa_supplicantstart) and I got this oops:...
EIP is atzd_mac_config_interface+0xc/0x35[zd1211rw_mac80211]
...
I believe Jon Smirl reported the same bug. But I didn't quite understand how to provoke it.
Cheers,
Uli
Signature · 1 line
Uli Kunitz
Quoted 23 lines · On Sunday 08 July 2007 20:15:24 Ulrich Kunitz wrote:
Quoted 10 lines · On 07-07-08 17:22 Andy Green wrote:
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
I assume you were connected over a different interface. It appears that the code, which enables the reception of all packets hasn't been called or is wrong. Currently you will see only packets that are sent to the interface. Promiscous mode is also interesting, but shouldn't have any importance in monitor mode, which the iwconfig manual describes as passing all packets on the frequency.
Quoted 3 lines
Then I decided to start
wpa_supplicant(this
is an FC6 box so it was servicewpa_supplicantstart) and I got this oops:
Quoted 6 lines
Quoted 3 lines
...
EIP is atzd_mac_config_interface+0xc/0x35[zd1211rw_mac80211]
...I believe Jon Smirl reported the same bug. But I didn't quite understand how to provoke it.
I think it's the NULL pointer dereference of the mac address pointer, if there's only a monitor interface. The address pointer can be NULL.
Signature · 1 line
Greetings Michael.
Quoted 13 lines · Michael Buesch
Quoted 12 lines · On Sunday 08 July 2007 20:15:24 Ulrich Kunitz wrote:
Quoted 10 lines · On 07-07-08 17:22 Andy Green wrote:
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
Quoted 6 lines
Quoted 6 lines
I assume you were connected over a different interface. It appears that the code, which enables the reception of all packets hasn't been called or is wrong. Currently you will see only packets that are sent to the interface. Promiscous mode is also interesting, but shouldn't have any importance in monitor mode, which the iwconfig manual describes as passing all packets on the frequency.
That's right, I actually use eth0 on the test box which ends up at an AP in bridge mode, and this laptop is coming in to the test box via the AP (and then eth0).
ZD1211 - usb - [test box] -- eth0 -- [AP] -- wireless -- [main laptop]
The ZD1211 should definitely be in a place to see the traffic between the main laptop and the eth0 side of the test box since it is also set to ch6, it is only 3 - 4 metres from the AP.
I wonder if there is some kind of filtering enabled with the firmware or the hardware, only packets with both the AP MAC and the wlan0 MAC are allowed somehow. And beacons.
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines
Then I decided to start
wpa_supplicant(this
is an FC6 box so it was servicewpa_supplicantstart) and I got this oops:...
EIP is atzd_mac_config_interface+0xc/0x35[zd1211rw_mac80211]
...I believe Jon Smirl reported the same bug. But I didn't quite understand how to provoke it.
I think it's the NULL pointer dereference of the mac address pointer, if there's only a monitor interface. The address pointer can be NULL.
Right, that is the situation: there is only a single default interface wlan0 and it has been placed into Monitor mode. Then you start wpa_supplicant to provoke the Oops.
-Andy
Quoted 2 lines · Michael Buesch
I think it's the NULL pointer dereference of the mac address pointer, if there's only a monitor interface. The address pointer can be NULL.
Ahem. I copied a whole bunch of people when I audited that and never got a reply (except from you)
johannes
Quoted 7 lines · Johannes Berg
Quoted 2 lines · Michael Buesch
I think it's the NULL pointer dereference of the mac address pointer, if there's only a monitor interface. The address pointer can be NULL.
Ahem. I copied a whole bunch of people when I audited that and never got a reply (except from you)
I did see the mail when you sent it, thanks. I am recording these issues here:
http://www.linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
As you can see, we have a number of things to be looking at, so apologies if we are little slow.
Daniel
Quoted 6 lines · Daniel Drake
Quoted 5 lines · Johannes Berg
Quoted 2 lines · Michael Buesch
I think it's the NULL pointer dereference of the mac address pointer, if there's only a monitor interface. The address pointer can be NULL.
Quoted 7 lines
Quoted 2 lines
Ahem. I copied a whole bunch of people when I audited that and never got a reply (except from you)
I did see the mail when you sent it, thanks. I am recording these issues here:
http://www.linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
Ah, good. Thanks for the pointer, I'm not following the wiki closely at the moment.
johannes
Quoted 10 lines · Andy Green
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
I have been down the same path, tcpdump shows the encrypted packets, but they aren't visible in Wireshark. I could only see directed packets and broadcast ones. What fixed for me was rm -rf .wireshark in /root.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 8 lines · Jon Smirl
Quoted 7 lines · Andy Green
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0
Quoted 8 lines
Quoted 3 lines
But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
I have been down the same path, tcpdump shows the encrypted packets, but they aren't visible in Wireshark. I could only see directed packets and broadcast ones. What fixed for me was rm -rf .wireshark in /root.
It's not quite the same path Jon, I don't use wireshark at all just tcpdump. Maybe it is zd1211rw-mac80211 -specific.
-Andy
Quoted 13 lines · Andy Green
Quoted 12 lines · Jon Smirl
Quoted 10 lines · Andy Green
I rebooted into the new kernel and did this only
# iwconfig wlan0 mode monitor # ifconfig wlan0 up # iwconfig wlan0 channel 6 # tcpdump -i wlan0But all I could see were beacons, this is despite I am ssh-d into that box over the same channel 6 network with WPA and should surely be seeing the encrypted packets?
Quoted 7 lines
Quoted 4 lines
I have been down the same path, tcpdump shows the encrypted packets, but they aren't visible in Wireshark. I could only see directed packets and broadcast ones. What fixed for me was rm -rf .wireshark in /root.
It's not quite the same path Jon, I don't use wireshark at all just tcpdump. Maybe it is zd1211rw-mac80211 -specific.
I can confirm. My BCM4318 is seeing all the packets. My zd1211 is only seeing the directed/broadcast ones. My rt2x00 is seeing all the packets.
All three devices are in the same machine and using the same mac80211 stack so it must be a driver issue with zd1211.
Quoted 4 lines
-Andy
Signature · 2 lines
Jon Smirl [email protected]
Quoted 9 lines · Jon Smirl
Quoted 2 lines
It's not quite the same path Jon, I don't use wireshark at all just tcpdump. Maybe it is zd1211rw-mac80211 -specific.
I can confirm. My BCM4318 is seeing all the packets. My zd1211 is only seeing the directed/broadcast ones. My rt2x00 is seeing all the packets.
All three devices are in the same machine and using the same mac80211 stack so it must be a driver issue with zd1211.
I can add iwl3945 to "sees all the expected stuff" (after a battle) list as well.
-Andy
Quoted 9 lines · On 07-07-08 20:17 Andy Green wrote:
Quoted 7 lines · Jon Smirl
Quoted 2 lines
It's not quite the same path Jon, I don't use wireshark at all just tcpdump. Maybe it is zd1211rw-mac80211 -specific.
I can confirm. My BCM4318 is seeing all the packets. My zd1211 is only seeing the directed/broadcast ones. My rt2x00 is seeing all the packets.
Quoted 7 lines
Quoted 2 lines
All three devices are in the same machine and using the same mac80211 stack so it must be a driver issue with zd1211.
I can add iwl3945 to "sees all the expected stuff" (after a battle) list as well.
-Andy
I just wrote a patch, which forwards now all the received packets on ZD1211. Right now no FCS checks are done, so you will see suspicous packets with strange packets in Wireshark. However you can see now also packets going to other devices.
I put the NULL pointer access on my TODO list.
Just look at:
http://deine-taler.de/git-bin/gitweb.cgi?p=zd1211rw.git;a=shortlog;h=zd1211rw-dev
or
git://deine-taler.de/git/zd1211rw.git -- branch zd1211rw-dev
Signature · 1 line
Uli Kunitz
Quoted 4 lines · Ulrich Kunitz
I just wrote a patch, which forwards now all the received packets on ZD1211. Right now no FCS checks are done, so you will see suspicous packets with strange packets in Wireshark. However you can see now also packets going to other devices.
This isn't going to work properly when you add a sta interface and then a monitor interface, which afaict the driver doesn't prevent in zd_mac_open. Basically, it has the phy always follow the last-added virtual interface which doesn't seem right. Also, I might be missing something, but it shouldn't allow multiple sta interfaces, afaict it does now.
johannes
Quoted 6 lines · Johannes Berg
Quoted 4 lines · Ulrich Kunitz
I just wrote a patch, which forwards now all the received packets on ZD1211. Right now no FCS checks are done, so you will see suspicous packets with strange packets in Wireshark. However you can see now also packets going to other devices.
Thanks for the work Uli, but I couldn't get it to act any differently. I didn't have the git-fu to magic your patchset on to wireless-dev, so I tried it three ways, first trying to git clone your whole thing and moving to the zd1211rw-dev branch ... but even when I was on that branch, there was no drivers/net/wireless/mac80211 dir.
Then I tried taking a snapshot of the drivers/net/wireless/mac80211/zd1211rw dir from the gitweb interface and replacing it by hand using quilt, and lastly saving raw copies of your 17 patches and using quilt to put them on top of wireless-dev one by one. The last two methods worked okay but the resulting module didn't act any differently in terms of what it picked up on Monitor mode. I confirmed it was the new module with md5sum.
Quoted 6 lines
This isn't going to work properly when you add a sta interface and then a monitor interface, which afaict the driver doesn't prevent in
zd_mac_open. Basically, it has the phy always follow the last-added virtual interface which doesn't seem right. Also, I might be missing something, but it shouldn't allow multiple sta interfaces, afaict it does now.
This is a bit of a general issue that has been discussed a couple of times, not really to a resolution: how to deal with conflicting demands of multiple interfaces on the same rx hardware. I guess it wants it to be that if any interface is in Monitor then the hardware promisc is enabled. IFF_PROMISC was discussed to be another way to select genuine promisc rx as well.
FWIW my script looks like this:
modprobe -r zd1211rw-mac80211
modprobe -r rc80211_simple
modprobe -r mac80211
modprobe zd1211rw-mac80211
sleep 2s
ifconfig wlan0 up
echo -n mon0 >/sys/class/ieee80211/phy0/add_iface iwconfig mon0 mode monitor
iwconfig mon0 channel 6
ifconfig mon0 up
-Andy
Quoted 16 lines · On 07-07-08 22:46 Andy Green wrote:
Quoted 6 lines
This isn't going to work properly when you add a sta interface and then a monitor interface, which afaict the driver doesn't prevent in
zd_mac_open. Basically, it has the phy always follow the last-added virtual interface which doesn't seem right. Also, I might be missing something, but it shouldn't allow multiple sta interfaces, afaict it does now.This is a bit of a general issue that has been discussed a couple of times, not really to a resolution: how to deal with conflicting demands of multiple interfaces on the same rx hardware. I guess it wants it to be that if any interface is in Monitor then the hardware promisc is enabled.
IFF_PROMISCwas discussed to be another way to select genuine promisc rx as well.FWIW my script looks like this:
Quoted 10 lines
modprobe -r zd1211rw-mac80211
modprobe -rrc80211_simple
modprobe -r mac80211
modprobe zd1211rw-mac80211
sleep 2s
ifconfig wlan0 up
echo -n mon0 >/sys/class/ieee80211/phy0/add_iface iwconfig mon0 mode monitor
iwconfig mon0 channel 6
ifconfig mon0 up
I forgot to mention that the monitor support doesn't work with additonal interfaces right now. Additional interfaces are broken currently for zd1211rw. I cannot fix all the problems with mac80211 interface of the driver at the same time.
Try
iwconfig wlan0 mode monitor
ifconfig wlan0 up
iwconfig wlan0 channel 6
for now.
The problem with the STA + MNTR interface is, that mac80211 must do the FCS checking for the STA interface or the driver has to filter them before forwarding them to the upper layer.
Signature · 1 line
Uli Kunitz
Quoted 29 lines · On Monday 09 July 2007 00:38:29 Ulrich Kunitz wrote:
Quoted 16 lines · On 07-07-08 22:46 Andy Green wrote:
Quoted 6 lines
This isn't going to work properly when you add a sta interface and then a monitor interface, which afaict the driver doesn't prevent in
zd_mac_open. Basically, it has the phy always follow the last-added virtual interface which doesn't seem right. Also, I might be missing something, but it shouldn't allow multiple sta interfaces, afaict it does now.This is a bit of a general issue that has been discussed a couple of times, not really to a resolution: how to deal with conflicting demands of multiple interfaces on the same rx hardware. I guess it wants it to be that if any interface is in Monitor then the hardware promisc is enabled.
IFF_PROMISCwas discussed to be another way to select genuine promisc rx as well.FWIW my script looks like this:
Quoted 10 lines
modprobe -r zd1211rw-mac80211
modprobe -rrc80211_simple
modprobe -r mac80211
modprobe zd1211rw-mac80211
sleep 2s
ifconfig wlan0 up
echo -n mon0 >/sys/class/ieee80211/phy0/add_iface iwconfig mon0 mode monitor
iwconfig mon0 channel 6
ifconfig mon0 up
Quoted 4 lines
I forgot to mention that the monitor support doesn't work with additonal interfaces right now. Additional interfaces are broken currently for zd1211rw. I cannot fix all the problems with mac80211 interface of the driver at the same time.
What do you mean by "additional interface"?
Do you mean multiple STA interfaces? Does the zd hardware support this? I'd say this is unlikely.
Quoted 3 lines
The problem with the STA + MNTR interface is, that mac80211 must do the FCS checking for the STA interface or the driver has to filter them before forwarding them to the upper layer.
Well, it's not _that_ bad to forward frames with bad FCS in monitor mode. Hey, it's monitor mode. We want to see what's going on. ;) I'd say just push the corrupt frames upstream and implement the FCS checking later.
Signature · 1 line
Greetings Michael.
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
echo -n mon0 >/sys/class/ieee80211/phy0/add_iface
What do you mean by "additional interface"?
Do you mean multiple STA interfaces? Does the zd hardware support this? I'd say this is unlikely.Quoted 1 line
Quoted 1 line
echo -n mon0 >/sys/class/ieee80211/phy0/add_iface
mon0 is an additional interface for me. An additional monitoring interface is not supported by the hardware, but can be emulated. However zd1211rw has registers for a second MAC address. Therefore STA+STA and AP+STA could be supported, if the firmware handles it properly.
Quoted 8 lines
Quoted 3 lines
The problem with the STA + MNTR interface is, that mac80211 must do the FCS checking for the STA interface or the driver has to filter them before forwarding them to the upper layer.
Well, it's not _that_ bad to forward frames with bad FCS in monitor mode. Hey, it's monitor mode. We want to see what's going on. ;) I'd say just push the corrupt frames upstream and implement the FCS checking later.
Right. I think the radiotap header has support for a bad fcs flag and for the STA interface, if present, the FCS check has to be done anyhow.
--
Uli Kunitz
Quoted 4 lines · Ulrich Kunitz
I forgot to mention that the monitor support doesn't work with additonal interfaces right now. Additional interfaces are broken currently for zd1211rw. I cannot fix all the problems with mac80211 interface of the driver at the same time.
Understood, I appreciate the work you and Daniel are putting in. Over the past few months the zd1211rw-mac80211 has been pretty much my reference platform since it was more stable than the other devices I have during that time.
Quoted 11 lines
Try
iwconfig wlan0 mode monitor
ifconfig wlan0 up
iwconfig wlan0 channel 6for now.
The problem with the STA + MNTR interface is, that mac80211 must do the FCS checking for the STA interface or the driver has to filter them before forwarding them to the upper layer.
Yep that works now thanks, I see encrypted data and ACKs spamming and the occasional bogon. BTW I quite like having the bogons too... in Monitor mode anyway.
-Andy
Quoted 7 lines · Johannes Berg
This isn't going to work properly when you add a sta interface and then a monitor interface, which afaict the driver doesn't prevent in
zd_mac_open. Basically, it has the phy always follow the last-added virtual interface which doesn't seem right. Also, I might be missing something, but it shouldn't allow multiple sta interfaces, afaict it does now.
It doesn't allow more than one interface, sta or mntr. mac80211 does soft monitor mode interfaces for zd1211rw when a sta interface is already up.
-Michael Wu
Quoted 2 lines · Michael Wu
It doesn't allow more than one interface, sta or mntr. mac80211 does soft monitor mode interfaces for zd1211rw when a sta interface is already up.
Oops. You're right, I confused .open and .add_interface.
johannes
Quoted 9 lines · Ulrich Kunitz
Quoted 7 lines · On 07-07-06 16:13 Andy Green wrote:
Quoted 5 lines · Daniel Drake
Quoted 4 lines · Andy Green
Second is a small patch for zd1211rw-mac80211 that fixes rate reporting on radiotap rx, last sent here 11 June.
...
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Are we really sure we need another rate conversion function? there are already a couple in the mac80211 driver, and one or 2 extra (for RTS/CTS rate programming) in the softmac driver.
I have created a commit (
24b5500dc) in my Git tree that implements Andy's patch. I didn't introduce a new rate conversion function, but changed onlyzd_rx_rate(). The function is only used for filling theieee80211_rx_statusstructure.
I tested this together with the new hardware promisc rx patches and it works fine. Thanks!
-Andy