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: > >> Hi, > >> > >> 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. Dan > > 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
