Bug 81640
Summary: | ping -I on secondary interfaces doesn't work | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Johannes Teveßen <j.tevessen> | ||||
Component: | iputils | Assignee: | Phil Knirsch <pknirsch> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 8.0 | CC: | rvokal | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2003-05-15 15:51:51 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Johannes Teveßen
2003-01-11 23:42:34 UTC
Please note that 194.120.248.64/29 isn't really private IP space. It was disconnected, so before renumbering my network I masqueraded it. In the process of renumbering to 172.16.x.x, I triggered this bug while testing. Another two things, sorry. :-) I just checked iputils-ss020927.tar.gz and iputils-ss021109-try.tar.bz2 from ftp://ftp.inr.ac.ru/ip-routing/ - Same problem. But maybe it's still interesting for RedHat to update the iputils package, since, for example, the latest "RELNOTES" reads: "[021108] * Noah L. Meyerhans <frodo> Wow. == instead = in traceroute6." Ahem. :-) Routing on my box is okay: Destination Gateway Genmask Flags Metric Ref Use Iface 194.120.248.64 0.0.0.0 255.255.255.248 U 0 0 0 eth0 172.19.84.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 194.120.248.65 0.0.0.0 UG 0 0 0 eth0 (Note that /sbin/route (net-tools[*]) lists eth0:1's address as belonging to eth0, too. This might be correct since it's the same physical NIC, but maybe also worth a fix to reduce possible confusion. [*] net-tools-1.60-7 on RH 8.0 and net-tools-1.60-4 on RH 7.3 After unsuccessful attempts with recent RedHat strace packages and the latest strace available in a tarball, I just fetched CVS strace and worked out a little patch to decode those SO_??? calls that are visible in the above strace() output. Using my patched strace, it turned out that it's indead a problem with ping(8) trying to bind to an interface it cannot reach - for whatever reason. But it doesn't display any error at all and silently goes on - with the wrong IP bound to... In strace, it now looks like this (note the SO_BINDTODEVICE call and that the newer strace(8) shows the actual string "eth0:1\0" instead of a memory pointer): socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3 getuid32() = 0 setuid32(0) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "eth0:1\0", 7) = -1 ENODEV (No such device) connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("193.141.40.1")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(32773), sin_addr=inet_addr("194.120.248.66")}, [16]) = 0 close(4) = 0 ioctl(3, 0x8933, 0xbffff8e0) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("194.120.248.66")}, 16) = 0 setsockopt(3, SOL_RAW, ICMP_FILTER, ~(ICMP_ECHOREPLY|ICMP_DEST_UNREACH|ICMP_SOURCE_QUENCH|ICMP_REDIRECT|ICMP_TIME_EXCEEDED|ICMP_PARAMETERPROB), 4) = 0 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [324], 4) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [131070], [4]) = 0 [...] The code in question in iputils is in iputils/ping.c around line 275: if (setsockopt(probe_fd, SOL_SOCKET, SO_BINDTODEVICE, device, strlen(device)+1) == -1) { if (IN_MULTICAST(ntohl(dst.sin_addr.s_addr))) { if (ioctl(probe_fd, SIOCGIFINDEX, &ifr) < 0) { fprintf(stderr, "ping: unknown iface %s\n", device); exit(2); } /* ... */ } } No "else", nothing. So, if the interface binding *fails* and the source IP address is *not* a multicast address, no error is issued and ping(8) silently continues. However, I don't have the slightest idea why a (root) process should not be allowed to bind to a subinterface like "eth0:1". Also I'm not at all sure whether the IN_MULTICAST check is in the right place here. Seems kind of wrong to me. However, I'll attach my little patch which at least outputs a message and terminates if the interface specified is unusable for the task. With this patch, ping barks if used on things like eth0:1 where it cannot bind to; it doesn't bark if it just doesn't have enough permissions. However, the message is also displayed if a _really_ non-existent interface is specified (NOTE: There is a difference here between "eth0:1" and, for example, "bla0". Different OS reaction!). The problem remains. Any ideas? Created attachment 89313 [details]
Patch that adds error reporting to ping(8) if it cannot bind to an EXISTING interface
Against iputils-ss021109; should be easy to apply.
Patch included in iputils-20020927-4 to appear in rawhide soon. Read ya, Phil |