[Ovmsdev] A promiscous wifi client

[Mark Webb-Johnson]

> If you trigger it from a startup script then it never connects because monotonictime is 0 which doesn't pass the test in EventTimer10(). I'm running with the following patch, but you might want to start monotonictime at 1, or not overload a boolean into m_nextscan.
> -  m_nextscan = monotonictime;
> +  // if we are triggered by a startup script, monotonictime will be zero which
> +  // won't pass the test in EventTimer10()
> +  m_nextscan = monotonictime == 0 ? 1 : monotonictime;

Nice find.

I think it is sufficient to just set m_nextscan = monotonictime+1 (to schedule it for the next second). I’ve done that, committed, and pushed.

> If there is a network in range that has the same name as a network that is saved but has a different password, the client never tries the next network. Instead it tries to connect to the "fake" network over and over and over. It appears to use the network that is alphabetically first in the list, which isn't good if it knows about an AndroidAP and there happens to be someone else's AndroidAP switched on while you're trying to connect to a network with a name that doesn't start with A.

Yeah. I am not sure how this is handled in cellphones/laptops. We can pickup the MAC address of the station, and use that as the key, but even that can be maliciously spoofed. Also a pain for networks with multiple APs on the same SSID, etc. I’m reasonably sure that phones/laptops use the SSID as the key.

On my iPhone, I can set a “don’t automatically connect to this SSID” flag on the SSID entry itself, but I can’t prioritise them in any way.

Is this going to be an issue? If so, any suggestions for how to address it?

Regards, Mark.

> On 9 Nov 2017, at 5:52 PM, Tom Parker <tom at carrott.org> wrote:
> 
> 
> On 09/11/17 18:38, Mark Webb-Johnson wrote:
>> I’ve committed a change to the esp32wifi component, to try to support a promiscuous mode for the wifi client. This should make it work the way it does on cellphones, computers, and pretty much all equipment. Rather than specifying a specific wifi AP to connect to, it just connects to whichever it can (based on where it has connected to in the past).
> 
> Nice! This is much better than the terrible network manager I wrote.
> 
> If you trigger it from a startup script then it never connects because monotonictime is 0 which doesn't pass the test in EventTimer10(). I'm running with the following patch, but you might want to start monotonictime at 1, or not overload a boolean into m_nextscan.
> 
> diff --git a/vehicle/OVMS.V3/components/esp32wifi/esp32wifi.cpp b/vehicle/OVMS.V3/components/esp32wifi/esp32wifi.cpp
> index 236f4c9..c6ebcd4 100644
> --- a/vehicle/OVMS.V3/components/esp32wifi/esp32wifi.cpp
> +++ b/vehicle/OVMS.V3/components/esp32wifi/esp32wifi.cpp
> @@ -262,7 +262,9 @@ void esp32wifi::StartScanningClientMode()
>    memset(&m_wifi_apsta_cfg,0,sizeof(m_wifi_apsta_cfg));
>    ESP_ERROR_CHECK(esp_wifi_start());
> 
> -  m_nextscan = monotonictime;
> +  // if we are triggered by a startup script, monotonictime will be zero which
> +  // won't pass the test in EventTimer10()
> +  m_nextscan = monotonictime == 0 ? 1 : monotonictime;
>    }
> 
>  void esp32wifi::StartAccessPointMode(std::string ssid, std::string password)
> 
> If there is a network in range that has the same name as a network that is saved but has a different password, the client never tries the next network. Instead it tries to connect to the "fake" network over and over and over. It appears to use the network that is alphabetically first in the list, which isn't good if it knows about an AndroidAP and there happens to be someone else's AndroidAP switched on while you're trying to connect to a network with a name that doesn't start with A.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev