AI-on-the-edge-device
AI-on-the-edge-device copied to clipboard
jomjol
Add optional IPv6 support
Add the first cut add (optional) IPv6 support. The main (invasive) logic will not be compiled in unless CONFIG_LWIP_IPV6 is on.
I cannot helpt as well, hopefully @haverland @caco3 can help.
As long as the build fails, I cannot merge.
Good - build is working. If I enable the IPV6 and also compile it, does the IPV4 still work?
Official answer: I don't know, hence (based on our previous communication) it is off by default and I dind't touch sdkconfig.default. I don't have IPv4 in-house anymore (apart from a Lab network for some HW requiring PXE). I could try firing up an AP for that and test it.
In theory it should as it is just another event in connect_wlan.cpp. I would expect both events to fire in case of a Dual-Stack network. The problem might be that WIFI_CONNECTED_BIT is set by whatever happens first and xEventGroupWaitBits() will continue. If there is only IPv4 that should work just fine. So expectation is: IPv4-only is fine, IPv6-only is fine, Dual-Stack is ???
I'll try to find/build a Dual-Stack and IPv4-only network during the weekend and test all three cases.
Just to make you aware: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/lwip.html#ipv6-support
Both IPv4 and IPv6 are supported as dual stack and enabled by default
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/lwip.html#lwip-ram-usage
Disable CONFIG_LWIP_IPV6 can save about 39 KB for firmware size and 2KB RAM when system power up and 7KB RAM when TCPIP stack running. If there is no requirement for supporting IPV6 then it can be disabled to save flash and RAM footprint.
Since RAM is a precious good in this project, it would be better to keep IPv6 off. How ever we could build 2 variants, one with IPv4 and the other with IPv6 resp. Dual Stack.
Since I don't have an IPv6 network, it would be trick for me to test!
I quickly tested the different memory usage (at build time), but did not see any difference:
CONFIG_LWIP_IPV6=n (in sdkconfig.defaults)
RAM: [== ] 20.6% (used 67388 bytes from 327680 bytes)
Flash: [==========] 97.5% (used 1897685 bytes from 1945600 bytes)
CONFIG_LWIP_IPV6=y (in sdkconfig.defaults)
RAM: [== ] 20.6% (used 67388 bytes from 327680 bytes)
Flash: [==========] 97.5% (used 1897685 bytes from 1945600 bytes)
hello @jomjol , how do crop digits, rotate, and save? can it be written using arduino ide? if so, how to write?
hello @jomjol , how do crop digits, rotate, and save? can it be written using arduino ide? if so, how to write?
please open a new discussion for this!
I quickly tested the different memory usage (at build time), but did not see any difference:
CONFIG_LWIP_IPV6=n (in sdkconfig.defaults) RAM: [== ] 20.6% (used 67388 bytes from 327680 bytes) Flash: [==========] 97.5% (used 1897685 bytes from 1945600 bytes) CONFIG_LWIP_IPV6=y (in sdkconfig.defaults) RAM: [== ] 20.6% (used 67388 bytes from 327680 bytes) Flash: [==========] 97.5% (used 1897685 bytes from 1945600 bytes)
CONFIG_LWIP_IPV6 is not set to CONFIG_LWIP_IPV6=n in sdkconfig.defaults actually. IPV6 is already enabled in compilation, but not used.
I mean you can accept pull request cause the macro definition #ifdef CONFIG_LWIP_IPV6 are used in the code.
It would be better to use another definition like #ifdef ENABLE_IPV6 to not infer with esp32 idf macro and stay the same model:
build_flags = -D ENABLE_MQTT -D ENABLE_INFLUXDB -D ENABLE_IPV6
@bzfbd can you also rebase it to rolling and solve the conflicts? Sorry for the late response, but we where quite busy with bug fixing.
Hi, sorry. Have had constructions in the house and was pre-occupied with that.
I lately did put a DHCPv4 server on the network with device and it almost immediately asked for a lease. So at least dual-stack should be fine.
I can try to rebase this to your latest code and change the compile time option and the re-open, if you are still willing to give it a shot. I'll have about 3 weeks to holidays :)