Bug handling devices with weird names

Bug handling devices with weird names

[Martín Ferrari]

According to dev_valid_name (net/core/dev.c), a valid device name is
one that doesn't include spaces, slashes, and is not "." or "..". But
if I create a device called "foo:", some operations fail:

# ip link add name foo: type dummy
# ip link list foo:
155: foo:: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN ioctl(SIOCGIFXQLEN)
failed: No such device

    link/ether 92:7f:4d:0d:8f:57 brd ff:ff:ff:ff:ff:ff

Strace reveals that the problem occurs when executing an ioctl:

ioctl(4, SIOCGIFTXQLEN, {ifr_name="foo:", ???}) = -1 ENODEV (No such device)

ifconfig gets completely lost, of course:

$ /sbin/ifconfig foo:
foo:: error fetching interface information: Device not found

ioctl(5, SIOCGIFFLAGS, {ifr_name="foo:", ???}) = -1 ENODEV (No such device)


So, is this fixable or iproute should stop using the ioctl interface?
(dunno if netlink provides everything already)

-- 
Martín Ferrari

Re: Bug handling devices with weird names

[Stephen Hemminger]

On Thu, 8 Jul 2010 19:08:07 +0200
Martín Ferrari <martin.ferrari@gmail.com> wrote:

> According to dev_valid_name (net/core/dev.c), a valid device name is
> one that doesn't include spaces, slashes, and is not "." or "..". But
> if I create a device called "foo:", some operations fail:
> 
> # ip link add name foo: type dummy
> # ip link list foo:
> 155: foo:: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN ioctl(SIOCGIFXQLEN)
> failed: No such device
> 
>     link/ether 92:7f:4d:0d:8f:57 brd ff:ff:ff:ff:ff:ff
> 
> Strace reveals that the problem occurs when executing an ioctl:
> 
> ioctl(4, SIOCGIFTXQLEN, {ifr_name="foo:", ???}) = -1 ENODEV (No such device)
> 
> ifconfig gets completely lost, of course:
> 
> $ /sbin/ifconfig foo:
> foo:: error fetching interface information: Device not found
> 
> ioctl(5, SIOCGIFFLAGS, {ifr_name="foo:", ???}) = -1 ENODEV (No such device)
> 
> 
> So, is this fixable or iproute should stop using the ioctl interface?
> (dunno if netlink provides everything already)

Colons are used for the old IP aliasing. IP aliasing was an older way of handling
multiple addresses per interface, and is not necessary anymore. The syntax is
retained for legacy compatibility.

Re: Bug handling devices with weird names

[Martín Ferrari]

On Thu, Jul 8, 2010 at 19:27, Stephen Hemminger <shemminger@vyatta.com> wrote:
> Colons are used for the old IP aliasing. IP aliasing was an older way of handling
> multiple addresses per interface, and is not necessary anymore. The syntax is
> retained for legacy compatibility.

I know, but there is some code that is not accepting any valid name.
So i am able to create the device but then I cannot do some stuff. So
that's why I think this is a bug.


-- 
Martín Ferrari

Re: Bug handling devices with weird names

[Eric Dumazet]

Le vendredi 09 juillet 2010 à 12:04 +0200, Martín Ferrari a écrit :
> On Thu, Jul 8, 2010 at 19:27, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > Colons are used for the old IP aliasing. IP aliasing was an older way of handling
> > multiple addresses per interface, and is not necessary anymore. The syntax is
> > retained for legacy compatibility.
> 
> I know, but there is some code that is not accepting any valid name.
> So i am able to create the device but then I cannot do some stuff. So
> that's why I think this is a bug.
> 
> 

Update user land tools ?

No problem here :

# ip link add name foo: type dummy
# ip link list foo:
14: foo:: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN 
    link/ether e6:48:a9:57:d4:1f brd ff:ff:ff:ff:ff:ff
# ip link del foo:
# ip -V
ip utility, iproute2-ss100519

Re: Bug handling devices with weird names

[Martín Ferrari]

Hi,

On Fri, Jul 9, 2010 at 12:19, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Update user land tools ?
>
> No problem here :
>
> # ip link add name foo: type dummy
> # ip link list foo:
> 14: foo:: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
>    link/ether e6:48:a9:57:d4:1f brd ff:ff:ff:ff:ff:ff
> # ip link del foo:
> # ip -V
> ip utility, iproute2-ss100519

I am using the exact same version (from Debian), and I can also
reproduce it with fedora's iproute2-ss080725.
The kernels are 2.6.35-rc4 and 2.6.27, respectively.. Maybe your
version of iprout is patched as to not use ioctl?



-- 
Martín Ferrari

Re: Bug handling devices with weird names

[Eric Dumazet]

Le vendredi 09 juillet 2010 à 17:41 +0200, Martín Ferrari a écrit :
> Hi,
> 
> On Fri, Jul 9, 2010 at 12:19, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Update user land tools ?
> >
> > No problem here :
> >
> > # ip link add name foo: type dummy
> > # ip link list foo:
> > 14: foo:: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
> >    link/ether e6:48:a9:57:d4:1f brd ff:ff:ff:ff:ff:ff
> > # ip link del foo:
> > # ip -V
> > ip utility, iproute2-ss100519
> 
> I am using the exact same version (from Debian), and I can also
> reproduce it with fedora's iproute2-ss080725.
> The kernels are 2.6.35-rc4 and 2.6.27, respectively.. Maybe your
> version of iprout is patched as to not use ioctl?
> 
> 
> 

Well

I use the git version of iproute2, this includes following patch.

Nothing very exciting, but this avoids this ioctl() as you guessed ;)

You cannot ask old binaries to handle foo: devices very well, since
this special char (:) had special meaning in old days.

commit 62a5e0668e2920b7f09896abd884753255712a46
Author: Eric Dumazet <dada1@cosmosbay.com>
Date:   Fri Oct 23 06:25:53 2009 +0200

    ip: Support IFLA_TXQLEN in ip link show command
    
    We currently use an expensive ioctl() to get device txqueuelen, while
    rtnetlink gave it to us for free. This patch speeds up ip link operation
    when many devices are registered.

diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 267ecb3..cadc1a3 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -131,26 +131,31 @@ static void print_operstate(FILE *f, __u8 state)
 		fprintf(f, "state %s ", oper_states[state]);
 }
 
-static void print_queuelen(FILE *f, const char *name)
+static void print_queuelen(FILE *f, struct rtattr *tb[IFLA_MAX + 1])
 {
-	struct ifreq ifr;
-	int s;
-
-	s = socket(AF_INET, SOCK_STREAM, 0);
-	if (s < 0)
-		return;
-
-	memset(&ifr, 0, sizeof(ifr));
-	strcpy(ifr.ifr_name, name);
-	if (ioctl(s, SIOCGIFTXQLEN, &ifr) < 0) {
-		fprintf(f, "ioctl(SIOCGIFXQLEN) failed: %s\n", strerror(errno));
+	int qlen;
+
+	if (tb[IFLA_TXQLEN])
+		qlen = *(int *)RTA_DATA(tb[IFLA_TXQLEN]);
+	else {
+		struct ifreq ifr;
+		int s = socket(AF_INET, SOCK_STREAM, 0);
+
+		if (s < 0)
+			return;
+
+		memset(&ifr, 0, sizeof(ifr));
+		strcpy(ifr.ifr_name, (char *)RTA_DATA(tb[IFLA_IFNAME]));
+		if (ioctl(s, SIOCGIFTXQLEN, &ifr) < 0) {
+			fprintf(f, "ioctl(SIOCGIFXQLEN) failed: %s\n", strerror(errno));
+			close(s);
+			return;
+		}
 		close(s);
-		return;
+		qlen = ifr.ifr_qlen;
 	}
-	close(s);
-
-	if (ifr.ifr_qlen)
-		fprintf(f, "qlen %d", ifr.ifr_qlen);
+	if (qlen)
+		fprintf(f, "qlen %d", qlen);
 }
 
 static void print_linktype(FILE *fp, struct rtattr *tb)
@@ -253,7 +258,7 @@ int print_linkinfo(const struct sockaddr_nl *who,
 		print_operstate(fp, *(__u8 *)RTA_DATA(tb[IFLA_OPERSTATE]));
 		
 	if (filter.showqueue)
-		print_queuelen(fp, (char*)RTA_DATA(tb[IFLA_IFNAME]));
+		print_queuelen(fp, tb);
 
 	if (!filter.family || filter.family == AF_PACKET) {
 		SPRINT_BUF(b1);