Hello!
As I wrote before, bcm43xx_d80211 connects quickly to an 802.11g AP only
if it doesn't support OFDM modes (bcm43xx_g_ratetable_size changed from
12 to 4). Actually, association is not a problem, but no data goes
through for several minutes.
I'm attaching a capture file of an unsuccessful APR exchange following
the association.
The AP is current MadWifi, MAC address 00:0F:B5:35:73:D8. The STA is
current bcm43xx_d80211 from mb branch, PCIe 4312, MAC address
00:19:7D:21:7B:50. The capture is done by another system running
Wireshark 0.99.5 and current MadWifi in monitor mode.
AP broadcasts a beacon announcing that it supports rates from 1 to
54Mbps. The flags indicate short preamble, spectrum management and
short slot time.
STA broadcasts an ARP request at 36Mbps. QoS field requests normal ACK.
STA receives ACK at 24Mbps.
STA broadcasts another ARP request, this time at 1Mbps. It's a non-QoS
data frame. However, the flags indicate that it's a frame from DS not
to DS, unlike the previous ARP request that got that part correctly!
AP rends APR reply at 5.5Mbps. QoS field requests normal ACK, which
never arrives.
AP sends another such frame with retry bit set, followed by 6 more
frames at 1Mbps. QoS field requests normal ACK, which never arrives.
STA broadcasts an ARP request at 36Mbps. To-DS is set correctly. Retry
bit is set. QoS field requests normal ACK.
STA receives ACK at 24Mbps.
STA broadcasts an ARP request at 24Mbps. To-DS is set correctly. Retry
bit is set. QoS field requests normal ACK.
Following seems wrong to me:
1) STA sends some packets with From-DS instead of To-DS. I've seen more
than one such packet, and they are always sent at 1Mbps.
2) STA doesn't send ACK to frames specifically requesting it (if I
understand the Wireshark interpretation correctly).
--
Regards,
Pavel Roskin
On Mon, 2007-02-19 at 21:28 -0500, Pavel Roskin wrote:
> My first assumption was that the field QoS confuses it, but looking at
> the code, it's more likely a low-level problem.
bcm43xx firmware can definitely handle QoS.
> I'll try to see if the
> frame is even seen by the driver.
I would expect you to find that it is not, but just run a monitor
interface in addition.
> I agree. The frames are either not received physically or thrown out.
> Which makes me wonder why the association happens so quickly. Perhaps
> it's done at lower rates.
Could you start capturing earlier to confirm this?
> When ping finally starts working, all the data is transmitted at 1Mbps.
> And the QoS field is still there , so it's not a problem by itself.
Didn't you say that you're using mb's tree? You have a 4311 IIRC so I
wouldn't be surprised if there are problems with receive sensitivity
that go away after, say, two minutes (recalibration interval).
johannes
Hi, Jouni!
Thanks for quick and helpful reply!
On Mon, 2007-02-19 at 17:58 -0800, Jouni Malinen wrote:
> On Mon, Feb 19, 2007 at 08:31:25PM -0500, Pavel Roskin wrote:
> > STA broadcasts another ARP request, this time at 1Mbps. It's a non-QoS
> > data frame. However, the flags indicate that it's a frame from DS not
> > to DS, unlike the previous ARP request that got that part correctly!
>
> This is the same ARP packet being sent out by the AP and this time it is
> actually transmitted to broadcast address (and no ACK, as expected).
That's a relief. I should pay more attention to the order of addresses,
not just to the contents of the "source" column.
> > AP rends APR reply at 5.5Mbps. QoS field requests normal ACK, which
> > never arrives.
> >
> > AP sends another such frame with retry bit set, followed by 6 more
> > frames at 1Mbps. QoS field requests normal ACK, which never arrives.
>
> It looks like the client has some problems receiving this frame or
> ACKing it..
My first assumption was that the field QoS confuses it, but looking at
the code, it's more likely a low-level problem. I'll try to see if the
frame is even seen by the driver.
> > STA broadcasts an ARP request at 36Mbps. To-DS is set correctly. Retry
> > bit is set. QoS field requests normal ACK.
> >
> > STA receives ACK at 24Mbps.
>
> This is odd.. This frame is a retry of the first ARP request. In other
> words, it looks like the non-AP STA did not receive the ACK from the AP.
> What's even stranger is that it took so long to retry the frame that the
> AP had enough time to actually send its reply multiple times.. It looks
> like the non-AP STA is just not receiving any frames from the AP at this
> point.
I agree. The frames are either not received physically or thrown out.
Which makes me wonder why the association happens so quickly. Perhaps
it's done at lower rates.
When ping finally starts working, all the data is transmitted at 1Mbps.
And the QoS field is still there , so it's not a problem by itself.
> > 2) STA doesn't send ACK to frames specifically requesting it (if I
> > understand the Wireshark interpretation correctly).
>
> And continues retrying a packet ACK'ed by the AP. In other words, the
> non-AP STA does not seem to be receiving anything here (either data or
> ACK to stop retransmission of its own data frame). And this is not only
> OFDM frames getting lost (all ACKs were using 24 Mbps), but also 1 and
> 5.5 Mbps frames in the case of ARP response..
That's the most interesting part, especially that ARP responses at 1Mbps
are ignored.
It looks like my doubts about the d80211 stack were wrong, and the
solution is deeper in the driver, almost certainly on the receiving
side.
--
Regards,
Pavel Roskin
On Mon, Feb 19, 2007 at 08:31:25PM -0500, Pavel Roskin wrote:
> STA broadcasts an ARP request at 36Mbps. QoS field requests normal ACK.
That's not broadcast transmission in IEEE 802.11 (or well, the frame is
to broadcast address eventually, but the ToDS frame from non-AP STA is a
unicast transmission to the AP(BSSID).
> STA receives ACK at 24Mbps.
As expected for a unicast transmission.
> STA broadcasts another ARP request, this time at 1Mbps. It's a non-QoS
> data frame. However, the flags indicate that it's a frame from DS not
> to DS, unlike the previous ARP request that got that part correctly!
This is the same ARP packet being sent out by the AP and this time it is
actually transmitted to broadcast address (and no ACK, as expected).
> AP rends APR reply at 5.5Mbps. QoS field requests normal ACK, which
> never arrives.
>
> AP sends another such frame with retry bit set, followed by 6 more
> frames at 1Mbps. QoS field requests normal ACK, which never arrives.
It looks like the client has some problems receiving this frame or
ACKing it..
> STA broadcasts an ARP request at 36Mbps. To-DS is set correctly. Retry
> bit is set. QoS field requests normal ACK.
>
> STA receives ACK at 24Mbps.
This is odd.. This frame is a retry of the first ARP request. In other
words, it looks like the non-AP STA did not receive the ACK from the AP.
What's even stranger is that it took so long to retry the frame that the
AP had enough time to actually send its reply multiple times.. It looks
like the non-AP STA is just not receiving any frames from the AP at this
point.
> Following seems wrong to me:
>
> 1) STA sends some packets with From-DS instead of To-DS. I've seen more
> than one such packet, and they are always sent at 1Mbps.
No, it doesn't. This is AP re-transmitting the broadcast frame (this
time as a real broadcast transmission). This is the way IEEE 802.11 is
supposed to work..
> 2) STA doesn't send ACK to frames specifically requesting it (if I
> understand the Wireshark interpretation correctly).
And continues retrying a packet ACK'ed by the AP. In other words, the
non-AP STA does not seem to be receiving anything here (either data or
ACK to stop retransmission of its own data frame). And this is not only
OFDM frames getting lost (all ACKs were using 24 Mbps), but also 1 and
5.5 Mbps frames in the case of ARP response..
--
Jouni Malinen PGP id EFC895FA
On Tuesday 20 February 2007 09:23, Johannes Berg wrote:
> > When ping finally starts working, all the data is transmitted at 1Mbps.
> > And the QoS field is still there , so it's not a problem by itself.
>
> Didn't you say that you're using mb's tree? You have a 4311 IIRC so I
> wouldn't be surprised if there are problems with receive sensitivity
> that go away after, say, two minutes (recalibration interval).
My tree has serious transmission problems (TX and I think RX, too).
I'd like to fix that as soon as possible, but I really can't find the
damn bug. It's kind of: I verified the whole PHY code for sanity and
correctness, but still don't see where it is.
Maybe we can workaround that by driving the card at highest
attenuation control values, always. But that would obviously break
regulatory domain laws, so... .
Let's try to find the bug. :)
If someone wants to help searching, please do so. I'm kind of
running out of ideas where to search.
It's some issue with the idle-TSSI measurement in the PHY powercontrol
init code. We almost always get a 0 value there, but we should
get something around 50. That messes up attenuation control, later.
Well, why do we get a 0 there? I have no idea. Must be a bug somewhere
in the code that's run before the idle-TSSI is measured.
--
Greetings Michael.