Advanced Users can post their questions and comments here for the not so Newbie crowd.

Moderator: eriksl

User avatar
By jeffrey92
#83528 This is @someburner from github, haven't been on here in a long time but glad to see the "advanced" section was created! I hope to be more active on here.

What is the status on merging up to lwip 2.1.2? I mentioned on a github issue for NONOS_SDK that I got this repo working with esp-open-sdk https://github.com/d-a-v/esp82xx-nonos-linklayer. From what I can tell, your edits implant the Espressif stuff directly into the source instead of that one that maps old functions to new ones and then has a bunch of patches. The mapping way is a bit clunky in my opinion, although it does make it easier to pull upstream changes for lwip. But lwip doesn't seem like the most active project.

I would prefer to compile lwip in my project's source so I'm thinking your way would be better. But I also want to have upstream fixes/features from lwip2. Do you see this being difficult?
User avatar
By eriksl
#83532 I did no work for getting LWIP up to date to upstream, other than some changes to get the sources as much as possible equal to what's in the (old) public LWIP version.

I found no reason to continue working on this, as the newer LWIP (2) versions don't offer anything relevant to me that the current version doesn't have. IPv6 is nice and fun, but not required.

If anyone wants to pursue this path, that would be nice. The current version as in my repo is almost equal to the LWIP upstream, so one could apply all newer commits one by one or maybe even do a merge. My fear though is that it will break the subtile changes Espressif added to workaround shortcomings in the wlan driver code.

And BTW I think no-one should be using the ridiculous "esp-connect" code. It only adds another layer of code, needs extra resources and has a few bugs too, for free. It's better to use the LWIP interface directly, althought the learning curve is a bit steep, the documentation isn't that great.
User avatar
By jeffrey92
#84071
I found no reason to continue working on this, as the newer LWIP (2) versions don't offer anything relevant to me that the current version doesn't have. IPv6 is nice and fun, but not required.


The other reason for wanting to use lwip 2.x is also to get upstream fixes/improvements. Using d-a-v's repo I have seen less disconnects on certain routers/networks.

I looked into a clean patch for lwip 2.x and I think the only way to do it is how d-a-v has done it, hooking the SDK calls. The issue is the netif structures have changed in later versions, and there needs to be a way to interface lwip1 netif/dhcp with lwip2.

And BTW I think no-one should be using the ridiculous "esp-connect" code. It only adds another layer of code, needs extra resources and has a few bugs too, for free. It's better to use the LWIP interface directly, althought the learning curve is a bit steep, the documentation isn't that great.


I would like to ditch the espconn code but, as you say, the documentation for lwip is sparse. I limit all my network i/o to under the MTU so I'm not sure if I need all the pbuf chaining code? There is also some wacky stuff in espconn_udp.c that I am not sure how to replicate not using espconn- particularly UDP broadcasting in STA+AP mode.

Looking at esp-arduino sources, it appears they have re-written all of that, but they also use a very customized toolchain now and make use of a lot of cpp utilities that can't be used with esp-open-sdk. It would be nice to have something like ESPAsyncTCP but without the Arduino framework. I'm almost tempted to switch to Arduino now that it's reaching a level of maturity/stability.
User avatar
By eriksl
#84076 For me it's easy, I don't have to use any of the espconnect stuff, so I ditched it completely.

IIRC I once had a glance at the espconn code and it struck me that sometimes the UDP packets are simply duplicated. I guess that's for the case where STA+AP mode is used, using broadcasting (and apparently two low-level interfaces are used). Can't you do the same yourself in your application code?

I can confirm LWIP as-is works with either STA or AP mode, but I have no experience in the mixed mode.

I've seen that LWIP 2.x and higher are quite a bit different in the data structure area, that's one of the reasons I didn't continue on the path. And as said, it doesn't give much more functionality, so I considered it not to be worth the effort.