[Snort-users] ICMP Fragment Reassembly time exceeded

John Sage jsage at ...2022...
Tue Jan 15 20:56:02 EST 2002


To paraphrase WR Stevens, "TCP/IP Illustrated vol.1" page 158:

"ICMP Fragment Reassembly Time Exceeded" itself is generated when the IP 
layer sets a timer upon the first arrival of any fragment, not 
necessarily the first. If all fragement have not arrived when the timer 
expires, then that response is sent so long as the *first* fragment 
*was* received...


So how could a client deliberately generate this?

Well, what sort of client?  Stevens implies that this is not that 
unusual: it simply means that all fragments were not received when your 
server's timer expired.

After that, if someone wanted, I suppose this could be deliberately 
triggered by some crafted client sending partial fragment sets...

...why bother? I don't know how current it is now, but Stevens states 
that Berkeley-derived IP implementations never generate this error, so I 
'spose some sort of OS identification could be at work.

Or maybe not.

The icmp packet sent out should contain the first 8 bytes of the 
original IP datagram; does that show anything interesting?

- John

The web page you seek
cannot be found here:
countless others await

Sheahan, Paul (PCLN-NW) wrote:

> Hello,
> In my Snort logs I am seeing "ICMP Fragment Reassembly time exceeded" on a
> daily basis being sent as a response from our web servers to random clients
> on the Internet. I am running Snort Version 1.8.1-RELEASE (Build 78) under
> Red Hat Linux 7.0.
> Can anyone tell me or point me in the right direction on how a client is
> able to force a web server to respond with this ICMP message? I assume it is
> a means of a client gathering information from a server but want to get more
> information.
> Thanks!
> Paul

More information about the Snort-users mailing list