[HTC One X] pakjebakmeel:
Not fixed but looking slightly better, it doesn't roam automatically but it now actually roams when loosing signal.

Connection quality monitor event: beacon loss!
Event START_ROAMING received

... blablabla

Received scan results (5 BSSes)

And then it connects to the new AP.

So now the START_ROAMING event is actually triggered (upon signal loss unfortunately) maybe it's a case of getting the bgscan parameters in the config file to have it trigger the START_ROAMING event upon signal evaluation. I've read wpa_supplicant won't roaming without bgscans in the config.

I think the fact that START_ROAMING is triggered now is an improvement. I did not see this before. (Hope I didn't just miss it and the situation is exactly the same.)

OK THIS IS GOOOOD:

wlan0: New scan results available
... BLABLA ...
wlan0: Considering within-ESS reassociation
wlan0: Current BSS: <MACADDRESS>
wlan0: Selected BSS: <SAMEMACADDRES>
wlan0: Skip roam - too small difference

and then some more event but I can't copy paste them atm because my menu button isn't working and the buttons enty in settings FC's :-S :-S :-S

anyhow, this happened after triggering a scan using wpa_cli scan. Things changed:

Compiled WPA supplicant using CONFIG_BGSCAN=y

Set scan_interval 30 using wpa_cli

added bgscan="simple:30:-45:300" to wpa_supplicant.conf

Not sure if this works automatically now and I need to figure out what change caused this to work. I'm not seeing any roaming considerations by just leaving the phone alone so I guess it only works manually.

So performing a scan through wpa_cli makes it consider roaming, scheduled scans do not.. Could that scheduled bgscan triggered be different from triggering wpa_cli scan?

EUREKA?

Ok, further testing proofs that If I'm connected to AP1 (Bad signal) and stood under AP2 (good signal) it will not roam. Not even after 10 minutes, but performing a wpa_cli scan triggers roaming even if the signal is not lost. It will evaluate all AP's and pick AP2 whilst still connected to AP1 and the switch is performed like it's supposed to do.

So, my conclusion so far is that the regular scans are different from triggering a wpa_cli scan. I believe something has to be done with the regular scan type to make it trigger the same scan as wpa_cli scan triggers.

Could someone with dev knowledge investigate this please? It looks like changing the automated scan type to whatever wpa_cli triggers could solve the issue. Maybe that Add 'SCAN TYPE=ONLY' functionality breaks roaming because as intended it only scans and does not do anything else with it.

This is what I believe an wpa_cli scan triggers (taken from wpa_cli.c):

static int wpa_cli_cmd_scan(struct wpa_ctrl *ctrl, int argc, char *argv[])
{
if (argc > 0)
return wpa_cli_cmd(ctrl, "SCAN", 1, argc, argv);
return wpa_ctrl_command(ctrl, "SCAN");
}

Another addition; the code for roaming is working fine. The main problem is that a forced scan through wpa_cli triggers roaming and the periodic background scans do not. What's the difference here as we may be on to something now?

I'm wondering if the BGSCAN module works at all. It seems during initialization it should debug log about the BGSCAN module and I cannot see anything logged about it.. So is this quest turning to getting BGSCAN working?