When driving, and therefore out of range of the home wifi, the following messges emitted every 10 seconds will fill up the log: I (2019-01-04 03:46:36.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:36.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:36.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:36.989) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:46.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:46.899) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:46.949) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:46.999) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:56.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:56.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:56.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:56.979) esp32wifi: STA disconnected with reason 201 I'd like to add code to suppress those messages when there is no change in state. Any objections? -- Steve
Steve, Presumably, you are set to connect to a particular wifi access point? (not scanning client mode). It would be good to suppress the netmanager work if the link was already disconnected (or suppress the messages if the interface priority doesn’t change, as a more general solution?). Same for the STA disconnection. Regards, Mark.
On 11 Jan 2019, at 6:17 AM, Stephen Casner <casner@acm.org> wrote:
When driving, and therefore out of range of the home wifi, the following messges emitted every 10 seconds will fill up the log:
I (2019-01-04 03:46:36.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:36.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:36.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:36.989) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:46.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:46.899) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:46.949) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:46.999) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:56.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:56.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:56.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:56.979) esp32wifi: STA disconnected with reason 201
I'd like to add code to suppress those messages when there is no change in state. Any objections?
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark, Yes, my unit is set to connect only to my home network. But even when set to scan it is unlikely to connect while driving. Rather than suppressing the netmanager work I was proposing to just suppress the messages if they would repeat from the previous time. -- Steve On Fri, 11 Jan 2019, Mark Webb-Johnson wrote:
Steve,
Presumably, you are set to connect to a particular wifi access point? (not scanning client mode).
It would be good to suppress the netmanager work if the link was already disconnected (or suppress the messages if the interface priority doesn't change, as a more general solution?). Same for the STA disconnection.
Regards, Mark.
On 11 Jan 2019, at 6:17 AM, Stephen Casner <casner@acm.org> wrote:
When driving, and therefore out of range of the home wifi, the following messges emitted every 10 seconds will fill up the log:
I (2019-01-04 03:46:36.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:36.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:36.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:36.989) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:46.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:46.899) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:46.949) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:46.999) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:56.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:56.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:56.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:56.979) esp32wifi: STA disconnected with reason 201
I'd like to add code to suppress those messages when there is no change in state. Any objections?
-- Steve
Steve, I think you broke something, I'm now losing connectivity after changing from wifi to modem or back. On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls. Regards, Michael Am 11.01.19 um 07:45 schrieb Stephen Casner:
Mark,
Yes, my unit is set to connect only to my home network. But even when set to scan it is unlikely to connect while driving.
Rather than suppressing the netmanager work I was proposing to just suppress the messages if they would repeat from the previous time.
-- Steve
On Fri, 11 Jan 2019, Mark Webb-Johnson wrote:
Steve,
Presumably, you are set to connect to a particular wifi access point? (not scanning client mode).
It would be good to suppress the netmanager work if the link was already disconnected (or suppress the messages if the interface priority doesn't change, as a more general solution?). Same for the STA disconnection.
Regards, Mark.
On 11 Jan 2019, at 6:17 AM, Stephen Casner <casner@acm.org> wrote:
When driving, and therefore out of range of the home wifi, the following messges emitted every 10 seconds will fill up the log:
I (2019-01-04 03:46:36.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:36.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:36.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:36.989) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:46.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:46.899) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:46.949) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:46.999) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:56.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:56.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:56.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:56.979) esp32wifi: STA disconnected with reason 201
I'd like to add code to suppress those messages when there is no change in state. Any objections?
-- Steve
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change. Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine? -- Steve On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
Maybe expressif/esp-idf vs openvehicles/esp-idf? On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
I'll change the implementation to more explicit checks. -- Steve On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
Steve, I'll try to find some time for a closer look this evening, but the error seems to be in there: I've reversed your commit yesterday for my module and it's working perfectly again today. My situation is standard (I believe…) of using wifi client mode at home and modem + wifi ap on the road. My wifi mode is apclient, using my phone for the dashboard on the road. Regards, Michael Am 17.01.19 um 00:44 schrieb Stephen Casner:
I'll change the implementation to more explicit checks.
-- Steve
On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
We’re up to 3.1.011-202-g3974d64, and looking good from my point of view. My javascript object code is in place, and working well. I’ve ported over a bunch of vehicle functions to OvmsVehicle object and they work well. I see Steve committed another change to try to address this. I’ll run it in my car, but might take a while to see if it solves the problem or not. Once we’ve got that stable, I think we are well overdue for a 3.1.012. Or maybe a 3.2.0 given the number of changes we have now? Regards, Mark.
On 17 Jan 2019, at 5:33 PM, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
I'll try to find some time for a closer look this evening, but the error seems to be in there: I've reversed your commit yesterday for my module and it's working perfectly again today.
My situation is standard (I believe…) of using wifi client mode at home and modem + wifi ap on the road. My wifi mode is apclient, using my phone for the dashboard on the road.
Regards, Michael
Am 17.01.19 um 00:44 schrieb Stephen Casner:
I'll change the implementation to more explicit checks.
-- Steve
On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark, To be clear, the change I committed should fix the problem for Michael that my earlier commit introduced, but this is not a fix for the weak wifi performance nor the wifi getting stuck. This change only avoids repeated log messages every 10 seconds when the wifi client is out of range of any AP. You can observe that right away by just driving away from your AP. I have now implemented the changes to ovms_location to support adding action parameters to the location configuration. I have not committed it yet, though, because there's no code yet to make those actions effective. -- Steve On Thu, 17 Jan 2019, Mark Webb-Johnson wrote:
We're up to 3.1.011-202-g3974d64, and looking good from my point of view. My javascript object code is in place, and working well. I've ported over a bunch of vehicle functions to OvmsVehicle object and they work well.
I see Steve committed another change to try to address this. I'll run it in my car, but might take a while to see if it solves the problem or not.
Once we've got that stable, I think we are well overdue for a 3.1.012. Or maybe a 3.2.0 given the number of changes we have now?
Regards, Mark.
On 17 Jan 2019, at 5:33 PM, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
I'll try to find some time for a closer look this evening, but the error seems to be in there: I've reversed your commit yesterday for my module and it's working perfectly again today.
My situation is standard (I believe...) of using wifi client mode at home and modem + wifi ap on the road. My wifi mode is apclient, using my phone for the dashboard on the road.
Regards, Michael
Am 17.01.19 um 00:44 schrieb Stephen Casner:
I'll change the implementation to more explicit checks.
-- Steve
On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Thanks Steve, the fix works. Regards, Michael Am 18.01.19 um 08:18 schrieb Stephen Casner:
Mark,
To be clear, the change I committed should fix the problem for Michael that my earlier commit introduced, but this is not a fix for the weak wifi performance nor the wifi getting stuck. This change only avoids repeated log messages every 10 seconds when the wifi client is out of range of any AP. You can observe that right away by just driving away from your AP.
I have now implemented the changes to ovms_location to support adding action parameters to the location configuration. I have not committed it yet, though, because there's no code yet to make those actions effective.
-- Steve
On Thu, 17 Jan 2019, Mark Webb-Johnson wrote:
We're up to 3.1.011-202-g3974d64, and looking good from my point of view. My javascript object code is in place, and working well. I've ported over a bunch of vehicle functions to OvmsVehicle object and they work well.
I see Steve committed another change to try to address this. I'll run it in my car, but might take a while to see if it solves the problem or not.
Once we've got that stable, I think we are well overdue for a 3.1.012. Or maybe a 3.2.0 given the number of changes we have now?
Regards, Mark.
On 17 Jan 2019, at 5:33 PM, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
I'll try to find some time for a closer look this evening, but the error seems to be in there: I've reversed your commit yesterday for my module and it's working perfectly again today.
My situation is standard (I believe...) of using wifi client mode at home and modem + wifi ap on the road. My wifi mode is apclient, using my phone for the dashboard on the road.
Regards, Michael
Am 17.01.19 um 00:44 schrieb Stephen Casner:
I'll change the implementation to more explicit checks.
-- Steve
On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, I already committed a more robust implementation that only skips log messages and no other steps. No need to investigate the previous behavior, just go ahead and update. -- Steve On Thu, 17 Jan 2019, Michael Balzer wrote:
Steve,
I'll try to find some time for a closer look this evening, but the error seems to be in there: I've reversed your commit yesterday for my module and it's working perfectly again today.
My situation is standard (I believe...) of using wifi client mode at home and modem + wifi ap on the road. My wifi mode is apclient, using my phone for the dashboard on the road.
Regards, Michael
Am 17.01.19 um 00:44 schrieb Stephen Casner:
I'll change the implementation to more explicit checks.
-- Steve
On Wed, 16 Jan 2019, Stephen Casner wrote:
Michael,
I thought that skipping the netif_set_default() and > SetDNSServer() calls would be OK there because they should be called when the priority interface (pri) changes. This worked for me. It was a simplification to avoid having to make a separe check inside the DNS code to suppress its messages when DNS did not change.
Now, I admit that comparing interface object addresses could give a false result if the objects come and go, but again I thought that did not happen here. Do you know why this would be different for your situation compared to mine?
-- Steve
On Wed, 16 Jan 2019, Michael Balzer wrote:
Steve,
I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and SetDNSServer() calls.
Regards, Michael
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner