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
On 7/8/07, Andy Green <[email protected]> wrote:
> Jon Smirl wrote:
> > On 7/8/07, Andy Green <[email protected]> wrote:
> >> 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 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.
>
> -Andy
>
>
--
Jon Smirl
[email protected]
Jon Smirl wrote:
>> 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
Andy Green wrote:
> 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
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
On Fri, 2007-07-06 at 07:52 +0100, Andy Green wrote:
> 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 :)
> 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
Johannes Berg wrote:
> On Sun, 2007-07-08 at 22:37 +0200, Ulrich Kunitz wrote:
>
>> 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.
> 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
On 7/8/07, Andy Green <[email protected]> wrote:
> 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 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.
--
Jon Smirl
[email protected]
On Sun, 2007-07-08 at 15:44 -0700, Michael Wu wrote:
> 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
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 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 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.
> Then I decided to start wpa_supplicant (this
> is an FC6 box so it was service wpa_supplicant start) and I got this oops:
>
> ...
> EIP is at zd_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
--
Uli Kunitz
On 07-07-08 20:17 Andy Green wrote:
> Jon Smirl wrote:
>
> >> 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
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
--
Uli Kunitz
Jon Smirl wrote:
> On 7/8/07, Andy Green <[email protected]> wrote:
>> 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 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
On 07-07-06 16:13 Andy Green wrote:
> Daniel Drake wrote:
> > Andy Green wrote:
> >> 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
> ...
> > 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
--
Uli Kunitz
Ulrich Kunitz wrote:
> 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.
> 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.
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
Ulrich Kunitz wrote:
> On 07-07-06 16:13 Andy Green wrote:
>
>> Daniel Drake wrote:
>>> Andy Green wrote:
>>>> 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
>> ...
>>> 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.
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 5c
89 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
Ulrich Kunitz wrote:
> On 07-07-06 16:13 Andy Green wrote:
>
>> Daniel Drake wrote:
>>> Andy Green wrote:
>>>> 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
>> ...
>>> 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 tested this together with the new hardware promisc rx patches and it
works fine. Thanks!
-Andy
Andy Green wrote:
> 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
On Sun, 2007-07-08 at 22:37 +0200, Ulrich Kunitz wrote:
> 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
Daniel Drake wrote:
> Andy Green wrote:
>> 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
>
> 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).
> 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
>>> 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.
>>> 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.
>> 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
On 07-07-08 22:46 Andy Green wrote:
> > 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
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.
--
Uli Kunitz
On Sunday 08 July 2007 14:23, Johannes Berg wrote:
> 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
Johannes Berg wrote:
> On Sun, 2007-07-08 at 20:18 +0200, Michael Buesch wrote:
>
>> 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
On Sun, 2007-07-08 at 20:40 -0400, Daniel Drake wrote:
> Johannes Berg wrote:
> > On Sun, 2007-07-08 at 20:18 +0200, Michael Buesch wrote:
> >
> >> 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
Ah, good. Thanks for the pointer, I'm not following the wiki closely at
the moment.
johannes
On Monday 09 July 2007 00:38:29 Ulrich Kunitz wrote:
> On 07-07-08 22:46 Andy Green wrote:
>
> > > 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
>
> 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.
> 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.
--
Greetings Michael.
Michael Buesch wrote:
> On Sunday 08 July 2007 20:15:24 Ulrich Kunitz wrote:
>> 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 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 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.
>>> Then I decided to start wpa_supplicant (this
>>> is an FC6 box so it was service wpa_supplicant start) and I got this oops:
>>>
>>> ...
>>> EIP is at zd_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
On Sunday 08 July 2007 20:15:24 Ulrich Kunitz wrote:
> 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 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 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.
>
> > Then I decided to start wpa_supplicant (this
> > is an FC6 box so it was service wpa_supplicant start) and I got this oops:
> >
> > ...
> > EIP is at zd_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.
--
Greetings Michael.
On Sun, 2007-07-08 at 20:18 +0200, Michael Buesch wrote:
> 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