iproute2 and libbpf: vendoring on the small scale

Posted Nov 13, 2020 22:34 UTC (Fri) by rweikusat2 (subscriber, #117920)
In reply to: iproute2 and libbpf: vendoring on the small scale by Wol
Parent article: iproute2 and libbpf: vendoring on the small scale

Well, ifconfig has "always worked and always been there" for me since RedHat 3.0.3. But Linux 2.2 (released in 1998) added a bunch of useful features to the networking stack, eg, binding more than one protocol address to an interface, and because the guy who added them had a Cisco- and not a BSD-background (AFAIK), he also wrote a new, extensible command-line tool with a more orthogonal interface closer to the Cisco interface (eg, everything can be uniquely abbreviated).

I'm still using the exact fvwm2 configuration I did already use in 1998 and with how many "turn everything upside down and paint everything which used to be green in pink with orange flowers on it !" cycles has everyone else put up with since 1998? But using "ip addr" instead of "ifconfig" is just too much of a botheration?

:-))

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 14:59 UTC (Sun) by Wol (subscriber, #4433) [Link] (9 responses)

> But using "ip addr" instead of "ifconfig" is just too much of a botheration?

I just used to type "ifconfig" - no bothering with arguments and it told me all the basic stuff I needed to know. I don't think "ip" does that - you need the argument? Which means I need to remember more than just the basic command, and I don't use it much so I'm faffing around with man pages all the time ...

To my mind the obvious solution would have been to keep the single binary, but make the functionality dependent on the name it's called by. New functionality would require calling by the new name.

Still, hindsight is always 20/20 :-)

Cheers,
Wol

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 15:51 UTC (Sun) by dtlin (subscriber, #36537) [Link] (7 responses)

ip l + ip a provide equivalent information to no-options ifconfig. How Linux handles multiple IP addresses/masks per network interface (exposed directly by iproute2) just doesn't match the ifconfig command-line interface, though.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 18:22 UTC (Sun) by geert (subscriber, #98403) [Link] (6 responses)

<pre>
$ ip
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
ip [ -force ] -batch filename
where OBJECT := { link | address | addrlabel | route | rule | neigh | ntable |
tunnel | tuntap | maddress | mroute | mrule | monitor | xfrm |
netns | l2tp | fou | macsec | tcp_metrics | token | netconf | ila |
vrf | sr | nexthop }
OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
-h[uman-readable] | -iec | -j[son] | -p[retty] |
-f[amily] { inet | inet6 | mpls | bridge | link } |
-4 | -6 | -I | -D | -M | -B | -0 |
-l[oops] { maximum-addr-flush-attempts } | -br[ief] |
-o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] |
-rc[vbuf] [size] | -n[etns] name | -N[umeric] | -a[ll] |
-c[olor]}
$ ip enp0s31f6 # Another annoyance, fortunately "ifconfig" helps me to remember it ;-)
Object "enp0s31f6" is unknown, try "ip help".
$ ip l + ip
Command "+" is unknown, try "ip link help".
$
</pre>
Giving up.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 20:30 UTC (Sun) by dtlin (subscriber, #36537) [Link] (5 responses)

`ip l` and `ip a` being separate commands, short for `ip link` and `ip address`, as the help cryptically states.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 8:04 UTC (Mon) by Wol (subscriber, #4433) [Link] (4 responses)

So in order to get the informatiion I might want, I have to type three or four commands? Whereas ifconfig was just one command?

If that's what I want, how do I get multiple bits of information in one go?

Cheers,
Wol

iproute2 and libbpf: vendoring on the small scale

Posted Nov 18, 2020 0:18 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

'ip addr' displays all the information 'ip link' does about links and then adds address info to that, so that is usually enough unless you're looking for. ip -s addr if you want packet stats too (which I almost never do, so I'm glad it's off by default). ('ip link' is still valuable because that's what you use to *configure* the link layer: you can't use ip addr to do that.)

iproute2 and libbpf: vendoring on the small scale

Posted Nov 26, 2020 10:20 UTC (Thu) by ecree (guest, #95790) [Link] (1 responses)

But it's crazy that I have to type `ip -s addr` and can't `ip addr -s`, when command-subcommand-options is *so* much more natural. `tc` has this problem too. And `ip` doesn't understand `-h` at *all*, which is a cardinal sin for a Unix utility. (Though what can one expect from a Cisco-ism.)

iproute2 and libbpf: vendoring on the small scale

Posted Nov 27, 2020 22:19 UTC (Fri) by nix (subscriber, #2304) [Link]

I think it's supposed to indicate that the -s option applies to many ip subcommands. Quite a lot of other commands these days do the same thing: git for one. I find it a bit annoying, too, but it does allow git -P diff and git diff -P to mean different things... which matters a lot for a metastasized mega-command like git and... not so much at all for ip.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 26, 2020 15:59 UTC (Thu) by opsec (subscriber, #119360) [Link]

Write a wrapper named ifconfig ? That uses 'ip l' and 'ip a' to get what you need ?

I'm a FreeBSD user, we still have ifconfig, so I feel the pain as well, when I get to a linux box 8-}

iproute2 and libbpf: vendoring on the small scale

Posted Nov 18, 2020 0:15 UTC (Wed) by nix (subscriber, #2304) [Link]

> I just used to type "ifconfig" - no bothering with arguments and it told me all the basic stuff I needed to know.

Only if the basic stuff you need to know includes nothing at all about the routing table. It's hard for me to imagine what networking problem that might be :) and the route output is, uh, completely different (and even more wildly inaccurate than ifconfig's, to such an extent that it's often impossible to use it to tell what's going where).

Meanwhile in the ip world we have 'ip route get', which can tell you which route will be used for a packet to a given address. This is immensely valuable with complex multi-table routing setups and would on its own justify the existence of ip, in my eyes (though of course you can't set up such things at all with the ifconfig/route tools).