A question about monitor mode

A question about monitor mode

[Severin Kacianka]

Hello,

I have a question about monitor mode and the monitor interface: When
will a frame show up in the monitor interface?

If I understand 802.11 correctly, there will first be a Request to Send
(RTS), then a Clear to Send (CTS) signal. Then the actual frame will be
send followed by an ACK.
I did some testing and it seems, that the frame shows up in the
monitoring interface after the ACK is received.
My test setup was to record the socket.send call of an UDP packet with
an unique ID and then measure the time it takes for that packet to be
read on the monitor interface.
As the measured time was not constant, but seemed to vary in relation to
the network conditions I suppose that the frame only shows up after its
delivery was acknowledged.

Is this observation correct and where in the kernel's source (or
elsewhere) should I look for more details?

Thank you for your time and best regards,
Severin

Re: A question about monitor mode

[Kalle Valo]

Severin Kacianka <severin.kacianka@aau.at> writes:

> I have a question about monitor mode and the monitor interface: When
> will a frame show up in the monitor interface?

The question doesn't really make sense, at least not to me. But I'll try
to answer anyway :)

To simplify, the path when a frame is received with a monitor interface is:

1. hardware
2. firmware
3. driver (eg. ath9k or ath10k)
4. mac80211
5. netdevice
6. user space

And all steps above can cause different amount of latency. So there is
not really a good answer how long it will take the frame to reach user
space.

> If I understand 802.11 correctly, there will first be a Request to
> Send (RTS), then a Clear to Send (CTS) signal. Then the actual frame
> will be send followed by an ACK. I did some testing and it seems, that
> the frame shows up in the monitoring interface after the ACK is
> received.
>
> My test setup was to record the socket.send call of an UDP packet with
> an unique ID and then measure the time it takes for that packet to be
> read on the monitor interface. As the measured time was not constant,
> but seemed to vary in relation to the network conditions I suppose
> that the frame only shows up after its delivery was acknowledged.

There is a strict timing requirements when the ack frame must be sent so
in most of the designs hardware or firmware transmits the ack, host
software (driver/mac80211) cannot provide such accuracy.

-- 
Kalle Valo

Re: A question about monitor mode

[Severin Kacianka]

On 06/04/2014 02:48 PM, Kalle Valo wrote:
> The question doesn't really make sense, at least not to me. But I'll try
> to answer anyway :)

Thank you - I will try to better state my question. Let's say we have
two nodes A and B and A sends a packet to B while monitoring all
wireless traffic on mon0. We now have two scenarios when A sees its
packet in its monitor interface.
The first scenario is, that the packet shows up right after it is send
(i.e. after calling socket.send). The other is, that the packet is held
in some layer (probably the firmware) until the ACK is received and the
packet was really "send" before being passed to the monitoring interface.

In my concrete case, I have a program that sends RTP packets to an other
host. It logs the time of the socket.send call and then also logs the
time the packet is read from mon0 (RTP packets have sequence numbers, so
it is easy to match the packets).
I then noticed that this delay is usually extremely small (around 0.001
sec), but will quickly rise when the receiver is moved away from the
sender (up to 10 seconds and more). Along with this rise in the delay
the video quality will degrade to unwatchable when the delay rises
quickly (and quickly improves when the delay gets smaller).

My assumption is that the packet first has to be acknowledged, before it
shows up in the monitoring interface. Due to the movement the connection
quality is probably reduced and thus may require retransmissions (and so
increase this delay).

I am however not sure if this is how it really works :)

Thank you,
Severin