[Ovmsdev] Wifi: Support APCLIENT mode (for Access-Point + Client)

Wed Mar 14 14:08:12 HKT 2018

All the gory details are here:

http://esp-idf.readthedocs.io/en/latest/api-guides/wifi.html <http://esp-idf.readthedocs.io/en/latest/api-guides/wifi.html>

WIFI_MODE_APSTA	Station-AP coexistence mode: in this mode, esp_wifi_start() will simultaneously init both the station and the soft-AP. This is done in station mode and soft-AP mode. Please note that the channel of the external AP, which the ESP32 Station is connected to, has higher priority over the ESP32 Soft-AP channel.

In soft-AP mode, the home channel is defined as that of the soft-AP channel. In Station mode, the home channel is defined as the channel of the AP to which the station is connected. In Station+SoftAP mode, the home channel of soft-AP and station must be the same. If the home channels of Station and Soft-AP are different, the station’s home channel is always in priority. Take the following as an example: at the beginning, the soft-AP is on channel 6, then the station connects to an AP whose channel is 9. Since the station’s home channel has a higher priority, the soft-AP needs to switch its channel from 6 to 9 to make sure that both station and soft-AP have the same home channel.

Regards, Mark.

> On 14 Mar 2018, at 1:52 PM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> Yea!  Very nice.  Still a little work to do, but I think this mode will be very handy once the dust settles.
> 
> We do need to resolve the channel thing.  There's a race condition when you start, whether the client connects first to an available AP, or the AP starts up first.  If they're on different channels (likely), and the AP mode starts first, the client mode will never connect.  If I have the client AP available (my cell phone in tether mode), they both seem to come up properly.
> 
> All the APs I've ever worked with had the ability to service clients on one channel, and (without losing them) scan the other channels in the background.  But when this works, we'll also need the ability for the AP mode to change channels when the client connects.  Probably not too big a deal to reset the link at that time, I suppose.  There is a protocol for changing channels without losing your clients, but in practice it hardly ever worked, and as an advanced feature (used mostly on 5 ghz DFS channels), I rather doubt the ESP platform supports it.
> 
> There also seems to be a bit of a confusion point with the mode.  I tried leaving the client mode AP off (it's my tablet in tether mode, so easy to do), and restarted the module.  Then turned the tether on.  As expected, the module never connected.  But I also see a bit of confusion on the network status...  Why does the client mode apparently have the AP mode's IP address (even though it's not connected)?  I was able to connect my phone's wifi to the AP mode, but the browser would not connect to the server.  See below.
> 
> Also, when I have the client running, and then the modem connects, the connection to the v2 server seems to hang.  You see messages logged to the console of the traffic going out, but it never makes it to my phone's app.  Eventually the modem detects something wrong and resets.  The connection to the v2 server never makes it back, even though the client wifi connection is still reported as up.  I don't think this behavior is new with the AP + client mode, however.
> 
> Great progress, however!
> 
> Greg
> 
> 
>> OVMS > wifi status
>> WiFi
>>   Power: on
>>   Mode: Access-Point + Client mode
>> 
>>   STA SSID: gregnet3
>>     MAC: 30:ae:a4:37:1b:65
>>     IP: 192.168.4.1/255.255.255.0
>>     GW: 192.168.4.1
>> 
>>   AP SSID: ovms
>>     MAC: 30:ae:a4:37:1b:65
>>     IP: 192.168.4.1
>>     AP Stations: 0
>> I (85259) wifi: n:1 0, o:1 0, ap:1 1, sta:0 0, prof:1
>> I (85259) wifi: station: 40:4e:36:8a:44:c0 join, AID=1, n, 20
>> I (85269) esp32wifi: AP station connected: id: 1, MAC: 40:4e:36:8a:44:c0
>> OVMS > network status
>> Interface#3: pp
>>   IPv4: 10.170.146.142/255.255.255.255 <http://10.170.146.142/255.255.255.255> gateway 10.64.64.64
>> 
>> Interface#2: ap
>>   IPv4: 192.168.4.1/255.255.255.0 <http://192.168.4.1/255.255.255.0> gateway 192.168.4.1
>> 
>> Interface#1: st
>>   IPv4: 0.0.0.0/0.0.0.0 <http://0.0.0.0/0.0.0.0> gateway 0.0.0.0
>> 
>> Interface#0: lo
>>   IPv4: 127.0.0.1/255.0.0.0 <http://127.0.0.1/255.0.0.0> gateway 127.0.0.1
>> 
>> DNS: 9.9.9.9 8.8.8.8
>> OVMS > 
> 
> 
> Mark Webb-Johnson wrote:
>> 
>> I’ve added support for a new wifi mode ‘apclient’. This takes AP and STA mode SSIDs, and sets up as both an access point and a client.
>> 
>> Some caveats:
>> 
>> There seems to be a problem coming out of the mode (wifi mode off, etc). The network interfaces are not torn down correctly every time. Symptom is the client comes up, wifi shows an IP address on it, but the address is not set correctly on the ’st’ network interface. Reproducibility is random (maybe interface order related?). Not sure if this is my fault, or a bug in the framework. A 'module reset’ works around the problem ;-)
>> 
>> I updated Michael’s webserver, and the auto framework, to support this, but I’m not too familiar with that so might have got it wrong.
>> 
>> Wifi sclient style mode (scanning for known SSIDs to join without knowing the _exact_ SSID) is not currently supported. I’m not sure if this can ever be supported properly. The apclient mode works by locking the channel for both the AP and STA to be the same - if we are locked like that, how can we scan across channels?
>> 
>> I’m guessing that ‘wifi scan’ will be similarly restricted, when in ap or apclient modes.
>> 
>> This is not a router. Setting the gateway on the ’st’ interface would be trivial, but I don’t think packets can travel AP -> STA. Doing that would require source-nat, plus packet routing, etc. Routing would be easy, SNAT very nasty.
>> 
>> It does look pretty cool, and seems to work well:
>> 
>> OVMS > network
>> Interface#2: ap
>>   IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
>> 
>> Interface#1: st
>>   IPv4: 10.x.x.x/255.255.255.0 gateway 10.x.x.x
>> 
>> Interface#0: lo
>>   IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1
>> 
>> DNS: 8.8.8.8 8.8.4.4
>> 
>> OVMS > wifi
>> WiFi
>>   Power: on
>>   Mode: Access-Point + Client mode
>> 
>>   STA SSID: MY-STA-SSID
>>     MAC: re:da:ct:ed:da:ta
>>     IP: 10.x.x.x/255.255.255.0
>>     GW: 10.x.x.x
>> 
>>   AP SSID: MY-AP-SSID
>>     MAC: da:ta:re:da:ct:ed
>>     IP: 10.x.x.x
>>     AP Stations: 1
>>       1: MAC: da:ta:re:da:ct:ed, IP: 192.168.4.2
>> 
>> Enjoy, Mark.
>> 
>>> Begin forwarded message:
>>> 
>>> Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] ee023a: Wifi: Support APCLIENT mode (for Access-Point + Cl...
>>> Date: 14 March 2018 at 11:09:21 AM HKT
>>> 
>>>  Branch: refs/heads/master
>>>  Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3>
>>>  Commit: ee023a5c8383901da2b190e3a42e94ad49724b07
>>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee023a5c8383901da2b190e3a42e94ad49724b07 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee023a5c8383901da2b190e3a42e94ad49724b07>
>>>  Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>  Date:   2018-03-14 (Wed, 14 Mar 2018)
>>> 
>>>  Changed paths:
>>>    M vehicle/OVMS.V3/changes.txt
>>>    M vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp
>>>    M vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.h
>>>    M vehicle/OVMS.V3/components/ovms_webserver/src/web_cfg.cpp
>>> 
>>>  Log Message:
>>>  -----------
>>>  Wifi: Support APCLIENT mode (for Access-Point + Client)
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180314/20c83936/attachment.htm>