[Snort-users] ICMP Fragment Reassembly time exceeded
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
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?
The web page you seek
cannot be found here:
countless others await
Sheahan, Paul (PCLN-NW) wrote:
> 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
More information about the Snort-users