wmediumd interference mode: scan_results signal values don't update when station position changes

[valentt]

Description

When using wmediumd in interference mode, the signal values reported by wpa_cli scan_results do not update when a station's position changes via setPosition(). However, the connected AP signal (from iw link) DOES update correctly.

This makes WiFi handoff/roaming impossible to simulate because the station always sees the initial AP as "best" regardless of physical position.

Environment

Mininet-WiFi version: 2.7 (from git)
OS: Ubuntu 22.04
wmediumd: installed via Mininet-WiFi
Python: 3.10
Steps to Reproduce

#!/usr/bin/env python3
from mininet.node import Controller
from mininet.log import setLogLevel, info
from mn_wifi.net import Mininet_wifi
from mn_wifi.link import wmediumd
from mn_wifi.wmediumdConnector import interference
import time

def test():
net = Mininet_wifi(controller=Controller,
link=wmediumd, wmediumd_mode=interference)

sta1 = net.addStation('sta1', position='15,33,0', bgscan_threshold=-60,
                      s_inverval=5, l_interval=10, bgscan_module='simple')
ap1 = net.addAccessPoint('ap1', mac='00:00:00:00:00:01', ssid='test',
                         mode='g', channel='1', passwd='123456789a',
                         encrypt='wpa2', position='10,30,0', datapath='user')
ap2 = net.addAccessPoint('ap2', mac='00:00:00:00:00:02', ssid='test',
                         mode='g', channel='1', passwd='123456789a',
                         encrypt='wpa2', position='30,30,0', datapath='user')
ap3 = net.addAccessPoint('ap3', mac='00:00:00:00:00:03', ssid='test',
                         mode='g', channel='1', passwd='123456789a',
                         encrypt='wpa2', position='50,30,0', datapath='user')
c1 = net.addController('c1')

net.setPropagationModel(model='logDistance', exp=3)
net.configureNodes()
net.addLink(ap1, ap2)
net.addLink(ap2, ap3)
net.build()
c1.start()
ap1.start([c1])
ap2.start([c1])
ap3.start([c1])

time.sleep(8)

for x in [15, 35, 55]:
    sta1.setPosition(f'{x},33,0')
    time.sleep(2)

    # Connected signal (WORKS - updates with position)
    connected_sig = sta1.cmd('iw dev sta1-wlan0 link | grep signal').strip()

    # Scan signal (BROKEN - stays static)
    sta1.cmd('wpa_cli -i sta1-wlan0 scan')
    time.sleep(2)
    scan = sta1.cmd('wpa_cli -i sta1-wlan0 scan_results | grep test')

    info(f'Position x={x}:\n')
    info(f'  Connected: {connected_sig}\n')
    info(f'  Scan:\n{scan}\n')

net.stop()

if name == 'main':
setLogLevel('info')
test()
Expected Behavior

At position x=55 (5m from AP3, 45m from AP1):

Scan AP1: ~-65 dBm (far)
Scan AP2: ~-50 dBm (medium)
Scan AP3: ~-35 dBm (close, strongest)
Station should see AP3 as strongest and potentially handoff.

Actual Behavior

At ALL positions (x=15, 35, 55):

Scan AP1: -39 dBm (SAME - cached from initial)
Scan AP2: -51 dBm (SAME)
Scan AP3: -62 dBm (SAME)
Connected signal DOES change correctly:

x=15: -39 dBm
x=35: -58 dBm
x=55: -65 dBm
Analysis

Two different signal calculation paths exist:

Connected AP signal (iw link): Uses position-based calculation - WORKS
Scan results signal (wpa_cli scan_results): Uses static/cached values - BROKEN
The setPosition() method calls set_pos_wmediumd() which sends position updates to wmediumd. This correctly updates the connected AP signal but does NOT update the signal values returned during scans.

Impact

WiFi handoff/roaming cannot be simulated
bgscan triggers but never switches AP (always sees initial AP as "best")
Research on handoff optimization is blocked
handover_bgscan.py example cannot demonstrate actual handoff programmatically
Attempted Workarounds (all failed)

wpa_cli bss_flush - Clears cache but new scan shows same values
Multiple consecutive scans - Same static values
Longer wait times - No effect
Different channels - No effect
Reset node.lastpos - No effect on scan values
Possible Root Cause

The scan response in mac80211_hwsim may be generated independently of wmediumd's position-based signal calculation. Scan frames might bypass the wmediumd signal attenuation that applies to data frames.

Related Files

mn_wifi/node.py: setPosition(), set_pos_wmediumd()
mn_wifi/wmediumdConnector.py: update_pos(), w_pos class
wmediumd source: signal calculation for scan vs data frames
Additional Context

This was discovered while testing mesh routing protocol handoff using Babel/Apex on the backhaul with WiFi client mobility. We verified:

Stock handover_bgscan.py has same issue
Problem exists regardless of AP spacing (10m to 50m)
Problem exists on same-channel and different-channel configurations
Connected signal always updates correctly
Only scan signal is broken

[ramonfontes]

Hi,

Have you tried using makeTerm() instead of node.cmd()? You could also try running scan_results manually from an xterm to see the output directly.

[valentt]

Hi Ramon, Thank you for the quick response. I have not yet tried makeTerm() - good suggestion. I will test this and report back with: 1. Screenshot of xterm showing scan results at position 1 (near AP1) 2. Screenshot of xterm showing scan results at position 2 (near AP2, far from AP1) 3. Comparison of signal values For context: when I move the station from (15,30,0) to (75,30,0), the connected signal (via iw link) correctly drops from -39 to -65 dBm. However, iw scan continues to show AP1 at -39 dBm even when the station is 60+ meters away. Will update with screenshots.

…

On Thu, 25 Dec 2025 at 23:58, Ramon Fontes ***@***.***> wrote: *ramonfontes* left a comment (intrig-unicamp/mininet-wifi#606) <#606 (comment)> Hi, Have you tried using makeTerm() instead of node.cmd()? You could also try running scan_results manually from an xterm to see the output directly. — Reply to this email directly, view it on GitHub <#606 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEXSZN4XNODF62TULRNGPD4DRTYBAVCNFSM6AAAAACQAQU4UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOJRHAYDCMRZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[valentt]

Hi Ramon,

Thanks for the quick response!

We're running on a headless Ubuntu 24.04 server (no X11), so makeTerm() isn't an option.

We tried wpa_cli as alternative:

• Close to AP1: scan shows AP1 -39dBm, AP2 -58dBm
• Move to AP2 position, wait, rescan
• Still shows AP1 -39dBm, AP2 -58dBm (unchanged!)

The connected signal (iw link) updates correctly, but scan results stay static.

Is there a way to check wmediumd's internal state directly in headless mode?

Setup: Ubuntu 24.04, Kernel 6.8, wmediumd interference mode, logDistance exp=3.5

Thanks!

[ramonfontes]

Is there a way to check wmediumd's internal state directly in headless mode?

Honestly, I don’t think this issue is related to wmediumd. As you can see, iw link reports the expected state, but wpa_cli does not. You can also try the same command through the mn_wifi CLI, but I expect you’ll get the same result as when using node.cmd().

[valentt]

UPDATE: You were right, Ramon. We ran isolation test: - iw scan (kernel level): Updates correctly after position change - wpa_cli scan_results: Shows STALE data The bug is in wpa_supplicant scan result caching, not wmediumd. iw scan shows AP2 at -26dBm (correct), but wpa_cli still shows -71dBm. Is this a known wpa_supplicant issue with virtual interfaces?

…

On Fri, 26 Dec 2025 at 00:38, Ramon Fontes ***@***.***> wrote: *ramonfontes* left a comment (intrig-unicamp/mininet-wifi#606) <#606 (comment)> Is there a way to check wmediumd's internal state directly in headless mode? Honestly, I don’t think this issue is related to wmediumd. As you can see, iw link reports the expected state, but wpa_cli does not. You can also try the same command through the mn_wifi CLI, but I expect you’ll get the same result as when using node.cmd(). — Reply to this email directly, view it on GitHub <#606 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEXSZMEBOWVZDQAX2VQZFD4DRYRDAVCNFSM6AAAAACQAQU4UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOJRHAZDCMBXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ramonfontes]

There’s no inherent issue with wpa_supplicant and virtual interfaces and you will get the same results with physical devices. I’d say this is simply how wpa_supplicant behaves. The real problem is that the scan results take some time to update and there is nothing we can do with it.

Have you tried either reducing the short and long intervals and use the learn mode instead of the simple one? Adjusting these values can make bgscan react faster to changes in signal strength.

ref: https://git.w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf

[valentt]

Thanks for the pointer. Follow-up questions:

1. Given that wpa_cli scan_results shows stale values while iw scan works correctly - is this a known limitation of wpa_supplicant with virtual interfaces?

2. For reliable automated handover testing, should we use controller-based (SDN) roaming instead of relying on bgscan?

We implemented a Python-based roaming agent that monitors iw link and forces handover via wpa_cli roam - works reliably. Happy to share if useful.

[ramonfontes]

Given that wpa_cli scan_results shows stale values while iw scan works correctly - is this a known limitation of wpa_supplicant with virtual interfaces?

Not exactly. This is simply how scan_results behaves. Have you tried enabling learn mode?

For reliable automated handover testing, should we use controller-based (SDN) roaming instead of relying on bgscan?

You can actually use both approaches.

[valentt]

Update: Your suggestion worked!

We tested with:

• bgscan_module='learn' (instead of 'simple')
• s_interval=2, l_interval=5 (reduced from 5/10)

Results:

• Native bgscan handover now works correctly
• Station roamed AP1→AP2→AP3 automatically
• No SDN workaround needed

Thank you for the guidance. This was a configuration issue, not a bug. We should have read the wpa_supplicant documentation more carefully before filing.

Confirmed working configuration for anyone else hitting this:

sta1 = net.addStation('sta1', position='15,20,0',
                      bgscan_threshold=-60,
                      s_inverval=2, l_interval=5,
                      bgscan_module='learn')

[ramonfontes]

Great! Sorry I couldn’t give you the right answer from the beginning. You know how it is - Mininet-WiFi involves countless tools and technologies, and I can’t always remember everything on the spot.

[valentt]

Hi Ramon,

Thank you for the guidance! You were absolutely right.

We tested with your suggested configuration:

• bgscan_module='learn' (instead of 'simple')
• s_interval=2, l_interval=5 (shorter intervals)

RESULT: Native bgscan roaming now works perfectly!

Test: Station walking across 3 APs (AP1 → AP2 → AP3)

• Handover AP1→AP2: Detected automatically
• Handover AP2→AP3: Detected automatically
• No manual intervention needed

Lesson learned: We should have read the wpa_supplicant.conf documentation more carefully before assuming there was a bug. The 'learn' mode and shorter intervals were the solution all along.

Thank you for your patience in explaining this. We've updated our wrapper library to use these defaults.

Best regards