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:
[EMAIL PROTECTED]:~$ ping -I eth0 celine bad interface address 'eth0' [EMAIL PROTECTED]:~$ 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.)
[EMAIL PROTECTED]:/# 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.
- To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs