I am working on a research project whose goal is to make testing alternative fast WiFi handoff (akin to 802.11r) protocols/algorithms easier. The way I plan to accomplish this at a high level is to tell a system (User Equipment) that it is gaining signal strength from a new AP while losing it with its currently associated AP. This is to simulate the model of moving from one AP to another where both APs are parallel to the line of motion of the UE. (Other physical models will be simulated later, if time permits.)

At a lower level, I am getting lost amid the modules and drivers. Initially, I believed that wpa_supplicant would be the code/module to "trick" into believing signal changes were occurring. However, I now think that it might be wiser to alter all messages related to signal strength across the netlink interface. I am unsure how many consumers of signal strength messages from the driver(s) exist; thus it seems wiser to alter them as close to the source of these messages as possible.

My question in a nutshell: Which files will I need to modify to trick a Linux system into believing it is experiencing different signal strength(s) than it really is? An ideal answer would trick as much of the system as possible, but a simpler solution that only tricks modules that handle AP association might be more realistic.

(I am not asking for C-programming advice on how to exactly implement this, as that would not be suitable for this particular StackExchange.)

  • watch -n 1 cat /proc/net/wireless This command will give you dynamic status (i.e. per sec) of link quality of Wireless device.
    – SHW
    Commented Apr 10, 2015 at 8:04
  • @SHW That is helpful information to have. Thank you. Commented Apr 10, 2015 at 13:43

1 Answer 1


Maybe you could do your research on the ns-3 platform?

ns-3 A network simulator for Internet systems

It abstracts away all the low level issues, and let you concentrate on the concrete research goal providing a high level API for simulation to you.

Good luck.

  • Well, the goal is actually to provide the simulator such that it could be run on arbitrary Linux devices. As strange (and non-researchy) as it sounds, my goal is to provide the low level details such that the end result becomes a simulation/emulation that is only different from a production setting in this single respect. Thank you for your advice though. Commented Apr 1, 2015 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .