Time for release 3.2.016?
Everyone, we're 624 commits away from 3.2.015, and we've got a bunch of new features & vehicle support. We've had some changes recently, but apparently no issues with these (at least none reported). I'd say it's time for 3.2.016. Objections? Anything in the works that should be included? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2/7/21 1:18 PM, Michael Balzer wrote:
we're 624 commits away from 3.2.015, and we've got a bunch of new features & vehicle support.
We've had some changes recently, but apparently no issues with these (at least none reported).
I'd say it's time for 3.2.016.
Objections? Anything in the works that should be included? Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I current am running ovms-3.2.015-607-g84abbaf7 and the first time I saw the alert was after upgrading the esp32-wroom... Craig
On Sun, 7 Feb 2021, Craig Leres wrote:
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I current am running ovms-3.2.015-607-g84abbaf7 and the first time I saw the alert was after upgrading the esp32-wroom...
That alert should not happen if the car is "on". So unless the alert was triggered shortly before you turned on the car and backed out, but was delayed in delivery, this does not make sense. Is v.e.on implemented properly for your car? -- Steve
On 2/7/21 1:38 PM, Stephen Casner wrote:
That alert should not happen if the car is "on". So unless the alert was triggered shortly before you turned on the car and backed out, but was delayed in delivery, this does not make sense. Is v.e.on implemented properly for your car?
Apparently not, cadillac_c2_cts started a copy of obdii and I had commented out the lines that manage that for some reason. After a quick test in the cars, I just submitted a pull request that uncomments the missing StandardMetrics.ms_v_env_on->SetValue() calls. Now it's more symmetrical with chevrolet_c6_corvette (which is also based on the obdii example). Craig
What's the status of the "for-v3.3" branch? Last weekend after I upgraded the esp32-wroom module in my dev ovms box I tried updating and I couldn't get it to run. It would be nice to get the simcom refactoring into master (or at least catch for-v3.3 up with things like the persistent metrics update, etc). I'm not advocating this for 3.2.016, just expressing an interest in it happening in the near term. Another question I had is what is the difference between: http://api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin http://api.openvehicles.com/firmware/ota/v3.1/main/ovms3.ver and: http://api.openvehicles.com/firmware/ota/v3.2/main/ovms3.bin http://api.openvehicles.com/firmware/ota/v3.2/main/ovms3.ver The v3.1 version currently points to 3.2.15 and the v3.2 version points to 3.2.008 which wasn't what I was expecting when I was looking for a 3.2.008 image to flash in the factory partition of my modules. Craig
Craig,
What's the status of the "for-v3.3" branch?
That’s on me. I’ve been ill for the last month (not COVID, thankfully), and master has diverged from for-v3.3 causing conflicts. I hope to resolve this week.
Another question I had is what is the difference between:
The v3.0 / v3.1 / v3.2 in the URL path refers to the _hardware_ version, not firmware. For all current hardware we should be using: http://api.openvehicles.com/firmware/ota/v3.1/ <http://api.openvehicles.com/firmware/ota/v3.1/>... The v3.2 path is not currently used. I’ve renamed it as ‘v3.2.obsolete’ in api.openvehicles.com <http://api.openvehicles.com/> to try to avoid confusion. Regards, Mark
On 8 Feb 2021, at 10:11 AM, Craig Leres <leres@xse.com> wrote:
What's the status of the "for-v3.3" branch? Last weekend after I upgraded the esp32-wroom module in my dev ovms box I tried updating and I couldn't get it to run. It would be nice to get the simcom refactoring into master (or at least catch for-v3.3 up with things like the persistent metrics update, etc). I'm not advocating this for 3.2.016, just expressing an interest in it happening in the near term.
Another question I had is what is the difference between:
http://api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin http://api.openvehicles.com/firmware/ota/v3.1/main/ovms3.ver
and:
http://api.openvehicles.com/firmware/ota/v3.2/main/ovms3.bin http://api.openvehicles.com/firmware/ota/v3.2/main/ovms3.ver
The v3.1 version currently points to 3.2.15 and the v3.2 version points to 3.2.008 which wasn't what I was expecting when I was looking for a 3.2.008 image to flash in the factory partition of my modules.
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Sun, 7 Feb 2021, Michael Balzer wrote:
We've had some changes recently, but apparently no issues with these (at least none reported).
I'd say it's time for 3.2.016.
Objections? Anything in the works that should be included?
Craig observed that the ssh connect time doubled from 5 seconds to 10 seconds. I noticed that connecting seemed slow but since it's never been fast I had not run a comparison test. Would that be considered a problem for release? This slowness is disappointing considering that the new code is supposed to include access to ESP32 hardware acceleration. I think I have the configuration set correctly to include this. I will try to turn on some tracing and investigate further. -- Steve
Steve, I can confirm that effect. Didn't notice, as the connect had been slow before. Also, mongoose appears to be locked during the whole connect, no other network activity can take place. Regards, Michael Am 08.02.21 um 03:32 schrieb Stephen Casner:
On Sun, 7 Feb 2021, Michael Balzer wrote:
We've had some changes recently, but apparently no issues with these (at least none reported).
I'd say it's time for 3.2.016.
Objections? Anything in the works that should be included? Craig observed that the ssh connect time doubled from 5 seconds to 10 seconds. I noticed that connecting seemed slow but since it's never been fast I had not run a comparison test. Would that be considered a problem for release?
This slowness is disappointing considering that the new code is supposed to include access to ESP32 hardware acceleration. I think I have the configuration set correctly to include this. I will try to turn on some tracing and investigate further.
-- Steve
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I am trying to investigate why the SSH connection time is long (about 10 seconds). So I added some wolfssl debugging configuration changes and calls in my copy of the master branch where I build for my bench v3.0 hardware unit. That configuration is drastically stripped down in order to fit into the limited RAM available; for example, Duktape can't fit. But then I repeated Craig's timing test and found the delay was only 4 seconds, which I think is about the same as it was with the original version of wolfssh code. That's why I did not notice the increase as all of my development was done on the bench unit. The final testing was done on the v3.1 unit in my car, but I guess I just overlooked the delay there. So I think this means it's not a problem of crypto computation time, so whether or not hardware acceleration is working is not the issue. There must be some interaction among our network activities that is causing some action to wait for a timeout or a subsequent event. I will try to dig into this further, but testing on the unit in my car is much less convenient. First I need to repeat the test there with the same configuration as on the v3.0 hardware to verify if the time is still shorter, then I will need to pare down my operational configuration towards the stripped down one one to find the significant case. Maybe I can group the features to make a sort of binary search. I've attached my stripped-down config in case that might prompt any ideas from any of you. I've also attached a diff for a change I'd like to make in can.cpp. I have no use for CAN operations on my bench unit and I observed that the CanRx task consumed 29kB even though I had unconfigured the CAN components. This change skips out of the MyCan object constructor. I have implemented it by defining a static const variable so the ugliness of the preprocessor conditional can be separate at the top of the file instead of in the midst of the code. -- Steve On Mon, 8 Feb 2021, Michael Balzer wrote:
Steve,
I can confirm that effect. Didn't notice, as the connect had been slow before.
Also, mongoose appears to be locked during the whole connect, no other network activity can take place.
Regards, Michael
Am 08.02.21 um 03:32 schrieb Stephen Casner:
On Sun, 7 Feb 2021, Michael Balzer wrote:
We've had some changes recently, but apparently no issues with these (at least none reported).
I'd say it's time for 3.2.016.
Objections? Anything in the works that should be included? Craig observed that the ssh connect time doubled from 5 seconds to 10 seconds. I noticed that connecting seemed slow but since it's never been fast I had not run a comparison test. Would that be considered a problem for release?
This slowness is disappointing considering that the new code is supposed to include access to ESP32 hardware acceleration. I think I have the configuration set correctly to include this. I will try to turn on some tracing and investigate further.
-- Steve
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Earlier I said, after observing that the SSH connection time was about 4 seconds on my bench v3.0 hardware vs. 10 seconds reported by Craig:
So I think this means it's not a problem of crypto computation time, so whether or not hardware acceleration is working is not the issue. There must be some interaction among our network activities that is causing some action to wait for a timeout or a subsequent event.
Nope! The difference is slow PSRAM vs. fast internal RAM. The v3.0 hardware has no PSRAM so I had to pare down the configuration so I could run SSH using internal RAM. In addition, to avoid needing to increase the NetMan stack size I changed the wolfssl configuration to reduce stack usage by allocating buffers using malloc instead of on the stack. There are three expensive functions that do many calculations and many mallocs: wc_ecc_make_key: 2.3 seconds, 13409 mallocs wc_ecc_shared_secret: 2.3 seconds, 13405 mallocs RsaPublicEncryptEx: 1.9 seconds, 4980 mallocs The result is that on a v3.1 module where malloc comes from PSRAM the connect time is 8-10 seconds. On the v3.0 module, stil doing malloc but from internal RAM, the connect time is 3.5-5 seconds. If I increase the NetMan stack by 2kB and switch back to stack buffers (which are in internal RAM with no malloc overhead) then the connect time is 2.9-3.5 seconds. So that explains why I didn't particularly notice the longer connect time before Craig reported it. All of my development testing was done with the larger stack and stack allocation of buffers. I only made the shift to malloc buffers as a later step to avoid the stack size increase. I verified that it was working, but only connected a few times with my attention focused on checking the stack usage. So: Can we afford to increase our base RAM usage by 2K for the benefit of reasonable SSH connect times? -- Steve
Steve, as written before, higher base memory footprint is probably OK but needs to be tested on complex vehicles. So I suggest we do that before finalizing 3.2.016. Mongoose SSL connects also are slow, speeding them up would have a broader effect. But mongoose won't benefit from wolfSSL in internal RAM, as it's using mbedTLS supplied by the esp-idf. What do you think, is there a chance we could reduce overall memory footprint _and_ gain speed for all SSL connects if we change mongoose to use wolfSSL? This comparison indicates wolfSSL is normally much more RAM efficient than mbedTLS: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pr... Maybe discarding mbedTLS frees enough memory to put wolfSSL into internal RAM? Regards, Michael Am 12.02.21 um 08:15 schrieb Stephen Casner:
Earlier I said, after observing that the SSH connection time was about 4 seconds on my bench v3.0 hardware vs. 10 seconds reported by Craig:
So I think this means it's not a problem of crypto computation time, so whether or not hardware acceleration is working is not the issue. There must be some interaction among our network activities that is causing some action to wait for a timeout or a subsequent event. Nope! The difference is slow PSRAM vs. fast internal RAM. The v3.0 hardware has no PSRAM so I had to pare down the configuration so I could run SSH using internal RAM.
In addition, to avoid needing to increase the NetMan stack size I changed the wolfssl configuration to reduce stack usage by allocating buffers using malloc instead of on the stack. There are three expensive functions that do many calculations and many mallocs:
wc_ecc_make_key: 2.3 seconds, 13409 mallocs wc_ecc_shared_secret: 2.3 seconds, 13405 mallocs RsaPublicEncryptEx: 1.9 seconds, 4980 mallocs
The result is that on a v3.1 module where malloc comes from PSRAM the connect time is 8-10 seconds. On the v3.0 module, stil doing malloc but from internal RAM, the connect time is 3.5-5 seconds. If I increase the NetMan stack by 2kB and switch back to stack buffers (which are in internal RAM with no malloc overhead) then the connect time is 2.9-3.5 seconds.
So that explains why I didn't particularly notice the longer connect time before Craig reported it. All of my development testing was done with the larger stack and stack allocation of buffers. I only made the shift to malloc buffers as a later step to avoid the stack size increase. I verified that it was working, but only connected a few times with my attention focused on checking the stack usage.
So: Can we afford to increase our base RAM usage by 2K for the benefit of reasonable SSH connect times?
-- 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
On Fri, 12 Feb 2021, Michael Balzer wrote:
as written before, higher base memory footprint is probably OK but needs to be tested on complex vehicles. So I suggest we do that before finalizing 3.2.016.
There seemed to be no response when that test was offered on a separate branch. Shall I increase the NetMan stack size now on master so all the cars (that have active developers) can test it?
Mongoose SSL connects also are slow, speeding them up would have a broader effect. But mongoose won't benefit from wolfSSL in internal RAM, as it's using mbedTLS supplied by the esp-idf.
Is mbedTLS configured to use heap instead of stack?
What do you think, is there a chance we could reduce overall memory footprint _and_ gain speed for all SSL connects if we change mongoose to use wolfSSL?
It does seem inefficient in at least the code size dimension to have multiple implementations of equivalent functionality, although I have limited that by explicitly including only those source files from wolfssl that are required by wolfssh. So switching mongoose to use wolfSSL would require increasing that set. I'd be happy to try that.
This comparison indicates wolfSSL is normally much more RAM efficient than mbedTLS: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pr...
It would be nice if that comparison stated timings as well.
Maybe discarding mbedTLS frees enough memory to put wolfSSL into internal RAM?
I would think that we don't have mongoose SSL processing and wolfSSL processing happening at the same time. If that's true, then the switch would not help stack usage. Do you know? -- Steve
Steve, Am 12.02.21 um 17:31 schrieb Stephen Casner:
On Fri, 12 Feb 2021, Michael Balzer wrote:
as written before, higher base memory footprint is probably OK but needs to be tested on complex vehicles. So I suggest we do that before finalizing 3.2.016. There seemed to be no response when that test was offered on a separate branch. Shall I increase the NetMan stack size now on master so all the cars (that have active developers) can test it?
Well, if the vehicle developers don't react, we can only release the test to the edge users and see if complaints come in or crash counts increase significantly… IOW, yes.
Mongoose SSL connects also are slow, speeding them up would have a broader effect. But mongoose won't benefit from wolfSSL in internal RAM, as it's using mbedTLS supplied by the esp-idf. Is mbedTLS configured to use heap instead of stack?
I have no idea. There are 74 config options for MBEDTLS, none seems to address heap or stack. There seems to be only the "Memory allocation strategy", which is currently configured for SPIRAM as well. That seems to indicate mbedTLS always uses the heap or at least has no option to reduce it's stack footprint.
What do you think, is there a chance we could reduce overall memory footprint _and_ gain speed for all SSL connects if we change mongoose to use wolfSSL? It does seem inefficient in at least the code size dimension to have multiple implementations of equivalent functionality, although I have limited that by explicitly including only those source files from wolfssl that are required by wolfssh. So switching mongoose to use wolfSSL would require increasing that set. I'd be happy to try that.
That would be great. Mongoose has an SSL library abstraction layer, but there certainly will be dragons…
This comparison indicates wolfSSL is normally much more RAM efficient than mbedTLS: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pr... It would be nice if that comparison stated timings as well.
I've searched hard, it seems there is no independant comparison of mbedTLS vs WolfSSL. The WolfSSL guys say their lib performs better, but don't provide any numbers.
Maybe discarding mbedTLS frees enough memory to put wolfSSL into internal RAM? I would think that we don't have mongoose SSL processing and wolfSSL processing happening at the same time. If that's true, then the switch would not help stack usage. Do you know?
-- Steve
Do we still need the larger stack if wolfSSL can run in internal RAM completely? If an ssh/scp channel is used while the module performs https requests (e.g. for scripts or OTA update checks) or has a connection to a V2/V3 server using TLS, both libs will be in use simultaneously. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael,
Well, if the vehicle developers don't react, we can only release the test to the edge users and see if complaints come in or crash counts increase significantly... IOW, yes.
Thanks.
switching mongoose to use wolfSSL would require increasing that set. I'd be happy to try that.
That would be great.
Mongoose has an SSL library abstraction layer, but there certainly will be dragons...
The Espressif reference you cited included a step of switching the ESP-TLS configuration parameter from mbedtls to wolfssl. If Mongoose was going to mbedtls through ESP-TLS, then that configuration might take care of it. But if not, ...
Do we still need the larger stack if wolfSSL can run in internal RAM completely?
I think you are asking about an option to still keep the small stack configuration for wolfSSL but change its heap allocations to come from internal RAM instead of PSRAM (which is straightforward since the heap allocations are funneled through our own allocation function in console_ssh.cpp). There is still the problem that the SSH connect would execute more than 30K malloc calls, which was a contributing factor in the slowness. And if internal RAM was running low, the connection would fail. We check for that and avoid a crash, but the remnants of the connection attempt are not cleaned up properly. We'd have to back off to PSRAM instead. And that still might leave internal RAM depleted when we might need it for something else like creating a task.
I would think that we don't have mongoose SSL processing and wolfSSL processing happening at the same time. If that's true, then the switch would not help stack usage. Do you know?
If an ssh/scp channel is used while the module performs https requests (e.g. for scripts or OTA update checks) or has a connection to a V2/V3 server using TLS, both libs will be in use simultaneously.
In the case of SSH, I think all the processing is done contiguously upon receipt of a packet. Because of our non-blocking design that keeps all of the SSH processing in the one NetMan task it is not possible to keep state from one packet to the next on the stack. As you noted, the HTTPS processing is blocked for the whole time that the SSH crypto processing is underway. I think the operations are all forced to be processed sequentially. -- Steve
On Fri, 12 Feb 2021, Stephen Casner wrote:
switching mongoose to use wolfSSL would require increasing that set. I'd be happy to try that.
That would be great.
Mongoose has an SSL library abstraction layer, but there certainly will be dragons...
The Espressif reference you cited included a step of switching the ESP-TLS configuration parameter from mbedtls to wolfssl. If Mongoose was going to mbedtls through ESP-TLS, then that configuration might take care of it. But if not, ...
Hmmm, it looks like the documentation on using wolfssl with ESP-IDF assumes the new CMake build system, not the older build system that we are still using for OVMS. You may be right about the dragons. -- Steve
On Fri, 12 Feb 2021, Stephen Casner wrote:
On Fri, 12 Feb 2021, Stephen Casner wrote:
switching mongoose to use wolfSSL would require increasing that set. I'd be happy to try that.
That would be great.
Mongoose has an SSL library abstraction layer, but there certainly will be dragons...
The Espressif reference you cited included a step of switching the ESP-TLS configuration parameter from mbedtls to wolfssl. If Mongoose was going to mbedtls through ESP-TLS, then that configuration might take care of it. But if not, ...
Hmmm, it looks like the documentation on using wolfssl with ESP-IDF assumes the new CMake build system, not the older build system that we are still using for OVMS. You may be right about the dragons.
Well, it turns out that Mongoose also has an OpenSSL library abstraction layer as an alternative to MBEDTLS, and wolfSSL has an OpenSSL compatibility layer. I have verified that we can plug the two together without bloodshed. I've made a mongoose-wolfssl branch with this change implemented, but I have not tested it thoroughly. I can run server v2 and make connections to it through the app and the server -- that uses SSL now, right? I have also not done anything to reduce or remove MBEDTLS yet. I don't know if there are other dependencies. Please check it out. -- Steve
Steve, I finally found some time to test the mongoose-wolfssl branch. Three issues so far… The first isn't related to the Mongoose wolfSSL change, just stumbled upon it because I did some "before" tests. So this currently applies to the wolfSSH/SSL update in "master" as well: Each ssh connect on my test module leaks 88 bytes of RAM in the NetMan task: D (158332) ssh: SSH command request: stat OVMS# mo me Free 8-bit 72088/268932, 32-bit 6672/11028, SPIRAM 3988500/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM OVMS NetMan 0 964 0 84 +0 +88 +0 +0 The same leak is in the wolfSSL version. Second is, the Mongoose/wolfSSL version doesn't validate CA certs the mbedTLS version has no issues with: I (340220) ovms-server-v2: Connection is ovms.dexters-web.de:6870 TEST1 E (340670) ovms-server-v2: mg_connect(ovms.dexters-web.de:6870) failed: Invalid SSL CA cert E (340670) ovms-server-v2: Status: Error: Connection failed Third, and probably the most disappointing one: the Mongoose/wolfSSL version uses more memory, not less. After booting, the module has ~3.5K less of 8 bit RAM available than with the mbedTLS version. mbedTLS: OVMS# mo me Free 8-bit 73196/268928, 32-bit 6672/11028, SPIRAM 3988540/4194252 wolfSSL: OVMS# mo me Free 8-bit 69676/266084, 32-bit 6672/11028, SPIRAM 3988540/4194252 Is it possible there still are other components using mbedTLS? Regards, Michael Am 18.02.21 um 08:56 schrieb Stephen Casner:
Well, it turns out that Mongoose also has an OpenSSL library abstraction layer as an alternative to MBEDTLS, and wolfSSL has an OpenSSL compatibility layer. I have verified that we can plug the two together without bloodshed. I've made a mongoose-wolfssl branch with this change implemented, but I have not tested it thoroughly. I can run server v2 and make connections to it through the app and the server -- that uses SSL now, right?
I have also not done anything to reduce or remove MBEDTLS yet. I don't know if there are other dependencies.
Please check it out.
-- Steve
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael,
I finally found some time to test the mongoose-wolfssl branch.
Thanks,
The first isn't related to the Mongoose wolfSSL change, just stumbled upon it because I did some "before" tests. So this currently applies to the wolfSSH/SSL update in "master" as well:
Each ssh connect on my test module leaks 88 bytes of RAM in the NetMan task:
D (158332) ssh: SSH command request: stat OVMS# mo me Free 8-bit 72088/268932, 32-bit 6672/11028, SPIRAM 3988500/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM OVMS NetMan 0 964 0 84 +0 +88 +0 +0
The same leak is in the wolfSSL version.
I recall something like this from when I first implemented SSH. This may be the socket structure that LWIP creates. It keeps a pool of 10 of them, if I remember right, and doesn't reuse them until all 10 have been created.
Second is, the Mongoose/wolfSSL version doesn't validate CA certs the mbedTLS version has no issues with:
I (340220) ovms-server-v2: Connection is ovms.dexters-web.de:6870 TEST1 E (340670) ovms-server-v2: mg_connect(ovms.dexters-web.de:6870) failed: Invalid SSL CA cert E (340670) ovms-server-v2: Status: Error: Connection failed
When I implemented the SSH features I trimmed down the set of algorithms in wolfcrypt to those that were useful for our application. The only one that I found I needed to bring back was PSK as detected because of an undefined symbol in the link. It's possible that now some more need to be brought back. I'm sure there's more to learn by diagnosis that I might need to do by compiling in some more logging. What would I need to do to repeat this test?
Third, and probably the most disappointing one: the Mongoose/wolfSSL version uses more memory, not less. After booting, the module has ~3.5K less of 8 bit RAM available than with the mbedTLS version.
mbedTLS:
OVMS# mo me Free 8-bit 73196/268928, 32-bit 6672/11028, SPIRAM 3988540/4194252
wolfSSL:
OVMS# mo me Free 8-bit 69676/266084, 32-bit 6672/11028, SPIRAM 3988540/4194252
Is it possible there still are other components using mbedTLS?
I saw in the configuration that libsodium uses mbedTLS. As I mentioned, I did not do anything at this point to trim the mbedTLS configuration. -- Steve
Steve, Am 21.02.21 um 22:08 schrieb Stephen Casner:
Each ssh connect on my test module leaks 88 bytes of RAM in the NetMan task: I recall something like this from when I first implemented SSH. This may be the socket structure that LWIP creates. It keeps a pool of 10 of them, if I remember right, and doesn't reuse them until all 10 have been created.
Confirmed, no more leakage after 10 connects.
Second is, the Mongoose/wolfSSL version doesn't validate CA certs the mbedTLS version has no issues with:
I (340220) ovms-server-v2: Connection is ovms.dexters-web.de:6870 TEST1 E (340670) ovms-server-v2: mg_connect(ovms.dexters-web.de:6870) failed: Invalid SSL CA cert E (340670) ovms-server-v2: Status: Error: Connection failed What would I need to do to repeat this test?
As shown in my example, simply try to establish a V2 TLS connection to my server. As the TLS already fails you don't need a vehicle login, but you can of course create one. I'm using Let's Encrypt certificates, testing other servers is easiest with our Duktape HTTP.request() method. See… https://docs.openvehicles.com/en/latest/userguide/scripting.html#http
Is it possible there still are other components using mbedTLS? I saw in the configuration that libsodium uses mbedTLS. As I mentioned, I did not do anything at this point to trim the mbedTLS configuration.
libsodium is linked in, but I don't find any API usage, neither from our code nor from esp-idf components. Maybe wolfSSL really is less memory efficient than mbedTLS? Maybe we should try to adapt wolfSSH to mbedTLS then… ;-) Regards, Michael
-- Steve
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael,
Second is, the Mongoose/wolfSSL version doesn't validate CA certs the mbedTLS version has no issues with:
I (340220) ovms-server-v2: Connection is ovms.dexters-web.de:6870 TEST1 E (340670) ovms-server-v2: mg_connect(ovms.dexters-web.de:6870) failed: Invalid SSL CA cert E (340670) ovms-server-v2: Status: Error: Connection failed
The problem here is that some modifications are needed analogous to the change that Mark made in mongoose.c in 58942ce9 for MBEDTLS to accept a directly embedded PEM certificate chain. As the code stands, we are giving wolfssl the PEM certificate chain as a char* argument that it then tries to interpert as a filename. I have not yet determined whether wolfssl includes an alternative function to accept the cert chain directly or if I will need to add one. -- Steve
On Mon, 8 Feb 2021, Michael Balzer wrote:
Also, mongoose appears to be locked during the whole connect, no other network activity can take place.
In case I didn't adequately answer this point in replies to later emails: The reason mongoose is locked out is that we chose to implement all of this in one task because we could not afford the space for multiple stacks. It was a challenge to implement it all in a non-blocking manner, but it is working so long as you can accept the above limitation that all the operations are serialized. -- Steve
Hi, I flashed my OVMS up to date with master to see how it goes, since I'm obviously keen to see the i3 support out there. The i3 stuff is working as expected as far as I can tell. But overall I'm having a really poor experience in the car when driving: I have an Android tablet which is trying to connect to the OVMS AP and view the dashboard etc. I find that the tablet loses its Wifi connection to the OVMS every few minutes - eventually it finds it again and recovers - some number of minutes. My first I thought I was getting many crashes - but I have only 3 recorded today and none during the time I was driving: mysql> select h_timestamp, h_recordtype, h_data from ovms_historicalmessages where h_timestamp > '2021-02-13 00:00' and h_recordtype like ' %Crash%' order by h_timestamp \G 1) Unknown cause, 4am, car parked. As you can see it was the task watchdog that rebooted ovms: *************************** 1. row *************************** h_timestamp: 2021-02-13 03:55:16 h_recordtype: *-OVM-DebugCrash h_data: 3.2.015-668-gc2a501eb-dirty/ota_0/main (build idf v3.3.4-845-gd59ed8bba-dirty Feb 12 2021 15:52:01),126,Crash,12,12,52,0,abort(),0,,0x4008e58e 0x4008e829 0x400e7bcc 0x4008406a ,6,Task watchdog,ticker.1,esp32wifi,0,IDLE1 2) This seems similar: *************************** 2. row *************************** h_timestamp: 2021-02-13 12:12:38 h_recordtype: *-OVM-DebugCrash h_data: 3.2.015-668-gc2a501eb-dirty/ota_0/main (build idf v3.3.4-845-gd59ed8bba-dirty Feb 12 2021 15:52:01),147,Crash,12,12,73,0,abort(),0,,0x4008e58e 0x4008e829 0x400e7bcc 0x4008406a ,6,Task watchdog,,,0,IDLE1 3) This one happened when I went to Tools>Editor and trying to open /sd: *************************** 3. row *************************** h_timestamp: 2021-02-13 16:47:58 h_recordtype: *-OVM-DebugCrash h_data: 3.2.015-668-gc2a501eb-dirty/ota_0/main (build idf v3.3.4-845-gd59ed8bba-dirty Feb 12 2021 15:52:01),148,Crash,12,12,74,0,StoreProhibited,1,0x4008b014 0x00060d30 0x800fe2f8 0x3ffe7270 0x00000000 0x3f97de70 0x0011ce31 0x00000000 0x31323032 0x2d32302d 0x00000000 0x3ffe7240 0x00000000 0x00239c63 0x4009d4bc 0x3ffbc5e4 0x0000000a 0x3ffca570 0x00000008 0x0000001d 0x00000000 0x4008b010 0x4008b02c 0x00011ce2 ,0x4008b014 0x400fe2f5 0x401efe03 0x40132007 0x40159c35 0x40149aae 0x4013ef2e 0x4013f01a 0x4010af29 0x4010b5e9 0x4010c75e 0x4010c782 0x4010af29 0x4010c8c5 0x4010ccf9 0x4010cfbe 0x4010916e 0x400fd747 0x400fd7f5 ,4,Exception/panic,,,0,IDLE1|OVMS DukTape So if it's not crashes, then why does the Wifi AP on the OVMS keep disappearing and disconnecting the tablet from the AP? Does the Wifi AP maybe get reset / restarted every time the status of the LTE connection changes? Since on my OVMS the 3G seems to be resetting frequently, logging like so: 2021-02-13 13:34:15.607 SAST I (21287) simcom: State timeout, transition to 2 2021-02-13 13:34:15.607 SAST I (21287) simcom: State: Enter PoweringOn state 2021-02-13 13:34:15.607 SAST I (21287) simcom: Power Cycle 2021-02-13 13:34:22.417 SAST I (28097) simcom: State: Enter PoweredOn state 2021-02-13 13:34:41.637 SAST I (47317) simcom: State: Enter MuxStart state 2021-02-13 13:34:42.607 SAST I (48287) simcom: State: Enter NetWait state 2021-02-13 13:34:52.627 SAST I (58307) simcom: CREG Network Registration: RegisteredHome 2021-02-13 13:34:53.607 SAST I (59287) simcom: State: Enter NetStart state 2021-02-13 13:34:54.667 SAST I (60347) simcom: PPP Connection is ready to start 2021-02-13 13:34:55.607 SAST I (61287) simcom: State: Enter NetMode state 2021-02-13 13:36:32.483 SAST I (21273) simcom: State timeout, transition to 2 (etc) Happens every few minutes: steve@maira ~ % egrep 'Power Cycle' ovms.log.20210213.shopping.trip egrep 'Power Cycle' ovms.log.20210213.shopping.trip 2021-02-13 13:24:50.411 SAST I (21271) simcom: Power Cycle 2021-02-13 13:25:13.037 SAST I (21287) simcom: Power Cycle 2021-02-13 13:27:22.167 SAST I (21287) simcom: Power Cycle 2021-02-13 13:29:57.177 SAST I (21287) simcom: Power Cycle 2021-02-13 13:32:07.417 SAST I (21287) simcom: Power Cycle 2021-02-13 13:34:15.607 SAST I (21287) simcom: Power Cycle 2021-02-13 13:36:32.483 SAST I (21273) simcom: Power Cycle 2021-02-13 13:39:10.193 SAST I (21273) simcom: Power Cycle 2021-02-13 13:41:19.993 SAST I (21273) simcom: Power Cycle 2021-02-13 13:43:27.773 SAST I (21273) simcom: Power Cycle 2021-02-13 13:45:41.523 SAST I (21273) simcom: Power Cycle 2021-02-13 13:48:07.303 SAST I (21273) simcom: Power Cycle 2021-02-13 13:51:35.063 SAST I (21273) simcom: Power Cycle 2021-02-13 13:55:37.663 SAST I (21273) simcom: Power Cycle 2021-02-13 13:57:47.493 SAST I (21263) simcom: Power Cycle 2021-02-13 14:00:25.547 SAST I (21287) simcom: Power Cycle 2021-02-13 14:03:41.837 SAST I (21287) simcom: Power Cycle 2021-02-13 14:06:20.182 SAST I (21282) simcom: Power Cycle 2021-02-13 14:08:28.393 SAST I (21283) simcom: Power Cycle 2021-02-13 14:10:40.519 SAST I (21279) simcom: Power Cycle 2021-02-13 14:12:48.538 SAST I (21278) simcom: Power Cycle I do see that my MQTT data doesn't seem to be getting to my broker when I'm away from home, so maybe there is an issue with my SIM. But not sure why that should disrupt the Wifi AP ? Regards, Steve On Sun, 7 Feb 2021 at 23:19, Michael Balzer <dexter@expeedo.de> wrote:
Everyone,
we're 624 commits away from 3.2.015, and we've got a bunch of new features & vehicle support.
We've had some changes recently, but apparently no issues with these (at least none reported).
I'd say it's time for 3.2.016.
Objections? Anything in the works that should be included?
Regards, Michael
-- 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
-- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
Steve, do you run the wifi client in scanning mode or with a fixed SSID? If scanning, please set the log level for component "esp32wifi" to verbose. You'll see the scans in the log. Then check if your tablet connection drops correlate with the scans. Further test options: a) set the client mode to a fixed SSID, b) disable client mode (only run the AP). Background info: scanning needs to pause the AP channel, and I had to raise the scan time per channel to find all networks: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/0a0c... I'm suspecting the scan to take too long now for some devices, so they lose the AP association. Thanks, Michael Am 13.02.21 um 19:11 schrieb Steve Davies:
I have an Android tablet which is trying to connect to the OVMS AP and view the dashboard etc.
I find that the tablet loses its Wifi connection to the OVMS every few minutes - eventually it finds it again and recovers - some number of minutes.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, On Sat, 13 Feb 2021 at 20:31, Michael Balzer <dexter@expeedo.de> wrote:
do you run the wifi client in scanning mode or with a fixed SSID?
Gotta say I don't know. I have added the SSID for the house. And only that one. I don't see anything in the settings about scanning, or on the web interface? OVMS# config list wifi.ssid wifi.ssid (protected writeable) DvDevs OVMS# config list wifi.ap wifi.ap (protected writeable) DvPanda But even with just DvDevs defined, surely if the OVMS is going to reconnect when I get home then it will have to scan from time to time for DvDevs otherwise how would it ever know to reconnect? (Well - one idea is to be able to tell it to only look if you are in a specific location ("Home"). I did enable verbose logging for esp32wifi and I'll see what that tells me. Steve -- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
You're right, the same scan timing parameters are applied in fixed mode after losing the connection. So you need to try disabling client mode. Am 13.02.21 um 19:43 schrieb Steve Davies:
Hi Michael,
On Sat, 13 Feb 2021 at 20:31, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
do you run the wifi client in scanning mode or with a fixed SSID?
Gotta say I don't know.
I have added the SSID for the house. And only that one.
I don't see anything in the settings about scanning, or on the web interface?
OVMS# config list wifi.ssid wifi.ssid (protected writeable) DvDevs OVMS# config list wifi.ap wifi.ap (protected writeable) DvPanda
But even with just DvDevs defined, surely if the OVMS is going to reconnect when I get home then it will have to scan from time to time for DvDevs otherwise how would it ever know to reconnect? (Well - one idea is to be able to tell it to only look if you are in a specific location ("Home").
I did enable verbose logging for esp32wifi and I'll see what that tells me.
Steve
https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
_______________________________________________ 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
I've had a second thought on the scan time change and replaced it by a configuration option, reverting the default timing to the previous defaults. So anyone having an issue with specific APs can change the config as needed, also on the fly. I've also added a WiFi documentation page, as we now have quite some configuration options that should be knowable for users: https://docs.openvehicles.com/en/latest/userguide/wifi.html Regards, Michael PS: I'd still like to know if your issues were caused by this. Am 13.02.21 um 19:50 schrieb Michael Balzer:
You're right, the same scan timing parameters are applied in fixed mode after losing the connection.
So you need to try disabling client mode.
Am 13.02.21 um 19:43 schrieb Steve Davies:
Hi Michael,
On Sat, 13 Feb 2021 at 20:31, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
do you run the wifi client in scanning mode or with a fixed SSID?
Gotta say I don't know.
I have added the SSID for the house. And only that one.
I don't see anything in the settings about scanning, or on the web interface?
OVMS# config list wifi.ssid wifi.ssid (protected writeable) DvDevs OVMS# config list wifi.ap wifi.ap (protected writeable) DvPanda
But even with just DvDevs defined, surely if the OVMS is going to reconnect when I get home then it will have to scan from time to time for DvDevs otherwise how would it ever know to reconnect? (Well - one idea is to be able to tell it to only look if you are in a specific location ("Home").
I did enable verbose logging for esp32wifi and I'll see what that tells me.
Steve
https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
_______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi, I went out yesterday and looking now at the esp32wifi log entries: Here's when it doesn't find anything: 2021-02-14 15:31:25.113 SAST V (13273) esp32wifi: StartConnect: scan started 2021-02-14 15:31:28.433 SAST V (16593) esp32wifi: EventWifiScanDone: no access points found Here's where it finds "foreign" ones: 2021-02-14 15:45:23.852 SAST V (33292) esp32wifi: StartConnect: scan started 2021-02-14 15:45:27.482 SAST V (36922) esp32wifi: ScanDone: #01 ssid='BMWi23024 CarPlay' bssid='b8:9f:09:26:0f:9f' chan=11 rssi=-49 2021-02-14 15:45:27.482 SAST V (36922) esp32wifi: EventWifiScanDone: no known SSID found and: 2021-02-14 15:47:11.947 SAST V (13287) esp32wifi: StartConnect: scan started 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #01 ssid='BMWi23024 CarPlay' bssid='b8:9f:09:26:0f:9f' chan=11 rssi=-54 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #02 ssid='Residenz2' bssid='c8:3a:35:50:a2:d0' chan=6 rssi=-91 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #03 ssid='mywifi' bssid='04:95:e6:d1:f2:b0' chan=5 rssi=-93 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #04 ssid='HUAWEI-A5F9' bssid='34:12:f9:fd:a5:f9' chan=11 rssi=-95 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: EventWifiScanDone: no known SSID found and: 2021-02-14 15:47:31.947 SAST V (33287) esp32wifi: StartConnect: scan started 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #01 ssid='BMWi23024 CarPlay' bssid='b8:9f:09:26:0f:9f' chan=11 rssi=-50 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #02 ssid='TP-LINK_58FEB6' bssid='c4:e9:84:58:fe:b6' chan=6 rssi=-89 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #03 ssid='TP-Link_F60F' bssid='d8:47:32:04:f6:0f' chan=1 rssi=-92 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #04 ssid='TP-Link_Guest_F60F' bssid='da:47:32:14:f6:0f' chan=1 rssi=-92 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #05 ssid='' bssid='c4:e9:84:58:f7:8e' chan=6 rssi=-92 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #06 ssid='David's Unifi' bssid='0a:18:d6:a9:f9:a6' chan=1 rssi=-93 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #07 ssid='Shalombosch' bssid='d4:6a:91:70:c9:e4' chan=7 rssi=-93 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: EventWifiScanDone: no known SSID found So the scan seems to take 4-5 seconds. As the car drives along the scan picks up a wide variety of SSIDs. I'm sure that you are right that the SSID disappears for long enough for the tablet to lose connection. Unfortunately the tablet then jumps to LTE (so no more connection to 192.168.4 network) and it is quite a while before IT notices that the SSID is back and reconnects. I don't really follow though why the AP is taken down to do this since when the car is home it is able to connect to my home Wifi AND operate the AP?
From the log it appears that sometimes the scan is done every 10 seconds and sometimes it seems to be every 80 seconds or so.
Obviously a scan done every 10 seconds that takes the SSID down for 4 to 5 seconds isn't going to make the AP near useless. Steve On Sat, 13 Feb 2021 at 20:50, Michael Balzer <dexter@expeedo.de> wrote:
You're right, the same scan timing parameters are applied in fixed mode after losing the connection.
So you need to try disabling client mode.
Am 13.02.21 um 19:43 schrieb Steve Davies:
Hi Michael,
On Sat, 13 Feb 2021 at 20:31, Michael Balzer <dexter@expeedo.de> wrote:
do you run the wifi client in scanning mode or with a fixed SSID?
Gotta say I don't know.
I have added the SSID for the house. And only that one.
I don't see anything in the settings about scanning, or on the web interface?
OVMS# config list wifi.ssid wifi.ssid (protected writeable) DvDevs OVMS# config list wifi.ap wifi.ap (protected writeable) DvPanda
But even with just DvDevs defined, surely if the OVMS is going to reconnect when I get home then it will have to scan from time to time for DvDevs otherwise how would it ever know to reconnect? (Well - one idea is to be able to tell it to only look if you are in a specific location ("Home").
I did enable verbose logging for esp32wifi and I'll see what that tells me.
Steve
https://www.telviva.co.za/legal/email-disclaimer
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://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
-- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
Steve, did you run my latest change there? If so, was that with default timing or with a changed configuration? A full scan now takes ~ 2 seconds with default timing on my modules, so I guess you still had the old version running. Also, the AP isn't taken down, and the WiFi module should of course send a beacon between the channels, but it's unfortunately closed source, so we can only guess what it does there from the effects observed. With scanning for up to the 500 ms per channel, my guess was that became too long for your tablet. We only scan if no client network is connected, so while you're in your home network, it won't scan. Please try again with default scan timing. Regards, Michael Am 15.02.21 um 16:28 schrieb Steve Davies:
Hi,
I went out yesterday and looking now at the esp32wifi log entries:
Here's when it doesn't find anything:
2021-02-14 15:31:25.113 SAST V (13273) esp32wifi: StartConnect: scan started 2021-02-14 15:31:28.433 SAST V (16593) esp32wifi: EventWifiScanDone: no access points found
Here's where it finds "foreign" ones:
2021-02-14 15:45:23.852 SAST V (33292) esp32wifi: StartConnect: scan started 2021-02-14 15:45:27.482 SAST V (36922) esp32wifi: ScanDone: #01 ssid='BMWi23024 CarPlay' bssid='b8:9f:09:26:0f:9f' chan=11 rssi=-49 2021-02-14 15:45:27.482 SAST V (36922) esp32wifi: EventWifiScanDone: no known SSID found
and:
2021-02-14 15:47:11.947 SAST V (13287) esp32wifi: StartConnect: scan started 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #01 ssid='BMWi23024 CarPlay' bssid='b8:9f:09:26:0f:9f' chan=11 rssi=-54 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #02 ssid='Residenz2' bssid='c8:3a:35:50:a2:d0' chan=6 rssi=-91 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #03 ssid='mywifi' bssid='04:95:e6:d1:f2:b0' chan=5 rssi=-93 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: ScanDone: #04 ssid='HUAWEI-A5F9' bssid='34:12:f9:fd:a5:f9' chan=11 rssi=-95 2021-02-14 15:47:16.177 SAST V (17517) esp32wifi: EventWifiScanDone: no known SSID found
and:
2021-02-14 15:47:31.947 SAST V (33287) esp32wifi: StartConnect: scan started 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #01 ssid='BMWi23024 CarPlay' bssid='b8:9f:09:26:0f:9f' chan=11 rssi=-50 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #02 ssid='TP-LINK_58FEB6' bssid='c4:e9:84:58:fe:b6' chan=6 rssi=-89 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #03 ssid='TP-Link_F60F' bssid='d8:47:32:04:f6:0f' chan=1 rssi=-92 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #04 ssid='TP-Link_Guest_F60F' bssid='da:47:32:14:f6:0f' chan=1 rssi=-92 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #05 ssid='' bssid='c4:e9:84:58:f7:8e' chan=6 rssi=-92 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #06 ssid='David's Unifi' bssid='0a:18:d6:a9:f9:a6' chan=1 rssi=-93 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: ScanDone: #07 ssid='Shalombosch' bssid='d4:6a:91:70:c9:e4' chan=7 rssi=-93 2021-02-14 15:47:36.477 SAST V (37817) esp32wifi: EventWifiScanDone: no known SSID found
So the scan seems to take 4-5 seconds.
As the car drives along the scan picks up a wide variety of SSIDs.
I'm sure that you are right that the SSID disappears for long enough for the tablet to lose connection. Unfortunately the tablet then jumps to LTE (so no more connection to 192.168.4 network) and it is quite a while before IT notices that the SSID is back and reconnects.
I don't really follow though why the AP is taken down to do this since when the car is home it is able to connect to my home Wifi AND operate the AP?
From the log it appears that sometimes the scan is done every 10 seconds and sometimes it seems to be every 80 seconds or so.
Obviously a scan done every 10 seconds that takes the SSID down for 4 to 5 seconds isn't going to make the AP near useless.
Steve
On Sat, 13 Feb 2021 at 20:50, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
You're right, the same scan timing parameters are applied in fixed mode after losing the connection.
So you need to try disabling client mode.
Am 13.02.21 um 19:43 schrieb Steve Davies:
Hi Michael,
On Sat, 13 Feb 2021 at 20:31, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
do you run the wifi client in scanning mode or with a fixed SSID?
Gotta say I don't know.
I have added the SSID for the house. And only that one.
I don't see anything in the settings about scanning, or on the web interface?
OVMS# config list wifi.ssid wifi.ssid (protected writeable) DvDevs OVMS# config list wifi.ap wifi.ap (protected writeable) DvPanda
But even with just DvDevs defined, surely if the OVMS is going to reconnect when I get home then it will have to scan from time to time for DvDevs otherwise how would it ever know to reconnect? (Well - one idea is to be able to tell it to only look if you are in a specific location ("Home").
I did enable verbose logging for esp32wifi and I'll see what that tells me.
Steve
https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
_______________________________________________ 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
participants (5)
-
Craig Leres -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner -
Steve Davies