Noam Mori has found a serious bug in a unicast messages mechanism in 802_11 MAC protocol. The bug is related to a wrong handling of duplicate message elimination in 802.11. As a result, the same message could be delivered twice to a higher layer, despite the duplicate message elimination mechanism present in 802.11.

This bug is originated from the following method (this is the original code): file Mac802_11.java:

public void sendDataUnicast(boolean afterCts)
{

// create data packet
MacMessage.Data data = new MacMessage.Data(
        packetNextHop, localAddr, (int)(
              MacMessage.Ack.SIZE*Constants.SECOND/bandwidth
              + (SYNCHRONIZATION + PROPAGATION + SIFS)
              + PROPAGATION),
        incSeq(), (byte)0, false,
        (shouldRTS() ? longRetry : shortRetry) > 0,
        packet);

// set mode and transmit
setMode(MAC_MODE_XUNICAST);
long delay = afterCts ? SIFS : RX_TX_TURNAROUND, duration = transmitTime(data);
radioEntity.transmit(data, delay, duration);

// wait for EOT, and schedule ACK timer
JistAPI.sleep(delay+duration);
self.startTimer(MacMessage.Ack.SIZE*Constants.SECOND/bandwidth
        + (SYNCHRONIZATION + PROPAGATION + SIFS)
        + SLOT_TIME
        + PROPAGATION,
        MAC_MODE_SWFACK);

}
 

The fix is:

public void sendDataUnicast(boolean afterCts)
{

//Changed by Noam Mori
short augmentedSeq = (shortRetry+longRetry)==0?incSeq():seq;
// create data packet
MacMessage.Data data = new MacMessage.Data(
        packetNextHop, localAddr, (int)(
              MacMessage.Ack.SIZE*Constants.SECOND/bandwidth
              + (SYNCHRONIZATION + PROPAGATION + SIFS)
              + PROPAGATION),
        augmentedSeq, (byte)0, false,
        (shouldRTS() ? longRetry : shortRetry) > 0,
        packet);

// set mode and transmit
setMode(MAC_MODE_XUNICAST);
long delay = afterCts ? SIFS : RX_TX_TURNAROUND, duration = transmitTime(data);
radioEntity.transmit(data, delay, duration);

// wait for EOT, and schedule ACK timer
JistAPI.sleep(delay+duration);
self.startTimer(MacMessage.Ack.SIZE*Constants.SECOND/bandwidth
        + (SYNCHRONIZATION + PROPAGATION + SIFS)
        + SLOT_TIME
        + PROPAGATION,
        MAC_MODE_SWFACK);

}

This change makes sure that if a message is retransmitted (because the Ack of the first transmission has not been received), the message keeps its original sequential number. This means that if the destination node did hear the original message and the Ack got lost due to some collision, then, when the target receives the retry it knows that it has already got this message, because the sequential number will be the same.
Before the fix, each retry had a different sequential number which caused the receiver erroneously think that this message was a brand new, in case it received both tries.

Gabriel Kliot

08/23/2008