IP fragment re-assembly / maximum packet size

[penfold42]

Got a sketch driving ws2812 LEDs.

This works great until you scale up the number of LEDs until the Ido packet gets fragmented - about 1470 bytes.

My sketch never sees the incoming UDP packets at this point.

Is this a bug or a feature ?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Links2004]

is the package is still send on the WiFi?
may the sending computer has 1Gbit and using Jumbo frames?
can you provide more info about the whole setup?

[igrr]

IP reassembly is disabled in LwIP build options:

https://github.com/esp8266/Arduino/blob/esp8266/hardware/esp8266com/esp8266/libraries/ESP8266WiFi/src/include/lwipopts.h#L519

On Fri, Oct 9, 2015 at 3:10 PM, Markus [email protected] wrote:

is the package is still send on the WiFi?
may the sending computer has 1Gbit and using Jumbo frames?
can you provide more info about the whole setup?

—
Reply to this email directly or view it on GitHub
#867 (comment).

[Links2004]

oO this is bad.
may we shut think about using https://github.com/kadamski/esp-lwip
then we can also get rip of the espconn functions to save some space.

[penfold42]

Is it off for a reason ?

I'm using Hyperion on a pi with my own UDP led driver to send UDP packets to the ESP.

Is this likely to be fixed any time soon or should I rework my led protocol to workaround this issue.

My view is we need a proper fix - There could be a hop with a tiny MTU which would make lots of UDP things unworkable.

[igrr]

I suspect that enabling IP reassembly increases memory requirements
somewhat. You could try fixing this by building Espressif's LwIP from
source (it can be downloaded from their BBS), with this option enabled. If
you end up doing that, please let me know how this affects the amount of
memory available to the sketch.

Let me know if you need additional instructions on how to build LwIP.

On Fri, Oct 9, 2015, 17:34 penfold42 [email protected] wrote:

Is it off for a reason ?

I'm using Hyperion on a pi with my own UDP led driver to send UDP packets
to the ESP.

Is this likely to be fixed any time soon or should I rework my led
protocol to workaround this issue.

My view is we need a proper fix - There could be a hop with a tiny MTU
which would make lots of UDP things unworkable.

—
Reply to this email directly or view it on GitHub
#867 (comment).

[drmpf]

IP reassembly is disabled in LwIP build options:

I suspect this is why the next packet is delayed by 0.2sec, until the first one is acked and why noDelay == true does not work.

[mtnbrit]

+1 for getting this implemented as an option. I am seeing major issues with OTA failing over the Internet, I've used mqtt and http as transport and they both show the same type of random failures where the stream times out.

[AndyKirby]

Slightly related (But only slightly).

I have had similar issues using vpn on linux debian of late.

Connections happened OK and then when attempting to use them they would
just hang or fail. Eventually timing out but mostly locking up with
endless retrys.

HTTP connected then failed to return pages or page content, SSH
connected fine but hung if I did an ls -alh or anything that attempted
to ship a lump of data. The issue seemed random until traced back not to
the application but to the TCP layer.

The issue turned out to be tcp related and the packet default MTU value.
My VPN connection was defaulting to 1500 where as there is a bunch of
overhead for the VPN and it needed to be defaulting to 1300.

Setting the default MTU lower prevented the need to fragment and
re-assemble in transit. My VPN connections now all work fine.

In the ESP's case I would imagine that the limiting factor is limited
memory and buffer. It may be worth trialling setting the ESP's MTU to
something smaller in the OTA section. Maybe the default MTU is set
larger than the OTA section of code can comfortably buffer when flooded.
Hence why the applications work but OTA can be random.

It might not be the above, but it is worth considering, maybe.

Cheers

Andy Kirby

On 15/10/15 03:41, mtnbrit wrote:

+1 for getting this implemented as an option. I am seeing major issues
with OTA failing over the Internet, I've used mqtt and http as
transport and they both show the same type of random failures where
the stream times out.

—
Reply to this email directly or view it on GitHub
#867 (comment).

[email protected]
www.kirbyand.co.uk

[penfold42]

I haven't yet, maybe another example for this project is the easiest way ?

Right now it's a simple UDP socket listener to the drive a string of ws2812b LEDs.

It listens on 3 ports to support 3 protocols.
ASCII, which lets you address each led individually (and status, version, blank. Fill commands)
Binary - send all led data starting from led 0, no more no less up to ~500 LEDs (subject to ip fragmentation)
Binary with a starting led number to work around the frag problem.

I've also written a UDP led driver fro Hyperion which gives me an effects engine and android/iPhone/web remote control

[skandragon]

For what it's worth, I'm getting OTA via http problems without fragmentation of any kind in effect.

UDP packets larger than the size and relying on IP level fragmentation to get the job done is asking for problems. IPv6, for instance, doesn't even support fragmentation, and for good reason.

I suggest you split your UDP packet into more than one frame, and include an LED offset or something if you need to do application-level fragmentation.

[penfold42]

That's exactly what I did - the third protocol option above.

As of yesterday it's driving 600 LEDs as xmas lights on my balcony.

[skandragon]

Grats :)

In my case, I'm trying to drive it with TCP, so I can't flood the system -- in theory, it will read as fast as it needs to and no faster. However, even though I am returning from loop() frequently, if I blast TCP data at this device, the hardware WDT gets me. Very, very strange.

[Alge]

has anyone gotten the fragmented packets to work?

[devyte]

@d-a-v I know very little of lwip, but from what I can tell, lwip2 still has fragmentation assembly disabled. Can you please confirm? Do you know the implications of enabling assembly?

[d-a-v]

Fragmentation and reassembly are still disabled.
They can be enabled. It has a cost (code in flash and fragments in ram).
There is a pending ready-to-merge awaiting-for-feedback PR #5126 with some important but optional configuration for TCP, fragmentation and reassembly can be enabled along this option (which is SACK).

(sorry for the delay)

[d-a-v]

Cost: 2284 flash bytes for IP fragmentation(output) and IP reassembly(input).

[d-a-v]

This is currently enabled with the lwIP-v2 w/ features and also with IPv6 options.
Closing.