0

Using Mininet for Wifi's Python API I am simulating one AP and two stations. The AP is at '0,0,0' and sta1 is at '0,10,0'. I am moving sta2 back and forth on a line '0,50,0' through '0,150,0'. Also, I have an extra radio configured when creating Mininet. Then in another window I put the extra radio's wlan interface in monitor mode, and capture the wifi traffic using tcpdump/Wireshark.

I was expecting to see the RSSI in the Radiotap headers to vary as the sta2 moves between 50 and 150 meters. But I see that the RSSI for each station to be fixed at 30 and 36dBm. What am I missing, why does the SSI not change as I believe it should? Is it because of some limitation of mac80211_hwsim or Mininet itself, or is my expectation incorrect?

The test Python program is here, and the captured tcpdump/Wireshark for the pings is here. Note that in the capture I have filtered out the beacons to keep minimum the packets the examine. Given the larger file sizes I have provided pointers to where you may download the two relevant files.

Cap
  • 99
  • 2
  • 11

1 Answers1

1

Although you are able to get the rssi through py staX.params['rssi'], mac80211_hwsim takes into account only the power_level (or tx power) in its formula, as you can see at row 1211 in https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c. That's why the RSSI doesn't change in the beacons.

Ramon Fontes
  • 156
  • 4
  • In the captured data I note that the AP transmitted frames have SSI or -30dBm, but those by the APs are "-36dBm". Why are these different? Are these set per frames from user space (Mininet)? I would imagine them to be the same if there wasn't anything done differently on each side. I understand & agree that within the Mininet API only the local / Mininet's view of SSI is reported. – Cap Nov 23 '16 at 16:29
  • Tx Power for AP probably is 20dBm (20 - 50 = -30) and for stations 14dBm (14 - 50 = -36). Please observe that the formula is defined as rx_status.signal = data->power_level - 50; – Ramon Fontes Nov 23 '16 at 17:03
  • Thanks. That helped me explore and understand better some of the pieces in the context, and hence the constraints on mac80211_hwsim. It would be interesting if a user space process could intercept packets flowing through the hwsim, and influence the SSI... it would make the data path slower, but would also help better test the RSSI handling by upper layers in the stack. – Cap Nov 24 '16 at 00:33
  • Yes. I totally agree with you. In my opinion there is an easy alternative: if we change "iw" in order to send the information of rssi to the kernel space (mac80211_hwsim). Unfortunately I couldn't work on this issue yet, but I'm planning to do so in the future. – Ramon Fontes Nov 24 '16 at 10:58
  • There seems to be another project, klem (https://github.com/stuartwells4/klem), that seems interesting, but I am not sure how active it is. – Cap Nov 24 '16 at 13:04
  • Alternative to changing "iw" I suspect that libnetfilter_queue may be more effective. libnetfilter_queue will allow a user to register for packets received or going out, then update a receiving/sending packet (SSI in our case), and then set the verdict to drop or modify/continue. It would only make sense in case of mac80211_hwsim but not in case of real hardware, at least as far as updating SSI on receive side is concerned. – Cap Nov 24 '16 at 14:27
  • 1
    Hi, RSSI varies in Mininet-WiFi right now: https://www.youtube.com/watch?v=gtaHCpaHBGc – Ramon Fontes Mar 01 '17 at 19:17