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] [day] [month] [year] [list]
Date:	Wed, 9 Apr 2014 22:36:11 +0200
From:	Hannes Frederic Sowa <>
To:	Heiner Kallweit <>
Cc:	"" <>
Subject: Re: ipv6: Should inet6_addr_del consider IFA_F_MANAGETEMPADDR?

On Wed, Apr 09, 2014 at 09:38:27PM +0200, Heiner Kallweit wrote:
> Am 08.04.2014 22:14, schrieb Hannes Frederic Sowa:
> > [cc Jiri + Thomas]
> >
> > Hi!
> >
> > On Tue, Apr 08, 2014 at 08:26:37PM +0200, Heiner Kallweit wrote:
> >> I stumbled accross the fact that inet6_addr_add as well as inet6_addr_modify
> >> consider IFA_F_TEMPORARY whilst inet6_addr_del does not.
> >>
> >> My understanding of IFA_F_MANAGETEMPADDR is that it allows userspace applications
> >> to deal with temporary addresses w/o having to create / track (and possibly delete)
> >> each and every temporary address.
> >>
> >> This works fine when creating / modifying a global address. However when a
> >> global address is deleted the orphaned temporary addresses remain.
> >> Shouldn't the userspace be able to set IFA_F_MANAGETEMPADDR also for RTM_DELADDR
> >> to signalize that the kernel should delete all related temporary addresses as well?
> > Sure, that is possible. I guess it was not done already because
> > inet6_addr_del did not handle IFA_FLAGS at all. But it should be a very
> > tiny change to pass that flag down. Please submit an iproute patch along
> > with your changes.
> After a brief look at the source code of iproute2 it seems like "ip addr del" already supports sending
> IFA_F_MANAGETEMPADDR with RTM_DELADDR, though I have the impression it's unintentional.
> The del command internally calls ipaddr_modify just like add / change / replace.
> And ipaddr_modify happily populates every flag provided on the command line w/o checking whether
> the flag is applicable for the respective command.
> Having said this only the usage info needs to be extended.
> Not sure: Should the related patch go to this mailing list or to Stephen directly who seems to be the
> current maintainer.

iproute patches are handled the same way as kernel patches on this mailing
list. Cc Stephen wouldn't hurt either. ;)


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists