Re: 2 NIC cards not talking

Ray Olszewski
2004-01-23T16:54:25Z

At 07:33 AM 1/23/2004 +0100, pa3gcu wrote:
>On Friday 23 January 2004 05:04, Beolach wrote:
> > chuck wrote:
> > > [snip]
> > >
> > > OBTW, when I
> > >
> > > ping -I eth0 192.168.1.1
> > > ping: bad interface address 'eth0'
> > >
> > > is what I get. I do have an eth0 device. :-|
> >
> > The -I option doesn't take an interface name (ie eth0), but rather the
> > IP address (ie 192.168.0.1) assigned to the interface.
>
>Get your facts right, it does take an interface name as option.
> >From the manual page of ping;
>
>-I interface address
>Set source address to specified interface address. Argument may be numeric IP
>address or name of device. When pinging IPv6 link-local address this option
>is required.

When this sort of disagreement pops up, it is helpful to remember that many
"standard" Unix/Linux programs actually exist in multiple versions, even
with up-to-date distros. In this instance, for example, my ping app (on a
fairly current Debian-Sid system) behaves as Beolach's version does, not as
Richard's does. For example:

ray@kuryakin:~$ ping -I eth0 celine
bad interface address 'eth0'
ray@kuryakin:~$ ping -I 192.168.1.2 celine
PING celine.comarre (192.168.1.23): 56 data bytes
64 bytes from 192.168.1.23: icmp_seq=0 ttl=254 time=798.5 ms
64 bytes from 192.168.1.23: icmp_seq=1 ttl=254 time=0.7 ms

(And my version of "the" man page for ping doesn't even mention the -I flag.)

>root@localhost:/# ping -I eth0 192.168.10.23
>PING 192.168.10.23 (192.168.10.23) from 192.168.10.15 eth0: 56(84) bytes of
>data.
>64 bytes from 192.168.10.23: icmp_seq=1 ttl=255 time=0.151 ms
>64 bytes from 192.168.10.23: icmp_seq=2 ttl=255 time=0.148 ms
>64 bytes from 192.168.10.23: icmp_seq=3 ttl=255 time=0.153 ms
>
>Now if i try that from my router then i get the same as Chuck gets, why it is
>i dont know and to be honest i dont really care as i do not see the point in
>using the -l option in this case period.

I want to second this final comment. Using tricky tests is always worse
than using straightforward ones, and this is, at best, a tricky test of
routing capabilities. I don't know how to interpret successes or failures,
and I've seen no indication in this discussion that anyone else here does
either. OTOH, testing whether a router actually routes by trying to connect
an actual, distinct host through it is a familiar exercise, with known,
interpretable failure bahaviors.