|
Bugzilla – Full Text Bug Listing |
| Summary: | RTS/CTS NAV reset prematurely | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | marco.porsch |
| Component: | wifi | Assignee: | Daniel L. <nikkipui> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | ns-bugs, ruben, tomh |
| Priority: | P5 | ||
| Version: | ns-3.16 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
proposed patch
The same patch from the latest ns-3-dev |
||
Created attachment 1677 [details]
The same patch from the latest ns-3-dev
The same patch but diff from the current ns-3-dev.
I agree that the two fixes are needed.
- tested with a small network with 3 nodes. NAV was indeed reset prematurely
- the assignment to m_lastNavStart is obviously incorrect (should be m_lastNavDuration as in the patch)
All tests in "test.py -c core" pass after applying the patch.
If anyone has any comment, please let me know. Otherwise, I think the patch is ready to go.
Actually, the m_lastNavDuration issue was the same as Bug 1681. Some discussion in there suggests that more work may be needed to confirm the second m_lastNavDuration issue before proceeding. |
Created attachment 1604 [details] proposed patch in mac-low.cc : NotifyNav there is a timeout set, in case no CTS is received to an RTS. There is a comment stating: "A STA [...] is permitted to reset its NAV if no PHY-RXSTART.indication is detected [some time after] the RTS frame." Unfortunately the check at timer expiry seems to be wrong, and perfoms an NAV reset when it should not. Also DoNavResetNow looks a bit sketchy. Please see my attached patch.