[Ovmsdev] ota questions

Sun Mar 18 00:09:29 HKT 2018

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 at 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 at 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 at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at 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 at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180318/70d2f408/attachment.htm>