Page History

...

I do no know if we have any such bugs today. Perhaps they still do? Perhaps they do not? Having such a guard is a good thing for reliability in any case.

...

1. When the packet is received a pointer to the location of the payload is set (d_appdata). This is an offset into the packet buffer For TCP, that accounts for the MAC/Ethernet header, the minimum IPv4/IPv6 header size, and the minimum TCP header size.
2. The TCP payload data is written at that location using a constant MSS,
3. The minimum sized IPv4/IPv6 headers and the minimumsize sized TCP header are added below the payload, and finally
4. The MAC/Ethernet header as add at the very beginning of the buffer.

The problem is, of course, is that IPv4/IPv6 and TCP headers are not constant. Using the minimum size for these headers precludes using IPv4/IPv6 or TCP header options. There are currently only a few places where options are required and these have to be handled as special cases. This needs to be formalized into the common packet formatting logic. Otherwise, the network will never be able to handle advanced features like tunneling or NAT.

...

• Keep CONFIG_NET_GUARDSIZE in all driver buffers, and
• Set the CONFIG_NET_GUARDSIZE to the maximum size of IPv4/IPv6 and TCP options (depending on which IP version is enabled and if TCP is enabled)
• Extend the driver interface to accept data offset into the driver's packet buffer.

Variable MSS

Closely related to this is the MSS which is the maximum size of the payload. Currently that is a constant because it assumes the minimum header lengths. It should be variable, depending on the actual header sizes.

...