<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Yea! Very nice. Still a little work to do, but I think this mode
will be very handy once the dust settles.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Great progress, however!<br>
<br>
Greg<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">OVMS > wifi status<br>
WiFi<br>
Power: on<br>
Mode: Access-Point + Client mode<br>
<br>
STA SSID: gregnet3<br>
MAC: 30:ae:a4:37:1b:65<br>
IP: <b>192.168.4.1/255.255.255.0</b><br>
GW: <b>192.168.4.1</b><br>
<br>
AP SSID: ovms<br>
MAC: 30:ae:a4:37:1b:65<br>
IP: 192.168.4.1<br>
AP Stations: 0<br>
I (85259) wifi: n:1 0, o:1 0, ap:1 1, sta:0 0, prof:1<br>
I (85259) wifi: station: 40:4e:36:8a:44:c0 join, AID=1, n, 20<br>
I (85269) esp32wifi: AP station connected: id: 1, MAC:
40:4e:36:8a:44:c0<br>
OVMS > network status<br>
Interface#3: pp<br>
IPv4: <a href="http://10.170.146.142/255.255.255.255">10.170.146.142/255.255.255.255</a>
gateway 10.64.64.64<br>
<br>
Interface#2: ap<br>
IPv4: <a href="http://192.168.4.1/255.255.255.0">192.168.4.1/255.255.255.0</a>
gateway 192.168.4.1<br>
<br>
Interface#1: st<br>
IPv4: <a href="http://0.0.0.0/0.0.0.0">0.0.0.0/0.0.0.0</a>
gateway 0.0.0.0<br>
<br>
Interface#0: lo<br>
IPv4: <a href="http://127.0.0.1/255.0.0.0">127.0.0.1/255.0.0.0</a>
gateway 127.0.0.1<br>
<br>
DNS: 9.9.9.9 8.8.8.8<br>
OVMS > <br>
</div>
</blockquote>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:054C5F45-F347-4E9E-9E77-B0D0A0136187@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class=""><br class="">
</div>
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.
<div class=""><br class="">
</div>
<div class="">Some caveats:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">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 ;-)<br class="">
<br class="">
</li>
<li class="">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.<br class="">
<br class="">
</li>
<li class="">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?<br class="">
<br class="">
</li>
<li class="">I’m guessing that ‘wifi scan’ will be similarly
restricted, when in ap or apclient modes.<br class="">
<br class="">
</li>
<li class="">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.</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">It does look pretty cool, and seems to work well:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class=""><font class="" face="Andale Mono"><span
style="font-size: 14px;" class="">OVMS > network<br
class="">
Interface#2: ap<br class="">
IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1<br
class="">
<br class="">
Interface#1: st<br class="">
IPv4: 10.x.x.x/255.255.255.0 gateway 10.x.x.x<br class="">
<br class="">
Interface#0: lo<br class="">
IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1<br class="">
<br class="">
DNS: 8.8.8.8 8.8.4.4<br class="">
<br class="">
</span></font></blockquote>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class=""><font class="" face="Andale Mono"><span
style="font-size: 14px;" class="">OVMS > wifi</span><br
class="">
<span style="font-size: 14px;" class="">WiFi</span><br
class="">
<span style="font-size: 14px;" class=""> Power: on</span><br
class="">
<span style="font-size: 14px;" class=""> Mode: Access-Point +
Client mode</span><br class="">
<br class="">
<span style="font-size: 14px;" class=""> STA SSID:
MY-STA-SSID</span><br class="">
<span style="font-size: 14px;" class=""> MAC:
re:da:ct:ed:da:ta</span><br class="">
<span style="font-size: 14px;" class=""> IP:
10.x.x.x/255.255.255.0</span><br class="">
<span style="font-size: 14px;" class=""> GW: 10.x.x.x</span><br
class="">
<br class="">
<span style="font-size: 14px;" class=""> AP SSID: MY-AP-SSID</span><br
class="">
<span style="font-size: 14px;" class=""> MAC:
da:ta:re:da:ct:ed</span><br class="">
<span style="font-size: 14px;" class=""> IP: 10.x.x.x</span><br
class="">
<span style="font-size: 14px;" class=""> AP Stations: 1<br
class="">
1: MAC: da:ta:re:da:ct:ed, IP: 192.168.4.2</span></font></blockquote>
<div class="">
<div><br class="">
</div>
<div>Enjoy, Mark.</div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">Begin forwarded message:</div>
<br class="Apple-interchange-newline">
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;" class=""><span
style="font-family: -webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b class="">Subject:
</b></span><span style="font-family:
-webkit-system-font, "Helvetica Neue",
Helvetica, sans-serif;" class=""><b class="">[openvehicles/Open-Vehicle-Monitoring-System-3]
ee023a: Wifi: Support APCLIENT mode (for Access-Point
+ Cl...</b></span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;" class=""><span
style="font-family: -webkit-system-font, Helvetica Neue,
Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"
class=""><b class="">Date: </b></span><span
style="font-family: -webkit-system-font, Helvetica Neue,
Helvetica, sans-serif;" class="">14 March 2018 at
11:09:21 AM HKT<br class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;" class=""><br
class="">
</div>
<div class="">
<div class=""> Branch: refs/heads/master<br class="">
Home: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3"
class="" moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3</a><br
class="">
Commit: ee023a5c8383901da2b190e3a42e94ad49724b07<br
class="">
<a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee023a5c8383901da2b190e3a42e94ad49724b07"
class="" moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee023a5c8383901da2b190e3a42e94ad49724b07</a><br
class="">
Author: Mark Webb-Johnson <<a
href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>><br
class="">
Date: 2018-03-14 (Wed, 14 Mar 2018)<br class="">
<br class="">
Changed paths:<br class="">
M vehicle/OVMS.V3/changes.txt<br class="">
M
vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp<br
class="">
M
vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.h<br
class="">
M
vehicle/OVMS.V3/components/ovms_webserver/src/web_cfg.cpp<br
class="">
<br class="">
Log Message:<br class="">
-----------<br class="">
Wifi: Support APCLIENT mode (for Access-Point + Client)<br
class="">
<br class="">
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>