Bugzilla – Bug 585
NAV bug
Last modified: 2009-06-19 03:04:42 EDT
You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=459) [details] propsed fix NAV must not be set to itself (see setting and resetting NAV of 802.11 -2007). I have only removed setting NAV to itself, but now I think, that it is not reasonable to pass any information to DcfManager, because I do not know, what shall we do when frame exchange terminates earlier (for example, what shall we do if there is no data goes after CTS?) that it was declared (Standart says, that we may pass one more frame of the sae queue, but I do not know how exactly we shall implement this, because I did not work with frame exchange sequences, except CTS/RTS), So the patch below only solves a problem with NAV.
Created an attachment (id=460) [details] Correct patch, sorry for previous :) This is a correct patch
why don't you want to pass information to DcfManager anymore ?
Now chapter 9.9.1.4 is not implemented at all, so, passing information to DcfManager is unneded now. The second problem - how to determine the ond of frame exchange sequence and its failure
(In reply to comment #3) > Now chapter 9.9.1.4 is not implemented at all, so, passing information to > DcfManager is unneded now. The second problem - how to determine the ond of > frame exchange sequence and its failure I am sorry but I cannot parse this sentence: can you rephrase what you mean here ?
Sorry for late reply. I think, that chapter 9.9.1.4 is not implemented at all at the moment, so there is no reason to pass information about remaining NAV to DcfManager. Also I have now idea about catching situations, when frame exchange sequence was interrupted (due to collision, for example)
changeset 19c0844361f3