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 gateway 10.64.64.64

Interface#2: ap
  IPv4: 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 gateway 0.0.0.0

Interface#0: lo
  IPv4: 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:

  1. 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 ;-)

  2. 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.

  3. 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?

  4. I’m guessing that ‘wifi scan’ will be similarly restricted, when in ap or apclient modes.

  5. 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
 Commit: ee023a5c8383901da2b190e3a42e94ad49724b07
     https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee023a5c8383901da2b190e3a42e94ad49724b07
 Author: Mark Webb-Johnson <mark@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev