[U-Boot] [PATCH 1/3] net: defragment IP packets

[Robin Getz]

On Fri 31 Jul 2009 10:02, Alessandro Rubini pondered:
> >> Is the target replying to all pings? 
> > 
> > Yes. And I can see the same in wireshark.
> 
> Ah. I see. Strange...
> 
> >> > What is missing in the reassembly code (that is described in RFC815) 
> >> > is the timer. (quote from the RFC):
> >> > --------------
> >> > The  final  part  of  the  algorithm  is  some  sort of timer based
> >> > mechanism which decrements the time to  live  field  of  each 
> >> > partially reassembled  datagram,  so that incomplete datagrams 
> >> > which have outlived their usefulness can be detected and deleted.
> >> > --------------
> >> 
> >> But I reassemble one packet only, so I don't need to timeout
> >> partly-filled packets to recover memory. 
> > 
> > But it is for the state that you described - the user cntr-C a current 
> > transfer, and the reassembly algorithm doesn't know to throw away a
> > partially  accepted packet, when things are cancelled...
> 
> No, it's not like that. 

Are you sure? That is how it is on my network/tftp server.

Maybe we are talking about different things.

What I'm talking about is:
 - start a tftp file transfer.
 - CNTR-C it, causing a partial reassembly to done.
 - start a new transfer.

All I did was add this to the start of NetLoop() to ensure that things are OK.

#ifdef CONFIG_IP_DEFRAG
memset(pkt_buff, 0, IP_HDR_SIZE_NO_UDP);
#endif


> The old instance of the TFTP server resends the last packet of the 
> aborted xfer, 

I don't see how this can happen. the tftp server gets a request for a block of 
2048 bytes (for example) - and whacks out all 2048 bytes at once, and waits 
for the ACK.

If the ACK never comes - it doesn't send the packet again. The client times 
out, and the client needs to send another ACK of the last block before it.

What tftp server are you using?

imhotep:/home/rgetz # /usr/sbin/in.tftpd -V
tftp-hpa 0.43, with remap, with tcpwrappers

> while the new server sends the new 
> packet. Both packets are new, they just come as intermixed fragments.
> And none survives as there is only one reassembly buffer. 

The only way this should happen - is a real attack - sending malformed packets 
to the U-Boot system while it is downloading things on the net - which I 
agree with your comments below - is outside the scope of what we are talking 
about.

As a minimal test - since we are only talking about tftp and nfs (so far) - if 
we did not attempt to assemble packets which are not coming from the 
serverip, that might be an OK thing to do...

if (NetReadIP(&ip->ip_src) != NetServerIP)

> Or something 
> like that, but both are fresh fragmented packets, no timeout would solve
> this sporadic problem.

I still don't understand the use case. The server should only be sending 
packets in response to an ACK. The packets should be the entire UDP block 
size. the server should never mix packets.

> It seems to me that if we want a secure defagment system (one that can
> be use to net-boot production systems in hostile networks), it's
> going to be too complex.  It could work well, however, as a faster
> tool for the interactive developer.

I don't want something that is secure - security is beyond tftp's ability. For 
that -- you need to boot an OS and use https or sftp. All I'm asking for is 
something robust... :)

-Robin