Bug in Mac80211 in MiXiM post-backoff

This entry was posted by on Friday, 16 December, 2011 at

Post-backoff was introduced into IEEE 802.11 to make sure that a station could not claim the channel by noting that the channel was idle after its own transmission, and then immediately transmit again. The idea is quite simple; transmission over -> pull a backoff from the contention window and count down (respecting the same rules w.r.t. carrier sense and inter-frame spacing etc.) and finally end up in the idle state. If a new packet was handed down by the network layer during post-backoff, the countdown would continue and result in a transmission. This behaviour is also implemented in MiXiM’s Mac80211 (and prior to that in the Mobility Framework). However, there’s a bug.

Fixed in MiXiM v2.2

What went wrong
The Extended Inter-Frame Spacing (EIFS) is used after a station observes an error in a received frame. This can be due to propagation (multipath, signal strength etc.) or because of a collision. The reasoning is that, though Station1 was not able to decode the frame, Station2 may be able to properly receive it and send an ACK to the transmitter of the frame. Station1, in the mean time, should allow Station2 to send this ACK. Hence, EIFS is defined as:


Now, what MiXiM’s Mac80211 does is, upon reception of a corrupted frame, set currentIFS to EIFS. Upon reception of a correct frame currentIFS is set to DIFS. All correct, but what this means is that a station can receive a corrupt frame, set currentIFS = EIFS and perform post-backoff. Then, say a few seconds later when it wants to transmit a new frame, currentIFS is still set to EIFS. This is wrong, because the EIFS pertains to the previously received frame, and was actually used to delay post-backoff.

How to fix it
The fix is relatively straight-forward: whenever a station completes post-backoff, currentIFS should be reset to DIFS (or AIFS[AC] in case of Mac80211p).

Proposed change in handleEndContentionTimer():

void Mac80211::handleEndContentionTimer()
    if(!contention->getResult().isIdle()) {

    if(state == IDLE) {
        remainingBackoff = 0; 
            currentIFS = DIFS;
    else if(state == CONTEND) {

The result is that currentIFS is reset to its “error-free” state; to be used during CCA for the next transmission.

Bug in Mac80211 in MiXiM backoff when channel busy – the missing contention delay.
MiXiM 802.11 – is CSMA/CA implemented correctly? – about the way CCA prior to transmission / backoff decision is modelled.

One Response to “Bug in Mac80211 in MiXiM post-backoff”

  1. si chen

    Is it really fixed in MiXiM 2.2? How come I still see the bug as it was?

Leave a Reply