Can we kill net-tools, please?

[Andrey Rahmatullin]

For the record:

# Broken Depends:
argus: argus-server [amd64 arm64 armel armhf hurd-i386 i386 mips mips64el mipsel powerpc ppc64el s390x]
bind9: bind9
bitlbee: bitlbee-common
chkrootkit: chkrootkit [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x]
debian-edu-config: debian-edu-config
dhcp-probe: dhcp-probe
diaspora-installer: diaspora-common
dtc-xen: dtc-xen
dyndns: dyndns
elog: elog
facter: facter
freedombox-setup: freedombox-setup
gnome-nettool: gnome-nettool [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x]
ifupdown: ifupdown [kfreebsd-amd64 kfreebsd-i386]
ifupdown-extra: ifupdown-extra
kvpnc: kvpnc
libguestfs: guestfsd [amd64 arm64 armel armhf i386 mipsel powerpc ppc64el s390x]
libnet-ifconfig-wrapper-perl: libnet-ifconfig-wrapper-perl
libsys-hostip-perl: libsys-hostip-perl
miniupnpd: miniupnpd [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x]
openvpn: openvpn [kfreebsd-amd64 kfreebsd-i386]
pmacct: pmacct [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x]
portsentry: portsentry
python3.5: libpython3.5-testsuite
rkhunter: rkhunter
sitesummary: sitesummary
snort: snort
sugar-presence-service-0.88: sugar-presence-service-0.88
systemtap: systemtap-server [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x]
systraq: systraq
tahoe-lafs: tahoe-lafs
tiger: tiger
tntnet: tntnet
util-vserver: util-vserver [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el s390x]
waagent: waagent
watcher: watcher-api

# Broken Build-Depends:
apr: net-tools
beanstalkd: net-tools
cctools: net-tools
cluster-glue: net-tools
gnutls28: net-tools
golang-github-jackpal-gateway: net-tools
heartbeat: net-tools
inetutils: net-tools
libapache-session-memcached-perl: net-tools
libaudio-mpd-perl: net-tools
libmemcached-libmemcached-perl: net-tools
libmongodb-perl: net-tools
libnet-arp-perl: net-tools
libnet-ifconfig-wrapper-perl: net-tools
libnet-route-perl: net-tools
libnet-sip-perl: net-tools
libpoe-component-client-mpd-perl: net-tools
libsys-hostip-perl: net-tools
openstack-trove: net-tools
openvpn: net-tools
python-tooz: net-tools
python2.7: net-tools
python3.5: net-tools
util-vserver: net-tools
virtuoso-opensource: net-tools

[Martín Ferrari]

ifconfig, route, etc...
Recently the net-tools maintainer has forked the abandoned net-tools
code base and started developing it again, after 15 years of stasis.

I am currently the Debian maintainer for net-tools, but note that I have
not forked, nor I am developing net-tools. Upstream got active again,
somehow.

With this post I want to encourage fellow maintainers to stop depending
on net-tools, which is obsolete software and has been replaced long ago
by iproute.
Can we stop shipping two network configuration CLI tools in the default
install?
net-tools has long been deprecated and should not have important
priority, for a start.

I agree wholeheartedly, and thought about retiring it in the past, but
it proved impossible at the time.

Maybe the output format change will make people finally switch to
something less awful.

[Steve Cotton]

Post by Martín Ferrari
I agree wholeheartedly, and thought about retiring it in the past, but
it proved impossible at the time.
Maybe the output format change will make people finally switch to
something less awful.

Given that the transition-freeze for Stretch was on Nov 5th, I think this
update should be kept out of Testing until Stretch has been released.

Steve

[Martín Ferrari]

Post by Steve Cotton
Given that the transition-freeze for Stretch was on Nov 5th, I think this
update should be kept out of Testing until Stretch has been released.

Actually, I made this update in September 2015. Yesterday I added a
debian/NEWS file to warn users about the possible breakage in scripts.

[Marco d'Itri]

Post by Martín Ferrari
I am currently the Debian maintainer for net-tools, but note that I have
not forked, nor I am developing net-tools. Upstream got active again,
somehow.

Thank you for your clarification.

I think that we have a consensus about this: can you switch to optional
priority for the next upload?
This way it will not be installed by default unless pulled in by
a dependency.

[Andrey Rahmatullin]

[...]
If by "broken" you wanted to list all packages that would be broken if
net-tools was dropped, then the lists are incomplete

It's output of `dak rm --no-action --rdep-check net-tools` on coccia,
not edited. The point about Recommends is valid though.

[Jonas Smedegaard]

Quoting Andrey Rahmatullin (2016-12-26 14:57:26)
[...]
If by "broken" you wanted to list all packages that would be broken if
net-tools was dropped, then the lists are incomplete: At least
sugar-presence-service (different from sugar-presence-service-0.88) is
missing in Depends:, and there are also packages recommending net-tools.


- Jonas

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2016-12-26 15:32:18)

Post by Jonas Smedegaard
Quoting Andrey Rahmatullin (2016-12-26 14:57:26)
[...]
If by "broken" you wanted to list all packages that would be broken if
net-tools was dropped, then the lists are incomplete: At least
sugar-presence-service (different from sugar-presence-service-0.88) is
missing in Depends:, and there are also packages recommending net-tools.

Oh, sugar-presence-service is irrelevant: Only a fallback-dependency.

- Jonas

[Guus Sliepen]

Post by Andrey Rahmatullin
ifupdown: ifupdown [kfreebsd-amd64 kfreebsd-i386]

Indeed, it's necessary for kFreeBSD where there's no iproute2. Luckily
it doesn't parse the output, but I guess I have to check carefully that
everything still works as expected.

[Andreas Henriksson]

Hello,
[...]

There's quite alot of cruft around still. I went through the
depends list and my notes/patches are attached.
(Can also be browsed at https://fatal.se/tmp/rm-net-tools/ for now.)

Help with filing bugs welcome. Some usertag to track them would
be nice.

I did not go through build-depends as you did not split them
between linux-any and !linux-any. I guess most of them falls
into either of these:
- build-depends on kfreebsd-any only
- used by testsuite that's unloved.
- leftover no longer needed.

I think we should consider downgrading the priority of net-tools
in Buster.
Potentially a lintian warning for anything that depends on
net-tools (on linux-any atleast) could be a useful motivator
to highlight that maintainers should move away from it.

On the BSD side it would be nice if something like
https://github.com/luigirizzo/netlink-freebsd
could happen so we can get if of the need to carry
net-tools codepaths to support bsd.

Regards,
Andreas Henriksson

[Jochen Sprickerhof]

bitlbee-common.config uses netstat.
Dependency is thus valid. Could be ported to 'ss' from iproute2.

Already discussed here:

https://github.com/bitlbee/bitlbee/pull/91

Cheers Jochen

[Ben Hutchings]

On Mon, 2016-12-26 at 19:31 +0100, Andreas Henriksson wrote:
[bind9.patch]

--- bind9-9.10.3.dfsg.P4/debian/bind9.init 2016-05-04 01:40:36.000000000 +0200
+++ bind9-9.10.3.dfsg.P4.new/debian/bind9.init 2016-12-26 16:38:27.153860242 +0100
@@ -33,7 +33,7 @@
     else
  IFCONFIG_OPTS=""
     fi
-    if [ -z "$(/sbin/ifconfig $IFCONFIG_OPTS)" ]; then
+    if [ -x /sbin/ifconfig ] && [ -z "$(/sbin/ifconfig $IFCONFIG_OPTS)" ]; then
        #log_action_msg "No networks configured."
        return 1

This check currently succeeds even if only the loopback interface is
up, and it should never be taken down. So I think you could take out
the check entirely.

Ben.

[Geert Stappers]

ifconfig, route, etc...

From https://packages.debian.org/stretch/arm64/net-tools/filelist

* /bin/netstat
* /sbin/ifconfig
* /sbin/ipmaddr
* /sbin/iptunnel
* /sbin/mii-tool
* /sbin/nameif
* /sbin/plipconfig
* /sbin/rarp
* /sbin/route
* /sbin/slattach
* /usr/sbin/arp

Recently the net-tools maintainer has forked the abandoned net-tools
code base and started developing it again, after 15 years of stasis.
As a design choice he has changed the output of most commands, hence
breaking many scripts parsing their output.
With this post I want to encourage fellow maintainers to stop depending
on net-tools, which is obsolete software and has been replaced long ago
by iproute.
Can we stop shipping two network configuration CLI tools in the default
install?

Who confirms that the other one is `ip` from the iproute2 package.

net-tools has long been deprecated and should not have important
priority, for a start.

Without a replacement plan will net-tools survive some more releases.


Thing what Andreas Henriksson is doing
in https://lists.debian.org/debian-devel/2016/12/msg00619.html
providing patches how to get rit of net-tools,
is what will make the killing of net-tools more easy.

Merry Christmas.

Groeten
Geert Stappers

[Andreas Henriksson]

Hello,

Post by Geert Stappers
Thing what Andreas Henriksson is doing
in https://lists.debian.org/debian-devel/2016/12/msg00619.html
providing patches how to get rit of net-tools,
is what will make the killing of net-tools more easy.

I personally don't beleive in trying to patch us out of this mess
because it's chasing a moving goal. New crap gets uploaded to the
archive every day.

What I was trying to show was that the existing reverse dependencies of
net-tools are either not using it or are trivial to port, the real
question is if it makes any sense to spend time porting them?
Many things net-tool is used for is either useless or broken code.
Getting rid of it would be a service to our users.
Several times it's likely useful to get rid of the entire obsolete
package (that the package uses net-tools is just one symptom of
its outdatedness).

A better way than chasing a moving goal is in my opinion to declare
intent and then go in for the kill (taking all remaining rdeps with it).
Given not even the net-tools maintainer seems to suggest you should not
be using net-tools, I think we in this thread has declared that:

If you want your package to be part of Buster then make sure it doesn't
depend (solely) on net-tools!!!

(Atleast we should consider downgrading the priority so it only gets
installed when pulled in via dependency or manually installed.)

Regards,
Andreas Henriksson

[Andrew Shadura]

On 27 Dec 2016 08:40, "Andreas Henriksson" <***@fatal.se> wrote:

Hello,

Post by Geert Stappers
Thing what Andreas Henriksson is doing
in https://lists.debian.org/debian-devel/2016/12/msg00619.html
providing patches how to get rit of net-tools,
is what will make the killing of net-tools more easy.

I personally don't beleive in trying to patch us out of this mess
because it's chasing a moving goal. New crap gets uploaded to the
archive every day.

What I was trying to show was that the existing reverse dependencies of
net-tools are either not using it or are trivial to port, the real
question is if it makes any sense to spend time porting them?
Many things net-tool is used for is either useless or broken code.
Getting rid of it would be a service to our users.
Several times it's likely useful to get rid of the entire obsolete
package (that the package uses net-tools is just one symptom of
its outdatedness).

A better way than chasing a moving goal is in my opinion to declare
intent and then go in for the kill (taking all remaining rdeps with it).
Given not even the net-tools maintainer seems to suggest you should not
be using net-tools, I think we in this thread has declared that:

If you want your package to be part of Buster then make sure it doesn't
depend (solely) on net-tools!!!

(Atleast we should consider downgrading the priority so it only gets
installed when pulled in via dependency or manually installed.)


While I can certainly agree parsing net-tools output isn't a good idea,
please stop suggesting we should remove the package from Debian. It is
still useful and many people myself included use it.

[Wookey]

While I can certainly agree parsing net-tools output isn't a good idea, please
stop suggesting we should remove the package from Debian. It is still useful
and many people myself included use it.

Right, I use it most days. For those of us of a certain vintage this
is the networking tool we know. The chap who gave a talk at the UK
miniconf about updated functionality in /etc/network/interfaces and
ifconfig and friends got rapturous applause, so I'm not the only one
that finds this useful.

If we are supposed to change to something newer these days, a pointer
to a 'conversion' document would be nice. I am (vaguely) aware of
something caled 'ip' which does a similar job but have no idea how to
use it.

Like Andrew I don't like the tone of these 'get rid of this crap'
messages. It may not be your tool of choice, but it is some people's
(probbly quite a lot of people still) and I'm very happy that it's
there by default as networking-furtling is something one is often
doing on a bare system. If there is a desire to change the default
package I'd like to see a little more discussion about that.

Wookey

[Russell Stuart]

Post by Wookey
If we are supposed to change to something newer these days

We've been discussing doing that for 8 years now:

https://lists.debian.org/debian-devel/2009/03/msg00780.html

Post by Wookey
a pointer to a 'conversion' document would be nice.

https://wiki.debian.org/NetToolsDeprecation

(There are links on that page).

It's not a changeover document, but as I said earlier my favourite
resource is: http://baturin.org/docs/iproute2/

Post by Wookey
Like Andrew I don't like the tone of these 'get rid of this crap'
messages.

The issue is ifconfig was the tool up until Linux 2.2, but then the
kernel developers favoured iproute2. The kernel has moved on and they
maintained iproute2, but ifconfig has remained static. It now doesn't
support the most mundane things like multiple IP addresses per
interface, let alone multi routing takes, routing rules and the various
tunnelling protocols, or virtual ethernet devices needed by containers
to name but a few.

I don't know whether "crap" is the right word, but it is certainly
baggage from a bygone era. "Baggage" here means that if we are nice to
our users (ie, Debian sysadmins), we should not force them to know two
tools. We only have one complete tool set available: iproute2. This means at the very least ifconfg can not appear in any conffile, nor can it really appear in documented shell scripts like dhclient-script.

Unfortunately this pain does not end at ifconfig. iwconfig has suffered
the same fate. If you want to use Linux wireless in anger, then that's
the tool you have to use. It's doubly annoying because of the "Do NOT
screenscrape this tool, we don't consider its output stable" warning it
issues. It's not like you have much of a choice any more.

[Theodore Ts'o]

Post by Russell Stuart
I don't know whether "crap" is the right word, but it is certainly
baggage from a bygone era. "Baggage" here means that if we are nice to
our users (ie, Debian sysadmins), we should not force them to know two
tools. We only have one complete tool set available: iproute2. This means at the very least ifconfg can not appear in any conffile, nor can it really appear in documented shell scripts like dhclient-script.

This is really going to be a generational thing. For those of us who
started programming in the BSD 4.x days (my first kernel programming
experience was with BSD 4.3), ifconfig and netstat are still the tools
that I use every day, and I only use the iproute2 tools in the
*extremely* rare circumstances that I need to do something exotic
which is only supported by the iproute2 tools.

This probably makes me a bad person, but it's how I operate, because I
grew up using the ifconfig and netstat. From my perspective, it's the
height of arrogance to decide that we're being "kind" to Debian system
administrators by forcibly taking away the traditional BSD tools, and
forcing them to learn a new interface, just because we think it's the
right and moral choice for system administrators.

If you want to deprecate ifconfig and netstat, the kindest way to do
that is to (a) remove all of the progammatic dependencies on ifconfig
and netstat output, (b) add hints to ifconfig and netstat which look
at how they were invoked and adds a one-line hint:

Ifconfig has been deprecated; you should probably use "ip a show
dev lo" instad of the shorter and more convenient "ifconfig lo"
because debian is going to arrogantly make "ifconfig" go away in
the next stable release, because we believe this is in your best
interests, and Debian always has the priorities of our users at heart.

OK, you can remove the last half, but keep in mind there are plenty of
people who aren't using the exotic features provided by iproute2, and
are very happy using the more convenient and shorter BSD-style
commands. If you're going to remove it _becase_, the least you can do
is to make the transition a bit more gentle.

Regards,

- Ted

[Andrey Rahmatullin]

Post by Theodore Ts'o
Ifconfig has been deprecated; you should probably use "ip a show
dev lo" instad of the shorter and more convenient "ifconfig lo"

... and often wrong

Post by Theodore Ts'o
OK, you can remove the last half, but keep in mind there are plenty of
people who aren't using the exotic features provided by iproute2

... like two IPs on one iface.

[Gabor Gombas]

Post by Andrey Rahmatullin

Post by Theodore Ts'o
OK, you can remove the last half, but keep in mind there are plenty of
people who aren't using the exotic features provided by iproute2

... like two IPs on one iface.

Actually, that is only a problem if you re-use labels (including empty
ones). If you give distinct labels to all IPs, then ifconfig has no
trouble displaying/manipulating the addresses.

The issue is really at a lower level - ioctl() vs. netlink (*). Anything
which uses the SIOCGIF*/SIOCSIF* ioctl()s will have the same limitations
as ifconfig. So if you _really_ care about having multiple IPs sharing
the same label, then replacing the ifconfig command with ip is just the
beginning - you'll need to find all applications and libraries which use
the ioctl() interface, and replace/re-write them to use netlink instead.
The problem is, using netlink is more complicated than using ioctl(), so
that may not be a simple task.

If you don't have any legacy applications which would use ioctl()s, then
you're lucky. Otherwise, assigning unique labels to IP addresses could
turn out to be simpler.

Gabor

(*) This is all about IPv4, IPv6 is different

[Toni Mueller]

Hi,

I'm confused...

Post by Andrey Rahmatullin

Post by Theodore Ts'o
Ifconfig has been deprecated; you should probably use "ip a show
dev lo" instad of the shorter and more convenient "ifconfig lo"

... and often wrong

The BSD ifconfig can do this with ease, and since ages, too. Why is
the Linux ifconfig _so_ different? Forking for the sake of it?


Eg adding an IPv6 address:
# ifconfig em0 inet6 address alias

and removing it:
# ifconfig em0 inet6 address -alias


Just asking.


Cheers,
--Toni++

PS: http://man.openbsd.org/OpenBSD-current/man8/ifconfig.8

[Tom H]

Post by Toni Mueller

Post by Andrey Rahmatullin

Post by Theodore Ts'o
Ifconfig has been deprecated; you should probably use "ip a show
dev lo" instad of the shorter and more convenient "ifconfig lo"

... and often wrong

The BSD ifconfig can do this with ease, and since ages, too. Why is
the Linux ifconfig _so_ different? Forking for the sake of it?

Is there any relationship between current ifconfig on Linux and the
BSDs, other than the name? I don't think so. The BSDs have continued
to develop ifconfig, adding many features and options.

Post by Toni Mueller
# ifconfig em0 inet6 address alias
# ifconfig em0 inet6 address -alias

On Linux, you can do the same with ipv6

ifconfig eth0 inet6 add ipv6_address

but for ipv4 you have to label the NIC as an alias

ifconfig eth0:0 ipv4_address

You can use

ip a sh lo (if you have bash-completion installed, "a<tab>" will
complete to "addr" and "sh<tab>" will complete to "show")

instead of "ip a show dev lo" above (still longer than "ifc<tab> though).

[Andrey Rahmatullin]

Post by Tom H
You can use
ip a sh lo (if you have bash-completion installed, "a<tab>" will
complete to "addr" and "sh<tab>" will complete to "show")
instead of "ip a show dev lo" above (still longer than "ifc<tab> though).

OTOH "ip a" is not longer than that.

[Tom H]

Post by Andrey Rahmatullin

Post by Tom H
You can use
ip a sh lo (if you have bash-completion installed, "a<tab>" will
complete to "addr" and "sh<tab>" will complete to "show")
instead of "ip a show dev lo" above (still longer than "ifc<tab> though).

OTOH "ip a" is not longer than that.

Sure. But I was replying to displaying "ip a" for a specific NIC.

[Alexey Salmin]

Post by Tom H

Post by Toni Mueller

Post by Andrey Rahmatullin

Post by Theodore Ts'o
Ifconfig has been deprecated; you should probably use "ip a show
dev lo" instad of the shorter and more convenient "ifconfig lo"

... and often wrong

The BSD ifconfig can do this with ease, and since ages, too. Why is
the Linux ifconfig _so_ different? Forking for the sake of it?

Is there any relationship between current ifconfig on Linux and the
BSDs, other than the name? I don't think so. The BSDs have continued
to develop ifconfig, adding many features and options.

Right, but this raises all kinds of questions like "Is it possible to
improve the ifconfig on Linux to catch up with the BSD version? And
even with ip?". Networking standards and protocols are
platform-independent, maintaining a Unix-wide interface to do the
basic networking stuff sounds like a reasonable thing to do. At this
time ifconfig seems to be the answer, no ip is visible on the BSDs
horizon.

I realize that net-tools version is long gone, but what about the GNU
inetutils one? It's supported and is not Linux-specific. Maybe a new
default implementation of ifconfig should be provided rather than
simply discarding one from a basic install. Another question is
whether you absolutely have to switch to netlink to have a reasonable
ifconfig implementation or ioctl is still acceptable (I don't know).

Alexey

[Adam Borowski]

At this time ifconfig seems to be the answer, no ip is visible on the BSDs
horizon.

There's a patch set to add netlink to FreeBSD (I don't know how complete or
likely to be merged it is).

It even has <linux/> in the public headers :)


Meow!

[Vincent Bernat]

Post by Alexey Salmin
I realize that net-tools version is long gone, but what about the GNU
inetutils one? It's supported and is not Linux-specific. Maybe a new
default implementation of ifconfig should be provided rather than
simply discarding one from a basic install. Another question is
whether you absolutely have to switch to netlink to have a reasonable
ifconfig implementation or ioctl is still acceptable (I don't know).

The information you can gather from ioctl and files are incomplete. You
need to use netlink. Moreover, netlink is far more efficient (compare
"netstat -an" and "ss -an").

[Vincent Bernat]

Post by Tom H

Post by Toni Mueller
The BSD ifconfig can do this with ease, and since ages, too. Why is
the Linux ifconfig _so_ different? Forking for the sake of it?

Is there any relationship between current ifconfig on Linux and the
BSDs, other than the name? I don't think so. The BSDs have continued
to develop ifconfig, adding many features and options.

The BSDs maintain ifconfig (and route, netstat, arp) in parity with the
kernel. That's something that didn't happen with Linux for various
reasons (different teams, output compatibility to be maintained, dead
upstream, portability requirement).

[Lars Wirzenius]

Post by Theodore Ts'o
OK, you can remove the last half, but keep in mind there are plenty of
people who aren't using the exotic features provided by iproute2, and
are very happy using the more convenient and shorter BSD-style
commands. If you're going to remove it _becase_, the least you can do
is to make the transition a bit more gentle.

For stretch+1, what I'd like to see is a tool that a) works b) has
output that's nice for a human to read and c) has output that can be
easily processed by programs. None of the current tools comes anywhere
near. Bonus points if the command line syntax is reasonbly nice, and
the manpage doesn't start with a BNF syntax description.

Of, you know, I can continue to mostly ignore things since I'm in the
vast majority that doesn't do or need complicated network setups.

[Bernd Zeimetz]

Post by Lars Wirzenius
For stretch+1, what I'd like to see is a tool that a) works b) has
output that's nice for a human to read and c) has output that can be
easily processed by programs. None of the current tools comes anywhere
near. Bonus points if the command line syntax is reasonbly nice, and
the manpage doesn't start with a BNF syntax description.

In my opinion ip provides all the things you are mentioning - what are
you missing? with -o as option the output is rather easy to parse.

[Lars Wirzenius]

Post by Bernd Zeimetz
In my opinion ip provides all the things you are mentioning - what are
you missing? with -o as option the output is rather easy to parse.

I find ip's output hard to read. I have to take time to visually parse
it every time, I can't just skim it. The ip -o output seems parseable,
but no easily extensible (I'd prefer something like YAML instead).

[Ian Jackson]

Post by Lars Wirzenius
I find ip's output hard to read. I have to take time to visually parse
it every time, I can't just skim it. The ip -o output seems parseable,
but no easily extensible (I'd prefer something like YAML instead).

ip's output is certainly not easy to parse.

if (m{^\d+\:\s*(\S+)\s+$afstr\s+([0-9a-z.:]+)(?:/\d+)?\s}) {
+ my $rhs=$'; #';
my $outline = "$ip $1 $2";
+ # "ip -o addr show" has a ridiculous output format. In
+ # particular, it mixes output keywords which introduce
+ # values with ones which don't, and there seems to be
+ # no way to tell without knowing all the possible
+ # keywords. We hope that before the \ there is nothing
+ # which contains arbitrary text (specifically, which
+ # might be `tentative' other than to specify IPv6
+ # tentativeness). We have to do this for IPv6 only
+ # because in the IPv4 output, the interface name
+ # appears here!
+ next if $ip==6 && $rhs=~m{[^\\]* tentative\s};
$reported{$outline} .= "y";

from

http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=secnet.git;a=blob;f=polypath-interface-monitor-linux;h=0bb9b7e54100cb8eed7d7aae30385a3cba623487;hb=HEAD#l79

[Russ Allbery]

Post by Bernd Zeimetz

Post by Lars Wirzenius
For stretch+1, what I'd like to see is a tool that a) works b) has
output that's nice for a human to read and c) has output that can be
easily processed by programs. None of the current tools comes anywhere
near. Bonus points if the command line syntax is reasonbly nice, and
the manpage doesn't start with a BNF syntax description.

In my opinion ip provides all the things you are mentioning - what are
you missing? with -o as option the output is rather easy to parse.

It certainly doesn't provide a man page that doesn't start with a BNF
syntax description. The iproute2 documentation is awful.

Also, this is not at all easy to parse:

# ip -o address
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
3: wlan0 inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0\ valid_lft 598191sec preferred_lft 598191sec
3: wlan0 inet6 fe80::a288:69ff:fe31:2b62/64 scope link \ valid_lft forever preferred_lft forever

The fields aren't labeled, you have to make a bunch of assumptions about
ordering, the backslash thing is just completely bizarre and makes the
parsing way harder (see the "lo\" on the first line)... this is really
rather dire.

And the output (without -o) is less human-readable than the current
ifconfig output, although neither of them are going to win any awards.
ifconfig at least understands how to use whitespace to try to present
data, which ip definitely does not, but both have a lot of cryptic
abbreviations and provide a lot of uninteresting noise in the default
output format that's only useful in unusual situations.

ip address also has one of the worst output UI decisions I've ever seen,
namely this line:

inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0

specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command, used nowhere else in networking, and confusing to anyone who has
prior networking experience.

This is all probably a matter of opinion, but Lars is definitely not alone
in considering all this stuff to be quite bad.

[Sandro Tosi]

Post by Russ Allbery
# ip -o address
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
3: wlan0 inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0\ valid_lft 598191sec preferred_lft 598191sec
3: wlan0 inet6 fe80::a288:69ff:fe31:2b62/64 scope link \ valid_lft forever preferred_lft forever
The fields aren't labeled, you have to make a bunch of assumptions about
ordering, the backslash thing is just completely bizarre and makes the
parsing way harder (see the "lo\" on the first line)... this is really
rather dire.

i recently had to parse it (in particular, `ip -s -s -s -s -o link
show up`) it's not that hard: split by \, remove the first line,
remove any spurious other lines, then parse by line pairs: the first
is the headers, the second the values, and so on (kinda OT but yeah a
YAML/JSON/anything would have been better, but it's doable)

[Christian Seiler]

Post by Russ Allbery
It certainly doesn't provide a man page that doesn't start with a BNF
syntax description. The iproute2 documentation is awful.

Ack.

Post by Russ Allbery
# ip -o address
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
3: wlan0 inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0\ valid_lft 598191sec preferred_lft 598191sec
3: wlan0 inet6 fe80::a288:69ff:fe31:2b62/64 scope link \ valid_lft forever preferred_lft forever
The fields aren't labeled, you have to make a bunch of assumptions about
ordering, the backslash thing is just completely bizarre and makes the
parsing way harder (see the "lo\" on the first line)... this is really
rather dire.

Ack.

Post by Russ Allbery
And the output (without -o) is less human-readable than the current
ifconfig output, although neither of them are going to win any awards.
ifconfig at least understands how to use whitespace to try to present
data, which ip definitely does not, but both have a lot of cryptic
abbreviations and provide a lot of uninteresting noise in the default
output format that's only useful in unusual situations.

I personally hate both outputs as well, but vastly prefer ip over
the traditional ifconfig output. (The new ifconfig appears to have
gotten better, after just trying it for the first time.)

Post by Russ Allbery
ip address also has one of the worst output UI decisions I've ever seen,
inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command,

Nope, that's RFC 4632, Section 3.1, where that was introduced
first, see
https://tools.ietf.org/html/rfc4632#section-3.1

And at least I find it vastly superior to the traditional netmask
notation - if I see /29 I can immediately deduce that there are
three bits available for the host part, so with broadcast address
subtracted that gives me 6 hosts in that range. The corresponding
netmask is 255.255.255.248 - that is far harder to process
mentally for me. Add in IPv6 and there's a reason why traditional
netmasks have never been used there.

That said: to me it would have been much more logical to count
the bits that are zero in the netmask (as that defines the size
of the network directly) than the bits that are one, so I believe
there was room for improvement when that syntax was introduced.
Unfortunately that ship has now sailed...

Regards,
Christian

[Russ Allbery]

Post by Christian Seiler

Post by Russ Allbery
ip address also has one of the worst output UI decisions I've ever seen,
inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command,

Nope, that's RFC 4632, Section 3.1, where that was introduced
first, see
https://tools.ietf.org/html/rfc4632#section-3.1

No, I'm not talking about CIDR notation, which of course is long-standing
and familiar. I'm talking about randomly appending a CIDR suffix to
something that is obviously *not* the base for that CIDR block.

In other words, 192.168.0.0/24 is fine. The problem is with deciding to
merge two completely different things (a CIDR network specification, and
an individual IP address) in this weird hybrid notation that, by RFC 4632,
would mean the network starting at 192.168.0.195 and extending for a /24.
Which is a nonsensical specification.

IIRC, this was done in ip to "save space" instead of using the natural
expression, namely:

192.168.0.195 net 192.168.0.0/24

Saving space in UI output intended for humans by introducing new notation
is almost never a good idea.

It's possible that some other tool has abused CIDR notation in this way,
but ip is still the only place I ever see it. It's definitely not common.

[Samuel Thibault]

Post by Russ Allbery

Post by Russ Allbery
specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command,

It's possible that some other tool has abused CIDR notation in this way,
but ip is still the only place I ever see it. It's definitely not common.

/etc/network/interfaces uses it too.

Samuel

[Tollef Fog Heen]

]] Russ Allbery

Post by Russ Allbery
It's possible that some other tool has abused CIDR notation in this way,
but ip is still the only place I ever see it. It's definitely not common.

I picked a few arbitrary networking platforms:

From
http://www.juniper.net/techpubs/software/junos-es/junos-es93/junos-es-jseries-quick-start/basic-connection-and-configuration-with-the-cli.html:

root# set interfaces ge-0/0/0 unit 0 family inet address 1.1.2.31/24
[***@MikroTik] ip address> add address=10.10.10.1/24 interface=ether2

From
http://stackoverflow.com/questions/11225681/interface-configuration-in-arista-eos :

localhost(config-if-Eth1)# ip address 172.16.204.4/24

(Arista's configuration manual is a PDF, hence linking to a random
stackoverflow description.)

From
http://dev-random.net/d-link-dgs-3324sr-management-ip-address-configuration/ :

config ipif System ipaddress 192.168.2.2/24

Cisco does it differently, and I'm sure some others do too, but the
$ip/prefixlen notation is pretty common in the networking world at
least.

[Russ Allbery]

Post by Tollef Fog Heen
]] Russ Allbery

Post by Russ Allbery
It's possible that some other tool has abused CIDR notation in this way,
but ip is still the only place I ever see it. It's definitely not common.

Meh. Okay, thanks, I'm apparently just not well-informed about this and
will have to get over it.

[Vincent Bernat]

Post by Russ Allbery
No, I'm not talking about CIDR notation, which of course is long-standing
and familiar. I'm talking about randomly appending a CIDR suffix to
something that is obviously *not* the base for that CIDR block.
In other words, 192.168.0.0/24 is fine. The problem is with deciding to
merge two completely different things (a CIDR network specification, and
an individual IP address) in this weird hybrid notation that, by RFC 4632,
would mean the network starting at 192.168.0.195 and extending for a /24.
Which is a nonsensical specification.
IIRC, this was done in ip to "save space" instead of using the natural
192.168.0.195 net 192.168.0.0/24
Saving space in UI output intended for humans by introducing new notation
is almost never a good idea.
It's possible that some other tool has abused CIDR notation in this way,
but ip is still the only place I ever see it. It's definitely not common.

It's quite common. For example, on JunOS, this is also how IP addresses
are expressed. This is quite like "192.168.0.195 netmask 255.255.255.0",
except this is "192.168.0.195 prefixlen 24" which then can be
abbrieviated to "192.168.0.195/24". You know this is not a prefix
because the prefix is "192.168.0.0/24" (and the prefix length is less
than 31).

This is also how it works with IPv6 (even on Cisco).

[Russ Allbery]

I believe that is a mis-interpretation of that RFC. The examples are
all network addresses, but I don't think there is anything there that
restricts the CIDR notation only to that class of IPv4 addresses.
FWIW, the notation is much older and has been used for IPv4 address +
mask long before that RFC or the introduction of the "ip" tool. I am
unable to find the original first use, but here's at least one older
https://tools.ietf.org/html/rfc2373#section-2.3
"The text representation of IPv6 address prefixes is similar to the
way IPv4 addresses prefixes are written in CIDR notation. An IPv6
ipv6-address/prefix-length
"
The IPv4 CIDR notation was obviously already well enough known to be
used to explain the new IPv6 notation. I believe the above paragraph
would be very confusing, to the point of not making sense at all, if the
IPv4 notation was known to be used only for network address +
prefix-length.

Yeah, I'm clearly incorrect about this, and I apologize for the noise (and
appreciate all the good information). I'm also now remembering, to my
embarassment, that I'd already ranted about and been corrected on this
before and then didn't retain that. I suppose that shows how little I
deal with the ip tool. (I probably should alias ifconfig to something
that reminds me to use ip to force myself to do the mental conversion.)

I apparently haven't gotten over my initial confusion when I ran into it
for the first time, but that isn't a good idea not to use the notation,
and I do see the merits. Hopefully this time I'll remember and learn and
not forget the whole conversation again!

[Bjørn Mork]

Post by Russ Allbery

Post by Christian Seiler

Post by Russ Allbery
ip address also has one of the worst output UI decisions I've ever seen,
inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command,

Nope, that's RFC 4632, Section 3.1, where that was introduced
first, see
https://tools.ietf.org/html/rfc4632#section-3.1

No, I'm not talking about CIDR notation, which of course is long-standing
and familiar. I'm talking about randomly appending a CIDR suffix to
something that is obviously *not* the base for that CIDR block.
In other words, 192.168.0.0/24 is fine. The problem is with deciding to
merge two completely different things (a CIDR network specification, and
an individual IP address) in this weird hybrid notation that, by RFC 4632,
would mean the network starting at 192.168.0.195 and extending for a /24.
Which is a nonsensical specification.

I believe that is a mis-interpretation of that RFC. The examples are
all network addresses, but I don't think there is anything there that
restricts the CIDR notation only to that class of IPv4 addresses.

FWIW, the notation is much older and has been used for IPv4 address +
mask long before that RFC or the introduction of the "ip" tool. I am
unable to find the original first use, but here's at least one older
reference (from 1998):
https://tools.ietf.org/html/rfc2373#section-2.3

"The text representation of IPv6 address prefixes is similar to the
way IPv4 addresses prefixes are written in CIDR notation. An IPv6
address prefix is represented by the notation:

ipv6-address/prefix-length
"


The IPv4 CIDR notation was obviously already well enough known to be
used to explain the new IPv6 notation. I believe the above paragraph
would be very confusing, to the point of not making sense at all, if the
IPv4 notation was known to be used only for network address +
prefix-length.

Post by Russ Allbery
IIRC, this was done in ip to "save space" instead of using the natural
192.168.0.195 net 192.168.0.0/24

"save space" by removing redundant information was pretty much the only
reason to introduce the prefix-length, wasn't it? Well, maybe not... It
also prevents anyone from trying to configure a netmask with holes in
it.

But if you always had to include the redundant network address, then you
wouldn't save any space. What would the point of the CIDR notation be
then? You might as well use one of the mask notations:

192.168.0.195 0.0.0.255
192.168.0.195 255.255.255.0

They are just as short (and commonly used, just like 192.168.0.195/24 is)

Post by Russ Allbery
Saving space in UI output intended for humans by introducing new notation
is almost never a good idea.

True. But in this case it makes the result easier to read by removing
duplicate information. That is good.


Bjørn

[Peter Samuelson]

[Russ Allbery]

Post by Russ Allbery
ip address also has one of the worst output UI decisions I've ever seen,
inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command, used nowhere else in networking, and confusing to anyone who has
prior networking experience.

Huh ... I have exactly the opposite reaction. To me, this notation is
_far_ more readable than dotted quads, e.g., I know exactly what a /27
is, but it takes awhile to work out 255.255.255.224. I don't think
this notation originated in iproute2, I've seen it in lots of other
contexts.

(Yes, it's a bit annoying to parse this, as you have to split on /
after splitting on whitespace, but to me that's a small price to pay.)

In fact in my interfaces(5) files I always use 'address a.b.c.d/nn' and
no 'subnet' line. So tidy. (ifupdown added this feature in wheezy.)

[Wookey]

Post by Russ Allbery
# ip -o address
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
3: wlan0 inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0\ valid_lft 598191sec preferred_lft 598191sec
3: wlan0 inet6 fe80::a288:69ff:fe31:2b62/64 scope link \ valid_lft forever preferred_lft forever
The fields aren't labeled,
And the output (without -o) is less human-readable than the current
ifconfig output,

Yeah I think that mess is why I've never felt any need to move away
from ifconfig. I ran ip something a few times, went 'huh?' at the cryptic
output and stayed with the rather more civilised /sbin/ifconfig.

So it seem that the output does actually label things, but the things
and labels look exactly the same. Would some colons really have hurt
too much?

i.e. mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
is really
mtu: 1500 qdisc: mq state: UP mode: DEFAULT group: default qlen: 1000

Anyone think the latter is a tad clearer? I still don't know what a
qdisc is or a default group, but it's a lot easier to find things I do
recognise. Before this discussion I just saw it as a mysterious jumble
of 10 things (after a set of things in CAPITALS that were somewhat
mysterious too (what's a LOWER_UP, I wonder) - who knows what it might
mean.

The choice to use the former rather than the latter is presumably why
people who saw ifconfig's rather more civilised output first have not
shifted in 15 years. Some people are forcefully pointing out in this
thread that ifconfig is _wrong_, but I can't say I've ever noticed
enough to care. It's fine for normal, simple, network config where the
fanciest thing one ever does is create a bridge or mess with the
masquerading/nat tables.

Anyway, this discussion has produced some helpful links (cheers) which
I, and no doubt others, will peruse. (I do at least not have to prefix
ip with /sbin/, which is nice, so it's not all worse).

But I reckon this is a little lesson in UI design and adoption, which
it's worth remembering.

Wookey

[Vincent Bernat]

I still don't know what a qdisc is or a default group, but it's a lot
easier to find things I do recognise. Before this discussion I just
saw it as a mysterious jumble of 10 things (after a set of things in
CAPITALS that were somewhat mysterious too (what's a LOWER_UP, I
wonder) - who knows what it might mean.

iproute is developed in lockstep with the kernel (you can use all the
features from the kernel X.Y if you have at least version X.Y) and
exposes all the information the kernel knows about an interface.

LOWER_UP is a flag (like UP, BROADCAST), hence the use of upper case. It
means that the lower interface is up. For a physical interface, it means
the driver says the interface is operatively up (while UP is an
administrative flag). For a virtual interface, like a VLAN, it is the
status of the lower interface.

A qdisc is a "queuing discipline". It is related to QoS and you can
change it with "tc" (another tool from iproute).

Each interface can be assigned a group (a number). This is not much
used. It can be used to make "ip link" operate on a group of
interface. It can be used with Netfilter too (devgroup).

[Andrey Rahmatullin]

Post by Wookey
Yeah I think that mess is why I've never felt any need to move away
from ifconfig. I ran ip something a few times, went 'huh?' at the cryptic
output and stayed with the rather more civilised /sbin/ifconfig.
So it seem that the output does actually label things, but the things
and labels look exactly the same. Would some colons really have hurt
too much?
i.e. mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
is really
mtu: 1500 qdisc: mq state: UP mode: DEFAULT group: default qlen: 1000
Anyone think the latter is a tad clearer? I still don't know what a
qdisc is or a default group, but it's a lot easier to find things I do
recognise. Before this discussion I just saw it as a mysterious jumble
of 10 things (after a set of things in CAPITALS that were somewhat
mysterious too (what's a LOWER_UP, I wonder) - who knows what it might
mean.

Do you really think that

wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.** netmask 255.255.255.0 broadcast 192.168.**
inet6 fe80::** prefixlen 64 scopeid 0x20<link>
ether e4:**:ca txqueuelen 1000 (Ethernet)
RX packets 66323088 bytes 90518262611 (84.3 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 18425793 bytes 2920636610 (2.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

is clearer than

3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff
inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0
valid_lft 70216sec preferred_lft 70216sec
inet6 fe80:**/64 scope link
valid_lft forever preferred_lft forever

?


To me they are the same. Note that ifconfig too has cryptic uppercase jumble
and cryptic lowercase jumble and doesn't have any separators between field
names and values.

[Tom H]

Post by Andrey Rahmatullin
Do you really think that
wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.** netmask 255.255.255.0 broadcast 192.168.**
inet6 fe80::** prefixlen 64 scopeid 0x20<link>
ether e4:**:ca txqueuelen 1000 (Ethernet)
RX packets 66323088 bytes 90518262611 (84.3 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 18425793 bytes 2920636610 (2.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
is clearer than
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff
inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0
valid_lft 70216sec preferred_lft 70216sec
inet6 fe80:**/64 scope link
valid_lft forever preferred_lft forever
?
To me they are the same. Note that ifconfig too has cryptic uppercase
jumble and cryptic lowercase jumble and doesn't have any separators
between field names and values.

Those used to ifconfig's old output might dislike its new output too:

JESSIE

# ifconfig en0
en0 Link encap:Ethernet HWaddr 08:00:27:31:6a:8c
inet addr:192.168.43.242 Bcast:192.168.43.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

# ip a sh en0
2: en0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 08:00:27:31:6a:8c brd ff:ff:ff:ff:ff:ff
inet 192.168.43.242/24 brd 192.168.43.255 scope global en0
valid_lft forever preferred_lft forever

STRETCH

# ifconfig en0
en0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.43.242 netmask 255.255.255.0 broadcast 192.168.43.255
ether 08:00:27:31:6a:8c txqueuelen 1000 (Ethernet)

# ip a sh en0
2: en0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 08:00:27:31:6a:8c brd ff:ff:ff:ff:ff:ff
inet 192.168.43.242/24 brd 192.168.43.255 scope global en0
valid_lft forever preferred_lft forever

The stretch output's similar to the output on the BSDs and Solaris...

[Philip Hands]

Post by Andrey Rahmatullin

Post by Wookey
Yeah I think that mess is why I've never felt any need to move away
from ifconfig. I ran ip something a few times, went 'huh?' at the cryptic
output and stayed with the rather more civilised /sbin/ifconfig.
So it seem that the output does actually label things, but the things
and labels look exactly the same. Would some colons really have hurt
too much?
i.e. mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
is really
mtu: 1500 qdisc: mq state: UP mode: DEFAULT group: default qlen: 1000
Anyone think the latter is a tad clearer? I still don't know what a
qdisc is or a default group, but it's a lot easier to find things I do
recognise. Before this discussion I just saw it as a mysterious jumble
of 10 things (after a set of things in CAPITALS that were somewhat
mysterious too (what's a LOWER_UP, I wonder) - who knows what it might
mean.

Do you really think that
wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.** netmask 255.255.255.0 broadcast 192.168.**
inet6 fe80::** prefixlen 64 scopeid 0x20<link>
ether e4:**:ca txqueuelen 1000 (Ethernet)
RX packets 66323088 bytes 90518262611 (84.3 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 18425793 bytes 2920636610 (2.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
is clearer than
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff
inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0
valid_lft 70216sec preferred_lft 70216sec
inet6 fe80:**/64 scope link
valid_lft forever preferred_lft forever
?

There are two things that make it less clear.

The thing you are looking for no longer starts at the first column

there are no blank lines between interfaces

If the numbers reach 2 digits then the interface name is indented at the
same level as the rest of the data, which makes it slightly worse.

I suspect that "wasting" a line feed between records would have made a
vast difference to people's ease of adoption.

Try comparing:

ip addr

to

ip addr | sed '2,$s/^\b/\n/'

I'm obviously already somewhat used to the normal output, so that now
looks weird, but it is also triggering my pattern recognition from
ifconfig a bit, so seems to have made me feel rather better about ip's
output.

I'm not suggesting we should actually change ip to have blank lines now,
but if you still find ip's output confusing, perhaps trying it with the
sed for a bit will allow you to transfer your familiarity from ifconfig.

If you want an even more old school look without losing any info, try:

| sed 's/^\(.*\): \(.*:\)/\1-\2/;2,$s/^\b/\n/;s/ /\t/'

Cheers, Phil.

[Russell Stuart]

Post by Russ Allbery
It certainly doesn't provide a man page that doesn't start with a BNF
syntax description.  The iproute2 documentation is awful.
# ip -o address
1: lo    inet 127.0.0.1/8 scope host lo\ valid_lft foreverpreferred_lft forever

All true. In particular the documentation produced by kernel's
networking group is a pet hobby horse of mine. To paraphrase an old
joke - you can't complain about most of it, because it doesn't exist.
[0]

When it comes to parsing they look equally bad once you have used them
for a while. Worse from my point of view they are both unnecessarily
difficult to scrape in a script. The "ip" does have one outstanding
attribute though - it is complete. ifconfig doesn't list multiple ipv4
address (but does list multiple ipv6 addresses - what's up with that?).
route can't handle multiple routing tables let alone routing rules.
The equivalent of "ip tunnel" doesn't exist - and it goes on and on.
net-tools might still be useful for configuring your laptop - but it's
now useless for any serious networking work.

To me this thread looks like a bunch of old men grumbling that the
young'ins have taken over what they created and turned the tools they
were comfortable with into something unrecognisable. It's true - they
did do that, and it's true it was unnecessary. They could have just
extended net-tools. But this is how the young'ins have behaved for
time immemorial - when they take over the reins from the previous
generation and make it their own. Look on the bright side. They've
given the kernel's networking stack a large array of new tools that
weren't envisaged when net-tools was conceived - like QoS.


[0] Now I've started, the Linux kernel's networking stack is a mess.
From the outside it looks like a mob of warning tribes, each 
developing with their own way of doing the same thing. To people 
not familiar with it this will sound like a hyperbolic claim. So 
lets consider one simple task: dropping a packet.

- Did you know the routing table can drop a packet?
"ip route add w.x.y.z/c blackhole" and
"ip route add w.x.y.z/c prohibit" and
"ip route add w.x.y.z/c unreachable" all do that.

- The traffic control engine can "police" packets. You can "shot"
a packet during policing. (Being Australian, I find this odd,
but I'm sure US citizens will be comfortable with it).

- Traffic control engine schedulers can also drop packets, (as well
as move them like a bridge, create duplicates and a lot of other
things).

- Iptables can drop packets. This how most people do it.

- The new nftables can drop packets.

Not only can they drop packets, each has their own way of figuring
out what packets to drop. Which means each must pull apart the
packet to see it it matches, so the same work is being repeated
over and over again.

This has real impacts. One is this spaghetti you see at the API 
level is reflected underneath, making for one large, complex, hard 
to understand and consequently fragile lump of code. Another is 
the the BSD networking stack is faster than Linux - sometimes near 
an order of magnitude faster(!)

http://www.phoronix.com/scan.php?page=article&item=netperf-bsd-linux

[Russ Allbery]

Post by Russell Stuart
To me this thread looks like a bunch of old men grumbling that the
young'ins have taken over what they created and turned the tools they
were comfortable with into something unrecognisable. It's true - they
did do that, and it's true it was unnecessary. They could have just
extended net-tools. But this is how the young'ins have behaved for time
immemorial - when they take over the reins from the previous generation
and make it their own. Look on the bright side. They've given the
kernel's networking stack a large array of new tools that weren't
envisaged when net-tools was conceived - like QoS.

That's a fair point. :) I'm probably going to force myself to learn ip
and ss and whatnot, since that's the direction of the future and it's not
really that much worse on the output front, and arguable. I'm not really
complaining about the changes so much as I'm complaining about the changes
that *weren't* made: even better command-line UI, better documentation,
JSON or YAML output format.

Of course, just as with the people who complain about missing features in
Debian, I could always go implement such things if I cared that much about
them. :)

[Vincent Bernat]

Post by Russell Stuart
[0] Now I've started, the Linux kernel's networking stack is a mess.
From the outside it looks like a mob of warning tribes, each 
developing with their own way of doing the same thing. To people 
not familiar with it this will sound like a hyperbolic claim. So 
lets consider one simple task: dropping a packet.
- Did you know the routing table can drop a packet?
"ip route add w.x.y.z/c blackhole" and
"ip route add w.x.y.z/c prohibit" and
"ip route add w.x.y.z/c unreachable" all do that.
- The traffic control engine can "police" packets. You can "shot"
a packet during policing. (Being Australian, I find this odd,
but I'm sure US citizens will be comfortable with it).
- Traffic control engine schedulers can also drop packets, (as well
as move them like a bridge, create duplicates and a lot of other
things).
- Iptables can drop packets. This how most people do it.
- The new nftables can drop packets.
Not only can they drop packets, each has their own way of figuring
out what packets to drop. Which means each must pull apart the
packet to see it it matches, so the same work is being repeated
over and over again.

The same work is not repeated over and over again. The kernel keeps the
needed information in a structure to avoid parsing the packet several
times.

When you need to decide how to route the packet, you need to do a route
lookup. If the route entry you find happens to be a blackhole route, you
drop the packet. You didn't do any additional work. The same applies for
all your examples. Those are different subsystems for different
tasks. They all happen to have a way to drop packets but that's not
their sole purpose.

Post by Russell Stuart
This has real impacts. One is this spaghetti you see at the API 
level is reflected underneath, making for one large, complex, hard 
to understand and consequently fragile lump of code. Another is 
the the BSD networking stack is faster than Linux - sometimes near 
an order of magnitude faster(!)
http://www.phoronix.com/scan.php?page=article&item=netperf-bsd-linux

Those benchmarks show huge differences between Linux distributions for a
kernel-related task. Like all phoronix benchmarks, it should not be
trusted.

[Russell Stuart]

Post by Vincent Bernat
The same work is not repeated over and over again. The kernel keeps
the needed information in a structure to avoid parsing the packet
several times.

Yes, it does indeed keep the offset of the headers for the various
protocol layers (link, ip, transport) in the skbuff. And yes, it uses
them where it can - for example when routing it knows it will be
looking at the destination ip address, and when routing it can use
those fields. In netfilter (iptables) has a separate block of code for
each test, so it can use them so the test knows . Unfortunately this
comes at a large cost - sequential execution. In the traffic control
engine the main filter, u32, doesn't have a clue what you are looking
at, so it can't. nftables could conceivably do it - but internally is
structured like u32 so it doesn't. eBpf could also conceivably do it -
but it has less of an idea of what it is looking at than u32 so it
doesn't either.

Linux provides what 2(?) API's for manipulating files - read/write and
memory mapped io. Want to count the number of ways it provides to
dissect and act upon network packets? These aren't the esoteric things
the file system hides under ioctl's either (which is arguably how it
the main API remains so clean) - all these ways of pulling apart and
manipulating packets are in the fast path.

Post by Vincent Bernat
When you need to decide how to route the packet, you need to do a
route lookup. If the route entry you find happens to be a blackhole
route, you drop the packet. You didn't do any additional work.

I bet the bash authors use that argument when they add another feature.
In reality all code has a cost. Do you remember Van Jacobson's
suggestion for speeding up Linux's network stack? (It's mentioned in
his Wikipedia page.) I was lucky enough to be at linux.conf.au when he
first presented it. He provided working code and some very impressive
benchmarks. It went nowhere because of that cost thing - the code
doesn't have to be executed in order to slow down development. I think
Linux's networking mob pretty much gave up after the ipchains to
iptables transition. Now stuff doesn't get ripped out and replaced,
instead new ideas are bolted onto the side - creating a bigger ball of
wax that's even harder to move. Which is how we got to having the
ability to drop packets added in so many different places.

Post by Vincent Bernat
Those benchmarks show huge differences between Linux distributions
for a kernel-related task. Like all phoronix benchmarks, it should
not be trusted.

Maybe you trust Facebook's opinion instead (it's weird - that wasn't
easy to write):

http://www.theinquirer.net/inquirer/news/2359272/f

[Vincent Bernat]

Post by Russell Stuart

Post by Vincent Bernat
When you need to decide how to route the packet, you need to do a
route lookup. If the route entry you find happens to be a blackhole
route, you drop the packet. You didn't do any additional work.

I bet the bash authors use that argument when they add another feature.
In reality all code has a cost.

The only additional cost is the cost to check if the routing entry is a
blackhole (while the check for anything else already exists). Even
FreeBSD supports this feature since a long time.

Post by Russell Stuart
Do you remember Van Jacobson's suggestion for speeding up Linux's
network stack? (It's mentioned in his Wikipedia page.) I was lucky
enough to be at linux.conf.au when he first presented it. He provided
working code and some very impressive benchmarks. It went nowhere
because of that cost thing - the code doesn't have to be executed in
order to slow down development. I think Linux's networking mob pretty
much gave up after the ipchains to iptables transition. Now stuff
doesn't get ripped out and replaced, instead new ideas are bolted onto
the side - creating a bigger ball of wax that's even harder to move.
Which is how we got to having the ability to drop packets added in so
many different places.

The flexibility is also what people like with Linux. Dropping a packet
in Netfilter is not an universal solution. Notably, it implies enabling
the Netfilter hooks (and paying a huge performance penalty). It also
implies dropping the packet after the creation of the skb struct, the IP
handling and (in most cases) the conntrack handling.

This can be far too late in certain cases (like deflecting a DoS
attack), hence the need to be able to drop earlier (even adding filters
directly in the NIC).

Blackhole routing has its own use: advertising in routing protocols and
avoid endless loops when a packet has an unreachable destination (when a
more specific route should have been available).

Post by Russell Stuart

Post by Vincent Bernat
Those benchmarks show huge differences between Linux distributions
for a kernel-related task. Like all phoronix benchmarks, it should
not be trusted.

Maybe you trust Facebook's opinion instead (it's weird - that wasn't
http://www.theinquirer.net/inquirer/news/2359272/f

Yes, I trust them far more as they are good open source
players. However, a job posting is not a benchmark showing an order of
magnitude of difference with FreeBSD.

[Russell Stuart]

Post by Vincent Bernat

Post by Russell Stuart
I bet the bash authors use that argument when they add another
feature. In reality all code has a cost.

The only additional cost is the cost to check if the routing entry is
a blackhole (while the check for anything else already exists). Even
FreeBSD supports this feature since a long time.

I wasn't talking about the merits of doing it in any particular place.
It was about the same thing being done in multitudes of places - in a
different way in each case, with a different API, with different code
pulling apart the packet.

Post by Vincent Bernat
The flexibility is also what people like with Linux.

True.

Post by Vincent Bernat
hence the need to be able to drop earlier (even adding filters
directly in the NIC).

Of course - bypassing the entire stack is always going to be faster.

The reason I have the irritates is because I don't bypass it. I use
the multiple routing tables, the traffic control engine, iptables,
tunnels, bridges, tun/tap, ipsec, veth, vlan's. I tried to collect
information on flows - but that slowed throughput to the point people
actually noticed it on a 10M bit/sec link. Thus my complaining about
having to use a different syntax every time I recognise a packet, how I
have to set MARK's to communicate between different levels of the
stack.

And also thus my long and loud whining about the lack of documentation.

It turns out such whining isn't entirely pointless. While looking at
the kernel code again I came across the net/openvswitch. Implemented
as yet another bolt on, of course. But if it does what it says on the
box it may be the answer to my complaints. This quote from the web
site is heartening: "The goal with Open vSwitch is to keep the in-
kernel code as small as possible (as is necessary for performance)".
Indeed.

[Bjørn Mork]

Post by Russell Stuart

Post by Russ Allbery
It certainly doesn't provide a man page that doesn't start with a BNF
syntax description.  The iproute2 documentation is awful.
# ip -o address
1: lo    inet 127.0.0.1/8 scope host lo\ valid_lft foreverpreferred_lft forever

All true. In particular the documentation produced by kernel's
networking group is a pet hobby horse of mine.

It's a collaborative project open for anyone with the slightest
interest in it. Sure it can need improvements. But complaining doesn't
really work. Fix it instead :)

FWIW, I find it much harder to document a new feature than implementing
it. And I believe many others feel the same. Any help improving the
docs is greatly appreciated. New networking features often have a
narrow target and are added by a person knowing the specific area pretty
well, but not necessarily everything else... Writing good docs in this
context is difficult because your point of view is so different from the
readers.

Post by Russell Stuart
To me this thread looks like a bunch of old men grumbling that the
young'ins have taken over what they created and turned the tools they
were comfortable with into something unrecognisable. It's true - they
did do that, and it's true it was unnecessary.

Note that the reason there are two sets of tools is exactly because they
*didn't* turn the existing tools into something unrecognisable. The
existing tools were left alone when the kernel API went from ioctls to
netlink.

But I see no point in the subject of this discussion. Leave net-tools
as they are for anyone used to them. "Priority: important" seems wrong,
though.


Bjørn

[Russell Stuart]

Post by Bjørn Mork
Fix it instead :)

I have submitted patches for kernel the network stack to improve QoS
for ADSL (ie where ATM cells are the link layer carrier). I'm not
terribly forgiving of the long drawn out initiation rites the kernel
dev's seem to demand, so I eventually gave up. (It didn't help that
the kernel networking dev's all seemed to use cable and so didn't
notice the issue. As I was a heavy ADSL user it was a very pertinent
itch for me.) My co-conspirator, Jesper Brouer, did persevere in the
area and is now a name some in kernel development might recognise.
Years later he re-submitted the patch. When it was rejected by the
same people in much the same way he responded "please lets not go
through this again", and it was accepted.

Post by Bjørn Mork
FWIW, I find it much harder to document a new feature than
implementing it. And I believe many others feel the same.  Any help
improving the docs is greatly appreciated.

As it happens I did write documentation. Not stuff most people consume
directly, but in a effort to use QoS I pored through the kernel source,
documented what it did and put the result up in a public place. That
documentation is now referenced in a number of places. For example
it's in the "SEE ALSO" of the tc-u32 man page, I think because it
copied large chunks of it.

Post by Bjørn Mork
New networking features often have a narrow target and are added by a
person knowing the specific area pretty well, but not necessarily
everything else...  Writing good docs in this context is difficult
because your point of view is so different from the readers.

I acknowledge it's hard to write good documentation. But I wasn't
talking about language skills. I was talking about writing a single
word. There wasn't one for tc for a long while. Some modules of tc
are still only mentioned in examples - like the ifb device (which sadly
because it's a key part of the traffic control puzzle).

Some get an introductory para only:

atm - a scheduler for ATM VC's.
gact - probabilistic filter action.
gred - generalised random early detection scheduler.
hhf - Heavy-Hitter Filter scheduler.
multiq - driver for multi queue devices, disguised as a scheduler
rsvp - Match Resource Reservation Protocol filter.
qfq - better version of pfifo, maybe.

At least a casual user can find the above and look up the kernel source
if they are desperate enough (I did it after all). But there are other
parts still haven't attracted a single word:

blackhole - a scheduler that always drops packets.
canid - a filter that looks at CAN bus ID's.
mq - the default scheduler used for virtual devices.
plug - scheduler allowing user space start / stopping of flows.
teql - link bonder disguised as a scheduler.
text - filter matching strings of text in a packet.

Post by Bjørn Mork
Note that the reason there are two sets of tools is exactly because
they *didn't* turn the existing tools into something
unrecognisable.  The existing tools were left alone when the kernel
API went from ioctls to netlink.

You learn something new every day. I had read the kernel devs had
rewritten net-tools. I presumed that was because the ioctl interface
had gone, so they were doing it out of the kindness of their hearts to
reduce the impact of the change over. Now I've looked at the source I
see that isn't so.

Post by Bjørn Mork
But I see no point in the subject of this discussion. 

It always puzzles me when I see someone make a point like this - right
after adding another 100 words to the very discussion they say is
pointless!

Post by Bjørn Mork
 Leave net-tools as they are for anyone used to them.

There are 2(!) versions of ifconfig available - one in inettools and
one in net-tools. I don't recall anybody suggesting we remove either.

The issue is the new maintainer of net-tools is changing it's output.
This could reasonably be expected to break scripts scraping it. Since
its been superseded the suggestion is packages using it switch to
iproute2 rather than simply adapting to the change. Re-wording that in
Debian terms: that means no packages should depend on it.

Granted this simple suggestion has prompted several people to charge
off on vaguely related hobby horses, and I'm a prime if not the major
offender. Undoubtedly this has distracted from the original
discussion. That is unfortunate as the original idea seemed sound to
me - and not at all pointless.

[Matt Zagrabelny]

On Tue, Dec 27, 2016 at 9:08 PM, Wookey <***@wookware.org> wrote:
I am (vaguely) aware of

Post by Wookey
something caled 'ip' which does a similar job but have no idea how to
use it.

Here are the few sub-commands I use regularly. Their abbreviated form
and unabridged form, and the legacy command:

ip a
ip address show
ifconfig -a

ip r
ip route show
route -n

ip n
ip neigh show
arp -n

-m

[Josh Triplett]

Post by Geert Stappers

ifconfig, route, etc...

From https://packages.debian.org/stretch/arm64/net-tools/filelist
* /bin/netstat

The rest of net-tools aside (which have sensible replacements), what
replaces netstat in the absence of net-tools?

lsof can do a subset of its functions, but only a subset, and with much
less useful output.

- Josh Triplett

[Ansgar Burchardt]

Post by Josh Triplett

Post by Geert Stappers

ifconfig, route, etc...

From https://packages.debian.org/stretch/arm64/net-tools/filelist
* /bin/netstat

The rest of net-tools aside (which have sensible replacements), what
replaces netstat in the absence of net-tools?

Which parts of netstat?

`ss` displays socket information. And is more informative then netstat,
for example it shows correctly which programs(!) use a listening socket.
Compare:

+---
| # netstat -xlp | grep gpg-agent.ssh
| unix 2 [ ACC ] STREAM LISTENING 25888 1911/systemd /run/user/1000/gnupg/S.gpg-agent.ssh
| # ss -lp | grep gpg-agent.ssh
| u_str LISTEN 0 128 /run/user/1000/gnupg/S.gpg-agent.ssh 25888 * 0 users:(("gpg-agent",pid=20584,fd=5),("systemd",pid=1911,fd=22))
+---

(which reminds me of `ip` vs. `ifconfig` on interfaces with multiple
IPv4 addresses. `ifconfig` will show only one of them...)

Ansgar

[Russell Stuart]

Post by Josh Triplett
The rest of net-tools aside (which have sensible replacements), what
replaces netstat in the absence of net-tools?

/bin/ss, which is part of iproute2

It's probably wise to 'dpkg -L iproute2 | grep bin/'. They are the
tools provided by the current kernel network maintainers for
manipulating the kernel's network stack. You will find some surprising
things in there, like tipc.

If you are contemplating moving to iproute2 this web page is
invaluable:

http://baturin.org/docs/iproute2/

[Josh Triplett]

Post by Russell Stuart

Post by Josh Triplett
The rest of net-tools aside (which have sensible replacements), what
replaces netstat in the absence of net-tools?

/bin/ss, which is part of iproute2

Thanks, that looks perfect, and it even accepts many of the same option
letters with the same meanings (-t, -u, -4, -6, -a, -l, -p).

- Josh Triplett

[Scott Leggett]

Can we stop shipping two network configuration CLI tools in the default
install?
net-tools has long been deprecated and should not have important
priority, for a start.

Yes, please!

FWIW, Red Hat did this in 2014 for RHEL7. Discussion here:
https://bugzilla.redhat.com/show_bug.cgi?id=1119297

[Marc Haber]

With this post I want to encourage fellow maintainers to stop depending
on net-tools, which is obsolete software and has been replaced long ago
by iproute.

Does iproute work on Non-Linux kernels?

Greetings
Marc

[Samuel Thibault]

Post by Marc Haber

With this post I want to encourage fellow maintainers to stop depending
on net-tools, which is obsolete software and has been replaced long ago
by iproute.

Does iproute work on Non-Linux kernels?

No, but net-tools doesn't work on non-Linux either :)

inetutils tools do, however.

Samuel

[Marc Haber]

On Wed, 28 Dec 2016 12:08:06 +0100, Samuel Thibault

Post by Samuel Thibault

Post by Marc Haber

With this post I want to encourage fellow maintainers to stop depending
on net-tools, which is obsolete software and has been replaced long ago
by iproute.

Does iproute work on Non-Linux kernels?

No, but net-tools doesn't work on non-Linux either :)
inetutils tools do, however.

Ah. Thanks for educating me. I didn't know the difference.

Greetings
Marc

[Simon Richter]

Hi,

Post by Samuel Thibault

Post by Marc Haber
Does iproute work on Non-Linux kernels?

No, but net-tools doesn't work on non-Linux either :)
inetutils tools do, however.

As long as there is still a way to have working "netstat" and "ifconfig"
commands, that is fine.

I often work in mixed environments, and having a consistent way of
checking this information on any host without first checking what OS it
is running is important to me. The exact output format isn't important
as long as it is roughly understandable for humans -- there are enough
subtle differences across platforms anyway, and if I wanted
machine-readable I'd use SNMP.

Simon

[Marco d'Itri]

Post by Simon Richter
As long as there is still a way to have working "netstat" and "ifconfig"
commands, that is fine.

I do not think that anybody sane wants to remove the package from the
archive: the idea is to stop using it in script in other packages since
iproute is a) better and b) going to be installed anyway.

(Still, using ifconfig is a bad idea because it shows an incomplete
view of the system.)

[Simon Richter]

Hi,

Post by Marco d'Itri

Post by Simon Richter
As long as there is still a way to have working "netstat" and "ifconfig"
commands, that is fine.

I do not think that anybody sane wants to remove the package from the
archive: the idea is to stop using it in script in other packages since
iproute is a) better and b) going to be installed anyway.

Yes, I'm totally in favour of that. Parsing the output of any of these
tools is wrong, and has been for far longer than iproute has even existed.

Simon

[Ian Jackson]

Post by Bernd Zeimetz
In my opinion ip provides all the things you are mentioning - what are
you missing? with -o as option the output is rather easy to parse.

OK then, I'll bite. I just got my `ip -o addr show' on my laptop to
produce, amongst other things, this output:

10: secondary inet 10.2.3.4/32 scope global secondary\ valid_lft forever preferred_lft forever
11: home inet 10.4.5.6/32 scope global home home\ valid_lft
forever preferred_lft forever

How is a parser supposed to know which of these words are what ?

Ian.

[Geert Stappers]

Post by Ian Jackson

Post by Bernd Zeimetz
In my opinion ip provides all the things you are mentioning - what are
you missing? with -o as option the output is rather easy to parse.

OK then, I'll bite. I just got my `ip -o addr show' on my laptop to
10: secondary inet 10.2.3.4/32 scope global secondary\ valid_lft forever preferred_lft forever
11: home inet 10.4.5.6/32 scope global home home\ valid_lft forever preferred_lft forever
How is a parser supposed to know which of these words are what ?

I come back on that.

This e-mail is to request to leave this thread in the year 2016.
We have concencus that the install priority of net-tools should be lowered.

It doesn't matter what is "easy" with "ip" or with "ifconfig|route|arp"
It is important that we can let go net-tools.


|> 10: secondary inet 10.2.3.4/32 scope global secondary\ valid_lft forever preferred_lft forever
|> 11: home inet 10.4.5.6/32 scope global home home\ valid_lft forever preferred_lft forever
|>
|> How is a parser supposed to know which of these words are what ?

The position of the words.


Groeten
Geert Stappers

[Ian Jackson]

Post by Geert Stappers
This e-mail is to request to leave this thread in the year 2016.
We have concencus that the install priority of net-tools should be lowered.

That has been done.

Post by Geert Stappers
It doesn't matter what is "easy" with "ip" or with "ifconfig|route|arp"
It is important that we can let go net-tools.

Unfortunately, bundled in with your request to leave the thread for
2016, was another message arguing that `ip' is easy. So your request
is actually a request to have the last word.

Post by Geert Stappers
|> 10: secondary inet 10.2.3.4/32 scope global secondary\ valid_lft forever preferred_lft forever
|> 11: home inet 10.4.5.6/32 scope global home home\ valid_lft forever preferred_lft forever
|>
|> How is a parser supposed to know which of these words are what ?
The position of the words.

Can you please provide a simple regexp or parser which, given a
keyword like `secondary', `home', `scope', `valid_lft' or whatever,
will tell whether that keyword is present and if so what (if any)
value it has ?

For example, something like this:

sub extract_value_from_ip_o_addr_line ($$) {
my ($line, $keyword) = @_;
if ($line =~ m/ $keyword (\S+)/) {
return $1;
} else {
return undef;
}
}

Only without the many bugs.

Ian.

[Geert Stappers]

Post by Ian Jackson

Post by Geert Stappers
This e-mail is to request to leave this thread in the year 2016.

Happy New Year

Post by Ian Jackson

Post by Geert Stappers
We have concencus that the install priority of net-tools should be lowered.

That has been done.

Yes

Post by Ian Jackson

Post by Geert Stappers
It doesn't matter what is "easy" with "ip" or with "ifconfig|route|arp"
It is important that we can let go net-tools.

Unfortunately, bundled in with your request to leave the thread for
2016, was another message arguing that `ip' is easy. So your request
is actually a request to have the last word.

:-)

Post by Ian Jackson

Post by Geert Stappers
|> 10: secondary inet 10.2.3.4/32 scope global secondary\ valid_lft forever preferred_lft forever
|> 11: home inet 10.4.5.6/32 scope global home home\ valid_lft forever preferred_lft forever
|>
|> How is a parser supposed to know which of these words are what ?
The position of the words.

Can you please provide a simple regexp or parser which, given a
keyword like `secondary', `home', `scope', `valid_lft' or whatever,
will tell whether that keyword is present and if so what (if any)
value it has ?
sub extract_value_from_ip_o_addr_line ($$) {
if ($line =~ m/ $keyword (\S+)/) {
return $1;
} else {
return undef;
}
}
Only without the many bugs.

This e-mail only to hand over the last word, please take it.

[Joerg Jaspert]

On 14533 March 1977, Marco d'Itri wrote:

dak override net-tools net optional
I: Will change priority from important to optional
Continue (y/N)? y

dak override iproute2
iproute2 is in section 'net' at priority 'important'

Whoever wants net-tools can have it by simply installing it - or getting
it by one of its rev-deps/recommends, which isn't a short list either.

[Martín Ferrari]

Post by Joerg Jaspert
dak override net-tools net optional
I: Will change priority from important to optional
Continue (y/N)? y

Thanks!

[Jonathan Dowland]

Recently the net-tools maintainer has forked the abandoned net-tools
code base and started developing it again, after 15 years of stasis.

...

Can we stop shipping two network configuration CLI tools in the default
install?

The UI for ip(8) is absolutely appalling. I'd like Debian to continue to carry
net-tools in parallel to iproute2 until such time as a third tool (with a
decent UI) comes along and obsoletes iproute2.

[net-tools] should not have important priority, for a start.

I have no problem with the priority dropping to optional and it not being part
of the default install. I wouldn't want to see it dropped from the archive.

[Jonathan Dowland]

Post by Jonathan Dowland
The UI for ip(8) is absolutely appalling. I'd like Debian to continue to carry
net-tools in parallel to iproute2 until such time as a third tool (with a
decent UI) comes along and obsoletes iproute2.

...

Post by Jonathan Dowland
I have no problem with the priority dropping to optional and it not being part
of the default install. I wouldn't want to see it dropped from the archive.

Oh, all points already made. Move along :)