Your message dated Mon, 16 Mar 2009 01:54:43 -0300 with message-id <1237179283.25707.25.ca...@abraxas> and subject line Fixed in current stable release has caused the Debian Bug report #116573, regarding net-tools: ifconfig using /prefixlen format fails 1st time, works 2nd to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 116573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116573 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: net-tools Version: 1.60-1 Severity: normal Howdy.. I noticed some odd behavior with ifconfig when setting an address and netmask. Because ifconfig supports it, I usually use the /prefixlen format instead of providing an explicit netmask: ifconfig lo:1 inet 10.2.0.1/16 up I've noticed that using that command results in an error the first time it is run: SIOCSIFNETMASK: Cannot assign requested address and the interface gets the address set, but it erroneously gets the default (classful) netmask: lo:1 Link encap:Local Loopback inet addr:10.2.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 If I immediately run the same ifconfig again, it completes without an error, and now the netmask is correct. However, if I use the 'inet NN netmask NN' form of the command, it works OK the first time, without any error messages: ifconfig lo:1 inet 10.2.0.1 netmask 255.255.0.0 up ifconfig lo:1 lo:1 Link encap:Local Loopback inet addr:10.2.0.1 Mask:255.255.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 I stared at the code for a while, and it looks like the problem is that the /prefixlen argument is causing ifconfig to try to set the netmask before it has set the address. If the interface was down beforehand (and had no address bound to it), this fails. When the command is run a second time, the interface is already up, so the early SIOCSIFNETMASK succeeds. The 'netmask 255.255.0.0' argument gets parsed after the address has been set, so it always succeeds. In ifconfig.c, the code flows as follows (abridged): if (ap->getmask) { // line 905 switch (ap->getmask(host, &sa, NULL)) { case -1: usage(); break; case 1: if (didnetmask) usage(); goterr = set_netmask(skfd, &ifr, &sa); didnetmask++; break; } } ap->input(0, host, &sa) < 0); // line 923 memcpy((char *) &ifr.ifr_addr, (char *) &sa, sizeof(struct sockaddr)); r = ioctl(fd, SIOCSIFADDR, &ifr); // 939 The set_netmask() probably needs to be deferred until after the SIOCSIFADDR, which probably means making a copy of 'sa' to hold the netmask during ap->input(), as the hostname lookup operations used there will probably trash the netmask portions of 'sa'. thanks, -Brian -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux luther.lothar.com 2.4.11 #1 Wed Oct 10 00:36:15 PDT 2001 i586 Locale: LANG=C, LC_CTYPE=C Versions of packages net-tools depends on: ii libc6 2.2.4-3 GNU C Library: Shared libraries an
--- End Message ---
--- Begin Message ---Package: net-tools Version: 1.60-22 Hi, While I can easily reproduce this bug in sarge and etch, in lenny seems to be working ok: # ifconfig dummy0 10.2.0.1/16 # ifconfig dummy0 dummy0 Link encap:Ethernet HWaddr ae:67:27:ac:89:6f inet addr:10.2.0.1 Bcast:10.2.255.255 Mask:255.255.0.0 # dpkg -s net-tools | grep ^Version: Version: 1.60-22 So, I close this bug now.
--- End Message ---
