linux-kernel - Re: /proc/sys/net/ipv[46]/conf/ issue unsolved

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: <45D1FDAA.6070704@hp.com>
Date:	Tue, 13 Feb 2007 13:04:26 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	Hasso Tepper <hasso@...pak.ee>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: /proc/sys/net/ipv[46]/conf/ issue unsolved

Stephen Hemminger wrote:
> On Tue, 13 Feb 2007 15:29:04 +0200
> Hasso Tepper <hasso@...pak.ee> wrote:
> 
>> There is long standing issue in kernel which makes using /etc/sysctl.conf
>> useless for boottime configuration of specific interface properties and
>> breaks probably any software relying on unconditional existence of the
>> conf trees like it was in previous kernels (I alone have written several
>> pieces of such software). It's broken AFAIK from 2.6.15. There has been
>> several notes about issue in the list, but issue haven't got any (at least
>> efficient) attention from developers.
>>
>> The current behaviour bites users in many ways and breaks several use cases.
>> I asked several times in the past "what I should do now?" question, but
>> got no clear answer.
>>
>> References:
>> http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2
>> http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809
>>
>> Is there any chance this will be fixed or at least clear position is
>> taken by developers? Breaking userspace applications is declared nonono
>> several times in the past ... I'm not even against breaking it if there
>> is _very_ good reason to do it. Ok, but I want to know how userspace is
>> meant to behave now. I can't continue using crappy workarounds.
> 
> As Herbert Xu said:
> 
>> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
>> reenable it on the interfaces that you actually want.
> 

Sorry, but this is backwards.

Let's say you have an interface on which you want to turn DAD off.

There are ways to do it:

1.  Turn DAD off on all interfaces usinc ipv6/conf/default and then
     turn it on just on the interface you want.

This solution is a royal pain and introduces a potential race
on the interfaces that should have DAD enabled (i.e. you address will
be preferred when it really should be tentative).

2.  Wait until the interface is up and then turn off dad.

However at this point, DAD may have completely already so turning it off
is useless to us.

There needs to be a mechanism by which protocol parameters may be 
changed on the interface bases before the interface is up/running.

This has been bugging me for while too.

-vlad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/