/proc/sys/net/ipv[46]/conf/ issue unsolved

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.


regards,

-- 
Hasso Tepper

On Tue, 13 Feb 2007 15:29:04 +0200
Hasso Tepper [off-list ref] 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.

And Xen is broken because it tries to use the same bogus Mac
address on on all pseudo devices.

Hi,

On 2/13/07, Stephen Hemminger [off-list ref] wrote:

quoted

You can disable it in /proc/sys/net/ipv6/conf/default/... and then
reenable it on the interfaces that you actually want.

  Is there any technical reason to not have the sysconf entries
available at interface creation? It seems to me that this solution is
very intrusive. Imagine for instance i'm developing some custom
application that uses a TAP interface and i don't want any
autoconfiguration over this interface. For instance a multi-homed host
creating a custom tunnel. Within the current rules i would have to
disable autoconfiguration system-wide to influence the expected
behaviour. Also, this is not reliable as a different application (or a
negligent user) may change back the sysconf values before i set the
TAP interface up.

  Unless there are strong technical reasons against it, it would seem
to me that having conf/tapX/{autoconf, accept_ra} (as an example)
available after the interface is created would provide the cleaner and
most reliable interface.

  Hugo

Stephen Hemminger wrote:

On Tue, 13 Feb 2007 15:29:04 +0200
Hasso Tepper [off-list ref] wrote:

quoted

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:

quoted

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

On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper 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.

Can't this simply be fixed by adding a custom udev rule?  Correct me if I'm
wrong, but the only reason that interfaces come up automatically after their
appropriate module is inserted is because most distos udev rules issue an ifup
$DEVICE when they get a creation event for $DEVICE.  Why not add a custom rule
in for net device creation events to set appropriate sysctl values before the
ifup is issued.

Regards
Neil

regards,

-- 
Hasso Tepper
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Neil,

On 2/13/07, Neil Horman [off-list ref] wrote:

Can't this simply be fixed by adding a custom udev rule?  Correct me if I'm
wrong, but the only reason that interfaces come up automatically after their
appropriate module is inserted is because most distos udev rules issue an ifup
$DEVICE when they get a creation event for $DEVICE.  Why not add a custom rule
in for net device creation events to set appropriate sysctl values before the
ifup is issued.

  The issue is not as much with automatic auto-configuration but with
not being able to disable auto-configuration (and others) before
setting the interface up.

  Hugo

Neil Horman wrote:

On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:

quoted

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.

Can't this simply be fixed by adding a custom udev rule?  Correct me if I'm
wrong, but the only reason that interfaces come up automatically after their
appropriate module is inserted is because most distos udev rules issue an ifup
$DEVICE when they get a creation event for $DEVICE.  Why not add a custom rule
in for net device creation events to set appropriate sysctl values before the
ifup is issued.

You can't.  The /proc/sys/conf/eth<x>/  structure appears when the 
interface is marked UP.  At this point, if protocol modules are already
loaded, your configuration parameters are already set.

I was going to ask.. How are you testing Optimistic DAD patch.  The
only way I could do it was to set /proc/sys/conf/default/ipv6  entry.

-vlad

On Tue, Feb 13, 2007 at 07:24:32PM +0000, Hugo Santos wrote:

Neil,

On 2/13/07, Neil Horman [off-list ref] wrote:

quoted

Can't this simply be fixed by adding a custom udev rule?  Correct me if I'm
wrong, but the only reason that interfaces come up automatically after 
their
appropriate module is inserted is because most distos udev rules issue an 
ifup
$DEVICE when they get a creation event for $DEVICE.  Why not add a custom 
rule
in for net device creation events to set appropriate sysctl values before 
the
ifup is issued.

 The issue is not as much with automatic auto-configuration but with
not being able to disable auto-configuration (and others) before
setting the interface up.

Yes, I understand that, but until the IFF_UP flag is set on the interface, it
doesn't really have any effect on the system as a whole.  You should be able to
undo any default setting that you want before you call ifup on the interface, or
am I missing something?

Neil

 Hugo

Yes, I understand that, but until the IFF_UP flag is set on the interface, it
doesn't really have any effect on the system as a whole.  You should be able to
undo any default setting that you want before you call ifup on the interface, or
am I missing something?

  If i understand what you are proposing, in that context you can't
undo before you set IFF_UP because the sysfs entries do not exist yet,
and undoing later is too late as in the case of auto-configuration for
instance the kernel might already have sent a RtSol.

  Hugo

On Tue, Feb 13, 2007 at 07:49:50PM +0000, Hugo Santos wrote:

quoted

Yes, I understand that, but until the IFF_UP flag is set on the interface, 
it
doesn't really have any effect on the system as a whole.  You should be 
able to
undo any default setting that you want before you call ifup on the 
interface, or
am I missing something?

 If i understand what you are proposing, in that context you can't
undo before you set IFF_UP because the sysfs entries do not exist yet,
and undoing later is too late as in the case of auto-configuration for
instance the kernel might already have sent a RtSol.

It was my understanding, from what I can see, that this is the order of events:

1) Kernel network driver X detects that it has hardware to drive, and
consequently calls register_netdev.  This creates the network interface and
registers all the appropriate proc and sysfs files, which are now accessible in
user space.

2) The kernel, as a result of (1), also sends an event to userspace indicating a
new interface has been created

3) The udev daemon receives this message in userspace, and looks the event up in
its udev rules configuration.

4) Most distros have a udev rule for new interface creation that amount to, in
summary, /sbin/ifup $DEVICE

5) the ifup $DEVICE from (4) goes through the network interface bring up
process, and consequently sends the ioctl SIOCSIFFLAGS to the kernel, setting
the IFF_UP flag on the appropriate interface, kicking of whatever default
processes need to be as defined by the settings found in
/proc/sys/net/conf/<interface>/*

if I understand the issue correctly (and perhaps I still don't), the concern is
that steps 3 4 and 5 have no logic in them that allow the override of the
defaults for specific interfaces, and as such manual intervention is prone to
race (i.e. the previous example in which addrconf may start and complete before
you have the opportunity to manually disable it).

As has been seen, one place to fix this is by adding logic to the ifup scripts
for the appropriate protocol to issue sysctl -w commands to set configs prior to
issuing the ifconfig up or ip link up commands.  Another approach (the one I'm
recommending here), is to add logic to the udev rules to determine if there are
any specific interface settings that need to be set prior to issuing the ifup
command at all.

All that being said, this is all moot if there is a in-kernel process that gets
started at device creation time, which also has a knob to configure it.  If that is
the case then none of these solutions will work and the process and knob
themselves are broken, since there is no way for userspace to interviene and
configure the process at all prior to it being started.

Regards
Neil

On Tue, Feb 13, 2007 at 02:43:32PM -0500, Vlad Yasevich wrote:

Neil Horman wrote:

quoted

On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:

quoted

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.

Can't this simply be fixed by adding a custom udev rule?  Correct me if I'm
wrong, but the only reason that interfaces come up automatically after 
their
appropriate module is inserted is because most distos udev rules issue an 
ifup
$DEVICE when they get a creation event for $DEVICE.  Why not add a custom 
rule
in for net device creation events to set appropriate sysctl values before 
the
ifup is issued.

You can't.  The /proc/sys/conf/eth<x>/  structure appears when the 
interface is marked UP.  At this point, if protocol modules are already
loaded, your configuration parameters are already set.

I was going to ask.. How are you testing Optimistic DAD patch.  The
only way I could do it was to set /proc/sys/conf/default/ipv6  entry.

I make a change in my patch before I post, to default it to on, rather than to
off.  Although I did that for convienience, not necessity.  I didn't realize
those files didn't show up until the interface was marked as up.  That seems
horribly broken to me.  We should definately have some registered file at
creation time, perhaps create the files when register_netdev is called and put
them in /proc/sys/ipv4/conf/offline/<interface>/*, and move them
conf/<interface> when IFF_UP is set?

Neil

-vlad

Stephen Hemminger wrote:

quoted

You can disable it in /proc/sys/net/ipv6/conf/default/... and then
reenable it on the interfaces that you actually want.

And YOSHIFUJI Hideaki answered to this:

The point is:

 - Until we have live address(es), we do not create inet6_dev{} for that
   device.
 - We do NOT run DAD until the link is ready (netif_carrier_ok()).

This means, we do NOT have any addresses until the link is once up,
and thus, because the sysctl entries live in inet6_dev{}, we do not
install net.ipv6.conf.ethX from values of net.ipv6.conf.default until
then.

Ie. to make it very clear - I can't reenable it on the interface before
the first "carrier up" event (cable is plugged on). That's the point -
AFAICS the only way I can configure interface differently than default is
via daemon listening interface events via netlink. I can't do it in any
way before.


regards,

-- 
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
IP & Data Networking Expert

On 2/13/07, Neil Horman [off-list ref] wrote:

1) Kernel network driver X detects that it has hardware to drive, and
consequently calls register_netdev.  This creates the network interface and
registers all the appropriate proc and sysfs files, which are now accessible in
user space.

The problem is that in the IPv6 case, the sysfs files are _not_
registered in this step but only after the interface is set up (in
fact after the first proper address is added to the interface, which
generally would be the link local address).

As has been seen, one place to fix this is by adding logic to the ifup scripts
for the appropriate protocol to issue sysctl -w commands to set configs prior to
issuing the ifconfig up or ip link up commands.

  Due to the previous point, this wouldn't work. I believe the proper
solution is to init the ipv6 dev on interface creation (and thus
trigger the adding of the sysfs files) and not when the first address
is added to the interface.

  There might be issues with this solution (known internal races,
module unloading issues, etc), that's why i asked previously if there
were any known ones.

  Hugo

Neil Horman wrote:

5) the ifup $DEVICE from (4) goes through the network interface bring up
process, and consequently sends the ioctl SIOCSIFFLAGS to the kernel, setting
the IFF_UP flag on the appropriate interface, kicking of whatever default
processes need to be as defined by the settings found in
/proc/sys/net/conf/<interface>/*

... which is created _only_ if address of specific address familiy exists
already. If address is obtained via IPv6 autoconf (very common case for
IPv6 hosts) or via IPv4/IPv6 DHCP with netlink aware mechanism (also very
common nowadays - network manager) you don't have any addresses on interface
at this point therefore /proc/sys/net/ipv[46]/conf/<interface>/ are NOT
created. That's the point - you can't configure anything before the first
"carrier up" event - ie. cable is plugged on.


regards,

-- 
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
IP & Data Networking Expert