lwip tftp not working on imx8mm

[Peter Robinson]

On Wed, 28 May 2025 at 17:59, Tim Harvey <tharvey at gateworks.com> wrote:
>
> On Wed, May 28, 2025 at 5:24 AM Jerome Forissier
> <jerome.forissier at linaro.org> wrote:
> >
> >
> >
> > On 5/27/25 18:35, Tim Harvey wrote:
> > > On Mon, May 26, 2025 at 5:17 AM Jerome Forissier
> > > <jerome.forissier at linaro.org> wrote:
> > >>
> > >> Hi Tim,
> > >>
> > >> On 5/23/25 20:31, Tim Harvey wrote:
> > >>> Hi Jerome,
> > >>>
> > >>> I've enabled LWIP on imx8mm_venice to see how it's doing and while
> > >>> dhcp/dns/ping/wget appear to work great, tftp is broken.
> > >>>
> > >>> Enabling LWIP_DEBUG shows the following:
> > >>> ip4_input: packet accepted on interface et
> > >>> IP packet dropped since it was fragmented (0x2000) (while IP_REASSEMBLY == 0).
> > >>
> > >> Hmmmmm IP_REASSEMBLY should probably default to 1.
> > >>>
> > >>> I tried enabling IP_REASSEMBLY in lwip but that seems to change the issue to:
> > >>> ip4_input: packet accepted on interface et
> > >>> ip4_input:
> > >>> IP header:
> > >>> +-------------------------------+
> > >>> | 4 | 5 |  0xc0 |       108     | (v, hl, tos, len)
> > >>> +-------------------------------+
> > >>> |    10568      |000|       0   | (id, flags, offset)
> > >>> +-------------------------------+
> > >>> |   64  |    1  |    0xe25b     | (ttl, proto, chksum)
> > >>> +-------------------------------+
> > >>> |  172  |   24  |    0  |    2  | (src)
> > >>> +-------------------------------+
> > >>> |  172  |   24  |   21  |  251  | (dest)
> > >>> +-------------------------------+
> > >>> ip4_input: p->len 108 p->tot_len 108
> > >>> Unsupported transport protocol 1
> > >>>
> > >>> Any ideas what the issue is here?
> > >>
> > >> Not really :-/ Does the transfer work with a smaller block size?
> > >> (CONFIG_TFTP_BLOCKSIZE, default 1468, try 500 for instance). You could
> > >> also enable CONFIG_LWIP_DEBUG_RXTX in order to get a full hex dump of
> > >> the messages going into/out of the lwIP stack.
> > >
> > > Hi Jerome,
> > >
> > > My config was with 4096, setting it to 1468 works and anything above
> > > that seems to cause this failure.
> >
> > Good to know.
> >
> > > Some sort of fragmentation issue?
> >
> > Quite possibly, yes. In any case it does not make much sense to use a
> > clock size that causes the packet to be larger than the PMTU (it would
> > be sub-optimal) but it should definitely work, especially since I don't
> > believe PMTU discovery is implemented in lwIP. I add this to my to-do
> > list but feel free to investigate further :)
> >
>
> Hi Jerome,
>
> I'll take a look at it as larger than MTU packets are definitely not
> suboptimal for TFTP. A 4096B block size will ack once per 4K so 4x
> less ACK's and in my testing the 4K blocksize gives a 3x performance
> boost on large files.

Refreshing my memory on TFTP slightly, I think larger than MTU tftp
transfers need support for RFC 2348 [1], maybe that's something we
need to explicitly enable if the TFTP layer is part of LWIP (or maybe
LWIP doesn't support it), or if the tftp application is ours on top of
LWIP maybe we're missing some glue. I didn't look at the code, rather
this was from some of my own notes from a long time ago.

[1] https://www.rfc-editor.org/rfc/rfc2348