Dear ns users;
When the RTS/CTS is enabled, the following trace is obtained; s 10.110075000 _1_ MAC --- 0 RTS 44 [239e 0 1 0] r 10.110427170 _0_ MAC --- 0 RTS 44 [239e 0 1 0] s 10.110437170 _0_ MAC --- 0 CTS 38 [2264 1 0 0] D 10.110741339 _1_ MAC STA 0 CTS 38 [2264 1 0 0] s 10.110995000 _1_ MAC --- 0 RTS 44 [239e 0 1 0] D 10.111347170 _0_ MAC BSY 0 RTS 44 [239e 0 1 0] s 10.112115000 _1_ MAC --- 0 RTS 44 [239e 0 1 0] D 10.112467170 _0_ MAC BSY 0 RTS 44 [239e 0 1 0] s 10.114015000 _1_ MAC --- 0 RTS 44 [239e 0 1 0] D 10.114367170 _0_ MAC BSY 0 RTS 44 [239e 0 1 0] s 10.115915000 _1_ MAC --- 0 RTS 44 [239e 0 1 0] D 10.116267170 _0_ MAC BSY 0 RTS 44 [239e 0 1 0] D 10.116585000 _1_ MAC RET 0 RTS 44 [239e 0 1 0] D 10.116585000 _1_ MAC --- 6 cbr 1060 [13a 0 1 0] ------- [1:1 0:1 32 0] [0] 0 0 After I read the code in the file Mac802_11e.cc, I found that other priorities than priority 0 are not supported. RTS does not convey the priority information, and the responding node always reply with a priority-0 CTS. Therefore, I guess that the initiating node having a packet with priority 1, 2, or 3 will have the wrong state (STA in the above trace). The successive RTS's retransmitted by the initiator are all discarded by the responder which is waiting DATA packet. I know that TKN group said that they did not test the RTS/CTS mechanism. Is there anybody who had this experience? Any comments, patch or help will be appreciated very much. Thank you for reading. K. Lee [EMAIL PROTECTED]
