[Ovmsdev] ota questions
Michael Balzer
dexter at expeedo.de
Sun Mar 18 15:36:21 HKT 2018
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 at gmail.com <mailto: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
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 <mailto: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
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto: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
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180318/1c4b799f/attachment.htm>
More information about the OvmsDev
mailing list