[Ovmsdev] ota questions

Sun Mar 18 10:12:17 HKT 2018

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 at 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 at expeedo.de <mailto: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 <mailto: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 <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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> 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/4067ed8a/attachment.htm>