[Ovmsdev] Wifi setup

Michael Balzer dexter at expeedo.de
Sat Jul 11 04:41:55 HKT 2020


*sigh* Found it… it turned out my main router needed a reboot. I assume
somehow a faulty ARP cache entry got stuck.

https://www.youtube.com/watch?v=nn2FB1P_Mn8

So, no fault or bug on the module side.

Checking the code once again I nevertheless found one remaining
potential bug, fix is pushed.

Regards,
Michael


Am 10.07.20 um 20:53 schrieb Michael Balzer:
> 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
>
> _______________________________________________
> 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/27935bb1/attachment.htm>


More information about the OvmsDev mailing list