netdev - Re: Is the manpage wrong for "ip address delete"?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2sewezypi.fsf@gmail.com>
Date: Fri, 12 Jul 2024 11:33:45 +0100
From: Donald Hunter <donald.hunter@...il.com>
To: Adam Nielsen <a.nielsen@...kadi.net>
Cc: netdev@...r.kernel.org
Subject: Re: Is the manpage wrong for "ip address delete"?

Adam Nielsen <a.nielsen@...kadi.net> writes:

> Hi all,
>
> I'm trying to remove an IP address from an interface, without having to
> specify it, but the behaviour doesn't seem to match the manpage.
>
> In the manpage for ip-address it states:
>
>     ip address delete - delete protocol address
>        Arguments: coincide with the arguments of ip addr add.  The
>        device name is a required  argument. The rest are optional.  If no
>        arguments are given, the first address is deleted.
>
> I can't work out how to trigger the "if no arguments are given" part:
>
>   $ ip address delete dev eth0
>   RTNETLINK answers: Operation not supported
>
>   $ ip address delete "" dev eth0
>   Error: any valid prefix is expected rather than "".
>
>   $ ip address dev eth0 delete
>   Command "dev" is unknown, try "ip address help".
>
> In the end I worked out that "ip address flush dev eth0" did what I
> wanted, but I'm just wondering whether the manpage needs to be updated
> to reflect the current behaviour?

Yes, that paragraph of the manpage appears to be wrong. It does not
match the manpage synopsis, nor the usage from "ip address help" which
both say:

  ip address del IFADDR dev IFNAME [ mngtmpaddr ]

The description does match the kernel behaviour for a given address
family, which you can see by using ynl:

$ ip a show dev veth0
2: veth0@...h1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 6a:66:c7:67:bc:81 brd ff:ff:ff:ff:ff:ff
    inet 6.6.6.6/24 scope global fred
       valid_lft forever preferred_lft forever
    inet 2.2.2.2/24 scope global veth0
       valid_lft forever preferred_lft forever
    inet 4.4.4.4/24 scope global veth0
       valid_lft forever preferred_lft forever

$ sudo ./tools/net/ynl/cli.py \
  --spec Documentation/netlink/specs/rt_addr.yaml \
  --do deladdr --json '{"ifa-family": 2, "ifa-index": 2}'
None

$ ip a show dev veth0
2: veth0@...h1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 6a:66:c7:67:bc:81 brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.2/24 scope global veth0
       valid_lft forever preferred_lft forever
    inet 4.4.4.4/24 scope global veth0
       valid_lft forever preferred_lft forever

I guess it makes sense for "ip address del" to be stricter since 'first
address' is quite arbitrary behaviour.

> Cheers,
> Adam.
>
> (Not subscribed, please CC)