[Ovmsdev] A promiscous wifi client

[Tom Parker]

On 10/11/17 15:45, Mark Webb-Johnson wrote:
>> 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.

We shouldn't bind to the MAC address -- wifi networks with more than one 
Access Point will have multiple MAC addresses for the same SSID. From 
observing my laptop, it appears to try each network it has credentials 
for, one by one, until it gives up altogether. So I guess the thing to 
do is to do a scan, then iterate the list of networks detected, and for 
each we have credentials, try to associate. Since we won't often be in 
range of networks that we have credentials for but can't associate with, 
trying a few and failing won't happen often and anyway won't take long.

I do see with the terrible network manager and also with your work, a 
fair amount of instability. I'm seeing reboots with socket related 
frames on the stacktrace, and quite often it gets hung up and never 
reconnects. I haven't been able to look at what might be causing the 
hang because I've never had it happen while the laptop is plugged in and 
monitoring the console. It seems very reliable if you reset the OVMS 
with the button while in range of a network and never disconnect. 
However, maybe 50% of the time, after driving out of range it never 
reconnects when returning to the original network or seeing a new 
network it knows about.

I'll see if I can reproduce this by walking out of range with my cell 
phone while the OVMS is plugged into a laptop.

The following trace is from November 6th when I was using the terrible 
network manager. Sorry I don't have a recent trace from the the new 
network manager but the stack trace look the same as far as I remember. 
It seems reasonably easy to reproduce, my startup script has the following:

vehicle module NL
server v2 start
wifi mode client

1. reboot with the button
1. it connects to a v2 server via my cell phone hotspot
1. turn off the hotspot
1. it connects to my home wifi
1. it reconnects to the v2 server and crashes.
1. After the crash and reboot it connects to my home wifi and operates 
normally

I'm not seeing the recovery and normal operation very often when I take 
it for a drive and then return to the house.

Trace follows, I've only included the last part, prior to this it shows 
connecting to the v2 server and then disconnecting from the wifi and the 
v2 server, and reconnecting to a new wifi network.

I (125740) ovms-server-v2: Sending server login: MP-C 0 redacted
OVMS > Guru Meditation Error of type LoadProhibited occurred on core  1. 
Exception was unhandled.
Register dump:
PC      : 0x401630c8  PS      : 0x00060d30  A0      : 0x80161a9a A1      
: 0x3ffdaaf0
0x401630c8: event_callback at 
/home/ubuntu/esp/esp-idf/components/lwip/api/sockets.c:3195

A2      : 0x13780368  A3      : 0x000001b0  A4      : 0x00000001 A5      
: 0x3ffc750c
A6      : 0x00000005  A7      : 0x00000000  A8      : 0x000001b0 A9      
: 0x3ffdaad0
A10     : 0x00000001  A11     : 0xffffffff  A12     : 0x00000001 A13     
: 0x3ffedf92
A14     : 0x00000014  A15     : 0x00060023  SAR     : 0x00000010 
EXCCAUSE: 0x0000001c
EXCVADDR: 0x1378037c  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6 LCOUNT  
: 0xffffffff

Backtrace: 0x401630c8:0x3ffdaaf0 0x40161a97:0x3ffdab10 
0x401697c2:0x3ffdab30 0x4016dcee:0x3ffdab50 0x40172ee6:0x3ffdab70 
0x401610b5:0x3ffdab90
0x401630c8: event_callback at 
/home/ubuntu/esp/esp-idf/components/lwip/api/sockets.c:3195

0x40161a97: sent_tcp at 
/home/ubuntu/esp/esp-idf/components/lwip/api/api_msg.c:1813 
(discriminator 6)

0x401697c2: tcp_input at 
/home/ubuntu/esp/esp-idf/components/lwip/core/tcp_in.c:387 (discriminator 1)

0x4016dcee: ip4_input at 
/home/ubuntu/esp/esp-idf/components/lwip/core/ipv4/ip4.c:712

0x40172ee6: ethernet_input at 
/home/ubuntu/esp/esp-idf/components/lwip/netif/ethernet.c:176

0x401610b5: tcpip_thread at 
/home/ubuntu/esp/esp-idf/components/lwip/api/tcpip.c:474