svn commit: r336465 - in head/sys/netinet: . tcp_stacks

[Kurt Lidl]

On 7/19/18 9:18 AM, Maxim Konovalov wrote:
> On Thu, 19 Jul 2018, 08:09-0400, Michael Tuexen wrote:
> 
>>> On 19. Jul 2018, at 03:12, Maxim Konovalov <maxim.konovalov at gmail.com> wrote:
>>>
>>> Hi Randall,
>>>
>>> On Wed, 18 Jul 2018, 22:49-0000, Randall Stewart wrote:
>>>
>>>> Author: rrs
>>>> Date: Wed Jul 18 22:49:53 2018
>>>> New Revision: 336465
>>>> URL: https://svnweb.freebsd.org/changeset/base/336465
>>>>
>>>> Log:
>>>>   Bump the ICMP echo limits to match the RFC
>>>>
>>> [...]
>>>
>>> Just wonder, are there any practical reasons to do that?
>> In case you send encapsulated packets triggering an ICMP message
>> you actually need more than the 8 bytes which are currently
>> reflected.
> 
> OK, let me rephrase: why do you need more than 8 bytes?  It looks like
> it has been working rather well for 20+ years.

Coming late to the game (I was away for vacation)...

It's handy to have more than 8 bytes of returned payload for ICMP 
packets to allow for more sophisticated network health scanning metrics.

Back when I worked at UUNET, we used the ICMP ECHO REQUEST packets to 
carry accurate timestamps for monitoring dispersion of multicast 
datagrams to select hosts.  I know, ICMP ECHO REQUEST packets have 
required all payload to be returned since at least RFC 1712 - so it's 
not exactly the same as what is being change here...

I imagine that a similar generic treatment of payload data for other 
ICMP type message might be handy too.

-Kurt