Bug 1091720 - NetworkManager will only take TLD from DNSSL option in IPv6 router advertisement
Summary: NetworkManager will only take TLD from DNSSL option in IPv6 router advertisement
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libndp
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Jiri Pirko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-27 15:02 UTC by Peter Bieringer
Modified: 2014-07-30 06:55 UTC (History)
2 users (show)

Fixed In Version: libndp-1.3-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1091721 (view as bug list)
Environment:
Last Closed: 2014-07-30 06:55:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Peter Bieringer 2014-04-27 15:02:02 UTC
Description of problem:

radvd is distributing DNSSL option like

        DNSSL test.example {
                AdvDNSSLLifetime 600;
        };

But NetwormManager only takes ".example" and store this in /etc/resolv.conf


Version-Release number of selected component (if applicable):
NetworkManager-0.9.9.0-38.git20131003.fc20.i686
NetworkManager-0.9.9.0-25.git20131108.el7.x86_647

How reproducible:
Always


Steps to Reproduce:
1. configure a router with radvd option

        DNSSL test.example {
                AdvDNSSLLifetime 600;
        };

2. restart radvd
3. check /etc/resolv.conf on client system

Actual results:

# egrep '(domain|search)' /etc/resolv.conf 
domain .example
search .example



Expected results:
domain test.example
search test.example


Additional info:

enabled debugging in NetworkManager shows (played around with test.com also):

Apr 27 16:53:02 ipv6-client-fedora NetworkManager[529]: <debug> [1398610382.552528] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .com exp 7420
Apr 27 16:53:12 ipv6-client-fedora NetworkManager[529]: <debug> [1398610392.50782] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain example exp 7430
Apr 27 16:53:32 ipv6-client-fedora NetworkManager[529]: <debug> [1398610412.486412] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7450
Apr 27 16:53:48 ipv6-client-fedora NetworkManager[529]: <debug> [1398610428.495453] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7466
Apr 27 16:54:04 ipv6-client-fedora NetworkManager[529]: <debug> [1398610444.499166] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7482
Apr 27 16:54:20 ipv6-client-fedora NetworkManager[529]: <debug> [1398610460.508830] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7498
Apr 27 16:54:59 ipv6-client-fedora NetworkManager[529]: <debug> [1398610499.16039] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7537
Apr 27 16:55:43 ipv6-client-fedora NetworkManager[529]: <debug> [1398610543.19664] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7581
Apr 27 16:56:20 ipv6-client-fedora NetworkManager[529]: <debug> [1398610580.8978] [rdisc/nm-rdisc.c:134] config_changed():   dns_domain .example exp 7618

tcpdump shows complete domain, so radvd is not causing the problem

	0x0050:  0000 0000 0000 0000 1903 0000 0000 0258  ...............X
	0x0060:  2001 06f8 0900 8cbc 0000 0000 0000 0001  ................
	0x0070:  1f03 0000 0000 0258 0474 6573 7407 6578  .......X.test.ex
	0x0080:  616d 706c 6500 0000 0101 5254 009d 8a49  ample.....RT...I

Comment 1 Peter Bieringer 2014-04-28 06:07:33 UTC
Fedora Rawhide NetworkManager has same issue
NetworkManager-0.9.9.1-5.git20140319.fc21.i686


Apr 28 08:06:15 ipv6-client-fedora-rawhide NetworkManager[638]: <debug> [1398665175.834363] [rdisc/nm-rdisc.c:140] config_changed():   dns_domain .example exp 7210


Ubuntu 14.04 handles this different:

# dpkg -l |grep NetworkManager
ii  gir1.2-networkmanager-1.0                             0.9.8.8-0ubuntu7

Apr 28 07:34:04 ipv6-ubuntu NetworkManager[625]: <debug> [1398663244.924714] [nm-ip6-manager.c:1216] process_nduseropt(): processing netlink nduseropt message
Apr 28 07:34:04 ipv6-ubuntu NetworkManager[625]: <debug> [1398663244.924878] [nm-ip6-manager.c:1179] process_nduseropt_dnssl(): (eth1): found RA-provided domain demo.bieringer.de (expires in 7200 seconds)


but misses the IPv6 DNS server, which is also distributed

# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search test.example

Comment 2 Dan Williams 2014-05-16 18:39:07 UTC
(In reply to Peter Bieringer from comment #1)
> Fedora Rawhide NetworkManager has same issue
> NetworkManager-0.9.9.1-5.git20140319.fc21.i686
> 
> 
> Apr 28 08:06:15 ipv6-client-fedora-rawhide NetworkManager[638]: <debug>
> [1398665175.834363] [rdisc/nm-rdisc.c:140] config_changed():   dns_domain
> .example exp 7210
> 
> 
> Ubuntu 14.04 handles this different:
> 
> # dpkg -l |grep NetworkManager
> ii  gir1.2-networkmanager-1.0                             0.9.8.8-0ubuntu7
> 
> Apr 28 07:34:04 ipv6-ubuntu NetworkManager[625]: <debug> [1398663244.924714]
> [nm-ip6-manager.c:1216] process_nduseropt(): processing netlink nduseropt
> message
> Apr 28 07:34:04 ipv6-ubuntu NetworkManager[625]: <debug> [1398663244.924878]
> [nm-ip6-manager.c:1179] process_nduseropt_dnssl(): (eth1): found RA-provided
> domain demo.bieringer.de (expires in 7200 seconds)
> 
> 
> but misses the IPv6 DNS server, which is also distributed
> 
> # cat /etc/resolv.conf 
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8)
> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> nameserver 127.0.1.1
> search test.example

NetworkManager in Fedora is not built with resolvconf support and expects to manage /etc/resolv.conf by itself.   Does your system have resolvconf enabled?  If so, it will fight with NetworkManager.

Comment 3 Dan Williams 2014-05-16 19:44:27 UTC
This is a bug in libndp and is fixed by the commit 4376e752c822444f1a26b5e1e974ddd7104ae15c.  The F20 packages need to be updated to include that patch. Over to libndp for that...

Comment 4 Fedora Update System 2014-05-16 20:06:05 UTC
libndp-1.2-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libndp-1.2-2.fc20

Comment 5 Peter Bieringer 2014-05-16 20:25:18 UTC
Fixed now:

# more /etc/resolv.conf 
# Generated by NetworkManager
domain test.example
search test.example

# more /etc/resolv.conf 
# Generated by NetworkManager
domain demo.bieringer.de
search demo.bieringer.de

also NetworkManager shows the value:

# nmcli c show active "Kabelgebundene Verbindung 1" | grep DOMAIN
IP6.DOMAIN[1]:                          demo.bieringer.de


Regarding

> NetworkManager in Fedora is not built with resolvconf support and expects to manage /etc/resolv.conf by itself.   Does your system have resolvconf enabled?  If so, it will fight with NetworkManager.

Are you sure? I see here same behavior as on RHEL7, not aware that I have changed anything on the system regarding "resolvconf"

Comment 6 Fedora Update System 2014-05-17 06:31:08 UTC
Package libndp-1.2-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libndp-1.2-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6451/libndp-1.2-2.fc20
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2014-06-26 10:13:15 UTC
libndp-1.3-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libndp-1.3-1.fc20

Comment 8 Fedora Update System 2014-07-29 13:44:28 UTC
libndp-1.4-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libndp-1.4-1.fc20

Comment 9 Fedora Update System 2014-07-30 06:55:49 UTC
libndp-1.3-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.