[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-0001.html>
More information about the OvmsDev
mailing list