[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ns] NAV bug in 802.11 MAC



I'm looking at precisely that problem, right now. Do you have a patch,
or
should I share the patch I do for this with you?

> 
> hi,
>   while on the 802.11 MAC, i have another bug (could be misinterpretation on
> my part) to report. my copy of the 802.11 spec
> has this to say about the EIFS (sec. 9.2.3.4):
> 
> "...The EIFS is defined to provide enough time for another STA to
> acknowledge what was, to this STA, an incorrectly received frame before this
> STA commences transmission. Reception of an error-free frame during the EIFS
> resynchronizes the STA to the actual busy/idle state of the medium, so the
> EIFS is terminated and normal medium-access (using DIFS and, if necessary,
> backoff) continues following reception of that frame."
> 
> currently, the set_nav() function does not remember if the nav_ was updated
> by an eifs_ and hence is_idle() does not adjust for the fact. thus (for
> example) if "this STA" receives an RTS during the EIFS, when it is ready to
> send the CTS (in check_pktCTRL()), its call to is_idle() will come up false.
> hence it will not respond with a CTS even though it is allowed to do so.
> similarly, a CTS correctly received during the EIFS may be ignored. the
> eifs_ is set to be long enough for either of these possibilities.
> 
> -neeraj


Mucking with the state variable might be more dangerous; the effect
that you create right now - is rather local in the sense that the
recvCTS sets your intermediate state, which is reset to the right
state by tx_resume immediately. If someone moved code around in
adding new stuff, it intermediate state will interfere will detection
of idle mac etc..
On the other hand the simulation seems to constantly rely on pkt
size at various instances..

> i had posted a message about this earlier, but got no response. my
> workaround was to add another rx state MAC_RECV_CTS. rx_state_ is set to
> MAC_RECV_CTS in recvCTS and tx_resume() checks for this state.
> so the relevant code in tx_resume() is something like:
> 
> if(tx_state_ == MAC_RTS && rx_state_ == MAC_RECV_CTS) {
>         mhDefer_.start(sifs_);
> } else {
>         mhDefer_.start(difs_);
> }
> 
> that may be safer than determining based on packet size. you can tell me if
> i'm wrong...

:a