Re: [ns] NAV bug in 802.11 MAC

["Neeraj Poojary" <legolas_3@hotmail.com>]

aman,
i don't have a patch for the NAV problem. please let me know when you have 
one ready.

you're right about the possible side-effects from creating an intermediate 
recv state. i should change my code.

thanks,
neeraj

>From: Aman Singla <aman@atheros.com>
>To: Neeraj Poojary <legolas_3@hotmail.com>
>CC: ns-users@ISI.EDU
>Subject: Re: [ns] NAV bug in 802.11 MAC
>Date: Thu, 07 Sep 2000 12:59:20 -0700
>
>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

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.