6 ms·
LwIP – Lightweight IP Stack
- tony-allan 2y agoFrom 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."
- tonyarkles 2y agoI'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.
- yuye 2y agoThat 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.
- 1oooqooq 2y agothey are probably testing with more than the best case simple connection before declaring success, unlike everyone here.
- yuye 2y agoI 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.
- pts_ 2y agoYour onshore contract handlers were definitely difficult to work with. The number 1 reason for bad work are bad managers. See Boeing.
- _joel 2y agoI'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).
- aleph_minus_one 2y ago> 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-think-it-means https://changelog.com/posts/waterfall-doesnt-mean-what-you-t... * HN discussion: https://news.ycombinator.com/item?id=37405049 https://news.ycombinator.com/item?id=37405049 * http://bawiki.com/wiki/Waterfall.html http://bawiki.com/wiki/Waterfall.html * HN discussion: https://news.ycombinator.com/item?id=26760606 https://news.ycombinator.com/item?id=26760606
- _joel 2y agoThat's why I said waterfally
- yuye 2y ago>daily standups Daily what? Luckily going to another employer soon, this place is a mess.
- rramadass 2y agoAre 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.
- Thervicarl 2y agoI 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.
- rowanG077 2y agoWell you need an Ethernet phy driver. If you have that that can work with the api of lwip it really is that easy.
- wiskinator 2y agoDepends 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.
- leptons 2y agoLwIP 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.
- stevefolta 2y agoWhat is nongnu.org, and what is its relationship to gnu.org?
- TheDong 2y agonongnu.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/register/requirements.php https://savannah.nongnu.org/maintenance/GNUvsNonGNU/ https://savannah.nongnu.org/maintenance/GNUvsNonGNU/
- mannyv 2y agoI 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?
- convolvatron 2y agoLwip has v6 support
- RachelF 2y agoYes, 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.
- kaycebasques 2y agoPico W uses this, right? https://github.com/raspberrypi/pico-examples/blob/master/pico_w/wifi/tls_client/tls_common.c https://github.com/raspberrypi/pico-examples/blob/master/pic...
- MathMonkeyMan 2y agoYep! <https://github.com/dgoffredo/picoro/blob/main/include/picoro/tcp.h https://github.com/dgoffredo/picoro/blob/main/include/picoro...>
- tptacek 2y agoSimilarly, for Go programmers: https://pkg.go.dev/inet.af/netstack https://pkg.go.dev/inet.af/netstack
- ranger_danger 2y agoalso gVisor has a tcp/ip stack, tun2socks uses it
- tptacek 2y agonetstack is the gVisor IP stack. :)
- Gazoche 2y agoAnd similarly, for Rust: https://github.com/smoltcp-rs/smoltcp https://github.com/smoltcp-rs/smoltcp I've been using it in a toy OS project and it works brilliantly.
- throwawayabcdef 2y agosee also uip and contiki as well as the other creations from Mr. Dunkles: https://dunkels.com/adam/software.html https://dunkels.com/adam/software.html
- jacobmarble 2y agoAdam Dunkels also wrote (most of) Protothreads. https://dunkels.com/adam/pt/ https://dunkels.com/adam/pt/
- cristoperb 2y agoHe also wrote uIP, the TCP/IP stack for the Contiki OS which is even smaller than LwIP https://en.wikipedia.org/wiki/UIP_(software) https://en.wikipedia.org/wiki/UIP_(software)
- lovidico 2y agoWhat’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)
- fragmede 2y agohttps://xkcd.com/1053/ https://xkcd.com/1053/
- wmf 2y agohttps://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.
- lovidico 2y agoFair enough, I’m not familiar with the rules.
- unmole 2y agoIn 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.
- kragen 2y agowhat kind of undocumented issues have you run into, and what did you have to do to deal with them?
- fargle 2y agothe 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 https://news.ycombinator.com/item?id=41462602
- kneep 2y agoI 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 https://github.com/FreeRTOS/FreeRTOS-Plus-TCP looks like a promising one.
- schnitzelbot 2y agoThere are high quality alternatives: - NetXDuo from ThreadX. It's Opensource for a while now. - Zephyr also brings its own stack
- bfrog 2y agoIt'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.
- quailfarmer 2y agoLWIP integrates quite well with the FreeRTOS scheduler, I’ve used that combo before. How does the “plus-TCP” stack compare?
- schnitzelbot 2y agoThe 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.
- high_priest 2y agoCan you say, with which hardware does, the LWIP stack, work well?
- 2y ago
- quailfarmer 2y agoI 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.
- taspeotis 2y ago[flagged]
- tptacek 2y agoThis code is over 2 decades old. Pointing out that it's written in C is just about the least interesting thing you can say about it. https://web.archive.org/web/20160304140507/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.109.1795&rep=rep1&type=pdf https://web.archive.org/web/20160304140507/https://citeseerx...
- taspeotis 2y agoOpenSSL leaking data was a huge deal and invited a lot of scrutiny of its choice of language. The IPv6 code that leaked data is not 20 years old. The question deserves to be asked: why persist with C? Why handwave a discussion about securing embedded devices away (this is a very popular embedded library) by claiming it's uninteresting?
- weinzierl 2y agoIP 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.
- evanjrowley 2y agoWhat 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 https://news.ycombinator.com/item?id=11747093
- rramadass 2y agoFor those folks interested in implementing their own lightweight TCP/IP stack, Jeremy Bentham's book; TCP/IP Lean is a great resource.
- bloco1 2y ago[flagged]
- gregfjohnson 2y agoWe 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.
- spacechild1 2y agoI 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 https://github.com/espressif/esp-lwip
- bfrog 2y agoHow does LwIP compare to SmolTCP at this point?
- bangaladore 2y agoFor 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 https://github.com/eclipse-threadx/netxduo
- GrqP 2y agoThis.
- mafuyu 2y agoIt’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.
- bangaladore 2y ago> 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. > 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. Yeah, I always had the impression their translation layers were afterthoughts. Never used the BSD one though.