README: DHCP packet size issues

[maniacbug]

You might want to point out in the readme that DHCP can cause issues for a 450-byte packet size. The default DHCP Offer packet is 590 bytes. Some routers have a configuration to reduce it down to the ~300 necessary bytes, but others do not. (See http://www.linksysinfo.org/index.php?threads/dhcp-reduce-packet-size.20699/ for one example).

In fact, RFC2131 says, "A DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP datagram size an IP host must be prepared to accept [3]. " No help to those of us on MCU's!

[sde1000]

It might be better to up the default buffer size and make a note in the README anyway, on the grounds that if people are running out of memory and need to reduce it then it's better that they do so knowing that they should test against their DHCP server first...

[maniacbug]

Yeah... This leads to the bigger problem that with memory so scarce on 328, packet size is so application dependent. Arduino is badly missing a way to configure libraries in a sketch. If you don't ever use dhcp, you dont need the large size. I have Internet radio streaming going with 300 byte packets.

I am thinking an even better approach is to rewrite the truncated packed in the enc driver. By putting a new size and CRC on the packet, the upper layers can be none the wiser.

[sde1000]

Yes, the way that Arduino goes for runtime configuration at the expense of RAM is really annoying. What's wrong with a per-sketch config file full of #defines?

That might be an interesting hack. Is the bit of the packet that doesn't make it through all padding?

[maniacbug]

Yes, the way that Arduino goes for runtime configuration at the expense of RAM is really annoying. What's wrong with a per-sketch config file full of #defines?

Indeed. Well I am having a conversation with David Mellis about this right now, trying to get it in. But it doesn't look likely. His view is that it's confusing for users. And by 'users', he means all the people who post on the forum asking, "How do I blink a light??"

What are your thoughts on moving to one-time dynamic allocation of buffers? That is, the values in uip-conf.f would be passed into the NanodeUIP constructor, and it allocates the required buffers, never to deallocate them.

That might be an interesting hack. Is the bit of the packet that doesn't make it through all padding?

Yup. And it's the only way this would work, because to validate the packet was not corrupted, you'd need to remake the checksum, and that requires knowing what the truncated values were.

---

From: Stephen Early reply@reply.github.com To: maniacbug maniacbug@ymail.com Sent: Wednesday, January 4, 2012 4:40 AM Subject: Re: [NanodeUIP] README: DHCP packet size issues (#4)

Yes, the way that Arduino goes for runtime configuration at the expense of RAM is really annoying. What's wrong with a per-sketch config file full of #defines?

That might be an interesting hack. Is the bit of the packet that doesn't make it through all padding?

---

Reply to this email directly or view it on GitHub: https://github.com/sde1000/NanodeUIP/issues/4#issuecomment-3354005

[sde1000]

We could try a one-time dynamic allocation of buffers. The problems I foresee are:

• We will need to keep the configuration in RAM - pointers to the various things we allocate dynamically (the packet buffer, the TCP state array, the UDP state array, the listening port arrays, the resolver cache), the sizes of each of these, and in the case of the state arrays the size of the application state. This will be at least another 23 (I think!) bytes of RAM used.
• The UIP code will need to do pointer arithmetic with these all the time, leading to an increase in compiled code size and reduction in speed. I don't know whether this will be enough to be significant compared to (for example) moving packets to and from the ethernet chip.
• We'll probably have to add another parameter to the connection setup functions so that apps can pass in sizeof(their state structure) so UIP can reject them if there's not enough space configured.

So it's probably worth a shot, but I'm not sure I like it!

[maniacbug]

It's not ideal... Other alternatives:

• Build from the command line, then you can put uip-conf.h in the sketch directory.
• Require users to hand-tune the library uip-conf.h for individual sketches.

As to the connection setup. One possibility is to keep a shared single size pool, like it is now, just make it dynamically allocated at runtime, so connections wouldn't have to pass in anything each time. Alternately, I would want to explore using dynamic allocation for ONLY the connection appdata. I hypothesize that in this case fragmentation is less likely due to its controlled nature. Needs experimentation. Alternately, connection app data could come from a fixed size allocator pool as implemented in memb.c. This would at least allow freeing of the DHCP state.

[nolith]

I would like to inform you that I had this problem in my home LAN. (I've got a fritzbox 7390 router)

I had to set #define UIP_CONF_BUFFER_SIZE 600 into libraries/NanodeUIP/uip-conf.h.

Maybe this issue, and the workaround, deserves to be more visible into the homepage.