icmp echo disable (or dont answer pings)

Steven Johnson sjohnson at sakuraindustries.com
Wed May 31 05:41:53 UTC 2006

Chris Johns wrote:

> Joel Sherrill wrote:
>> Comments please.  This does seem like a reasonable application feature.
> I would like to see the Wiki updated to document this feature as it is
> not standard.

Will Do.

> Extending the stack this way could result in this feature being lost
> if (or when) the stack is upgraded. I see it is a simple patch which
> provides a specific solution to a specific problem, but have to wonder
> what FreeBSD does to handle this normally. Does it use some sort of
> firewall rules ? If it does could this approach have been used ?

I don't know how FreeBSD handles this, as you say it doesnt have a
network stack option as standard.  I looked in their code base to see if
there was, so i could use their sysctl name.  Linux does, with the
sysopt "icmp_echo_ignore_all".  Linux has different sysopt names from
the FreeBSD stack, so i tried to use a name which was closer to the
current name's in use in the FreeBSD stack.  Im not sure how a Firewall
rule could do it, because its tied into the network protocol stack, and
I would have thought the firewall would need to set the option in the stack.

Another way to resolve any feature lost on a future import would be to
submit the patch to the FreeBSD people for inclusion into their code
base.  As I don't have the FreeBSD code base, and I know next to nothing
about FreeBSD, except for the few man pages on their sysctl's i read,
that's not something I can do.

>>>     case ICMP_ECHO:
>>> -        if (!icmpbmcastecho
>>> -            && (m->m_flags & (M_MCAST | M_BCAST)) != 0
>>> -            && IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) {
>>> +        if (!icmpallecho +            || (!icmpbmcastecho
>>> +            && (m->m_flags & (M_MCAST | M_BCAST)) != 0
>>> +            && IN_MULTICAST(ntohl(ip->ip_dst.s_addr)))) {
>>>             icmpstat.icps_bmcastecho++;
>>>             break;
> This code does not update the icps_allecho counter. Should it ?

Um, yes it should. Bugger. Attached is a revised patch to fix that.

Steven J
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems-
Type: text/x-patch
Size: 2483 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20060531/92375f8f/attachment-0001.bin>

More information about the users mailing list