RTS/CTS not fully disabled?
ahuguet at cttc.es
ahuguet
Mon May 21 04:03:04 PDT 2007
Greetings,
I'm doing some experiments, and using Ethereal to capture the network
traffic to check how the system behaves.
One of the things I've noticed is that some nodes try to use the RTS/CTS
mechanism, even if the RTS threshold is set to off through the iwconfig
command.
Ethereal screenshot link:
http://img227.imageshack.us/img227/8062/etherealwk7.png
The higlighted Z-com 2d:a4:1a broadcast packet is a custom one that
triggers the reaction of the nearby nodes, that immediately try to send
data to the 2d:a4:1a node.
It's expectable that collisions will take place, and retries would be
necessary, although, the RTS/CTS mechanism should remain unused during the
experiment.
Particularly, in the screenshot you can see how node a8:a8 and a8:bb fail
to receive an ACK to their frame, so they keep trying (the retry limit is
set to 8 in all nodes) until they receive the ACK (and they don't use any
RTS/CTS mechanism in those attempts).
Although, the a8:f5 node, tries one time and fails, tries a second one and
fails, and then it starts a RTS/CTS mechanism with 2d:a4:1a.
This shouldn't happen, and, it's also noticeable that upon reception of
the CTS, the node doesn't react sending the packet, but stays in a loop,
sending another RTS.
This behavior is not particular of a8:f5 node, at each experiment, there
can be a different node which behaves that way.
I'd like to know if there's an explanation about this behavior and how
could I avoid it, if possible.
The settings are as follow:
a4:1a is the master node, with a 11M auto speed.
There are 10 other nodes, managed, with fixed 11M speed.
The RTS threshold is set to off in all of them. (I also tried setting it
to a high number, like 2000B to see if it was disabled that way, but it
also failed)
The MAC retry limit is set to 8 in all of them.
The managed modes are set to promiscuous mode (iwpriv wlan0 set_rid_word
64645 1)
I'd like some help in order to clarify the reasons of this behavior.
Thanks in advance.
More information about the Hostap
mailing list