Hi everyone,
I noticed a bug (details later) in Linus' git tree, which wasn't there in
2.6.35.7. So I went on to bisect the bug. 12 compiles and reboots later, I
could narrow it down to this commit:
# bad: [05318bc905467237d4aa68a701f6e92a2b332218] Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
Unfortunately, I couldn't further bisect down wireless-next, because all three
commits I picked were unworkable (bringing down an interface caused the kernel
to oops, which made my test case impossible).
The test case is as follows: I have eth0 and wlan0 (the interface to an
rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
try to connect with a client to my hostapd AP, I can successfully
authenticate, but all further packets don't reach the interface of the AP.
However, I can see broadcast packets *from* the AP on my client, but not the
other way round (DHCP requests from client to AP). To make sure the bug was
not specific to broadcast packets, I manually set an IP on my client and tried
to ping the AP, but those packets didn't come through, either.
Right now I'm a bit clueless on how to get to the root of this bug, so any
help is appreciated.
Regards,
Lee
On 29/10/10 00:17, Helmut Schaa wrote:
> Am Donnerstag 28 Oktober 2010 schrieb Gertjan van Wingerde:
>> On 10/28/10 21:06, Lee wrote:
>>> On 28/10/10 10:23, Helmut Schaa wrote:
>>>> Am Donnerstag 28 Oktober 2010 schrieb Lee:
>>>>> On 26/10/10 07:40, Helmut Schaa wrote:
>>>>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>>>>>
>>>>>> Do you see any frames from your specific client?
>>>>>
>>>>> Yes. I can see this:
>>>>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
>>>> [...]
>>>>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>>>>>
>>>>> However, on wlan0 I don't see anything beyond the EAPOL packets.
>>>>> Temporarily turning off WPA encryption let me successfully connect to my AP.
>>>>
>>>> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
>>>>
>>>> Helmut
>>>
>>> (argh, brown paper bag)
>>>
>>> I went through the compiled kernels again, and I've screwed up at the last
>>> commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
>>> later:
>>>
>>> # bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
>>>
>>> On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
>>
>> Hmm, the patch itself that seems to cause the badness doesn't look bad.
>> However, closer inspection shows that the intf->bssid field may be initialized incorrectly.
>>
>> I may be a long shot, but can you check if the attached patch helps?
>
> Hmm, indeed that part of the code looks suspicious. However, setting the bssid
> and mac always worked for me on rt2800pci.
>
> Furthermore, the removal of the& seems to not make any difference in this
> case. I've just tried the following:
>
> #include<stdio.h>
> int main() {
> int x[2];
> printf("%p %p\n", x,&x);
> }
>
> Output is as follows:
>
> 0x7fff74cb1df0 0x7fff74cb1df0
>
> So, x and&x are equivalent in this case and this is similar to the code in
> rt2x00mac. I'm fine with changing both memcpy's as you've suggested as it
> really looks cleaner but I doubt that this is going to fix the problem.
>
> In commit f1aa4c541e98afa8b770a75ccaa8504d0bff44a7 "rt2x00: Write the BSSID
> to register when interface is added" we've added the bssid passing to the
> device in AP mode to fix hw crypto on rt2800 devices in AP mode. But maybe
> the older devices behave differently and don't like getting a bssid set
> in AP mode?
>
> Lee, if you just revert the commit you've identified are you able to use
> the device in AP mode with hw crypto?
>
> Thanks,
> Helmut
Reverting that memcpy() to it's original parameters works for me (AP mode + hw
crypto).
Hi,
Am Samstag 23 Oktober 2010 schrieb Lee:
> On 22/10/10 01:47, Lee wrote:
> > The test case is as follows: I have eth0 and wlan0 (the interface to an
> > rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
> > try to connect with a client to my hostapd AP, I can successfully
> > authenticate, but all further packets don't reach the interface of the AP.
> >
> > However, I can see broadcast packets *from* the AP on my client, but not the
> > other way round (DHCP requests from client to AP). To make sure the bug was
> > not specific to broadcast packets, I manually set an IP on my client and tried
> > to ping the AP, but those packets didn't come through, either.
[...]
> I checked vanilla 2.6.36, the bug is still there. Is this a known bug? Does
> anyone care to give me some hints? Are any details needed?
Please try to create a monitor interface on the rt73usb AP after setting it up:
# iw dev wlan0 interface add mon0 type monitor
and run a tcpdump on that (with XX:...:XX replaced by the MAC address of
your client):
# tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
Do you see any frames from your specific client?
Helmut
Am Donnerstag 28 Oktober 2010 schrieb Gertjan van Wingerde:
> On 10/28/10 21:06, Lee wrote:
> > On 28/10/10 10:23, Helmut Schaa wrote:
> >> Am Donnerstag 28 Oktober 2010 schrieb Lee:
> >>> On 26/10/10 07:40, Helmut Schaa wrote:
> >>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
> >>>>
> >>>> Do you see any frames from your specific client?
> >>>
> >>> Yes. I can see this:
> >>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
> >> [...]
> >>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
> >>>
> >>> However, on wlan0 I don't see anything beyond the EAPOL packets.
> >>> Temporarily turning off WPA encryption let me successfully connect to my AP.
> >>
> >> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
> >>
> >> Helmut
> >
> > (argh, brown paper bag)
> >
> > I went through the compiled kernels again, and I've screwed up at the last
> > commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
> > later:
> >
> > # bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
> >
> > On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
>
> Hmm, the patch itself that seems to cause the badness doesn't look bad.
> However, closer inspection shows that the intf->bssid field may be initialized incorrectly.
>
> I may be a long shot, but can you check if the attached patch helps?
Hmm, indeed that part of the code looks suspicious. However, setting the bssid
and mac always worked for me on rt2800pci.
Furthermore, the removal of the & seems to not make any difference in this
case. I've just tried the following:
#include <stdio.h>
int main() {
int x[2];
printf("%p %p\n", x, &x);
}
Output is as follows:
0x7fff74cb1df0 0x7fff74cb1df0
So, x and &x are equivalent in this case and this is similar to the code in
rt2x00mac. I'm fine with changing both memcpy's as you've suggested as it
really looks cleaner but I doubt that this is going to fix the problem.
In commit f1aa4c541e98afa8b770a75ccaa8504d0bff44a7 "rt2x00: Write the BSSID
to register when interface is added" we've added the bssid passing to the
device in AP mode to fix hw crypto on rt2800 devices in AP mode. But maybe
the older devices behave differently and don't like getting a bssid set
in AP mode?
Lee, if you just revert the commit you've identified are you able to use
the device in AP mode with hw crypto?
Thanks,
Helmut
On 25/10/10 19:49, John W. Linville wrote:
> On Sat, Oct 23, 2010 at 09:58:59PM +0200, Lee wrote:
>> On 22/10/10 01:47, Lee wrote:
>>> Hi everyone,
>>>
>>> I noticed a bug (details later) in Linus' git tree, which wasn't there in
>>> 2.6.35.7. So I went on to bisect the bug. 12 compiles and reboots later, I
>>> could narrow it down to this commit:
>>>
>>> # bad: [05318bc905467237d4aa68a701f6e92a2b332218] Merge branch 'master' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
>>>
>>> Unfortunately, I couldn't further bisect down wireless-next, because all three
>>> commits I picked were unworkable (bringing down an interface caused the kernel
>>> to oops, which made my test case impossible).
>>>
>>> The test case is as follows: I have eth0 and wlan0 (the interface to an
>>> rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
>>> try to connect with a client to my hostapd AP, I can successfully
>>> authenticate, but all further packets don't reach the interface of the AP.
>>>
>>> However, I can see broadcast packets *from* the AP on my client, but not the
>>> other way round (DHCP requests from client to AP). To make sure the bug was
>>> not specific to broadcast packets, I manually set an IP on my client and tried
>>> to ping the AP, but those packets didn't come through, either.
>>>
>>> Right now I'm a bit clueless on how to get to the root of this bug, so any
>>> help is appreciated.
>>>
>>> Regards,
>>> Lee
>>
>> I checked vanilla 2.6.36, the bug is still there. Is this a known
>> bug? Does anyone care to give me some hints? Are any details needed?
>
> Hard to say if you can't complete the bisect.
>
> The bisect you mention is a merge from wireless-next-2.6 at 88c1f4f.
> The preceding merge from wireless-next-2.6 was from abf52f8. It looks
> like there were a number of rt2x00 commits in between.
>
> So, you might try a new bisect:
>
> git bisect start 88c1f4f abf52f8
>
> If you still get commits that don't work but in an apparently unrelated
> way, you can use 'git bisect skip'.
>
> Does that help you to narrow things down?
>
> John
I found a way to work around that oops I was hitting, so I took your two
commit points to start off a new bisect.
> 1df90809f79b765fd4e8868c2b182d948f198a17 is the first bad commit
I tried to revert that commit on top of v2.6.36, but there were a few commits
to rt2800lib.c. But since that file doesn't get compiled in my .config, I just
reverted the changes to rt2x00dev.c and tried that kernel. It compiled fine,
but didn't fix my problem.
I don't really understand the code, so I guess I'll stop fiddling around with
it. I've got a working test-case, though, so I'm happy to test any patches
that are sent in my direction.
Lee
Am Freitag 29 Oktober 2010 schrieb Lee:
> On 29/10/10 00:17, Helmut Schaa wrote:
> > In commit f1aa4c541e98afa8b770a75ccaa8504d0bff44a7 "rt2x00: Write the BSSID
> > to register when interface is added" we've added the bssid passing to the
> > device in AP mode to fix hw crypto on rt2800 devices in AP mode. But maybe
> > the older devices behave differently and don't like getting a bssid set
> > in AP mode?
> >
> > Lee, if you just revert the commit you've identified are you able to use
> > the device in AP mode with hw crypto?
> >
> Reverting that memcpy() to it's original parameters works for me (AP mode + hw
> crypto).
Thanks for the info Lee. So, in AP mode we need to set the bssid on rt2800
devices in order to get hw crypto to work but on (at least) rt73 devices we
may not set the bssid to get hw crypto to work :(
Ivo, Gertjan, any ideas how to handle that case. I don't feel like introducing
another device specific flag makes sense here?
Helmut
On 28/10/10 21:54, Gertjan van Wingerde wrote:
> On 10/28/10 21:06, Lee wrote:
>> On 28/10/10 10:23, Helmut Schaa wrote:
>>> Am Donnerstag 28 Oktober 2010 schrieb Lee:
>>>> On 26/10/10 07:40, Helmut Schaa wrote:
>>>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>>>>
>>>>> Do you see any frames from your specific client?
>>>>
>>>> Yes. I can see this:
>>>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
>>> [...]
>>>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>>>>
>>>> However, on wlan0 I don't see anything beyond the EAPOL packets.
>>>> Temporarily turning off WPA encryption let me successfully connect to my AP.
>>>
>>> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
>>>
>>> Helmut
>>
>> (argh, brown paper bag)
>>
>> I went through the compiled kernels again, and I've screwed up at the last
>> commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
>> later:
>>
>> # bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
>>
>> On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
>
> Hmm, the patch itself that seems to cause the badness doesn't look bad.
> However, closer inspection shows that the intf->bssid field may be initialized incorrectly.
>
> I may be a long shot, but can you check if the attached patch helps?
>
> ---
> Gertjan.
I tried the patch. Old behaviour: nohwcrypt=0 doesn't work, nohwcrypt=1 does.
I'm compiling the kernel with the revert of 'bisect bad' right now.
-Lee
Hi,
>> Am Samstag 23 Oktober 2010 schrieb Lee:
>>> On 22/10/10 01:47, Lee wrote:
>>>> The test case is as follows: I have eth0 and wlan0 (the interface to an
>>>> rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
>>>> try to connect with a client to my hostapd AP, I can successfully
>>>> authenticate, but all further packets don't reach the interface of the AP.
>>>>
>>>> However, I can see broadcast packets *from* the AP on my client, but not the
>>>> other way round (DHCP requests from client to AP). To make sure the bug was
>>>> not specific to broadcast packets, I manually set an IP on my client and tried
>>>> to ping the AP, but those packets didn't come through, either.
>>
>> [...]
>>
>>> I checked vanilla 2.6.36, the bug is still there. Is this a known bug? Does
>>> anyone care to give me some hints? Are any details needed?
>>
>> Please try to create a monitor interface on the rt73usb AP after setting it up:
>>
>> # iw dev wlan0 interface add mon0 type monitor
>>
>> and run a tcpdump on that (with XX:...:XX replaced by the MAC address of
>> your client):
>>
>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>
>> Do you see any frames from your specific client?
>>
>> Helmut
>
> Yes. I can see this:
> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
> 10:09:31.193127 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit][|802.11]
<..snip..>
> However, on wlan0 I don't see anything beyond the EAPOL packets.
> Temporarily turning off WPA encryption let me successfully connect to my AP.
And if you enable WPA, but disable Hardware encryption?
(module parameter hw_crypto=0).
Ivo
On Tue, Oct 26, 2010 at 07:40:47AM +0200, Helmut Schaa wrote:
> Am Samstag 23 Oktober 2010 schrieb Lee:
> > On 22/10/10 01:47, Lee wrote:
> > > The test case is as follows: I have eth0 and wlan0 (the interface to an
> > > rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
> > > try to connect with a client to my hostapd AP, I can successfully
> > > authenticate, but all further packets don't reach the interface of the AP.
> > >
> > > However, I can see broadcast packets *from* the AP on my client, but not the
> > > other way round (DHCP requests from client to AP). To make sure the bug was
> > > not specific to broadcast packets, I manually set an IP on my client and tried
> > > to ping the AP, but those packets didn't come through, either.
>
> [...]
>
> > I checked vanilla 2.6.36, the bug is still there. Is this a known bug? Does
> > anyone care to give me some hints? Are any details needed?
>
> Please try to create a monitor interface on the rt73usb AP after setting it up:
>
> # iw dev wlan0 interface add mon0 type monitor
>
> and run a tcpdump on that (with XX:...:XX replaced by the MAC address of
> your client):
>
> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>
> Do you see any frames from your specific client?
This could be the same issue I reported in
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-October/002152.html
with compat-wireless-2.6.36-rc3-1.
I had to do other work and couldn't follow up on this issue, but I'll
try to reproduce it later today.
BTW, if I want to test the current rt2x00 git version with a 2.6.32 kernel,
like outlined in "Testing with compat-rt2x00"
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-October/002175.html
can I base it on stable compat-wireless or do I need to use a
compat-wireless based on linux-next (aka bleeding edge)?
What do rt2x00 developers use?
Thanks
Johannes
On Sat, Oct 23, 2010 at 09:58:59PM +0200, Lee wrote:
> On 22/10/10 01:47, Lee wrote:
> >Hi everyone,
> >
> >I noticed a bug (details later) in Linus' git tree, which wasn't there in
> >2.6.35.7. So I went on to bisect the bug. 12 compiles and reboots later, I
> >could narrow it down to this commit:
> >
> ># bad: [05318bc905467237d4aa68a701f6e92a2b332218] Merge branch 'master' of
> >git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
> >
> >Unfortunately, I couldn't further bisect down wireless-next, because all three
> >commits I picked were unworkable (bringing down an interface caused the kernel
> >to oops, which made my test case impossible).
> >
> >The test case is as follows: I have eth0 and wlan0 (the interface to an
> >rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
> >try to connect with a client to my hostapd AP, I can successfully
> >authenticate, but all further packets don't reach the interface of the AP.
> >
> >However, I can see broadcast packets *from* the AP on my client, but not the
> >other way round (DHCP requests from client to AP). To make sure the bug was
> >not specific to broadcast packets, I manually set an IP on my client and tried
> >to ping the AP, but those packets didn't come through, either.
> >
> >Right now I'm a bit clueless on how to get to the root of this bug, so any
> >help is appreciated.
> >
> >Regards,
> >Lee
>
> I checked vanilla 2.6.36, the bug is still there. Is this a known
> bug? Does anyone care to give me some hints? Are any details needed?
Hard to say if you can't complete the bisect.
The bisect you mention is a merge from wireless-next-2.6 at 88c1f4f.
The preceding merge from wireless-next-2.6 was from abf52f8. It looks
like there were a number of rt2x00 commits in between.
So, you might try a new bisect:
git bisect start 88c1f4f abf52f8
If you still get commits that don't work but in an apparently unrelated
way, you can use 'git bisect skip'.
Does that help you to narrow things down?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On 22/10/10 01:47, Lee wrote:
> Hi everyone,
>
> I noticed a bug (details later) in Linus' git tree, which wasn't there in
> 2.6.35.7. So I went on to bisect the bug. 12 compiles and reboots later, I
> could narrow it down to this commit:
>
> # bad: [05318bc905467237d4aa68a701f6e92a2b332218] Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
>
> Unfortunately, I couldn't further bisect down wireless-next, because all three
> commits I picked were unworkable (bringing down an interface caused the kernel
> to oops, which made my test case impossible).
>
> The test case is as follows: I have eth0 and wlan0 (the interface to an
> rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
> try to connect with a client to my hostapd AP, I can successfully
> authenticate, but all further packets don't reach the interface of the AP.
>
> However, I can see broadcast packets *from* the AP on my client, but not the
> other way round (DHCP requests from client to AP). To make sure the bug was
> not specific to broadcast packets, I manually set an IP on my client and tried
> to ping the AP, but those packets didn't come through, either.
>
> Right now I'm a bit clueless on how to get to the root of this bug, so any
> help is appreciated.
>
> Regards,
> Lee
I checked vanilla 2.6.36, the bug is still there. Is this a known bug? Does
anyone care to give me some hints? Are any details needed?
On Tue, Oct 26, 2010 at 01:03:32PM +0200, Johannes Stezenbach wrote:
>
> (The client is sending ARP requests but not getting answer:
> zzz:~# tcpdump -p -i wlan0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:00:35.740957 ARP, Request who-has 172.28.120.1 tell 172.28.120.2, length 28
> 13:00:36.740924 ARP, Request who-has 172.28.120.1 tell 172.28.120.2, length 28
> 13:00:37.740926 ARP, Request who-has 172.28.120.1 tell 172.28.120.2, length 28
> )
I used a third machine (using ath9k) to dump the traffic with airodump-ng.
ARP requests are sent to broadcast address.
- first I checked power save is off on the client
(iw dev wlan0 set power_save off)
- then I made static ARP entry on the client (arp -i wlan0 -s 172.28.120.1 00:22:B0:xx:xx:xx)
Then I can see in the dump data packets going to the AP address, and
the AP returns ACK packets.
On AP, "tcpdump -i mon0" outputs one packet per second (corresponding with
the ping), but "tcpdump -p -i wlan0" does not output anything at all.
RX packet count in "ifconfig wlan0" output does not increase.
on AP:
# cd /sys/kernel/debug/ieee80211/phy0/stations/00*
# grep . *
agg_status:next dialog_token: 0x1
agg_status:(snip, all zeros)
dev:wlan0
flags:AUTH
flags:ASSOC
flags:AUTHORIZED
flags:SHORT PREAMBLE
ht_capa:ht not supported
inactive_ms:1160
last_seq_ctrl:ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff cc0
last_signal:-40
num_ps_buf_frames:0
rc_stats:(snip, all zeors)
rc_stats:Total packet count:: ideal 2 lookaround 0
rx_bytes:1476
rx_dropped:80
rx_duplicates:0
rx_fragments:19
rx_packets:19
tx_bytes:2238
tx_filtered:0
tx_fragments:18
tx_packets:18
tx_retry_count:0
tx_retry_failed:0
wep_weak_iv_count:0
(rx_ + tx_packets does not increase with the ping)
# cd /sys/kernel/debug/ieee80211/phy0/keys/18
(keys/18 appears after the station is connected)
# grep . *
algorithm:CCMP
flags:0x1
hw_key_idx:0
ifindex:wlan0
key:1a62718edaf300998cc974f709a0baed
keyidx:0
keylen:16
replays:1
rx_spec:000000000000
(snip repeats)
tx_rx_count:18
tx_spec:000000000000
tx_rx_count increases with the ping
HTH,
Johannes
Am Donnerstag 28 Oktober 2010 schrieb Lee:
> On 26/10/10 07:40, Helmut Schaa wrote:
> > # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
> >
> > Do you see any frames from your specific client?
>
> Yes. I can see this:
> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
[...]
> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>
> However, on wlan0 I don't see anything beyond the EAPOL packets.
> Temporarily turning off WPA encryption let me successfully connect to my AP.
Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
Helmut
On 26/10/10 07:40, Helmut Schaa wrote:
> Hi,
>
> Am Samstag 23 Oktober 2010 schrieb Lee:
>> On 22/10/10 01:47, Lee wrote:
>>> The test case is as follows: I have eth0 and wlan0 (the interface to an
>>> rt37usb device) in a bridge lan0. I have a properly configured hostapd. When I
>>> try to connect with a client to my hostapd AP, I can successfully
>>> authenticate, but all further packets don't reach the interface of the AP.
>>>
>>> However, I can see broadcast packets *from* the AP on my client, but not the
>>> other way round (DHCP requests from client to AP). To make sure the bug was
>>> not specific to broadcast packets, I manually set an IP on my client and tried
>>> to ping the AP, but those packets didn't come through, either.
>
> [...]
>
>> I checked vanilla 2.6.36, the bug is still there. Is this a known bug? Does
>> anyone care to give me some hints? Are any details needed?
>
> Please try to create a monitor interface on the rt73usb AP after setting it up:
>
> # iw dev wlan0 interface add mon0 type monitor
>
> and run a tcpdump on that (with XX:...:XX replaced by the MAC address of
> your client):
>
> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>
> Do you see any frames from your specific client?
>
> Helmut
Yes. I can see this:
# tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
10:09:31.193127 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit][|802.11]
10:09:31.193360 1.0 Mb/s [bit 15] Probe Response (<MY_AP>) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH: 11, PRIVACY[|802.11]
10:09:40.952828 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit][|802.11]
10:09:40.952986 1.0 Mb/s [bit 15] Probe Response (<MY_AP>) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH: 11, PRIVACY[|802.11]
10:09:40.963821 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Probe Request (<MY_AP>) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit][|802.11]
10:09:40.963906 1.0 Mb/s [bit 15] Probe Response (<MY_AP>) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH: 11, PRIVACY[|802.11]
10:09:42.739932 1.0 Mb/s 2462 MHz 11b -78dB signal antenna 1 [bit 14] Authentication (Open System)-1: Succesful
10:09:42.740120 1.0 Mb/s [bit 15] Authentication (Open System)-2:
10:09:42.742538 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Assoc Request (<MY_AP>) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit][|802.11]
10:09:42.742726 1.0 Mb/s [bit 15] Assoc Response AID(2) : PRIVACY : Succesful[|802.11]
10:09:42.744261 1.0 Mb/s [bit 15] EAPOL key (3) v2, len 95
10:09:42.771053 1.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14]
10:09:42.788163 1.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
10:09:42.844416 1.0 Mb/s [bit 15] EAPOL key (3) v2, len 95
10:09:42.849396 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] EAPOL key (3) v1, len 117
10:09:42.849864 1.0 Mb/s [bit 15] EAPOL key (3) v2, len 207
10:09:42.854022 1.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] EAPOL key (3) v1, len 95
10:09:42.893532 1.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 1 Pad 20 KeyID 0
10:09:42.987625 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14]
10:09:43.079505 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14]
10:09:43.358335 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 2 Pad 20 KeyID 0
10:09:44.198308 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 3 Pad 20 KeyID 0
10:09:44.359547 1.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 4 Pad 20 KeyID 0
10:09:44.377797 2.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 5 Pad 20 KeyID 0
10:09:44.425039 2.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 6 Pad 20 KeyID 0
10:09:44.446283 1.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 7 Pad 20 KeyID 0
10:09:44.692999 2.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 8 Pad 20 KeyID 0
10:09:44.943957 2.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 9 Pad 20 KeyID 0
10:09:45.004451 2.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: a Pad 20 KeyID 0
10:09:45.144803 2.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: b Pad 20 KeyID 0
10:09:45.458125 2.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: c Pad 20 KeyID 0
10:09:45.997789 2.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: d Pad 20 KeyID 0
10:09:46.177139 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: e Pad 20 KeyID 0
10:09:47.491055 5.5 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: f Pad 20 KeyID 0
10:09:48.210438 5.5 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 10 Pad 20 KeyID 0
10:09:48.367412 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 11 Pad 20 KeyID 0
10:09:50.769904 2.0 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14]
10:09:50.861516 2.0 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14]
10:09:51.007367 5.5 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 12 Pad 20 KeyID 0
10:09:52.377411 5.5 Mb/s 2462 MHz 11b -74dB signal antenna 1 [bit 14] Data IV: 13 Pad 20 KeyID 0
10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
However, on wlan0 I don't see anything beyond the EAPOL packets.
Temporarily turning off WPA encryption let me successfully connect to my AP.
Lee
Hi.
On Thu, Oct 28, 2010 at 9:54 PM, Gertjan van Wingerde
<[email protected]> wrote:
> On 10/28/10 21:06, Lee wrote:
>> On 28/10/10 10:23, Helmut Schaa wrote:
>>> Am Donnerstag 28 Oktober 2010 schrieb Lee:
>>>> On 26/10/10 07:40, Helmut Schaa wrote:
>>>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>>>>
>>>>> Do you see any frames from your specific client?
>>>>
>>>> Yes. I can see this:
>>>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
>>> [...]
>>>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>>>>
>>>> However, on wlan0 I don't see anything beyond the EAPOL packets.
>>>> Temporarily turning off WPA encryption let me successfully connect to my AP.
>>>
>>> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
>>>
>>> Helmut
>>
>> (argh, brown paper bag)
>>
>> I went through the compiled kernels again, and I've screwed up at the last
>> commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
>> later:
>>
>> # bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
>>
>> On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
>
> Hmm, the patch itself that seems to cause the badness doesn't look bad.
> However, closer inspection shows that the intf->bssid field may be initialized incorrectly.
>
> I may be a long shot, but can you check if the attached patch helps?
Good catch, but with this invalid copy, I would also expected random segfaults.
But even if this doesn't fix the hostapd issue, I would be a valid
bugfix anyway. ;)
Ivo
On Tue, Oct 26, 2010 at 07:40:47AM +0200, Helmut Schaa wrote:
>
> Please try to create a monitor interface on the rt73usb AP after setting it up:
>
> # iw dev wlan0 interface add mon0 type monitor
>
> and run a tcpdump on that (with XX:...:XX replaced by the MAC address of
> your client):
ip link set up dev mon0
> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>
> Do you see any frames from your specific client?
On the client I run:
zzz:~# ping 172.28.120.1
PING 172.28.120.1 (172.28.120.1) 56(84) bytes of data.
>From 172.28.120.2 icmp_seq=1 Destination Host Unreachable
>From 172.28.120.2 icmp_seq=2 Destination Host Unreachable
>From 172.28.120.2 icmp_seq=3 Destination Host Unreachable
On AP I get:
# tcpdump -i mon0 "ether src 00:15:61:xx:xx:xx"
tcpdump: WARNING: mon0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 65535 bytes
00:02:51.398953 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14] Data IV: 56 Pad 20 KeyID 0
00:02:51.497845 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14]
00:02:52.415053 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14] Data IV: 57 Pad 20 KeyID 0
00:02:53.414897 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14]
00:02:53.415135 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14] Data IV: 58 Pad 20 KeyID 0
00:02:53.513661 48.0 Mb/s 2447 MHz 11g -44dB signal antenna 1 [bit 14]
00:02:54.415042 48.0 Mb/s 2447 MHz 11g -44dB signal antenna 1 [bit 14] Data IV: 59 Pad 20 KeyID 0
00:02:54.415671 36.0 Mb/s 2447 MHz 11g -44dB signal antenna 1 [bit 14] Data IV: 59 Pad 20 KeyID 0
00:02:54.513572 48.0 Mb/s 2447 MHz 11g -44dB signal antenna 1 [bit 14]
00:02:55.430725 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14] Data IV: 5a Pad 20 KeyID 0
00:02:56.430702 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14]
00:02:56.430942 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14] Data IV: 5b Pad 20 KeyID 0
00:02:56.529433 48.0 Mb/s 2447 MHz 11g -46dB signal antenna 1 [bit 14]
00:02:57.249028 1.0 Mb/s 2447 MHz 11b -44dB signal antenna 1 [bit 14] Probe Request (foo) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit][|802.11]
00:02:57.350169 48.0 Mb/s 2447 MHz 11g -44dB signal antenna 1 [bit 14]
00:02:57.350402 24.0 Mb/s 2447 MHz 11g -44dB signal antenna 1 [bit 14]
00:02:57.350582 18.0 Mb/s 2447 MHz 11g -42dB signal antenna 1 [bit 14]
...
(The client is sending ARP requests but not getting answer:
zzz:~# tcpdump -p -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:00:35.740957 ARP, Request who-has 172.28.120.1 tell 172.28.120.2, length 28
13:00:36.740924 ARP, Request who-has 172.28.120.1 tell 172.28.120.2, length 28
13:00:37.740926 ARP, Request who-has 172.28.120.1 tell 172.28.120.2, length 28
)
The station is using rt3070 usb dongle, AP is D-Link DWL-G122 rt73usb dongle.
Johannes
On 10/28/10 21:06, Lee wrote:
> On 28/10/10 10:23, Helmut Schaa wrote:
>> Am Donnerstag 28 Oktober 2010 schrieb Lee:
>>> On 26/10/10 07:40, Helmut Schaa wrote:
>>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>>>
>>>> Do you see any frames from your specific client?
>>>
>>> Yes. I can see this:
>>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
>> [...]
>>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>>>
>>> However, on wlan0 I don't see anything beyond the EAPOL packets.
>>> Temporarily turning off WPA encryption let me successfully connect to my AP.
>>
>> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
>>
>> Helmut
>
> (argh, brown paper bag)
>
> I went through the compiled kernels again, and I've screwed up at the last
> commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
> later:
>
> # bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
>
> On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
Hmm, the patch itself that seems to cause the badness doesn't look bad.
However, closer inspection shows that the intf->bssid field may be initialized incorrectly.
I may be a long shot, but can you check if the attached patch helps?
---
Gertjan.
On 10/28/10 22:36, Ivo Van Doorn wrote:
> Hi.
>
> On Thu, Oct 28, 2010 at 9:54 PM, Gertjan van Wingerde
> <[email protected]> wrote:
>> On 10/28/10 21:06, Lee wrote:
>>> On 28/10/10 10:23, Helmut Schaa wrote:
>>>> Am Donnerstag 28 Oktober 2010 schrieb Lee:
>>>>> On 26/10/10 07:40, Helmut Schaa wrote:
>>>>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>>>>>
>>>>>> Do you see any frames from your specific client?
>>>>>
>>>>> Yes. I can see this:
>>>>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
>>>> [...]
>>>>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>>>>>
>>>>> However, on wlan0 I don't see anything beyond the EAPOL packets.
>>>>> Temporarily turning off WPA encryption let me successfully connect to my AP.
>>>>
>>>> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
>>>>
>>>> Helmut
>>>
>>> (argh, brown paper bag)
>>>
>>> I went through the compiled kernels again, and I've screwed up at the last
>>> commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
>>> later:
>>>
>>> # bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
>>>
>>> On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
>>
>> Hmm, the patch itself that seems to cause the badness doesn't look bad.
>> However, closer inspection shows that the intf->bssid field may be initialized incorrectly.
>>
>> I may be a long shot, but can you check if the attached patch helps?
>
> Good catch, but with this invalid copy, I would also expected random segfaults.
> But even if this doesn't fix the hostapd issue, I would be a valid
> bugfix anyway. ;)
>
Yeah, that's why I called it a long shot. I wouldn't expect segfaults, BTW, but more strange behavior.
However, you never know, maybe this fixes the issue.
I found more occurrences of the same pointer mistake, so I will prepare a single patch fixing all of them
and submit it later.
---
Gertjan.
On 28/10/10 10:23, Helmut Schaa wrote:
> Am Donnerstag 28 Oktober 2010 schrieb Lee:
>> On 26/10/10 07:40, Helmut Schaa wrote:
>>> # tcpdump -i mon0 "ether src XX:XX:XX:XX:XX:XX"
>>>
>>> Do you see any frames from your specific client?
>>
>> Yes. I can see this:
>> # tcpdump -i mon0 "ether host 00:1F:3B:79:41:6F"
> [...]
>> 10:10:03.013402 5.5 Mb/s 2462 MHz 11b -76dB signal antenna 1 [bit 14] Data IV: 14 Pad 20 KeyID 0
>>
>> However, on wlan0 I don't see anything beyond the EAPOL packets.
>> Temporarily turning off WPA encryption let me successfully connect to my AP.
>
> Aha, could you please try if loading rt73usb with nohwcrypt=1 helps?
>
> Helmut
(argh, brown paper bag)
I went through the compiled kernels again, and I've screwed up at the last
commit while bisecting (Sorry, Helmut!). The first bad kernel is a commit
later:
# bad: [f1aa4c541e98afa8b770a75ccaa8504d0bff44a7] rt2x00: Write the BSSID to register when interface is added
On the good side, I tested 2.6.36 with nohwcrypt=1, and it works. Yay!
Hi,
Am Dienstag 02 November 2010 schrieb Ivo Van Doorn:
> > After studying the code some more, I'm confused by the
> > comment for this code in rt2x00mac_add_interface():
> >
> > * The BSSID address must only be configured in AP mode,
> > * however we should not send an empty BSSID address for
> > * STA interfaces at this time, since this can cause
> > * invalid behavior in the device.
Configuring the BSSID register in AP mode was added because rt2800 devices
need it in AP mode for hw crypto.
As I stated earlier it seems that older devices (<rt2800?) need the exact
opposite. In order to fix that issue we could work around this problem by
moving the BSSID register setting (in AP mode) into rt2800 and revert rt2x00lib
back to not setting it at all (only upon association).
> > On the contrary I think the BSSID needs to be configured for STA mode
> > since it acts as a receive filter for broadcase/multicast frames.
> > The 802.11 standard says in 7.2.2 Data frames:
> >
> > A STA uses the contents of the Address 1 field to perform address
> > matching for receive decisions. In cases where the Address 1 field
> > contains a group address, the BSSID also is validated to ensure that
> > the broadcast or multicast originated from a STA in the BSS of which
> > the receiving STA is a member.
> >
> > The ralinktech.com drivers seem to set the BSSID for STA mode and IBSS mode.
>
> True, but the comment in rt2x00 says:
> 'empty BSSID address' and 'at this time'
>
> The legacy drivers from Ralink configure the BSSID, same as rt2x00 driver do,
> when we start the association procedure. This complies with the 802.11 standard
> for filtering the data frames.
Yep, Ivo is correct.
Helmut
Hi,
>> Sorry for slow response time. ?I can confirm that changing
>> ? ? ? ? ? ? ? rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? intf->mac, intf->bssid);
>> to
>> ? ? ? ? ? ? ? rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? intf->mac, NULL);
>> in rt2x00mac_add_interface() fixes rt73usb AP mode for me, too.
>
> After studying the code some more, I'm confused by the
> comment for this code in rt2x00mac_add_interface():
>
> ? ? ? ? * The BSSID address must only be configured in AP mode,
> ? ? ? ? * however we should not send an empty BSSID address for
> ? ? ? ? * STA interfaces at this time, since this can cause
> ? ? ? ? * invalid behavior in the device.
>
> On the contrary I think the BSSID needs to be configured for STA mode
> since it acts as a receive filter for broadcase/multicast frames.
> The 802.11 standard says in 7.2.2 Data frames:
>
> ? ? ? ?A STA uses the contents of the Address 1 field to perform address
> ? ? ? ?matching for receive decisions. In cases where the Address 1 field
> ? ? ? ?contains a group address, the BSSID also is validated to ensure that
> ? ? ? ?the broadcast or multicast originated from a STA in the BSS of which
> ? ? ? ?the receiving STA is a member.
>
> The ralinktech.com drivers seem to set the BSSID for STA mode and IBSS mode.
True, but the comment in rt2x00 says:
'empty BSSID address' and 'at this time'
The legacy drivers from Ralink configure the BSSID, same as rt2x00 driver do,
when we start the association procedure. This complies with the 802.11 standard
for filtering the data frames.
Ivo
On Tue, Nov 02, 2010 at 01:50:07PM +0100, Johannes Stezenbach wrote:
>
> While reading through the code I noticed the following in rt2800_config_intf():
>
> rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
>
> However, in Ralink source from http://www.ralinktech.com/support.php?s=2
> in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
> USHORT BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, 01: 2 BSSID , 11: 8BSSID
>
> This is different from rt73usb where 3 means "one BSSID".
Any comments on this?
I still have a very limited understanding of mac80211 and rt2xx code,
but I'm reading through the code and report what looks suspicious
to me. I hope that's OK? Here's another one:
In rt2x00lib_rxdone():
/*
* Allocate a new sk_buffer. If no new buffer available, drop the
* received frame and reuse the existing buffer.
*/
skb = rt2x00queue_alloc_rxskb(rt2x00dev, entry);
if (!skb)
return;
Should this not be "goto submit_entry;"?
Johannes
On Tue, Nov 02, 2010 at 04:05:36PM +0100, Helmut Schaa wrote:
> Am Dienstag 02 November 2010 schrieb Ivo Van Doorn:
> >
> > The legacy drivers from Ralink configure the BSSID, same as rt2x00 driver do,
> > when we start the association procedure. This complies with the 802.11 standard
> > for filtering the data frames.
>
> Yep, Ivo is correct.
Ah, I see. I missed the call in rt2x00mac_bss_info_changed().
Sorry for the noise and thanks for your comments.
Johannes
On Tue, Nov 02, 2010 at 01:50:07PM +0100, Johannes Stezenbach wrote:
>
> Sorry for slow response time. I can confirm that changing
> rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
> intf->mac, intf->bssid);
> to
> rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
> intf->mac, NULL);
> in rt2x00mac_add_interface() fixes rt73usb AP mode for me, too.
After studying the code some more, I'm confused by the
comment for this code in rt2x00mac_add_interface():
* The BSSID address must only be configured in AP mode,
* however we should not send an empty BSSID address for
* STA interfaces at this time, since this can cause
* invalid behavior in the device.
On the contrary I think the BSSID needs to be configured for STA mode
since it acts as a receive filter for broadcase/multicast frames.
The 802.11 standard says in 7.2.2 Data frames:
A STA uses the contents of the Address 1 field to perform address
matching for receive decisions. In cases where the Address 1 field
contains a group address, the BSSID also is validated to ensure that
the broadcast or multicast originated from a STA in the BSS of which
the receiving STA is a member.
The ralinktech.com drivers seem to set the BSSID for STA mode and IBSS mode.
Johannes
Am Mittwoch 03 November 2010 schrieb Johannes Stezenbach:
> On Wed, Nov 03, 2010 at 03:51:52PM +0100, Ivo Van Doorn wrote:
> > On Wed, Nov 3, 2010 at 3:14 PM, Johannes Stezenbach <[email protected]> wrote:
> > > On Tue, Nov 02, 2010 at 01:50:07PM +0100, Johannes Stezenbach wrote:
> > >>
> > >> While reading through the code I noticed the following in rt2800_config_intf():
> > >>
> > >> rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
> > >>
> > >> However, in Ralink source from http://www.ralinktech.com/support.php?s=2
> > >> in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
> > >> USHORT BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, 01: 2 BSSID , 11: 8BSSID
> > >>
> > >> This is different from rt73usb where 3 means "one BSSID".
> > >
> > > Any comments on this?
> >
> > Well RT3370 isn't rt73 ;)
> > Instead (altough I don't know this exact chipset), I suspect it to be
> > of the rt2800 family.
>
> OK, seems hat I wrote was confusing.
>
> rt73usb sets the field to 3 (meaning "one BSSID").
>
> But rt2800usb also sets it to 3, but it should be 0 (in rt2800_config_intf).
I would be fine with setting this to 0 but only in STA and IBSS mode. At
least in AP mode we want to keep the max value to be able to use multiple
AP mode interfaces.
Helmut
Am Mittwoch 03 November 2010 schrieb Johannes Stezenbach:
> On Tue, Nov 02, 2010 at 01:50:07PM +0100, Johannes Stezenbach wrote:
> >
> > While reading through the code I noticed the following in rt2800_config_intf():
> >
> > rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
> >
> > However, in Ralink source from http://www.ralinktech.com/support.php?s=2
> > in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
> > USHORT BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, 01: 2 BSSID , 11: 8BSSID
> >
> > This is different from rt73usb where 3 means "one BSSID".
>
> Any comments on this?
The BSSID mask in rt2800 is correct. Since we allow up to 8 AP mode interfaces
we really want to have a BSSID mask of 3.
Of course we could also create the BSSID mask dynamically but that would
complicate adding/removing interfaces. Thus we decided to stick with the
maximum value here.
Helmut
On Wed, Nov 03, 2010 at 03:50:20PM +0100, Ivo Van Doorn wrote:
>
> Absolutely true, I committed a patch for that 1 or 2 weeks ago,
> so that should be visible in compat-wireless by now.
grmbl, I was looking at wireless-testing updated on Monday, and it
seems I got an outdated tree due to the hera server fuckup :-(
Johannes
Hi,
>>
>> While reading through the code I noticed the following in rt2800_config_intf():
>>
>> ? ? ? ? ? ? ? rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
>>
>> However, in Ralink source from http://www.ralinktech.com/support.php?s=2
>> in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
>> ? ? ? ? ? ? ? ? USHORT ? ? ? ? ?BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, ?01: 2 BSSID , 11: 8BSSID
>>
>> This is different from rt73usb where 3 means "one BSSID".
>
> Any comments on this?
>
>
> I still have a very limited understanding of mac80211 and rt2xx code,
> but I'm reading through the code and report what looks suspicious
> to me. ?I hope that's OK? ? Here's another one:
Off course thats ok. :)
> In rt2x00lib_rxdone():
>
> ? ? ? ?/*
> ? ? ? ? * Allocate a new sk_buffer. If no new buffer available, drop the
> ? ? ? ? * received frame and reuse the existing buffer.
> ? ? ? ? */
> ? ? ? ?skb = rt2x00queue_alloc_rxskb(rt2x00dev, entry);
> ? ? ? ?if (!skb)
> ? ? ? ? ? ? ? ?return;
>
> Should this not be "goto submit_entry;"?
Absolutely true, I committed a patch for that 1 or 2 weeks ago,
so that should be visible in compat-wireless by now.
Ivo
Hi,
On Sat, Oct 30, 2010 at 02:30:15PM +0200, Helmut Schaa wrote:
> Am Freitag 29 Oktober 2010 schrieb Lee:
> > On 29/10/10 00:17, Helmut Schaa wrote:
> > > In commit f1aa4c541e98afa8b770a75ccaa8504d0bff44a7 "rt2x00: Write the BSSID
> > > to register when interface is added" we've added the bssid passing to the
> > > device in AP mode to fix hw crypto on rt2800 devices in AP mode. But maybe
> > > the older devices behave differently and don't like getting a bssid set
> > > in AP mode?
> > >
> > > Lee, if you just revert the commit you've identified are you able to use
> > > the device in AP mode with hw crypto?
> > >
> > Reverting that memcpy() to it's original parameters works for me (AP mode + hw
> > crypto).
>
> Thanks for the info Lee. So, in AP mode we need to set the bssid on rt2800
> devices in order to get hw crypto to work but on (at least) rt73 devices we
> may not set the bssid to get hw crypto to work :(
>
> Ivo, Gertjan, any ideas how to handle that case. I don't feel like introducing
> another device specific flag makes sense here?
Sorry for slow response time. I can confirm that changing
rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
intf->mac, intf->bssid);
to
rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
intf->mac, NULL);
in rt2x00mac_add_interface() fixes rt73usb AP mode for me, too.
(still using compat-wireless-2.6.36-rc3-1)
While reading through the code I noticed the following in rt2800_config_intf():
rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
However, in Ralink source from http://www.ralinktech.com/support.php?s=2
in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
USHORT BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, 01: 2 BSSID , 11: 8BSSID
This is different from rt73usb where 3 means "one BSSID".
I have not tested this change yet.
Johannes
On Wed, Nov 03, 2010 at 03:51:52PM +0100, Ivo Van Doorn wrote:
> On Wed, Nov 3, 2010 at 3:14 PM, Johannes Stezenbach <[email protected]> wrote:
> > On Tue, Nov 02, 2010 at 01:50:07PM +0100, Johannes Stezenbach wrote:
> >>
> >> While reading through the code I noticed the following in rt2800_config_intf():
> >>
> >> ? ? ? ? ? ? ? rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
> >>
> >> However, in Ralink source from http://www.ralinktech.com/support.php?s=2
> >> in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
> >> ? ? ? ? ? ? ? ? USHORT ? ? ? ? ?BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, ?01: 2 BSSID , 11: 8BSSID
> >>
> >> This is different from rt73usb where 3 means "one BSSID".
> >
> > Any comments on this?
>
> Well RT3370 isn't rt73 ;)
> Instead (altough I don't know this exact chipset), I suspect it to be
> of the rt2800 family.
OK, seems hat I wrote was confusing.
rt73usb sets the field to 3 (meaning "one BSSID").
But rt2800usb also sets it to 3, but it should be 0 (in rt2800_config_intf).
I assumed this is a copy&paste mistake.
My device has rt3070 chipset.
Johannes
On Wed, Nov 3, 2010 at 3:14 PM, Johannes Stezenbach <[email protected]> wrote:
> On Tue, Nov 02, 2010 at 01:50:07PM +0100, Johannes Stezenbach wrote:
>>
>> While reading through the code I noticed the following in rt2800_config_intf():
>>
>> ? ? ? ? ? ? ? rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
>>
>> However, in Ralink source from http://www.ralinktech.com/support.php?s=2
>> in DPO_RT3370_LinuxSTA_V2.4.0.1_20100831/include/chip/rtmp_mac.h it says:
>> ? ? ? ? ? ? ? ? USHORT ? ? ? ? ?BssIdMask:2; // 0: one BSSID, 10: 4 BSSID, ?01: 2 BSSID , 11: 8BSSID
>>
>> This is different from rt73usb where 3 means "one BSSID".
>
> Any comments on this?
Well RT3370 isn't rt73 ;)
Instead (altough I don't know this exact chipset), I suspect it to be
of the rt2800 family.
Ivo