The problem really seemed to occur only after switching from Wifi to modem, also tried with another SIM. I have now configured the Google DNS servers as well, will report if I get the issue again. Another OTA issue, I haven't fully figured out yet: after switching on the modem, the download will always go via modem. As long as Wifi is available, it should be used -- maybe we also need to control the default route? OTA modem download does not work from my server. First thought it's Hologram (a single firmware update needs more volume than is covered by the free developer plan), but it also does not work with my local SIM with a high volume plan. I noticed a rather strange effect: when I let it run, the server actually logged the download after 17 minutes, but still no download progress on the console. I need to retry this with verbose logging on the gsm-ppp channel to see what's going on. Regards, Michael Am 12.03.2018 um 16:08 schrieb Mark Webb-Johnson:

I’ve added a ‘network status’ command. Can you try it, when you get DNS errors, to see what the DNS servers are set to?

Regards, Mark

...

On 12 Mar 2018, at 10:29 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

...

Working on the OTA web UI.

That will be very useful. Thanks.

...

a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages: Can these safely be ignored? The flashed partitions seem to work correctly.

Yes, I too find these ugly. It is a ‘make monitor weirdism:

https://www.esp32.com/viewtopic.php?t=4199

/No, no need to worry. Those are from the ``make monitor`` command. As soon as this sees a hex number scroll by that smells like an address in the ESP32 memory map, it tries to be helpful and converts it to a symbol. In some cases, this leads it to weird messages like this./

...

b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command?

Supposedly if the OTA partition doesn’t boot (or checksum mismatch, etc), the bootloader will boot factory.

The selection of current boot partition is in the otadata partition:

# OVMS 16MB flash ESP32 Partition Table # Name,   Type, SubType, Offset,   Size nvs,      data, nvs,     0x9000,  0x4000 otadata,  data, ota,     0xd000,  0x2000 phy_init, data, phy,     0xf000,  0x1000 factory,  app,  factory, 0x10000,  4M ota_0,    app,  ota_0,   ,         4M ota_1,    app,  ota_1,   ,         4M store,    data, fat,     ,         1M

I guess zapping that would reset to defaults (factory boot)? I think erase_region may do that:

|esptool.py erase_region 0xd000 0x2000|

But, haven’t tried it myself.

...

c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com <http://api.openvehicles.com/> and fails to download from api.openvehicles.com <http://api.openvehicles.com>, regardless of the type of network (wifi/modem).

I saw this a few months ago, but not recently.

Line 107 of ovms_net.cpp. It just does a getaddrinfo() on the host.

Regards, Mark.

...

On 12 Mar 2018, at 7:13 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Working on the OTA web UI.

Some questions:

a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages:

OVMS > ota flash vfs /sd/ovms3.done Current running partition is: ota_0 Target partition is: ota_1 Source image is 1480592 bytes in size Preparing flash partition... Flashing image partition... Setting boot partition... OTA flash was successful   Flashed 1480592 bytes from /sd/ovms3.done   Next boot will be from 'ota_1' I (1316956) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (1317156) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (1317156) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 (  1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (1317166) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (1317176) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:?

I (1317746) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293

I (1317776) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 (    52) I (1317776) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (1317976) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (1317986) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 (  1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (1317986) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (1317996) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:?

I (1318566) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293

I (1318606) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 (    52)

…

OVMS > ota boot ota_1 Boot from ota_1 at 0x00810000 (size 0x00400000) I (301766) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (301966) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (301976) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 (  1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (301976) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (301986) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:?

I (302556) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293

I (302596) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 (    52)

Can these safely be ignored? The flashed partitions seem to work correctly.

b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command?

I would have expected "make flash" to reset the boot partition to "factory", as all flashes are only done there, but it doesn't.

So if you're on another partition with a broken firmware, how do you recover? Is there a way to set the boot partition using esptool.py?

c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com <http://api.openvehicles.com/> and fails to download from api.openvehicles.com <http://api.openvehicles.com/>, regardless of the type of network (wifi/modem).

OVMS > ota flash http www.google.com/ovms3.bin <http://www.google.com/ovms3.bin> Current running partition is: factory Target partition is: ota_0 Download firmware from www.google.com/ovms3.bin <http://www.google.com/ovms3.bin> to ota_0 Error: Request failed W (666891) net: DNS lookup on www.google.com <http://www.google.com/> failed err=200

OVMS > ota flash http api.openvehicles.com/test.bin <http://api.openvehicles.com/test.bin> Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/test.bin <http://api.openvehicles.com/test.bin> to ota_0 […dead, needs reset]

Is this a local problem of mine?

Regards, Michael

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

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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

Hi, I’ve been reluctant to butt in here, but the behavior apropos DNS is expected behavior and hard-coding DNS servers would seem a little heavy-handed at least. Basically the dhcp client is just doing its job. The fix is just to re-issue a dhcp lease request for/from the interface that is still up, if any. This will reset the resolver information and DNS will just work. The solution with both nets working and routing would largely seem unnecessary and a bit complex. It’s also going to be too difficult to know what to route where for the average user, i.e. path cost. In today’s world, it would be a rare exception if 3G/4G was a preferred path based on either bandwidth or cost. Yada, yada, Shaun

On 16 Mar 2018, at 02:28, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

The problem really seemed to occur only after switching from Wifi to modem, also tried with another SIM.

Yes, that is it. If modem gives you some public DNS, then you start wifi which gives a private DNS, then you stop wifi and are left with a modem that can’t access the wifi’s private DNS.

Setting 8.8.8.8 8.8.4.4, with my new code, avoids that.

...

Another OTA issue, I haven't fully figured out yet: after switching on the modem, the download will always go via modem. As long as Wifi is available, it should be used -- maybe we also need to control the default route?

I haven’t address the ‘preferred route’ issue yet. My original idea was to sleep the modem when wifi came up, but I’m now thinking maybe better to keep the modem alive and instead use a priority preference thing. Something like some helper functions in NetManager that can be simply called to bind an outgoing connection to the highest priority network. But, not implemented yet.

Regards, Mark.

...

On 16 Mar 2018, at 7:05 AM, Michael Balzer <dexter@expeedo.de> wrote:

The problem really seemed to occur only after switching from Wifi to modem, also tried with another SIM.

I have now configured the Google DNS servers as well, will report if I get the issue again.

Another OTA issue, I haven't fully figured out yet: after switching on the modem, the download will always go via modem. As long as Wifi is available, it should be used -- maybe we also need to control the default route?

OTA modem download does not work from my server. First thought it's Hologram (a single firmware update needs more volume than is covered by the free developer plan), but it also does not work with my local SIM with a high volume plan.

I noticed a rather strange effect: when I let it run, the server actually logged the download after 17 minutes, but still no download progress on the console.

I need to retry this with verbose logging on the gsm-ppp channel to see what's going on.

Regards, Michael

...

Am 12.03.2018 um 16:08 schrieb Mark Webb-Johnson: I’ve added a ‘network status’ command. Can you try it, when you get DNS errors, to see what the DNS servers are set to?

Regards, Mark

...

On 12 Mar 2018, at 10:29 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

Working on the OTA web UI.

That will be very useful. Thanks.

...

a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages:

...

Can these safely be ignored? The flashed partitions seem to work correctly.

Yes, I too find these ugly. It is a ‘make monitor weirdism:

https://www.esp32.com/viewtopic.php?t=4199

No, no need to worry. Those are from the ``make monitor`` command. As soon as this sees a hex number scroll by that smells like an address in the ESP32 memory map, it tries to be helpful and converts it to a symbol. In some cases, this leads it to weird messages like this.

...

b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command?

Supposedly if the OTA partition doesn’t boot (or checksum mismatch, etc), the bootloader will boot factory.

The selection of current boot partition is in the otadata partition:

# OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M

I guess zapping that would reset to defaults (factory boot)? I think erase_region may do that:

esptool.py erase_region 0xd000 0x2000

But, haven’t tried it myself.

...

c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com and fails to download from api.openvehicles.com, regardless of the type of network (wifi/modem).

I saw this a few months ago, but not recently.

Line 107 of ovms_net.cpp. It just does a getaddrinfo() on the host.

Regards, Mark.

...

On 12 Mar 2018, at 7:13 AM, Michael Balzer <dexter@expeedo.de> wrote:

Working on the OTA web UI.

Some questions:

a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages:

OVMS > ota flash vfs /sd/ovms3.done Current running partition is: ota_0 Target partition is: ota_1 Source image is 1480592 bytes in size Preparing flash partition... Flashing image partition... Setting boot partition... OTA flash was successful Flashed 1480592 bytes from /sd/ovms3.done Next boot will be from 'ota_1' I (1316956) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (1317156) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (1317156) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 ( 1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (1317166) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (1317176) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:?

I (1317746) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293

I (1317776) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 ( 52) I (1317776) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (1317976) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (1317986) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 ( 1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (1317986) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (1317996) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:?

I (1318566) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293

I (1318606) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 ( 52)

…

OVMS > ota boot ota_1 Boot from ota_1 at 0x00810000 (size 0x00400000) I (301766) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (301966) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (301976) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 ( 1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (301976) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (301986) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:?

I (302556) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293

I (302596) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 ( 52)

Can these safely be ignored? The flashed partitions seem to work correctly.

b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command?

I would have expected "make flash" to reset the boot partition to "factory", as all flashes are only done there, but it doesn't.

So if you're on another partition with a broken firmware, how do you recover? Is there a way to set the boot partition using esptool.py?

c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com and fails to download from api.openvehicles.com, regardless of the type of network (wifi/modem).

OVMS > ota flash http www.google.com/ovms3.bin Current running partition is: factory Target partition is: ota_0 Download firmware from www.google.com/ovms3.bin to ota_0 Error: Request failed W (666891) net: DNS lookup on www.google.com failed err=200

OVMS > ota flash http api.openvehicles.com/test.bin Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/test.bin to ota_0 […dead, needs reset]

Is this a local problem of mine?

Regards, Michael

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

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

DNS DHCP Am 17.03.2018 um 12:44 schrieb Michael Balzer:

Maybe renewing the DNS lease would also fix my new issue.

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

I haven’t watched closely enough to see if the AP mode offers a separate logical interface as an AP target (where a separate dhcp daemon/server would need to be running/listening), as that very well may muck with the above logic considerably otherwise.

It does. I have some ideas on this, and will reply to Michael’s thread. Regards, Mark.

On 17 Mar 2018, at 8:50 PM, Shaun Jurrens <shamziman@gmail.com> wrote:

Hi,

I am just a passive observer still, unfortunately. I believe your net manager should be able to deal with these events and trigger the lease (renew) request.

The logic would entail having a preferred interface, most likely the Wi-Fi interface, if present, because we can’t really determine which dhcp client will get its lease first (or last) in situations like at boot-up.

If both interfaces are up at boot, only the preferred interface runs the dhcp request for IP address, default gateway, DNS server info, etc. Otherwise, obviously, the non-preferred interface does this.

If the preferred interface loses “up”(link) status (for some random transient period, we don’t want to flap back and forth too much), the second interface runs a dhcp lease request.

If the preferred interface again has link up, a dhcp lease request is sent, which then “resets” the DNS server info after getting an IP and default gateway.

This is a pretty rough algorithm and ignores other eventual flakiness on the ESP side for other edge cases, but it should solve a few of the basic multi-homed challenges. Basically, you really just want one OVMS “client” interface working at a time to keep it simple.

I haven’t watched closely enough to see if the AP mode offers a separate logical interface as an AP target (where a separate dhcp daemon/server would need to be running/listening), as that very well may muck with the above logic considerably otherwise.

Yada, yada, Shaun

...

On 17 Mar 2018, at 12:48, Michael Balzer <dexter@expeedo.de> wrote:

DNS DHCP

...

Am 17.03.2018 um 12:44 schrieb Michael Balzer: Maybe renewing the DNS lease would also fix my new issue.

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I found and fixed an issue with wifi not attempting STA reconnections in APCLIENT mode. That may have been the cause of some of Greg’s issues. Regarding Wifi and Modem co-existing, I think this is a similar issue to what I saw with APCLIENT. Sometimes wifi doesn’t remove the interface. There is also a race condition where an interface is ‘up’, but has not yet been assigned an IP address (as is the case with the ‘pp’ interface you show below). I remain convinced that the correct way to deal with this is to bind our source address to the preferred interface, whenever we want to make an outgoing call. But, looking at the mongoose library code they simply don’t seem to offer that option. The standard socket API does, of course, have the bind option after socket creation but before connect. LWIP does, however, seem to have an alternative: netif_set_default(). That function supposedly sets the default interface to be used, unless one is specified manually (presumably by binding the socket). I think we can have net manager use that whenever modem/wifi comes up or goes down. Going down that route, I added it, but then found some messy handling (in netmanager) of m_connected_wifi. That would be set if either a STA or AP wifi came up, but that doesn’t seem right. We don’t want to set default routes out an AP link. So, I refactored that, and added a separate m_wifi_ap flag in netmanager to track AP being up/down. Then, that introduced a problem into MDNS as it was listening on the network.wifi.up event (as it needs to come up both in AP and STA modes), so I fixed MDNS to work like the others. I may re-visit this tomorrow, as perhaps two new events ‘wifi.any.up’ and ‘wifi.any.down’ may be a better way to do this (rather than the generic network manager messages we are using at the moment, with the client then checking the flags to see which one came up - wifi or modem). There is a new Info level output from ‘netmanager’ to show if it changes the default interface, and I extended ‘network status’ to show link status on interfaces, interface numbers, and default interface status. This should give us some more visibility as to what is going on. I haven’t managed to find the issue with wifi AP not bringing down interfaces correctly. Overall, this was a fairly large re-factor, and I am concerned about unintended consequences. I do, however, think that the approach is right. I haven’t got cellular coverage at home (almost midnight here) so can’t test modem connections. I’ll take it for a drive tomorrow and try then. This is what it looks like for me, tonight: OVMS > wifi mode apclient AP STA Starting WIFI as Access Point and Client... ... I (21957) wifi: mode : sta (re:da:ct:ed:da:ta) + softAP (al:so:re:da:ct:ed) I (21967) events: Signal(system.wifi.sta.start) I (21977) events: Signal(system.wifi.ap.start) I (21987) esp32wifi: AP started with SSID: STA, MAC: al:so:re:da:ct:ed, IP: 192.168.4.1 I (21987) events: Signal(network.mgr.init) I (22027) ovms-mdns: Launching MDNS service OVMS > network Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 Interface#1: st1 (ifup=0 linkup=1) IPv4: 0.0.0.0/0.0.0.0 gateway 0.0.0.0 Interface#0: lo0 (ifup=1 linkup=1) IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1 DNS: None Default Interface: ap2 (192.168.4.1/255.255.255.0 gateway 192.168.4.1) ... I (24377) wifi: connected with STA, channel 11 I (24387) events: Signal(system.wifi.sta.connected) I (27737) event: sta ip: 10.x.x.212, mask: 255.255.255.0, gw: 10.x.x.64 I (27747) events: Signal(network.interface.up) I (27747) netmanager: Set DNS#0 8.8.8.8 I (27757) netmanager: Set DNS#1 8.8.4.4 I (27757) events: Signal(system.wifi.sta.gotip) I (27767) netmanager: Interface priority is st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64) I (27767) events: Signal(network.wifi.up) I (27777) events: Signal(network.up) I (27787) time: Starting SNTP client I (27787) esp32wifi: WiFi UP with SSID: STA, MAC: re:da:ct:ed:da:ta, IP: 10.x.x.212, mask: 255.x.x.0, gw: 10.x.x.64 D (27827) time: ntp (stratum 1 trusted 1) provides time Sat Mar 17 15:30:37 2018 (135125us) UTC OVMS > network Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 Interface#1: st1 (ifup=1 linkup=1) IPv4: 10.x.x.212/255.255.25.0 gateway 10.x.x.64 Interface#0: lo0 (ifup=1 linkup=1) IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1 DNS: 8.8.8.8 8.8.4.4 Default Interface: st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64) All the above is committed, and pushed. Regards, Mark.

On 17 Mar 2018, at 7:40 PM, Michael Balzer <dexter@expeedo.de> wrote:

New issue, possibly also routing related: powering down the modem to force using Wifi used to work before, I now get:

I (724597) gsm-ppp: status_cb: Connected I (724597) gsm-ppp: our_ipaddr = 10.170.195.13 I (724597) gsm-ppp: his_ipaddr = 10.64.64.64 I (724597) gsm-ppp: netmask = 255.255.255.255 I (724597) gsm-ppp: our6_ipaddr = :: I (724597) netmanager: Set DNS#0 8.8.8.8 I (724597) netmanager: Set DNS#1 8.8.4.4 I (724597) time: Starting SNTP client

OVMS > network status Interface#2: pp IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 > ota flash http ovms.dexters-web.de/g/spacer.gif Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/g/spacer.gif to ota_0 Expected file size is 67 Preparing flash partition... Error: ESP32 error #5379 when writing to flash - state is inconsistent E (763827) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x47

OVMS > power simcom off Power mode of simcom is now off I (782817) simcom: State: Enter PoweringOff state I (782817) gsm-ppp: Shutting down (soft)... I (782817) time: Restarting SNTP client I (782827) gsm-nmea: Shutdown (direct) I (782837) simcom: Power Cycle

OVMS > network status Interface#2: pp IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 I (793147) simcom: State timeout, transition to 1 I (793147) simcom: State: Enter CheckPowerOff state I (794657) gsm-ppp: StatusCallBack: User Interrupt I (794657) gsm-ppp: PPP connection has been closed

OVMS > network status Interface#2: pp IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 > ota flash http ovms.dexters-web.de/g/spacer.gif Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/g/spacer.gif to ota_0 Error: Request failed W (807247) net: Error: Failed to connect server ovms.dexters-web.de (error: 118)

Error 118 = Host is unreachable.

Same with modem setstate. The problem occurs after the first ppp init.

Regards, Michael

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I’ll be stunned if I got it 100%, but it should be closer to what we want. I’ve got mine set to modem + AP + STA (home Wi-Fi) - that will be a pretty good test. Regards, Mark

On 18 Mar 2018, at 12:06 AM, Michael Balzer <dexter@expeedo.de> wrote:

Looks good!

I've switched wifi and modem on and off a couple times, it always correctly reconfigured, with priority for wifi, and ota flash was usable on all connections.

I'll do some road tests later on.

Regards, Michael

...

Am 17.03.2018 um 16:49 schrieb Mark Webb-Johnson:

I found and fixed an issue with wifi not attempting STA reconnections in APCLIENT mode. That may have been the cause of some of Greg’s issues.

Regarding Wifi and Modem co-existing, I think this is a similar issue to what I saw with APCLIENT. Sometimes wifi doesn’t remove the interface. There is also a race condition where an interface is ‘up’, but has not yet been assigned an IP address (as is the case with the ‘pp’ interface you show below).

I remain convinced that the correct way to deal with this is to bind our source address to the preferred interface, whenever we want to make an outgoing call. But, looking at the mongoose library code they simply don’t seem to offer that option. The standard socket API does, of course, have the bind option after socket creation but before connect.

LWIP does, however, seem to have an alternative: netif_set_default(). That function supposedly sets the default interface to be used, unless one is specified manually (presumably by binding the socket). I think we can have net manager use that whenever modem/wifi comes up or goes down.

Going down that route, I added it, but then found some messy handling (in netmanager) of m_connected_wifi. That would be set if either a STA or AP wifi came up, but that doesn’t seem right. We don’t want to set default routes out an AP link. So, I refactored that, and added a separate m_wifi_ap flag in netmanager to track AP being up/down. Then, that introduced a problem into MDNS as it was listening on the network.wifi.up event (as it needs to come up both in AP and STA modes), so I fixed MDNS to work like the others. I may re-visit this tomorrow, as perhaps two new events ‘wifi.any.up’ and ‘wifi.any.down’ may be a better way to do this (rather than the generic network manager messages we are using at the moment, with the client then checking the flags to see which one came up - wifi or modem).

There is a new Info level output from ‘netmanager’ to show if it changes the default interface, and I extended ‘network status’ to show link status on interfaces, interface numbers, and default interface status. This should give us some more visibility as to what is going on.

I haven’t managed to find the issue with wifi AP not bringing down interfaces correctly.

Overall, this was a fairly large re-factor, and I am concerned about unintended consequences. I do, however, think that the approach is right. I haven’t got cellular coverage at home (almost midnight here) so can’t test modem connections. I’ll take it for a drive tomorrow and try then.

This is what it looks like for me, tonight:

OVMS > wifi mode apclient AP STA Starting WIFI as Access Point and Client... ... I (21957) wifi: mode : sta (re:da:ct:ed:da:ta) + softAP (al:so:re:da:ct:ed) I (21967) events: Signal(system.wifi.sta.start) I (21977) events: Signal(system.wifi.ap.start) I (21987) esp32wifi: AP started with SSID: STA, MAC: al:so:re:da:ct:ed, IP: 192.168.4.1 I (21987) events: Signal(network.mgr.init) I (22027) ovms-mdns: Launching MDNS service

OVMS > network Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1

Interface#1: st1 (ifup=0 linkup=1) IPv4: 0.0.0.0/0.0.0.0 gateway 0.0.0.0

Interface#0: lo0 (ifup=1 linkup=1) IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1

DNS: None

Default Interface: ap2 (192.168.4.1/255.255.255.0 gateway 192.168.4.1)

... I (24377) wifi: connected with STA, channel 11 I (24387) events: Signal(system.wifi.sta.connected) I (27737) event: sta ip: 10.x.x.212, mask: 255.255.255.0, gw: 10.x.x.64 I (27747) events: Signal(network.interface.up) I (27747) netmanager: Set DNS#0 8.8.8.8 I (27757) netmanager: Set DNS#1 8.8.4.4 I (27757) events: Signal(system.wifi.sta.gotip) I (27767) netmanager: Interface priority is st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64) I (27767) events: Signal(network.wifi.up) I (27777) events: Signal(network.up) I (27787) time: Starting SNTP client I (27787) esp32wifi: WiFi UP with SSID: STA, MAC: re:da:ct:ed:da:ta, IP: 10.x.x.212, mask: 255.x.x.0, gw: 10.x.x.64 D (27827) time: ntp (stratum 1 trusted 1) provides time Sat Mar 17 15:30:37 2018 (135125us) UTC

OVMS > network Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1

Interface#1: st1 (ifup=1 linkup=1) IPv4: 10.x.x.212/255.255.25.0 gateway 10.x.x.64

Interface#0: lo0 (ifup=1 linkup=1) IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1

DNS: 8.8.8.8 8.8.4.4

Default Interface: st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64)

All the above is committed, and pushed.

Regards, Mark.

...

On 17 Mar 2018, at 7:40 PM, Michael Balzer <dexter@expeedo.de> wrote:

New issue, possibly also routing related: powering down the modem to force using Wifi used to work before, I now get:

I (724597) gsm-ppp: status_cb: Connected I (724597) gsm-ppp: our_ipaddr = 10.170.195.13 I (724597) gsm-ppp: his_ipaddr = 10.64.64.64 I (724597) gsm-ppp: netmask = 255.255.255.255 I (724597) gsm-ppp: our6_ipaddr = :: I (724597) netmanager: Set DNS#0 8.8.8.8 I (724597) netmanager: Set DNS#1 8.8.4.4 I (724597) time: Starting SNTP client

OVMS > network status Interface#2: pp IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 > ota flash http ovms.dexters-web.de/g/spacer.gif Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/g/spacer.gif to ota_0 Expected file size is 67 Preparing flash partition... Error: ESP32 error #5379 when writing to flash - state is inconsistent E (763827) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x47

OVMS > power simcom off Power mode of simcom is now off I (782817) simcom: State: Enter PoweringOff state I (782817) gsm-ppp: Shutting down (soft)... I (782817) time: Restarting SNTP client I (782827) gsm-nmea: Shutdown (direct) I (782837) simcom: Power Cycle

OVMS > network status Interface#2: pp IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 I (793147) simcom: State timeout, transition to 1 I (793147) simcom: State: Enter CheckPowerOff state I (794657) gsm-ppp: StatusCallBack: User Interrupt I (794657) gsm-ppp: PPP connection has been closed

OVMS > network status Interface#2: pp IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 > ota flash http ovms.dexters-web.de/g/spacer.gif Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/g/spacer.gif to ota_0 Error: Request failed W (807247) net: Error: Failed to connect server ovms.dexters-web.de (error: 118)

Error 118 = Host is unreachable.

Same with modem setstate. The problem occurs after the first ppp init.

Regards, Michael

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Greg, Can you capture the logs (info level is probably sufficient) on startup through to network connection. Then, when you can’t get access to the web server, show us the output of ‘network status’. Regards, Mark.

On 18 Mar 2018, at 6:42 AM, Greg D. <gregd2350@gmail.com> wrote:

Yes, most definitely better! Also like the added information in network status. But I'm still having trouble with the webserver. Actually, worse than before. If I believe Chrome, it is complaining that the connection to 192.168.4.1 was refused ("err_connection_refused"). Firefox also fails, but doesn't say why. The interface can be pinged, but no joy with getting to the webserver. This also fails if I have the wifi client connected, and put my phone on the same router to go in that way. As with the AP mode, I can ping the client interface from my phone, but the browser doesn't connect to the webserver process.

I somehow managed to get the web interface to work briefly, but can't repeat it, even when configured for just AP mode.

As shown by network status, the connection to server v2 flips back and forth between wifi and modem, but not reliably. I often see the network pointing at an interface, yet the server can't apparently be reached through it to connect. DNS is set statically to '9.9.9.9 8.8.8.8' (Quad 9 and Google), to avoid any issues with the dhclient, though I'm consistently seeing correct information for IP address, network mask, and gateway.

Greg

Mark Webb-Johnson wrote:

...

I’ll be stunned if I got it 100%, but it should be closer to what we want.

I’ve got mine set to modem + AP + STA (home Wi-Fi) - that will be a pretty good test.

Regards, Mark

On 18 Mar 2018, at 12:06 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

...

Looks good!

I've switched wifi and modem on and off a couple times, it always correctly reconfigured, with priority for wifi, and ota flash was usable on all connections.

I'll do some road tests later on.

Regards, Michael

Am 17.03.2018 um 16:49 schrieb Mark Webb-Johnson:

...

I found and fixed an issue with wifi not attempting STA reconnections in APCLIENT mode. That may have been the cause of some of Greg’s issues.

Regarding Wifi and Modem co-existing, I think this is a similar issue to what I saw with APCLIENT. Sometimes wifi doesn’t remove the interface. There is also a race condition where an interface is ‘up’, but has not yet been assigned an IP address (as is the case with the ‘pp’ interface you show below).

I remain convinced that the correct way to deal with this is to bind our source address to the preferred interface, whenever we want to make an outgoing call. But, looking at the mongoose library code they simply don’t seem to offer that option. The standard socket API does, of course, have the bind option after socket creation but before connect.

LWIP does, however, seem to have an alternative: netif_set_default(). That function supposedly sets the default interface to be used, unless one is specified manually (presumably by binding the socket). I think we can have net manager use that whenever modem/wifi comes up or goes down.

Going down that route, I added it, but then found some messy handling (in netmanager) of m_connected_wifi. That would be set if either a STA or AP wifi came up, but that doesn’t seem right. We don’t want to set default routes out an AP link. So, I refactored that, and added a separate m_wifi_ap flag in netmanager to track AP being up/down. Then, that introduced a problem into MDNS as it was listening on the network.wifi.up event (as it needs to come up both in AP and STA modes), so I fixed MDNS to work like the others. I may re-visit this tomorrow, as perhaps two new events ‘wifi.any.up’ and ‘wifi.any.down’ may be a better way to do this (rather than the generic network manager messages we are using at the moment, with the client then checking the flags to see which one came up - wifi or modem).

There is a new Info level output from ‘netmanager’ to show if it changes the default interface, and I extended ‘network status’ to show link status on interfaces, interface numbers, and default interface status. This should give us some more visibility as to what is going on.

I haven’t managed to find the issue with wifi AP not bringing down interfaces correctly.

Overall, this was a fairly large re-factor, and I am concerned about unintended consequences. I do, however, think that the approach is right. I haven’t got cellular coverage at home (almost midnight here) so can’t test modem connections. I’ll take it for a drive tomorrow and try then.

This is what it looks like for me, tonight:

OVMS > wifi mode apclient AP STA Starting WIFI as Access Point and Client... ... I (21957) wifi: mode : sta (re:da:ct:ed:da:ta) + softAP (al:so:re:da:ct:ed) I (21967) events: Signal(system.wifi.sta.start) I (21977) events: Signal(system.wifi.ap.start) I (21987) esp32wifi: AP started with SSID: STA, MAC: al:so:re:da:ct:ed, IP: 192.168.4.1 I (21987) events: Signal(network.mgr.init) I (22027) ovms-mdns: Launching MDNS service

OVMS > network Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1

Interface#1: st1 (ifup=0 linkup=1) IPv4: 0.0.0.0/0.0.0.0 gateway 0.0.0.0

Interface#0: lo0 (ifup=1 linkup=1) IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1

DNS: None

Default Interface: ap2 (192.168.4.1/255.255.255.0 gateway 192.168.4.1)

... I (24377) wifi: connected with STA, channel 11 I (24387) events: Signal(system.wifi.sta.connected) I (27737) event: sta ip: 10.x.x.212, mask: 255.255.255.0, gw: 10.x.x.64 I (27747) events: Signal(network.interface.up) I (27747) netmanager: Set DNS#0 8.8.8.8 I (27757) netmanager: Set DNS#1 8.8.4.4 I (27757) events: Signal(system.wifi.sta.gotip) I (27767) netmanager: Interface priority is st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64) I (27767) events: Signal(network.wifi.up) I (27777) events: Signal(network.up) I (27787) time: Starting SNTP client I (27787) esp32wifi: WiFi UP with SSID: STA, MAC: re:da:ct:ed:da:ta, IP: 10.x.x.212, mask: 255.x.x.0, gw: 10.x.x.64 D (27827) time: ntp (stratum 1 trusted 1) provides time Sat Mar 17 15:30:37 2018 (135125us) UTC

OVMS > network Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1

Interface#1: st1 (ifup=1 linkup=1) IPv4: 10.x.x.212/255.255.25.0 gateway 10.x.x.64

Interface#0: lo0 (ifup=1 linkup=1) IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1

DNS: 8.8.8.8 8.8.4.4

Default Interface: st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64)

All the above is committed, and pushed.

Regards, Mark.

...

On 17 Mar 2018, at 7:40 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

New issue, possibly also routing related: powering down the modem to force using Wifi used to work before, I now get:

I (724597) gsm-ppp: status_cb: Connected I (724597) gsm-ppp: our_ipaddr = 10.170.195.13 I (724597) gsm-ppp: his_ipaddr = 10.64.64.64 I (724597) gsm-ppp: netmask = 255.255.255.255 I (724597) gsm-ppp: our6_ipaddr = :: I (724597) netmanager: Set DNS#0 8.8.8.8 I (724597) netmanager: Set DNS#1 8.8.4.4 I (724597) time: Starting SNTP client

OVMS > network status Interface#2: pp IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 > ota flash http ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif> Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif> to ota_0 Expected file size is 67 Preparing flash partition... Error: ESP32 error #5379 when writing to flash - state is inconsistent E (763827) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x47

OVMS > power simcom off Power mode of simcom is now off I (782817) simcom: State: Enter PoweringOff state I (782817) gsm-ppp: Shutting down (soft)... I (782817) time: Restarting SNTP client I (782827) gsm-nmea: Shutdown (direct) I (782837) simcom: Power Cycle

OVMS > network status Interface#2: pp IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 I (793147) simcom: State timeout, transition to 1 I (793147) simcom: State: Enter CheckPowerOff state I (794657) gsm-ppp: StatusCallBack: User Interrupt I (794657) gsm-ppp: PPP connection has been closed

OVMS > network status Interface#2: pp IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0

Interface#1: st IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1

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 > ota flash http ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif> Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif> to ota_0 Error: Request failed W (807247) net: Error: Failed to connect server ovms.dexters-web.de <http://ovms.dexters-web.de/> (error: 118)

Error 118 = Host is unreachable.

Same with modem setstate. The problem occurs after the first ppp init.

Regards, Michael

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Am 18.03.2018 um 04:18 schrieb Greg D.:

Sure, will do.  The default (out-of-box) config is to have Auto enabled for AP mode and Modem on, right?  Anything else?

If I erase the config points under Auto, will the module re-create them in the default state for me on the next boot?

Greg

Not quite, factory default auto start will not power on the modem. The default auto config is: Instance                Default           Remark ---------------------------------------------------------------------- init                    yes wifi.mode               ap                off|ap|client|apclient wifi.ssid.ap            OVMS wifi.ssid.client        -                 empty = scanning mode modem                   no vehicle.type            -                 moved from vehicle/type server.v2               no server.v3               no ext12v no obd2ecu - (with "-" meaning empty) The defaults are automatically used if an instance misses or is empty, but missing instances will not be recreated. Regards, Michael

Mark Webb-Johnson wrote:

...

Greg,

Can you capture the logs (info level is probably sufficient) on startup through to network connection. Then, when you can’t get access to the web server, show us the output of ‘network status’.

Regards, Mark.

...

On 18 Mar 2018, at 6:42 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

Yes, most definitely better!  Also like the added information in network status.  But I'm still having trouble with the webserver.  Actually, worse than before.  If I believe Chrome, it is complaining that the connection to 192.168.4.1 was refused ("err_connection_refused").  Firefox also fails, but doesn't say why.  The interface can be pinged, but no joy with getting to the webserver.  This also fails if I have the wifi client connected, and put my phone on the same router to go in that way.  As with the AP mode, I can ping the client interface from my phone, but the browser doesn't connect to the webserver process.

I somehow managed to get the web interface to work briefly, but can't repeat it, even when configured for just AP mode.

As shown by network status, the connection to server v2 flips back and forth between wifi and modem, but not reliably.  I often see the network pointing at an interface, yet the server can't apparently be reached through it to connect.  DNS is set statically to '9.9.9.9 8.8.8.8'  (Quad 9 and Google), to avoid any issues with the dhclient, though I'm consistently seeing correct information for IP address, network mask, and gateway.

Greg

Mark Webb-Johnson wrote:

...

I’ll be stunned if I got it 100%, but it should be closer to what we want.

I’ve got mine set to modem + AP + STA (home Wi-Fi) - that will be a pretty good test.

Regards, Mark

On 18 Mar 2018, at 12:06 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

...

Looks good!

I've switched wifi and modem on and off a couple times, it always correctly reconfigured, with priority for wifi, and ota flash was usable on all connections.

I'll do some road tests later on.

Regards, Michael

Am 17.03.2018 um 16:49 schrieb Mark Webb-Johnson:

...

I found and fixed an issue with wifi not attempting STA reconnections in APCLIENT mode. That may have been the cause of some of Greg’s issues.

Regarding Wifi and Modem co-existing, I think this is a similar issue to what I saw with APCLIENT. Sometimes wifi doesn’t remove the interface. There is also a race condition where an interface is ‘up’, but has not yet been assigned an IP address (as is the case with the ‘pp’ interface you show below).

I remain convinced that the correct way to deal with this is to bind our source address to the preferred interface, whenever we want to make an outgoing call. But, looking at the mongoose library code they simply don’t seem to offer that option. The standard socket API does, of course, have the bind option after socket creation but before connect.

LWIP does, however, seem to have an alternative: netif_set_default(). That function supposedly sets the default interface to be used, unless one is specified manually (presumably by binding the socket). I think we can have net manager use that whenever modem/wifi comes up or goes down.

Going down that route, I added it, but then found some messy handling (in netmanager) of m_connected_wifi. That would be set if either a STA or AP wifi came up, but that doesn’t seem right. We don’t want to set default routes out an AP link. So, I refactored that, and added a separate m_wifi_ap flag in netmanager to track AP being up/down. Then, that introduced a problem into MDNS as it was listening on the network.wifi.up event (as it needs to come up both in AP and STA modes), so I fixed MDNS to work like the others. I may re-visit this tomorrow, as perhaps two new events ‘wifi.any.up’ and ‘wifi.any.down’ may be a better way to do this (rather than the generic network manager messages we are using at the moment, with the client then checking the flags to see which one came up - wifi or modem).

There is a new Info level output from ‘netmanager’ to show if it changes the default interface, and I extended ‘network status’ to show link status on interfaces, interface numbers, and default interface status. This should give us some more visibility as to what is going on.

I haven’t managed to find the issue with wifi AP not bringing down interfaces correctly.

Overall, this was a fairly large re-factor, and I am concerned about unintended consequences. I do, however, think that the approach is right. I haven’t got cellular coverage at home (almost midnight here) so can’t test modem connections. I’ll take it for a drive tomorrow and try then.

This is what it looks like for me, tonight:

OVMS > wifi mode apclient AP STA Starting WIFI as Access Point and Client... ... I (21957) wifi: mode : sta (re:da:ct:ed:da:ta) + softAP (al:so:re:da:ct:ed) I (21967) events: Signal(system.wifi.sta.start) I (21977) events: Signal(system.wifi.ap.start) I (21987) esp32wifi: AP started with SSID: STA, MAC: al:so:re:da:ct:ed, IP: 192.168.4.1 I (21987) events: Signal(network.mgr.init) I (22027) ovms-mdns: Launching MDNS service

OVMS > network Interface#2: ap2 (ifup=1 linkup=1)   IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1

Interface#1: st1 (ifup=0 linkup=1)   IPv4: 0.0.0.0/0.0.0.0 gateway 0.0.0.0

Interface#0: lo0 (ifup=1 linkup=1)   IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1

DNS: None

Default Interface: ap2 (192.168.4.1/255.255.255.0 gateway 192.168.4.1)

... I (24377) wifi: connected with STA, channel 11 I (24387) events: Signal(system.wifi.sta.connected) I (27737) event: sta ip: 10.x.x.212, mask: 255.255.255.0, gw: 10.x.x.64 I (27747) events: Signal(network.interface.up) I (27747) netmanager: Set DNS#0 8.8.8.8 I (27757) netmanager: Set DNS#1 8.8.4.4 I (27757) events: Signal(system.wifi.sta.gotip) I (27767) netmanager: Interface priority is st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64) I (27767) events: Signal(network.wifi.up) I (27777) events: Signal(network.up) I (27787) time: Starting SNTP client I (27787) esp32wifi: WiFi UP with SSID: STA, MAC: re:da:ct:ed:da:ta, IP: 10.x.x.212, mask: 255.x.x.0, gw: 10.x.x.64 D (27827) time: ntp (stratum 1 trusted 1) provides time Sat Mar 17 15:30:37 2018 (135125us) UTC

OVMS > network Interface#2: ap2 (ifup=1 linkup=1)   IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1

Interface#1: st1 (ifup=1 linkup=1)   IPv4: 10.x.x.212/255.255.25.0 gateway 10.x.x.64

Interface#0: lo0 (ifup=1 linkup=1)   IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1

DNS: 8.8.8.8 8.8.4.4

Default Interface: st1 (10.x.x.212/255.255.255.0 gateway 10.x.x.64)

All the above is committed, and pushed.

Regards, Mark.

> On 17 Mar 2018, at 7:40 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > New issue, possibly also routing related: powering down the modem to force using Wifi used to work before, I now get: > > I (724597) gsm-ppp: status_cb: Connected > I (724597) gsm-ppp:    our_ipaddr  = 10.170.195.13 > I (724597) gsm-ppp:    his_ipaddr  = 10.64.64.64 > I (724597) gsm-ppp:    netmask     = 255.255.255.255 > I (724597) gsm-ppp:    our6_ipaddr = :: > I (724597) netmanager: Set DNS#0 8.8.8.8 > I (724597) netmanager: Set DNS#1 8.8.4.4 > I (724597) time: Starting SNTP client > * > OVMS > network status * > Interface#2: pp >   IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 > > Interface#1: st >   IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1 > > 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 > ota flash http ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif>* > Current running partition is: factory > Target partition is: ota_0 > Download firmware from ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif> to ota_0 > Expected file size is 67 > Preparing flash partition... > Error: ESP32 error #5379 when writing to flash - state is inconsistent > E (763827) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x47 > * > OVMS > power simcom off* > Power mode of simcom is now off > I (782817) simcom: State: Enter PoweringOff state > I (782817) gsm-ppp: Shutting down (soft)... > I (782817) time: Restarting SNTP client > I (782827) gsm-nmea: Shutdown (direct) > I (782837) simcom: Power Cycle > * > OVMS > network status * > Interface#2: pp >   IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0 > > Interface#1: st >   IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1 > > 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 > I (793147) simcom: State timeout, transition to 1 > I (793147) simcom: State: Enter CheckPowerOff state > I (794657) gsm-ppp: StatusCallBack: User Interrupt > I (794657) gsm-ppp: PPP connection has been closed > > *OVMS > network status * > Interface#2: pp >   IPv4: 0.0.0.0/255.255.255.255 gateway 0.0.0.0 > > Interface#1: st >   IPv4: 192.168.2.105/255.255.255.0 gateway 192.168.2.1 > > 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 > ota flash http ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif>* > Current running partition is: factory > Target partition is: ota_0 > Download firmware from ovms.dexters-web.de/g/spacer.gif <http://ovms.dexters-web.de/g/spacer.gif> to ota_0 > Error: Request failed > *W (807247) net: Error: Failed to connect server ovms.dexters-web.de <http://ovms.dexters-web.de/> (error: 118)* > > > Error 118 = Host is unreachable. > > Same with modem setstate. The problem occurs after the first ppp init. > > Regards, > Michael > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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

This is causing a crash for me: I (45043) simcom: State timeout, transition to 13 I (45043) simcom: State: Enter PoweredOff stateGuru Meditation Error: Core 0 panic'ed (LoadProhibited) . Exception was unhandled. Core 0 register dump: PC : 0x4012cdb4 PS : 0x00060030 A0 : 0x8012b791 A1 : 0x3ffd13b0 0x4012cdb4: GsmMux::Stop() at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmmux.cpp:246 A2 : 0x3ffda730 A3 : 0x00000001 A4 : 0x00000004 A5 : 0x0000001f A6 : 0x00000001 A7 : 0x00000005 A8 : 0x8012cdaa A9 : 0x3ffd1360 A10 : 0x400e0ce0 A11 : 0x3ffb3d00 A12 : 0x3f42c3f8 A13 : 0x00000040 0x400e0ce0: ConsoleAsync::ConsoleLogger(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:115 A14 : 0x00000009 A15 : 0x00000005 SAR : 0x0000000c EXCCAUSE: 0x0000001c EXCVADDR: 0x00000004 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff Backtrace: 0x4012cdb4:0x3ffd13b0 0x4012b78e:0x3ffd13d0 0x4012b7a5:0x3ffd1410 0x4012c67d:0x3ffd1430 0x4012c6e8:0x3ffd1450 0x400e5da1:0x3ffd1490 0x400e603d:0x3ffd14c0 0x400e6f53:0x3ffd1550 0x400e70e4:0x3ffd1600 0x4008d7fa:0x3ffd1620 0x4008d82d:0x3ffd1640 0x4008d93c:0x3ffd1670 0x4012cdb4: GsmMux::Stop() at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmmux.cpp:246 0x4012b78e: simcom::State1Enter(simcom::SimcomState1) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.cpp:469 0x4012b7a5: simcom::SetState1(simcom::SimcomState1) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.cpp:350 0x4012c67d: simcom::Ticker(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.cpp:267 I haven’t had a chance to look into cause yet (I’m working on the net manager issues Greg is seeing). Maybe clean-up of channels? Regards, Mark.

On 18 Mar 2018, at 4:43 PM, Michael Balzer <dexter@expeedo.de> wrote:

Am 18.03.2018 um 07:55 schrieb Greg D.:

...

Seems if I turn off the modem power (to prevent it from making a mess of things), the housekeeping process just turns it back on. Is there a command to stop that?

I've also noted this, it's not the housekeeper, it's the new simcom MUX watchdog. I've just pushed a fix for this, so "power simcom off" will stop the MUX.

Regards, Michael

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

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev