Bug#656585: iproute: ip l fails with RTNETLINK message
On Mon, Jan 30, 2012 at 11:27:00PM +0400, Paul Fertser wrote: Hi, Andreas, i do not understand the reasoning for l2tp to be higher in the list than the link command. I think it's quite common for the more experienced ip users to use the l abbreviation instead of the full link command. Can you please explain why l2tp should be added before link and not after so the users of the more popular and older link command wouldn't have to reteach themselves to type more to avoid hitting the rarely needed l2tp command? The reason is the alphabetic sorting of commands, which has been the way commands usually gets expanded in iproute2. So my suggestion is to swap the lines to make link prioritised to retain the old behaviour. Please see http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff;h=5aa08f6bf4107f8aec43c0678466a314dbd0d054 -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656585: iproute: ip l fails with RTNETLINK message
Hi, Andreas, i do not understand the reasoning for l2tp to be higher in the list than the link command. I think it's quite common for the more experienced ip users to use the l abbreviation instead of the full link command. Can you please explain why l2tp should be added before link and not after so the users of the more popular and older link command wouldn't have to reteach themselves to type more to avoid hitting the rarely needed l2tp command? So my suggestion is to swap the lines to make link prioritised to retain the old behaviour. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656585: iproute: ip l fails with RTNETLINK message
On Mon, 30 Jan 2012 23:27:00 +0400 Paul Fertser fercer...@gmail.com wrote: Hi, Andreas, i do not understand the reasoning for l2tp to be higher in the list than the link command. I think it's quite common for the more experienced ip users to use the l abbreviation instead of the full link command. Can you please explain why l2tp should be added before link and not after so the users of the more popular and older link command wouldn't have to reteach themselves to type more to avoid hitting the rarely needed l2tp command? So my suggestion is to swap the lines to make link prioritised to retain the old behaviour. It was accident already fixed upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656585: iproute: ip l fails with RTNETLINK message
Package: iproute Version: 20120105-1 Severity: normal Dear Maintainer, ip l started failing a few weeks ago: [skynet](0) $ ip -o l RTNETLINK answers: No such file or directory Error talking to the kernel [skynet](1) $ oddly enough, ip link operates as expected: [skynet](1) $ ip -o link 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN \ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000\link/ether 00:25:22:bc:b1:00 brd ff:ff:ff:ff:ff:ff 3: e100: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000\ link/ether 00:07:e9:09:c5:23 brd ff:ff:ff:ff:ff:ff 4: irda0: NOARP,PROMISC,UP,LOWER_UP mtu 2048 qdisc pfifo_fast state UNKNOWN qlen 8\link/irda c3:20:b8:be brd ff:ff:ff:ff 5: wlan1: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000\link/ether 00:c0:ca:4f:e3:b2 brd ff:ff:ff:ff:ff:ff 6: tap0: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100\link/ether c6:34:c1:4a:ff:54 brd ff:ff:ff:ff:ff:ff [skynet](0) $ The failure seemed to be concurrent with the replacement of libnl-3 with libnl-3-200, though the current ip(8) doesn't appear to be linked to libnl at all. Perhaps the old one was? Regardless, ip l used to work exactly link ip link. Note that ip a, for instance, works like ip addr. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0+ (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iproute depends on: ii libc6 2.13-24 ii libdb5.1 5.1.29-1 Versions of packages iproute recommends: pn libatm1 none Versions of packages iproute suggests: pn iproute-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656585: iproute: ip l fails with RTNETLINK message
On Fri, 20 Jan 2012 05:12:33 -0500 nick black d...@qemfd.net wrote: Package: iproute Version: 20120105-1 Severity: normal Dear Maintainer, ip l started failing a few weeks ago: [skynet](0) $ ip -o l RTNETLINK answers: No such file or directory Error talking to the kernel [skynet](1) $ oddly enough, ip link operates as expected: [skynet](1) $ ip -o link 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN \ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000\link/ether 00:25:22:bc:b1:00 brd ff:ff:ff:ff:ff:ff 3: e100: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000\ link/ether 00:07:e9:09:c5:23 brd ff:ff:ff:ff:ff:ff 4: irda0: NOARP,PROMISC,UP,LOWER_UP mtu 2048 qdisc pfifo_fast state UNKNOWN qlen 8\link/irda c3:20:b8:be brd ff:ff:ff:ff 5: wlan1: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000\link/ether 00:c0:ca:4f:e3:b2 brd ff:ff:ff:ff:ff:ff 6: tap0: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100\link/ether c6:34:c1:4a:ff:54 brd ff:ff:ff:ff:ff:ff [skynet](0) $ The failure seemed to be concurrent with the replacement of libnl-3 with libnl-3-200, though the current ip(8) doesn't appear to be linked to libnl at all. Perhaps the old one was? Regardless, ip l used to work exactly link ip link. Note that ip a, for instance, works like ip addr. The command 'ip l' is now ambiguous. The addition of l2tp support added: ip l2tp ... which overlaps 'ip link' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
