[Ovmsdev] Wifi setup

Michael Balzer dexter at expeedo.de
Sat Jul 11 02:53:36 HKT 2020


Sorry for not including the examples. The Edimax does not have a host
name, it's addressed using the IP, no DNS involved.

Linux host request example working the same way with both the old & new
version:

HTTP.Request({
  url: "http://192.168.2.108/f/test.json",
  always: function() { JSON.print(this, false); }
});

(OK, no output)
D (42703) script: DuktapeHTTPRequest: started
'http://192.168.2.108/f/test.json'
D (42913) script: DuktapeHTTPRequest: MG_EV_CONNECT err=0/Success
D (42933) script: DuktapeHTTPRequest: MG_EV_HTTP_REPLY status=200 bodylen=20
D (42943) script: DuktapeHTTPRequest: MG_EV_CLOSE status=200
D (42963) script: DuktapeHTTPRequest: done status=200 bodylen=20
url='http://192.168.2.108/f/test.json'
D (42973) script: DuktapeHTTPRequest: calling method 'always' nargs=0
I (43173) script: [eval:3:]
{"url":"http://192.168.2.108/f/test.json","always":function () {
[ecmascript code]
},"redirectCount":0,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{
\"das\": \"klappt?\" }","headers":[{"Date":"Fri, 10 Jul 2020 17:03:18
GMT"},{"Server":"Apache"},{"Last-Modified":"Sun, 29 Dec 2019 11:01:41
GMT"},{"ETag":"\"14-59ad5a6d190da\""},{"Accept-Ranges":"bytes"},{"Content-Length":"20"},{"Cache-Control":"max-age=0"},{"Expires":"Fri,
10 Jul 2020 17:03:18 GMT"},{"Content-Type":"application/json"}]}}

…vs. Edimax working with the old version:

HTTP.Request({
  url: "http://192.168.2.106/",
  always: function() { JSON.print(this, false); }
});

(OK, no output)
D (533720) script: DuktapeHTTPRequest: started 'http://192.168.2.106/'
D (533920) script: DuktapeHTTPRequest: MG_EV_CONNECT err=104/Connection
reset by peer
D (533930) script: DuktapeHTTPRequest: MG_EV_CLOSE status=0
D (533950) script: DuktapeHTTPRequest: failed error='Connection reset by
peer' url='http://192.168.2.106/'
D (533950) script: DuktapeHTTPRequest: calling method 'always' nargs=0
I (533990) script: [eval:3:]
{"url":"http://192.168.2.106/","always":function () { [ecmascript code]
},"redirectCount":0,"error":"Connection reset by peer"}

(connection reset = expected result here, as connecting w/o credentials
to the default port -- to show it's host related)

…but not with the new version:

(OK, no output)
D (151953) script: DuktapeHTTPRequest: started 'http://192.168.2.106/'
…18 seconds…
D (170273) script: DuktapeHTTPRequest: MG_EV_CONNECT err=113/Software
caused connection abort
D (170273) script: DuktapeHTTPRequest: MG_EV_CLOSE status=0
D (170293) script: DuktapeHTTPRequest: failed error='Software caused
connection abort' url='http://192.168.2.106/'
D (170303) script: DuktapeHTTPRequest: calling method 'always' nargs=0
I (170333) script: [eval:3:]
{"url":"http://192.168.2.106/","always":function () { [ecmascript code]
},"redirectCount":0,"error":"Software caused connection abort"}


Regards,
Michael


Am 10.07.20 um 20:03 schrieb David Corrigan:
> Sounds like a DNS issue. I’m really foggy on the details but you can
> probably look this stuff up easily enough. Local stuff is resolved a
> bit differently, it’s something like your home router keeps track of
> the names that get DHCP reservations and append .local so somehow when
> looking for devices the client needs to query that as well as the main
> DNS IPs given to it by the DHCP server. It might be that the same DHCP
> server automatically appends it’s own up IP to the list. There’s a
> discussion on it here that might yield some ideas
>
> https://superuser.com/questions/591863/how-to-resolve-local-domain-name
>
>
> On Fri, Jul 10, 2020 at 12:47 PM Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de>> wrote:
>
>     It seems I've found a real issue with the new implementation, I
>     don't know how to explain:
>
>     With the new implementation, mongoose fails to establish a HTTP
>     connection to my Edimax smart plug. Just that device, every other
>     host works correctly, also with SSL.
>
>     The mg_connect_http_opt() call fails after 18 seconds with error
>     113 "Software caused connection abort" … which may be a timeout or
>     the LWIP error code 113 "No route to host" passed through by mongoose.
>
>     Same behaviour in both client & apclient mode, fixed & scanning.
>
>     The Edimax is on the same network as the module (connected to the
>     same AP) and perfectly reachable from all other stations (and the
>     build before). Netmask and gateway are correct. Also the wifi
>     connect is still done by the esp_wifi_connect() call, so there
>     should be no difference…?
>
>     I'm puzzled. Any ideas? Any other hosts that cannot be connected
>     to with the new version?
>
>     To test a host, use this JS snippet in the editor with a URL of a
>     small page or non existent file on the host:
>
>     HTTP.Request({
>       url: "http://…" <http://…>,
>       always: function() { JSON.print(this, false); }
>     });
>
>     Regards,
>     Michael
>
>
>     Am 10.07.20 um 15:21 schrieb Michael Balzer:
>>     The dhcps log messages aren't new, I've had these all the time
>>     before, also sometimes repeating for some period.
>>
>>     Also not new are these messages:
>>
>>     I (8771413) wifi: ampdu: ignore deleting tx BA0
>>     I (8774723) wifi: ampdu: ignore deleting tx BA0
>>     I (8784043) wifi: ampdu: ignore deleting tx BA0
>>     I (8787253) wifi: ampdu: ignore deleting tx BA0
>>     I (8793673) wifi: ampdu: ignore deleting tx BA0
>>     I (8797813) wifi: ampdu: ignore deleting tx BA0
>>
>>     They now start consistently after doing a scan from a web client
>>     connected via the AP. They stop when the client disconnects. Seem
>>     to be coupled to the websocket somehow. I've found these in my
>>     log archives as well, no clue about the trigger. No issue other
>>     than annoying log spam though, everything works normally.
>>
>>     Regards,
>>     Michael
>>
>>
>>     Am 10.07.20 um 14:36 schrieb Mark Webb-Johnson:
>>>     Working for me on my test bench device. I’m building EDGE now.
>>>
>>>     Only strange thing so far is I am seeing this message repeatedly
>>>     in apclient mode:
>>>
>>>         dhcps: send_nak>>udp_sendto result 0
>>>
>>>
>>>     Can’t work out the timing, as it seems to be random. I’ll keep
>>>     looking...
>>>
>>>     Regards, Mark
>>>
>>>>     On 10 Jul 2020, at 7:42 PM, Michael Balzer <dexter at expeedo.de
>>>>     <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>>     Everyone,
>>>>
>>>>     the wifi rework is pushed:
>>>>     https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f124060326b92f35887878b4d49c8012542dc
>>>>     …and the new edge build is on my server.
>>>>
>>>>     This now allows to scan for networks in all modes without
>>>>     disruption of a running wifi network.
>>>>
>>>>     I've used this to also add a network selection dialog to the
>>>>     setup wizard & wifi config.
>>>>
>>>>     The apclient mode can now be started without a client SSID to
>>>>     let the module automatically connect to any network configured.
>>>>     The autostart config page now allows this setup. The special
>>>>     "scanning client" mode has been removed.
>>>>
>>>>     The wifi manager will still stick to an established connection,
>>>>     even if a new network with higher signal strength becomes
>>>>     available. I thought about automatically switching networks if
>>>>     the signal gets poor, but for now decided against it to avoid
>>>>     frequent network reconfigurations in edge cases. If you want
>>>>     the module to explicitly scan for a better network, issue "wifi
>>>>     reconnect".
>>>>
>>>>     Of course this has involved some changes to the wifi manager,
>>>>     so please test & report.
>>>>
>>>>     Regards,
>>>>     Michael
>>>>
>>>>
>>>>     Am 10.07.20 um 08:57 schrieb Michael Balzer:
>>>>>     TL;DR: yes, I'm currently also going towards not letting
>>>>>     esp_wifi_connect() decide which AP to connect to.
>>>>>
>>>>>     More precisely, exactly the first (!) call to
>>>>>     esp_wifi_connect() after a reboot/power up seems to do a round
>>>>>     robin scheme among all reachable access points of a network
>>>>>     regardless of their signal strength. This even applies to the
>>>>>     first connect() immediately after a scan.
>>>>>
>>>>>     Example:
>>>>>
>>>>>     D (5034) events: Signal(system.wifi.scan.done)
>>>>>     V (5034) esp32wifi: ScanDone: #01 ssid='WLAN-214677'
>>>>>     bssid='7c:ff:4d:15:2f:86' chan=11 rssi=-64
>>>>>     V (5034) esp32wifi: ScanDone: #02 ssid='WLAN-214677'
>>>>>     bssid='94:4a:0c:c3:9e:63' chan=11 rssi=-77
>>>>>     I (5044) esp32wifi: Found SSID WLAN-214677 - trying to connect
>>>>>     I (7564) esp32wifi: STA connected with SSID: WLAN-214677,
>>>>>     BSSID: 94:4a:0c:c3:9e:63, Channel: 11, Auth: WPA2
>>>>>
>>>>>     The next reboot will connect to 7c:ff (despite unchanged
>>>>>     signal strengths), the next again to 94:4a and so on. I've
>>>>>     only got two access points, so I can't test if it's really
>>>>>     round-robin, but it's wrong anyway.
>>>>>
>>>>>     On all following reconnects on the running system it will
>>>>>     correctly pick the 7c:ff AP, also if wifi is stopped & restarted.
>>>>>
>>>>>     This AP switching behaviour also persists powering off the
>>>>>     module, so the wifi blob seems to do this on purpose and even
>>>>>     use some persistent storage to implement it. Totally
>>>>>     undocumented and I've found no way to disable this and no
>>>>>     workaround so far.
>>>>>
>>>>>     There may be a fix for this in the current esp-idf wifi blob,
>>>>>     but I've found no issues on this, and esp-idf commit comments
>>>>>     are mostly not useful.
>>>>>
>>>>>     Regards,
>>>>>     Michael
>>>>>
>>>>>
>>>>>     Am 10.07.20 um 02:55 schrieb Mark Webb-Johnson:
>>>>>>     FYI:
>>>>>>
>>>>>>     I’ve recently done some work with the esphome system (based
>>>>>>     on platformio on top of esp idf), for home automation. They
>>>>>>     don’t seem to trust the ESP libraries identifying the
>>>>>>     strongest signal (in the case of two APs broadcasting the
>>>>>>     same SSID). They don’t blindly connect to a SSID, but instead
>>>>>>     first do a scan to produce an ordered list and then connect
>>>>>>     to the SSID+AP-MAC-Address of the AP with the strongest signal.
>>>>>>
>>>>>>     That approach might help with your other issue (recently
>>>>>>     raised in mantis).
>>>>>>
>>>>>>     Regards, Mark.
>>>>>>
>>>>>>>     On 10 Jul 2020, at 5:43 AM, Michael Balzer
>>>>>>>     <dexter at expeedo.de> <mailto:dexter at expeedo.de> wrote:
>>>>>>>
>>>>>>>      Welcome Derek,
>>>>>>>
>>>>>>>     I've got a rework of the wifi component near done that
>>>>>>>     allows to use scanning mode in apclient configuration. I
>>>>>>>     think I can push the changes tomorrow & suggest you'll be my
>>>>>>>     beta tester ;-)
>>>>>>>
>>>>>>>     Regards,
>>>>>>>     Michael
>>>>>>>
>>>>>>>
>>>>>>>     Am 09.07.20 um 20:50 schrieb Derek Caudwell:
>>>>>>>>     Hi devs,
>>>>>>>>
>>>>>>>>     I recently received the ovms hardware and have been trying
>>>>>>>>     to setup the unit so I can solely use the wifi AP+client.
>>>>>>>>     In NZ 3G is soon to be sunset and for my needs I don't
>>>>>>>>     really need a connection when I'm driving (and want to make
>>>>>>>>     sure everything is behaving nicely on the can bus before I
>>>>>>>>     do). 
>>>>>>>>
>>>>>>>>     I realise AP+client brings it limitations however hopefully
>>>>>>>>     some of these can be worked around as I want to be able to
>>>>>>>>     use the dashboard/plugins as well as the mobile app. I am
>>>>>>>>     new to C/ESP32 programming and the code base so I thought
>>>>>>>>     it best to ask a few questions before I begin tinkering
>>>>>>>>     with it.
>>>>>>>>
>>>>>>>>     Ideally I want the unit on loss of connection to an AP to
>>>>>>>>     try and find another AP that has been set in the wifi
>>>>>>>>     config and connect. The parts I am not too sure are as follows:
>>>>>>>>      - on boot the code uses the default wifi ssid, if the
>>>>>>>>     default is not available how does the code try and switch
>>>>>>>>     to one of the other saved APs?
>>>>>>>>         - can multiple APs be saved to the wifi config memory
>>>>>>>>     and handled by ESP32? or do they need to be retrieved from
>>>>>>>>     ovms config, wifi client details set, try connect and
>>>>>>>>     enumerated through?
>>>>>>>>      - I assume EventTimer10 is the logical place to add extra
>>>>>>>>     code if required to enumerate through APs and try to
>>>>>>>>     connect? similar to EventScanWifiDone when in SClient mode
>>>>>>>>      - What is the reason scanning mode is unavailable for
>>>>>>>>     AP+client mode in auto init, from the ESP32 documentation
>>>>>>>>     it appeared to be usable still but with limitations? 
>>>>>>>>
>>>>>>>>     Thanks in advance for any pointers and background.
>>>>>>>>
>>>>>>>>     Cheers Derek
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     OvmsDev mailing list
>>>>>>>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>>     -- 
>>>>>>>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>>>>>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>>     _______________________________________________
>>>>>>>     OvmsDev mailing list
>>>>>>>     OvmsDev at lists.openvehicles.com
>>>>>>>     <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OvmsDev mailing list
>>>>>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>>     -- 
>>>>>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>>>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>
>>>>>     _______________________________________________
>>>>>     OvmsDev mailing list
>>>>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>>     -- 
>>>>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>     _______________________________________________
>>>>     OvmsDev mailing list
>>>>     OvmsDev at lists.openvehicles.com
>>>>     <mailto:OvmsDev at lists.openvehicles.com>
>>>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>>     _______________________________________________
>>>     OvmsDev mailing list
>>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>     -- 
>>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>>     _______________________________________________
>>     OvmsDev mailing list
>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>     -- 
>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>     _______________________________________________
>     OvmsDev mailing list
>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200710/5b8b394a/attachment.htm>


More information about the OvmsDev mailing list