Make MTU configurable

[jcbnq]

In #492, we finally discovered that a network segment was dropping packets from booster because of an MTU less than 1500. Since booster doesn't implement anything to react to ICMP MTU-related responses from the segment refusing to deliver the large frames, everything ends up being silently dropped. Because the telemetry packets all get bundled together at ~300B each, it only takes about 4 to hit the MTU, and trigger this behaviour.

Rather than implementing full MTU handling, in this PR I've added a configuration setting that allows the user to reduce the default 1500 MTU if they wish to, on a fixed basis.

[jordens]

It's unlikely that this is the correct (or an acceptable) fix. Could you check whether this is a fixed bug (in booster main or #488 or addressed in a newer smoltcp)?

[jcbnq]

It's unlikely that this is the correct (or an acceptable) fix.

Ok, what's your reasoning here? Do you have an alternative in mind? What do you mean by "correct"? I already explained that this is my light-touch solution to get it working without adding a full discovery implementation. This solution I think is as correct as the existing implementation, with the added benefit of additional user config options. There are better solutions possible, but they'd take more work.

Could you check whether this is a fixed bug (in booster main or #488 or addressed in a newer smoltcp)?

Whether it's a bug depends on your viewpoint of the existing implementation choice, which is to hard-code 1500 as the MTU passed to smoltcp. As explained earlier, this then fails for any network where something on the route has a lower MTU, since the ICMP replies (Destination Unreachable; Fragmentation Needed) which ought to indicate to the client that the packets are not delivered are not handled by the booster client.

Although smoltcp 0.12 (as slated for addition in #488) does seem to add TCP congestion control, that isn't where the problem lies (the MTU is not in the TCP layer, and the tcp session is never established). In addition, I think you still need to enable congestion control, because the smoltcp seems to require non-default features, otherwise the default is for no congestion control. Since Path MTU Discovery (PMTUD) is implemented via returned ICMP messages, it requires a listening ICMP socket in addition to the sending TCP socket. Smoltcp's tcp sockets don't automatically come with an accompanying ICMP listener. As far as I can tell, although smoltcp supports fragmentation based on the (configured-once) MTU, it does not support MTU discovery of any kind (at least, not without the user implementing it themselves).

I didn't feel like implementing MTU discovery right now, so threw together this stop-gap to allow the MTU to be configured manually at startup so a device can be configured for a given network, which in many cases is sufficient to get this working for the user.

[jordens]

Nah. There are many things wrong here. You are severely confused by MTU, fragmentation, MSS, and congestion. Neither PMTUD nor congestion control/avoidance are needed to make TCP work. They certainly don't help fixing broken setups. Your scenarios are addressed by MSS clamping or fragmentation. Go check your network!
Generally we'd look at implementation quality, showing how the problem arises (here: packet trace and explanation), that other causes/solutions are unlikely/worse (which of the three checks I requested did you do? specifically here also identifying issues with and the fixing of your network), that a significant part of users is likely affected/helped, and that the consequences (reviewing, maintenance, docs, debugging, support, testing, porting, future compatibility) of the approach are acceptable. Your approach currently clears none of those bars.

[jcbnq]

Righto, I'll leave you to it, then.