LwIP – Lightweight IP Stack | Hacker News Reader

LwIP – Lightweight IP Stack

nongnu.org

183 pointsfidotron57 comments

IP Stack is a bit of an understatement. It comes with enough to be a HTTP client, a HTTP server or a MQTT client - and that is the way I've seen it used in practice.

It is more like the busybox of embedded networking, but with a much more convenient license.

We used LwIP for a project some years ago, and found a very nice way to do system testing.

The project involved multiple microcontrollers communicating over an internal LAN. They used a small embedded kernel named MicroCOS, with LwIP as the IP stack.

We had cross-platform build tools set up, so we could build our stand-alone microprocessor applications either for native execution or with gcc, compiling to x64 code and executable on developer boxes. In the latter case, we implemented the lowest level link-layer part of LwIP using a mock, that used standard TCP/IP! We wrote a small TCP server and would spool up the micro-controller applications, which would then talk to each other on the developer machines as though they were running inside the actual system.

This setup worked really well, and we used it for years during the development effort for the project.

For those looking for options like LwIP, consider NetXDuo [1] and its counterparts ThreadX, FileX, LevelX, and UsbX (I use TinyUSB instead).

It has been one of the top commercial RTOS network stacks for, I think, 20 years. It moved hands a couple of times and now is supported by the Eclipse Foundation and is MIT-licensed. I'd use it over LwIP.

[1] https://github.com/eclipse-threadx/netxduo

This.

It’s very neat that ThreadX and friends are MIT licensed now. I used ThreadX and NetX a bunch before the acquisition and open sourcing, and generally enjoyed using them. TX has a tight API / system design and implementation that makes it really nice to use.

I remember running into some obscure bugs with the NetX BSD socket layer that we ended up fixing in-house. It’s been way too long to dig up the specifics, but it’s great that fixes can now be upstreamed more easily.

> I remember running into some obscure bugs with the NetX BSD socket layer that we ended up fixing in-house. It’s been way too long to dig up the specifics, but it’s great that fixes can now be upstreamed more easily.

Unfortunately, it doesn't seem they have a process for that yet. But I'm sure that will improve. Or the community could take over. It would be nice to get a silicon vendor to pick this up to build a larger community around it.

Yeah, I always had the impression their translation layers were afterthoughts. Never used the BSD one though.

Adam Dunkels also wrote (most of) Protothreads. https://dunkels.com/adam/pt/

He also wrote uIP, the TCP/IP stack for the Contiki OS which is even smaller than LwIP

https://en.wikipedia.org/wiki/UIP_(software)

What is nongnu.org and how does it relate to gnu.org?

EDIT: I found an answer[0].

  StevePerkins on May 22, 2016 | unvote | next [–]

  http://savannah.gnu.org is a hosting site for "official" GNU software (i.e. sponsored by the Free Software Foundation).

  http://savannah.nongnu.org is a hosting site for "community" projects that are not sponsored by the FSF.

[0] https://news.ycombinator.com/item?id=11747093

I guess it's the most used TCP/IP stack in resource constrained devices. But it seemed that for long, there's no competent alternative to it. https://github.com/FreeRTOS/FreeRTOS-Plus-TCP looks like a promising one.

There are high quality alternatives:

- NetXDuo from ThreadX. It's Opensource for a while now.

- Zephyr also brings its own stack

It'd be interesting to see a breakdown of IP stacks for MCUs, their performance, how many security issues, etc.

NetX, Zephyr, LwIP, and SmolTCP all sort of fit in this realm these days it seems like. Probably others too... but yeah hard to discern the differences at a high level without digging in.

LWIP integrates quite well with the FreeRTOS scheduler, I’ve used that combo before. How does the “plus-TCP” stack compare?

The quality usually depends on the vendor adapting it to their silicon.

If you look at ST and their STM32 the lwip integration is extremely bug ridden. Just read all the articles in their forum from "Piranha". I also struggled with extremely hard to debug bugs coming from their adaption layers.

Lwip itself has a solid quality.

Can you say, with which hardware does, the LWIP stack, work well?

That sounds like ST. They make some really intriguing chips at good prices, but the tradeoff is that their hardware and software are full of bugs.

I really like LWIP because it lets you use the same block of memory allocated by the Ethernet MAC DMA for the lifetime of the packet. You can really optimize the memory “pools” for your use case to reduce the number of memcpys.

For those folks interested in implementing their own lightweight TCP/IP stack, Jeremy Bentham's book; TCP/IP Lean is a great resource.

From the article:

"This making lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM."

I've run it on a Cortex M4 with a built-in Ethernet MAC peripheral. It was shockingly simple to integrate... basically just needed to set up a receive ISR that handed packets to the LwIP stack and a transmit function that the LwIP stack could call to send packets.

That simple? We've got an overseas software team that was tasked with doing the exact same.

6 months later and they still haven't got a working implementation.

they are probably testing with more than the best case simple connection before declaring success, unlike everyone here.

I love your optimism.

I've seen their implementation. It was horrible. We eventually took the project away from them and had the local team work on it.

Also a fun story: they didn't use version control at all. When we eventually forced them to use git, they put the whole codebase in a .zip file and committed that.

Your onshore contract handlers were definitely difficult to work with. The number 1 reason for bad work are bad managers. See Boeing.

I've worked with offshore companies that are similarly as bad, but then again there have been some that have been excellent. In your case, I don't know how they lasted 6 months if they're not committing to git etc, if that's the standard. They should be brought into the daily standups as 6 months to wait for some delivery seems a bit waterfally (apologies if this is a mischaracterisation).

> They should be brought into the daily standups as 6 months to wait for some delivery seems a bit waterfally (apologies if this is a mischaracterisation).

At least it it a clear mischaracterisation of waterfall:

* https://changelog.com/posts/waterfall-doesnt-mean-what-you-t...

* HN discussion: https://news.ycombinator.com/item?id=37405049

* http://bawiki.com/wiki/Waterfall.html

* HN discussion: https://news.ycombinator.com/item?id=26760606

That's why I said waterfally

>daily standups

Daily what?

Luckily going to another employer soon, this place is a mess.

Are they integrating LwIP as it is or are they hacking its source to fit into your architecture?

I did the latter a decade ago for a home-grown SoC and it is non-trivial. And then testing it with conformance/performance in mind takes more time.

I have run it on a few hundred systems with Cortex R5 (used in a production context so demonstrated to be stable over tens of thousands of hours).

At that time there was a reference port for the Hercules development board available on-line. It was mostly working straight out of the box. I just had to fix a few issues with the Halcogen generated files (since then, TI has fixed the bugs), configure the lwIP options (to have DHCP and only use UDP). Since then (7 years ago), I have not touched the code once.

Well you need an Ethernet phy driver. If you have that that can work with the api of lwip it really is that easy.

Depends on the microcontroller and the rest of your stack but it should be fairly straight forward.

Feed received frames from your MAC into the appropriate receive function in a netif, and link the output function pointer to something that sends frames to your MAC.

Examples for STM32 parts are so prevalent on the web that ChatGPT or Copilot can probably get you working source in 30 seconds.

LwIP is part of Espressif's ESP-IDF framework, for the popular ESP32 devices. I've been working with LwIP for years on this platform, and while it does work, it still takes up more memory than I'd like it to. Thankfully we now have ESP32 devices with 2MB of RAM.

Pico W uses this, right? https://github.com/raspberrypi/pico-examples/blob/master/pic...

Yep! <https://github.com/dgoffredo/picoro/blob/main/include/picoro...>

Similarly, for Go programmers: https://pkg.go.dev/inet.af/netstack

also gVisor has a tcp/ip stack, tun2socks uses it

netstack is the gVisor IP stack. :)

And similarly, for Rust: https://github.com/smoltcp-rs/smoltcp

I've been using it in a toy OS project and it works brilliantly.

I love these tiny TCP stacks.

I used to work with TinyTCP back when. What's interesting is if a search for tinytcp turns up a bunch of them. Awesome!

Apparently there's no tiny ipv6 stack?

Lwip has v6 support

Yes, it's impressive. I had to write one in assembly years ago. However, could only do UDP unfortunately as I didn't have enough memory for code and TCP buffers in 64kB.

I first heard about LwIP when I worked with the ESP32. Espressiv seems to maintain its own fork with some ESP-specific patches: https://github.com/espressif/esp-lwip

see also uip and contiki as well as the other creations from Mr. Dunkles:

https://dunkels.com/adam/software.html

What is nongnu.org, and what is its relationship to gnu.org?

nongnu.org is also run by the same people as gnu.org, but hosts software which isn't currently officially part of the gnu project.

Basically, it's an area for software that is aligned with the GNU philosophy, might one day become part of the GNU project, but isn't officially currently part of the GNU project.

https://savannah.nongnu.org/register/requirements.php

https://savannah.nongnu.org/maintenance/GNUvsNonGNU/

How does LwIP compare to SmolTCP at this point?

What’s the news value of this? LWIP is the most popular embedded network stack and has been around for ages. It also is awful to use and riddled with undocumented issues (in my experience, anyway)

https://xkcd.com/1053/

https://xkcd.com/1053/ (jinx)

It's allowed to repost "classic" stuff on HN as long as it isn't too frequent.

Fair enough, I’m not familiar with the rules.

In my experience, it is a breeze to use. ~10 years ago, we managed to significantly cut down the cost of IP cameras by using lwIP with NuttX which allowed us to use a cheaper microcontroller instead of a more expensive chip that could run Linux.

Plugging in a new TCP congestion control scheme was also straightforward.

what kind of undocumented issues have you run into, and what did you have to do to deal with them?

the stack itself is extremely solid and works perfectly with reasonable performance. the codebase is extremely stable and has not had major changes, nor significant bugs in ages.

the biggest problem with lwip is the documentation. you have doxygen API docs that tell you exactly what the interfaces are (and not much more than the reading the header filed does), you have a few pages of "how to ..." and higher level background. but often it's slightly bit rotted, subtly hasn't kept up with design changes. so it's difficult to learn - you effectively have to thoroughly read the code to get the big picture. and if you make a mistake in handling your application callbacks, you can easily leak buffers or create other problems. it's not "awful to use", it's actually very simple - once you understand it, which is seriously hampered by truly lacking documentation.

the second issue is that the SoC vendors inevitably pay some overseas contractor to do the port and MAC/PHY drivers and example code, just like another [1] comment describes. that's where a lot of the instability and bugs come in. it's not lwip, it's the port that sucks.

[1] https://news.ycombinator.com/item?id=41462602

My experience comes from actually writing the ports as opposed to using it in other places. I’ve gotten issues like the UDP checksum generation breaking in the raw API at higher speeds or DHCP packets managing to come out corrupted, and in both cases I fixed it by just replacing the code that’s responsible. I’m not claiming this is representative of anything in general however, these are all for somewhat esoteric networking analysis in an academic setting. It definitely works well when you just use it as intended on microcontrollers however and I’ve never had issues when I’m not doing awful things to it :)

Reply on news.ycombinator.com