Limitations

As already mentioned, lwIP does not seek to provide a complete implementation of a TCP/IP stack providing the same level of functionality provided in large OSes such as Linux, Windows, *BSD, etc. While some aspects are controlled by configuration, in other cases functionality is intentionally limited to fit the design requirements of a compact footprint.

While a complete list of the limitations would be too numerous to enumerate, here are some of the most relevant ones to be aware of:

  • Retransmission and windowing algorithms are implemented simply, at the expense of some performance.

  • Routing is simplified - one gateway per interface. IP forwarding follows the same rules as the host itself.

  • No support for NAT, nor packet filtering.

  • The TCP, DHCP and IP protocols can contain options in their packets. Relatively few of these options are supported by lwIP.

  • IPv4 Path MTU discovery (from RFC1191) is not supported. Ordinarily it is used to avoid fragmentation of packets resulting from the maximum MTU of an intermediate link between source and destination being smaller than the packet sizes actually transmitted. lwIP does however allow the TCP Maximum Segment Size (MSS) to be configured.

  • No complex data structures, caches and search trees to optimise speed. Generally simple lists are used.

  • Thread safety (for the sequential and BSD compatibility API) is implemented in a very simple form. Individual connections should not be operated on by multiple threads simultaneously. The mutual exclusion that is provided is at a very coarse grain - the network processing operations themselves are not multi-threaded.

  • Selective Acknowledgements (SACKs) (from RFC2018) are not provided in the TCP implementation. SACKs are a commonly implemented approach to increasing performance on links subject to packet loss, packet errors or congestion.

  • Most ICMP packet types are ignored.

  • If IP fragmentation and reassembly support is enabled then a limited sequence of IP fragments can be reassembled at one time (controlled by lwIP configuration options). If the number of active sequences supported is exceeded then packet fragments for new sequences are simply dropped, with the hope that a subsequent retransmission may be successful. Received IP fragments are allowed to be reassembled out of order however.

  • The BSD sockets compatibility API does not implement all socket options, API functions, nor API semantics.

  • Error handling for application errors is frequently only handled with asserts - used only during debug builds during development, allowing for smaller production code in release builds.

  • The TCP persist timer is not implemented. If a remote peer has filled its receive window and as a result lwIP stops sending, then when the remote peer processes more data it sends an ACK to update the window. However if that ACK is lost, then if data is entirely unidirectional (lwIP to remote host), the connection could stall. In practice, this has not been something people have experienced really.

  • TCP data is not split in the unsent queue, resulting in somewhat inefficient use of receiver windows.

  • The DNS client support only returns IPv4 addresses.

  • The SNMP agent only provides traps to IPv4 addresses.

  • The lwIP IPv6 implementation does not currently track router advertisement “route info” information. The IPv6 routing simply uses the normal /64 prefix for matching destination addresses against acquired (source) addresses for each indivdual lwIP network interface. If a destination address cannot be matched against an acquired source /64 address then the “routing error” (ERR_RTE) code is returned. This is not normally a limitation when using link-local or global addresses, but if an organisation is using unique-local addressing the lwIP stack by default will limit addressing to destinations on the same subnet (i.e. the matching /64 prefix). However, an eCos specific extension exists for supporting unique-local addresses, where the CDL option CYGNUM_LWIP_IPV6_UNIQUELOCAL_MASK can define the number of “global” prefix bits which are matched (from /48 to /64). This option can be configured to allow destination addresses for other unique-local subnets to be matched against the specific /64 interface unique-local address.

There are many more examples.

If a lwIP Direct device driver is being used then see the Section called GDB/RedBoot in Chapter 155 regarding limitation of remote network GDB/RedBoot debugging.

2017-02-09
Documentation license for this page: eCosPro License