Date: Thu, 18 Oct 2001 17:27:53 -0700 From: Lars Eggert <larse@ISI.EDU> To: Lars Eggert <larse@ISI.EDU> Cc: net@freebsd.org, Yu-Shun Wang <yushunwa@ISI.EDU> Subject: Re: ARP & IP fragments Message-ID: <3BCF7389.9080104@isi.edu> References: <3BCF6A6E.5000302@isi.edu> <3BCF6E50.9080904@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Lars Eggert wrote: > we're seeing a strange thing happening, related to ARP and IP fragments. After a big of poking around, this is due to some code in arpresolve() and how struct llinfo_arp caches packets during lookup, see Stevens Vol. 2, page 699, the comment about lines 292-299. RFC 1122 also covers this. The structure that holds a packet while an ARP lookup for its destination is underway can only hold one packet. The problem is that if multiple packets arrive quickly for that destination, arpresolve() overwrites the cached packet with the last one it saw. For a fragment burst, this always causes the last fragment to be cached and eventually sent. Wouldn't it make more sense to do the ARP lookup before fragmentation, so that the unfragmented packet is cached? This should be OK according to RFC 1122, Section 2.3.2.2, which only specifies that the last of a set of packets to the same destination should be cached. Before fragmentation, there is only one packet... Also, according to the same section of RFC 1122, it should be OK to cache multiple packets here. Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BCF7389.9080104>