i'm writing an application which will be managing addresses via netlink
(i'm already using netlink for interfaces, and it's working swimmingly).
i noticed while debugging that netlink seemed to be ignoring the netmask
aspect of my RTM_DELADDR ipv4 requests (ifa_prefixlen); an addition of
ipfoo/nmbar to an interface, then ipfoo/nmqux, then a deletion of either
would always result in ipfoo/nmbar being deleted.
i'm not sure whether this was done by design or not. i managed to force
my selection to be the one deleted by setting the IFA_ADDRESS entry of
an rta alongside IFA_LOCAL, so i didn't need to rely on the previously
stated undefined behavior. so the question is whether either iproute
(ip utility, iproute2-ss010824) has a bug in
if (peer_len == 0 && local_len && cmd != RTM_DELADDR) {
peer = lcl;
addattr_l(&req.n, sizeof(req), IFA_ADDRESS,
&lcl.data, lcl.bytelen);
}
or the kernel has a bug in inet_rtm_deladdr():
(rta[IFA_ADDRESS-1] &&
(ifm->ifa_prefixlen != ifa->ifa_prefixlen ||
!inet_ifa_match(*(u32*)RTA_DATA(rta[IFA_ADDRESS-1]), ifa))))
or whether this is never a problem (i ran into it handling the case
where one wants only to change a netmask, not the ip). i'd definitely
like to see the cmd != RTM_DELADDR removed from iproute if it's not
needed; even if the current behavior has no problems, it's confusing.
log of iproute behavior follows, which i see as incorrect:
nectar:/home/dank# ip -V
ip utility, iproute2-ss010824
nectar:/home/dank# ip a l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:04:ac:33:15:4d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.32/24 scope global eth0
nectar:/home/dank# ip a a 10.10.2.20/8 dev eth0
nectar:/home/dank# ip a a 10.10.2.20/16 dev eth0
nectar:/home/dank# ip a d 10.10.2.20/24 dev eth0
nectar:/home/dank# ip a l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:04:ac:33:15:4d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.32/24 scope global eth0
inet 10.10.2.20/16 scope global eth0
nectar:/home/dank#
--
nick black <dank@reflexsecurity.com>
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
