Bug 393 - Recovery mechanism present on broadcast/multicast frames
: Recovery mechanism present on broadcast/multicast frames
Status: VERIFIED FIXED
: IPW2200
IBSS
: 0.13
: All All
: P2 major
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-11-17 04:51 by
Modified: 2005-10-03 15:31 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-11-17 04:51:05
- make IBSS connection between two devices
- send continuous broadcast PING from one machine

You can see, that there are multiple PING responses for each broadcast PING.
Sniffer reveals the reason:

One side retransmits PING reqs, because it receives no ACK for it. This is 
wrong. According to standard:

'Upon successful reception of a frame of a type that requires acknowledgment 
with the ToDS bit set, an AP shall generate an ACK frame. An ACK frame shall be 
transmitted by the destination STA that is not an AP, whenever it successfully 
receives a unicast frame of a type that requires acknowledgment, but not if it
receives a broadcast or multicast frame of such type.'

and:

'There is no MAC-level recovery on broadcast or multicast frames, except for 
those frames sent with the ToDS bit set.'

So, device must not retransmit broadcast/multicast frames since it must not 
wait for ACKs.
In the test above, retransmition of PING reqs stops upon reception of first 
PING reply.

Test was performed on two BG cards.
------- Comment #1 From 2004-11-21 22:27:27 -------
Fixed in 0.14.  I modified the Tx code patch such that if the Tx destination is
multicast or broadcast, we request that the firmware not require an ACK on the
packet.
------- Comment #2 From 2004-11-22 18:50:39 -------
can't verify this fix now, will verify it when bug 413 is fixed.
------- Comment #3 From 2004-11-25 02:33:15 -------
I don't see a reason why to wait for #413.
Just verified in 0.15.