Re: slowly or no configured connection usage

On Wed, 2015-08-05 at 03:41 +0200, Ingo Flaschberger wrote:

Am 04.08.2015 um 23:52 schrieb Dan Williams:
On Mon, 2015-08-03 at 03:00 +0200, Ingo Flaschberger wrote:

I use nm 0.9.10 with debian jessie at a raspberry pi.

Problem 1:
If I configure a single connection with auth ipv4, auto ipv6, auto
connect and delete all other connections it takes severall minutes after
reboot till the connection is used.
Also a new "eth0" connection is always generated.
Connection name is "internet", config is attached.
I think this one is probably due to the kernel-assigned IPv6LL address
that the device gets when something in the boot process brings the
interface IFF_UP.

Problem 2:
If I configure a single connection with static ipv4, link-local ipv6,
auto connect and delete all other connections after reboot the
connections is never used.
Only a new generated "eth0" connection is used.
Connection name is "emergency", config is attached.
This is due to the same reason.

Digging into code - I wonder why a new connection is generated and why
nm_utils_match_connection / check_possible_match / check_ip6_method  and
check_ip4_method behave such strange?
When NM starts up, it will read the existing interface configuration and
attempt to match it to a stored connection.  If it doesn't match, NM
tries very hard not to touch the interface, because something else
configured it and NM won't blow that away.

In case #2, I'll bet that the generated connection "eth0" was
ipv4.method=disabled, ipv6.method=link-local.  The connection you
created was ipv4.method=manual.  On bootup, the interface has only an
IPv6 link-local address, but not the static address from your
connection.  Therefore, the runtime config of the interface (ipv6ll
only) doesn't match any stored connection, and the existing
configuration wins.
yes, thats the case (dumped the settings yesterday), but interface also 
has a real ipv6 address assigned.

The real address likely comes from the kernel allowing IPv6 RA by
default when the interface is set IFF_UP early in boot.  You appear to
have an IPv6 router on your LAN :)  So in this case, I would expect NM
to set ipv4.method=disabled, ipv6.method=auto.

Of course, that still doesn't match your manual configuration, and in
this case the fixes I talked about for NM won't have any effect, because
the interface already has some configuration and NM will try very hard
not to blow that away.

So in addition to the fix I talk about, you could modify your accept_ra
default sysctl (at boot time) to be accept_ra=0, which will prevent the
interface from receiving an IPv6 address from the router when the
interface is initially brought up in early boot, and then allow NM to
handle IPv6 instead.


We realize that treating an interface with only an IPv6LL address isn't
very useful though, especially since the kernel will assign an LL
address whenever the interface is brought IFF_UP, which often happens
during boot for various reasons.  Therefore, NM 1.0.4 and later have
switched to ignoring interface configurations that have only an IPv6LL
address, and will use another configured connection instead.  We could
potentially backport that to 0.9.10, or at least make the patch
available to distros.

can you show me the affected code-lines?  then I could wrapup the patch 
very quick.

currently I use a cron-job to keep the interfaces up.

Kind regards,
    Ingo Flaschberger

networkmanager-list mailing list
networkmanager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]