>| how egregious would it be to have, for example, "arp -p" reach down
>| into the kernel and tickle it into arping the given default gateway
>| intending only to elicit an arp reply?  the theory here being that if
>| you can't arp the default gateway, it ain't a good gateway, regardless
>| of whether it's filtering icmp (or other) or not.
>
>It would be good to have a userland utility to be able
>to issue/recieve arps just as we can do so with icmp
>echo request.

yeah...

>Perhaps this could fill the void associated with
>lacking an ethernet-level "ping" utility. I don't
>think it belongs in the "arp" program, though...

no...?  it "sounds" like the appropriate place to put it.

on second thought...after considering my suggestion for a day, i think
that perhaps the ping command ought to stay exactly the way it is, and
the route command ought to be modified to use sensible exit codes (any
errors it encounters result in a 1, and if no errors are encountered,
but the gateway sockaddr isn't filled in, then it's a 2).  this way
ping could be used (and ignored) and the route could be used to see if
the gateway responded via arp (or whatever).

>For those not in the know, Ethernet in fact
>deffines a "Configuration and Test Protocol" with
>source-routing even (!), for doing layer two
>pings. Very few hosts implement it, though
>cisco routers do.
>
>I did up an implementation a few years ago, I
>periodically wonder if it's worth adding to NetBSD,
>and then I decide that it's not too useful unless
>it is widely deployed, which it is not...

can you check for the protocol's availablity at run-time?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."