iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 17:18 UTC (Mon) by sfeam (subscriber, #2841)
In reply to: iproute2 and libbpf: vendoring on the small scale by mkubecek
Parent article: iproute2 and libbpf: vendoring on the small scale

If there are indeed so many people who have been using it and prefer to continue using it, then the logical conclusion is that it is not "obsolete".

to post comments

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 17:37 UTC (Mon) by mkubecek (guest, #130791) [Link] (4 responses)

A tool serving as a configuration interface for kernel networking which has been incompatible with kernel networking for almost 22 years is definitely obsolete, no matter how many people still refuse to acknowledge it.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 17:56 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> A tool serving as a configuration interface for kernel networking which has been incompatible with kernel networking for almost 22 years is definitely obsolete, no matter how many people still refuse to acknowledge it.

I think you meant to say _incomplete_ -- because ifconfig is very much _compatible_ with modern kernels; it just can't configure every possible option. Indeed, even today ifconfig does everything that most users need.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 23:42 UTC (Mon) by mkubecek (guest, #130791) [Link] (2 responses)

No, I did not mean "incomplete" because the lack of features is only one part of the problem - and perhaps a minor one. For example, ifconfig (and the ioctl interface it uses) still pretends a network interface has (at most) one IPv4 address which is _set_ while kernel maintains a set of addresses which can be added to or removed from. To work around this, It also pretends there are "alias interfaces" which no longer exist since kernel 2.2, leading to its own kind of problems like "ifconfig foo:0 mtu 1400" actually changing MTU of foo. There are real people who made a remote host unresponsive because of this caveat and real poeple who keep asking why they cannot use "eth0:0" as an interface name in netfilter rules.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 23:57 UTC (Mon) by quotemstr (subscriber, #45331) [Link] (1 responses)

ISTM the problem was that the removal of alias interfaces broke userland. Was it infeasible to keep supporting them or something? It's too late to add them back now, but still.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 17, 2020 6:44 UTC (Tue) by jem (subscriber, #24231) [Link]

From iproute2.doc:

label NAME --- Each address may be tagged with a label string.

In order to preserve compatibility with Linux-2.0 net aliases, this string must coincide
with the name of the device or must be prefixed with device name followed by a colon. (eth0:duh)

An example: ip addr add 203.0.113.1/24 dev eth0 label eth0:0