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:
- 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
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev