Thanks for your very good answers, Anyone has received icmp ip reassembly time exceeded ? (and like my pb)
Regard. Guy Harris wrote: > On Fri, Jun 06, 2003 at 12:13:42PM +0200, rmkml wrote: > > but on this file, I read : > > 09:01:08.317354 195.146.229.47 > 81.51.107.135: icmp: ip reassembly time > > exceeded for 81.51.107.135.4662 > 195.146.229.47.3039: [|tcp] (frag > > 63732:[EMAIL PROTECTED]) (ttl 55, len 60) (ttl 119, id 59326, len 56) > > > > > > but I not found any fragment on this two ips ! > > Frame 1291 (from your Tethereal output) has the ICMP packet with the > time-to-live-exceeded error. That packet includes the IP and TCP > headers of the packet that got the error; the IP header has an IP > identification field of 0xf8f4. > > Frame 902 is a TCP segment; its IP header has an IP identification field > of 0xf8f4. (I used Ethereal to find it - I looked at frame 1291, > selected the "Identification" field in the IP header inside the ICMP > packet (rather than the IP header of the ICMP packet itself), and then > used the "Match->Selected" menu item from the menu you get with the > right mouse button; that found frame 902.) > > Frame 902, however, doesn't have the "More fragments" flag set, and it > also doesn't have a non-zero fragment offset. Its time-to-live is 64, > rather than the 55 in the IP header inside the ICMP packet. The next 4 > bytes of the TCP header, after the destination port field, are 0xef 0xcc > 0xa5 0xf3 in both cases; that's the sequence number of the packet. The > "Total Length" field in the IP header inside the ICMP packet is 60; it's > 1500 in frame 902. > > > Strange ? > > Yes. > > I don't know what's happening. I *suspect* that packet 902 somehow was > fragmented by some piece of networking equipment before it reached the > machine at 195.146.229.47 - if so, that piece of networking equipment is > violating RFC 791, which says > > An internet datagram can be marked "don't fragment." Any internet > datagram so marked is not to be internet fragmented under any > circumstances. If internet datagram marked don't fragment cannot be > delivered to its destination without fragmenting it, it is to be > discarded instead. > > If so, then that piece of networking equipment might be causing other > problems, which might cause some of the fragments to be lost. > - > This is the TCPDUMP workers list. It is archived at > http://www.tcpdump.org/lists/workers/index.html > To unsubscribe use mailto:[EMAIL PROTECTED] - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
