[Bug 351378] Re: dhclient fails for virtual interfaces (IP aliases)

[Tom Metro]

Attached is an archive containing the output of:

  # strace -ff -F -o /tmp/dhclient.strace dhclient eth0:0
  There is already a pid file /var/run/dhclient.pid with pid 134519072
  Internet Systems Consortium DHCP Client V3.0.6
  Copyright 2004-2007 Internet Systems Consortium.
  All rights reserved.
  For info, please visit http://www.isc.org/sw/dhcp/

  SIOCSIFADDR: Permission denied
  SIOCSIFFLAGS: Permission denied
  SIOCSIFFLAGS: Permission denied
  Bind socket to interface: No such device


Some interesting bits include:

>From dhclient.strace.9271-avahi-autoipd:

execve("/usr/sbin/avahi-autoipd", ["/usr/sbin/avahi-autoipd", "-k", "eth0:0"], [/* 7 vars */]) = 0
[...]
open("/var/run//avahi-autoipd.eth0:0.pid", O_RDWR) = -1 ENOENT (No such file or directory)
write(2, "Failed to kill daemon: No such f"..., 48) = 48
write(2, "\n", 1)                       = 1
exit_group(1)                           = ?


That avahi-autoipd is trying to access /var/run/avahi-autoipd.eth0:0.pid may be by design, or may be a bug. I don't know enough about avahi to know whether it normally has a separate daemon running for each interface, and if so, whether that should apply to virtual interfaces.

I saw a similar error in some of the messages output by dhclient, where
it was trying to create a PID file for itself that incorporated the
virtual device name. Again, should it be running a separate instance of
the daemon for each virtual interface?


And from dhclient.strace.9272-ifconfig:

execve("/sbin/ifconfig", ["ifconfig", "eth0:0", "inet", "0", "up"], [/* 7 vars */]) = 0
[...]
socket(PF_FILE, SOCK_DGRAM, 0)          = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
access("/proc/net/if_inet6", R_OK)      = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 6
[...]
ioctl(4, SIOCSIFADDR, 0xbfdbeb00)       = -1 EACCES (Permission denied)
dup(2)                                  = 7
fcntl64(7, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0b000
_llseek(7, 0, 0xbfdbe498, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFADDR: Permission denied\n", 31) = 31
close(7)                                = 0
munmap(0xb7f0b000, 4096)                = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0:0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0xbfdbe9e8)      = -1 EACCES (Permission denied)
dup(2)                                  = 7
fcntl64(7, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0b000
_llseek(7, 0, 0xbfdbe438, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFFLAGS: Permission denied\n", 32) = 32
close(7)                                = 0
munmap(0xb7f0b000, 4096)                = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0:0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0xbfdbe9e8)      = -1 EACCES (Permission denied)
dup(2)                                  = 7
fcntl64(7, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0b000
_llseek(7, 0, 0xbfdbe438, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFFLAGS: Permission denied\n", 32) = 32
close(7)                                = 0
munmap(0xb7f0b000, 4096)                = 0
exit_group(-1)                          = ?


This call to ifconfig seems to be the source of the errors. I'm puzzled how you can get an EACCES error on a newly created socket while running as root, if SELinux or AppArmor isn't involved (as far as I'm aware).

If I run the above command directly:

# /sbin/ifconfig eth0:0 inet 0 up
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address

Sure enough, same results. Using 0.0.0.0 also fails, but substitute a
real IP address for the zero placeholder and we get:

# /sbin/ifconfig eth0:0 inet 192.168.0.210 up
# ifconfig
[...]
eth0:0    Link encap:Ethernet  HWaddr 00:04:61:4b:d1:33  
          inet addr:192.168.0.210  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:16 
[...]


It seems the EACCES error is incorrect and misleading, and the call should instead return an error indicating that the address is invalid.

I'm assuming dhclient is calling ifconfig in this fashion in order to
create the virtual device, and if successful, is going to go back after
obtaining an IP address via DHCP and update the interface.

I gather some internals in ifconfig or the kernel changed.

 -Tom


** Attachment added: "strace -ff -F -o /tmp/dhclient.strace dhclient eth0:0"
   http://launchpadlibrarian.net/24607967/dhclient.strace.zip

-- 
dhclient fails for virtual interfaces (IP aliases)
https://bugs.launchpad.net/bugs/351378
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dhcp3 in ubuntu.