DNS problem with NetworkManager

StefanVater · February 20, 2019, 10:45am

Hi,

after a recent update my network connection stopped working. I can start a connection and everything seems fine. But I cannot access a website through my browser. ping directly an IP address on the command line works however. My /etc/resolv.conf looks good and is also updated by NetworkManager. Even nslookup works for e.g. conncheck.opensuse.org

Looking at the logs, tells me that the connectivity check in NM fails, and that NM has no global connectivity. But that seems to be related to the failure of dns configuration.

Can it be that routing is not set properly? How can I check?

Any help would be appreciated.

Sauerland · February 20, 2019, 11:53am

Try as root:

netconfig update -f

StefanVater · February 20, 2019, 12:43pm

Thanks, I already tried that multiple times. It updates my resolv.conf, but does not change anything. I just does not seem to set the routing properly.

StefanVater · February 20, 2019, 1:27pm

No correct route is set:


# nmcli dev show
...]
IP4.GATEWAY:                            10.0.0.1
IP4.ROUTE[1]:                           dst = 0.0.0.0/0, nh = 10.0.0.1, mt = 20600
IP4.ROUTE[2]:                           dst = 10.0.0.0/8, nh = 0.0.0.0, mt = 600
IP4.DNS[1]:                             160.45.8.8
IP4.DNS[2]:                             160.45.10.12
IP4.DNS[3]:                             130.133.1.57
...]

I hope that clarifies the situation.

tsu2 · February 20, 2019, 4:43pm

You can use ping and traceroute to test your Gateway, whether you can reach it and beyond. First test by IP address to verify IP networking connectivity, then test by hostname to verify whether name resolution is working properly.

TSU

StefanVater · February 20, 2019, 5:34pm

Hi, thanks for your help. Here is the output of ping and traceroute:


linux:/home/user # ping 216.58.206.4
PING 216.58.206.4 (216.58.206.4) 56(84) bytes of data.
64 bytes from 216.58.206.4: icmp_seq=1 ttl=54 time=11.3 ms
64 bytes from 216.58.206.4: icmp_seq=2 ttl=54 time=11.1 ms
64 bytes from 216.58.206.4: icmp_seq=3 ttl=54 time=11.1 ms
^C
--- 216.58.206.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 11.082/11.180/11.319/0.132 ms
linux:/home/user # ping www.google.com
ping: www.google.com: Der Name oder der Dienst ist nicht bekannt
linux:/home/user # traceroute 216.58.206.4
traceroute to 216.58.206.4 (216.58.206.4), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.867 ms  1.826 ms  3.038 ms
 2  160.45.254.3 (160.45.254.3)  4.760 ms  4.752 ms  6.118 ms
 3  160.45.254.65 (160.45.254.65)  6.131 ms  6.769 ms  7.416 ms
 4  160.45.252.101 (160.45.252.101)  7.571 ms  8.943 ms  9.013 ms
 5  188.1.234.173 (188.1.234.173)  14.815 ms  16.178 ms  17.679 ms
 6  188.1.144.133 (188.1.144.133)  23.619 ms  22.630 ms  22.161 ms
 7  80.81.192.108 (80.81.192.108)  22.091 ms  20.774 ms  21.130 ms
 8  108.170.251.193 (108.170.251.193)  20.897 ms 108.170.252.65 (108.170.252.65)  25.898 ms  25.473 ms
 9  216.239.56.151 (216.239.56.151)  24.763 ms 216.239.56.149 (216.239.56.149)  24.439 ms  23.655 ms
10  216.58.206.4 (216.58.206.4)  21.442 ms  16.802 ms  16.516 ms
linux:/home/user # traceroute www.google.com
www.google.com: Der Name oder der Dienst ist nicht bekannt
Cannot handle "host" cmdline arg `www.google.com' on position 1 (argc 1)

So, what shall I do?

karlmistelberger · February 20, 2019, 7:12pm

I configured Yast2 > Networking > Routing > Hostname/DNS: 192.168.178.1:

erlangen:~ # ip route
default via 192.168.178.1 dev wlp3s0 proto dhcp 
192.168.178.0/24 dev wlp3s0 proto kernel scope link src 192.168.178.29 
erlangen:~ #

StefanVater · February 21, 2019, 12:16pm

But this means that you are using wicked, which also does not work in my case. So it seems, my update broke something else.

When I look at the log (note that today it is a bit different internet connection):

Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3698] device[0x55e5cb87d690] (wlp2s0): queued IP4 config change
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3699] platform-linux: event-notification: RTM_NEWROUTE, flags excl,create, seq 0: ignore
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3699] platform-linux: event-notification: RTM_NEWROUTE, flags excl,create, seq 0: ignore
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3699] platform-linux: event-notification: RTM_NEWROUTE, flags excl,create, seq 0: ignore
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3699] platform-linux: do-add-ip4-address[2: 192.168.0.6/24]: success
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3699] platform: route: append     IPv4 route: 192.168.0.0/24 via 0.0.0.0 dev 2 metric 600 mss 0 rt-src rt-kernel scope link pref-src 192.168.0.6
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3700] platform-linux: event-notification: RTM_NEWROUTE, flags excl,create, seq 45: 192.168.0.0/24 via 0.0.0.0 dev 2 metric 600 mss 0 rt-src rt-kernel scope link pref-src 192.168.0.6
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3700] platform: signal: route   4   added: 192.168.0.0/24 via 0.0.0.0 dev 2 metric 600 mss 0 rt-src rt-kernel scope link pref-src 192.168.0.6
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3700] platform-linux: do-add-ip4-route[192.168.0.0/24 via 0.0.0.0 dev 2 metric 600 mss 0 rt-src rt-kernel scope link pref-src 192.168.0.6]: success
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3700] platform: route: append     IPv4 route: 0.0.0.0/0 via 192.168.0.1 dev 2 metric 20600 mss 0 rt-src dhcp
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3701] platform-linux: event-notification: RTM_NEWROUTE, flags excl,create, seq 46: 0.0.0.0/0 via 192.168.0.1 dev 2 metric 20600 mss 0 rt-src rt-dhcp scope global
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3701] platform: signal: route   4   added: 0.0.0.0/0 via 192.168.0.1 dev 2 metric 20600 mss 0 rt-src rt-dhcp scope global
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3701] platform-linux: do-add-ip4-route[0.0.0.0/0 via 192.168.0.1 dev 2 metric 20600 mss 0 rt-src rt-dhcp scope global]: success
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3702] platform: ip4-dev-route: register 192.168.0.0/24 via 0.0.0.0 dev 2 metric 0 mss 0 rt-src rt-kernel scope link pref-src 192.168.0.6
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3702] dbus-object[0x55e5cb7823c0]: export: "/org/freedesktop/NetworkManager/IP4Config/4"
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3705] device[0x55e5cb87d690] (wlp2s0): ip4-config: set IP Config instance (/org/freedesktop/NetworkManager/IP4Config/4)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3705] platform-linux: sysctl: reading '/proc/sys/net/ipv4/conf/wlp2s0/rp_filter': '0'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3706] platform-linux: sysctl: reading '/proc/sys/net/ipv4/conf/all/rp_filter': '1'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3706] platform-linux: sysctl: setting '/proc/sys/net/ipv4/conf/wlp2s0/rp_filter' to '2' (current value is '0')
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3708] dns-mgr: (device_ip_config_changed): queueing DNS updates (1)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3708] dns-mgr: (device_ip_config_changed): DNS configuration did not change
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3712] dns-mgr: (device_ip_config_changed): no DNS changes to commit (0)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3712] device[0x55e5cb87d690] (wlp2s0): remove_pending_action (1): 'dhcp4'
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3712] device[0x55e5cb87d690] (wlp2s0): ip4-state: set to 3 (done)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3713] active-connection[0x55e5cb7820d0]: set state-flags layer2-ready,ip4-ready (was layer2-ready)
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3714] device (wlp2s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3717] dispatcher: (3) (wlp2s0) dispatching action 'pre-up' (with callback)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3718] dispatcher: (3) simulate request; no scripts in /etc/NetworkManager/dispatcher.d/pre-up.d
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3723] device[0x55e5cb87d690] (wlp2s0): activation-stage: complete activate_stage5_ip4_config_result,v4 (id 3946)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3724] device[0x55e5cb87d690] (wlp2s0): ip4-config: update (commit=0, new-config=0x55e5cb7829b0)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3724] platform-linux: sysctl: reading '/proc/sys/net/ipv4/conf/wlp2s0/rp_filter': '2' (changed from '0' on last read)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3725] device[0x55e5cb87d690] (wlp2s0): add_pending_action (2): 'queued-state-change-secondaries'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3725] device[0x55e5cb87d690] (wlp2s0): queue-state[secondaries, reason:none, id:3951]: queue state change
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3726] device[0x55e5cb87d690] (wlp2s0): queue-state[secondaries, reason:none, id:3951]: change state
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3726] device (wlp2s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3728] device[0x55e5cb87d690] (wlp2s0): add_pending_action (3): 'queued-state-change-activated'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3728] device[0x55e5cb87d690] (wlp2s0): queue-state[activated, reason:none, id:3952]: queue state change
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3729] device[0x55e5cb87d690] (wlp2s0): device entered SECONDARIES state
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3729] device[0x55e5cb87d690] (wlp2s0): remove_pending_action (2): 'queued-state-change-secondaries'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3729] device[0x55e5cb87d690] (wlp2s0): queue-state[activated, reason:none, id:3952]: change state
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3729] device (wlp2s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3734] config: device-state: write #2 (/run/NetworkManager/devices/2); managed=managed, connection-uuid=c162e5d8-9f8f-4e39-ad6a-c0f44e71256f, route-metric-default=600-600
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3734] active-connection[0x55e5cb7820d0]: set state activated (was activating)
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3736] manager: NetworkManager state is now CONNECTED_LOCAL
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3737] active-connection[0x55e5cb7820d0]: check-master-ready: not signalling (state activated, no master)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3741] device[0x55e5cb87d690] (wlp2s0): remove_pending_action (1): 'activation-0x55e5cb7820d0'
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3794] settings-connection[0x55e5cb780b90,c162e5d8-9f8f-4e39-ad6a-c0f44e71256f]: autoconnect: retries set 4 (reset)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3801] dns-mgr: (device_state_changed): queueing DNS updates (1)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3803] dns-mgr: (update_routing_and_dns): queueing DNS updates (2)
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3805] manager: NetworkManager state is now CONNECTED_SITE
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3811] policy: set 'homenetwork' (wlp2s0) as default for IPv4 routing and DNS
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3811] manager: PrimaryConnection now homenetwork
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] policy: set-hostname: updating hostname (routing and dns)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] policy: get-hostname: "linux"
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] policy: get-hostname: "linux"
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] policy: set-hostname: hostname already set to 'linux' (from system configuration)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3814] dns-mgr: (update_routing_and_dns): DNS configuration changed
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3814] dns-mgr: (update_routing_and_dns): no DNS changes to commit (1)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3814] dns-mgr: (device_state_changed): DNS configuration changed
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3814] dns-mgr: (device_state_changed): committing DNS changes (0)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3814] dns-mgr: update-dns: updating resolv.conf
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] dns-mgr: config:      100 best    v4 2     : 192.168.0.1
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3815] dns-mgr: spawning '/sbin/netconfig modify --service NetworkManager'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3849] dns-mgr: writing to netconfig: INTERFACE='NetworkManager'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3849] dns-mgr: writing to netconfig: DNSSEARCH='localdomain'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3849] dns-mgr: writing to netconfig: DNSSERVERS='192.168.0.1'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3850] kill child process 'netconfig' (4054): waiting for process to terminate after sending no signal (0)...
Feb 21 10:15:59 linux NetworkManager[1332]: nisdomainname: you must be root to change the domain name
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.6993] kill child process 'netconfig' (4054): after sending no signal (0), process 4054 exited normally with status 0 (314382 usec elapsed)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.6995] dns-mgr: update-resolv-conf: write internal file /run/NetworkManager/resolv.conf succeeded
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.6997] dns-mgr: current configuration: {'nameservers': <'192.168.0.1']>, 'domains': <'localdomain']>, 'interface': <'wlp2s0'>, 'priority': <100>, 'vpn': <false>}]
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.6998] device (wlp2s0): Activation: successful, device activated.
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.6998] device[0x55e5cb87d690] (wlp2s0): set metered value 4
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7000] manager: new metered value: 4
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7001] dispatcher: (4) (wlp2s0) dispatching action 'up'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7008] create NMPacrunnerManager singleton (0x55e5cb8a6b00)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7009] pacrunner: call[0x7fab200a06c0]: send: new config ({'Interface': <'wlp2s0'>, 'Method': <'direct'>, 'BrowserOnly': <false>},)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.7009] device[0x55e5cb87d690] (wlp2s0): connectivity: periodic-check: re-scheduled in 1000 milliseconds (1 seconds interval)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.7009] device[0x55e5cb87d690] (wlp2s0): connectivity: start check (seq:13, periodic-check)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7009] connectivity: (wlp2s0) start request to 'http://conncheck.opensuse.org'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7009] device[0x55e5cb87d690] (wlp2s0): remove_pending_action (0): 'queued-state-change-activated'
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7010] bus-manager: (dhcp) closed connection 0x55e5cb76e7b0 on private socket
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7040] connectivity: (wlp2s0) check completed: LIMITED; check failed with curl status 6
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.7042] device[0x55e5cb87d690] (wlp2s0): connectivity: complete check (seq:13, state:LIMITED)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.7043] device[0x55e5cb87d690] (wlp2s0): connectivity: periodic-check: re-scheduled in 1996 milliseconds (2 seconds interval)
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.7341] pacrunner: name owner disappeared

the difference to a working machine comes in with

Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed

Does anyone know what that means?

karlmistelberger · February 21, 2019, 12:43pm

I use both wicked and NetworkManager:

erlangen:~ # nmcli
wlp3s0: connected to FRITZ!Box Karl Mistelberger
        "Qualcomm Atheros AR9287"
        wifi (ath9k), 84:16:x:xx:xx:xx, hw, mtu 1500
        ip4 default, ip6 default
        inet4 192.168.178.20/24
        route4 0.0.0.0/0
        route4 192.168.178.0/24
        inet6 ...
...

enp0s31f6: unavailable
        "Intel Ethernet"
        ethernet (e1000e), D0:xx:xx:xx:xx:xx, hw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: fd00::xxxxxxx ....
        interface: wlp3s0

        servers: 192.168.178.1
        domains: fritz.box
        interface: wlp3s0

Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.

Consult nmcli(1) and nmcli-examples(5) manual pages for complete usage details.
erlangen:~ #

Upon installation wicked was set up. I can switch back and forth between the two and I always have working inet4 and inet6. To my experience of three years switching fixed any glitches which occurred on rare occasions.

StefanVater · February 21, 2019, 1:43pm

Unfortunately, going to wicked, or back again, did not solve my problem, so far…

karlmistelberger · February 21, 2019, 2:07pm

I have some obvious settings in YAST2 wicked:

Hostname/DNS: Hostname: erlangen, Nameserver: 192.168.178.1, Domain search: fritz.box

Interface configuration: Dynamic Address: DHCP

That’s all. When done with Yast2 you may add: systemctl restart wicked

erlangen:~ # journalctl -b -u wicked* --since 14:04
-- Logs begin at Wed 2018-10-17 14:00:43 CEST, end at Thu 2019-02-21 14:05:16 CET. --
Feb 21 14:04:44 erlangen systemd[1]: Stopping wicked managed network interfaces...
Feb 21 14:04:44 erlangen wickedd-dhcp4[28043]: wlp3s0: Request to release DHCPv4 lease with UUID ed9f6e5c-3ac9-0300-8d6d-000006000000: releasing...
Feb 21 14:04:44 erlangen wickedd-dhcp6[28044]: wlp3s0: Request to release DHCPv6 lease using UUID ed9f6e5c-3ac9-0300-8d6d-000007000000: releasing...
Feb 21 14:04:45 erlangen wicked[29353]: wlp3s0          device-ready
Feb 21 14:04:45 erlangen systemd[1]: Stopped wicked managed network interfaces.
Feb 21 14:04:45 erlangen systemd[1]: Starting wicked managed network interfaces...
Feb 21 14:04:46 erlangen wickedd-dhcp4[28043]: wlp3s0: Request to acquire DHCPv4 lease with UUID ed9f6e5c-3ac9-0300-8d6d-00000e000000
Feb 21 14:04:46 erlangen wickedd-dhcp6[28044]: wlp3s0: Request to acquire DHCPv6 lease with UUID ed9f6e5c-3ac9-0300-8d6d-00000f000000 in mode auto
Feb 21 14:04:47 erlangen wickedd-dhcp4[28043]: wlp3s0: Committed DHCPv4 lease with address 192.168.178.29 (lease time 864000 sec, renew in 432000 sec, rebind in 756000 sec)
Feb 21 14:05:15 erlangen wicked[29688]: lo              up
Feb 21 14:05:15 erlangen wicked[29688]: wlp3s0          up
Feb 21 14:05:15 erlangen systemd[1]: Started wicked managed network interfaces.
erlangen:~ #

linXea · February 21, 2019, 10:08pm

Hi,

Sorry to interupt but you describe exactly the same problem that I am experiencing. Not even a static manual route with google DNS work. Tried both NetworkManager and Wicked, nothing works. Running the latest update of Tumbleweed (20190219). With only one computer (dualboot) this is getting frustrating trying to fix. Will FOLLOW this thread carefully…

StefanVater · February 22, 2019, 5:37pm

This is interesting, but I still do not have any solution. To me it seems that it is not directly related to NetworkManager. Maybe something mixed up with polkit?

karlmistelberger · February 22, 2019, 6:35pm

What is your output of the command nmcli?

tsu2 · February 22, 2019, 7:44pm

Although I haven’t inspected closely,
It’s my general impression that on a Linux box IP addressing is handled separately from configuring DNS, the only time you <might> see the two managed together is when the machine is configured as a DHCP client and even then, that is <only to acquire> IP addressing, ip routes and DNS servers, not to actually use that information.

This likely means that your current troubleshooting only tests IP addresses, but not name resolution at all.
To troubleshoot name resolution issues, you need to use either the “host” or “nslookup” utilities, with some additional testing using PING and hostname addresses.

Your use of nmcli has very limited usefulness and of course is useful only when you have NM configured to manage your networking, the info you posted is better found with “ip addr” and “ip route”

Additionally,
You seem to be pointing your network configuration to your Fritz box.
That means you should first test and verify your Fritz box is working properly… ie If you have multiple machines in your network pointing to your Fritz box, do they all work without problems? Only after your Fritz box is proven and verified to be working perfectly can you do any troubleshooting on your LAN hosts.

As for troubleshooting hostname resolution,
One of the nice things about nslookup is its versatility.
When you first fire it up, it identifies the ip address of the DNS server being used (most likely your Fritz box)
You can then simply type in various IP addresses and hostnames of machines in your LAN or places on the Internet to verify the DNS server can return correct results in a timely manner. If you see timeouts or failures, then you know that your Fritz box needs to be looked at.
You can further test by specifying a different DNS server, so for instance if you want to test whether you machine’s name resolution might work without pointing to the default DNS server, you can specify another server by simply “server 8.8.8.8” for instance to point to a Google DNS server (no permanent changes are made to your system to do this test re-configuration). Then query for a hostname or IP address again while pointing to your new DNS server.

And so on…
After you’ve gathered info querying different DNS servers, you should be able to pinpoint where your name resolution issues are.

HTH,
TSU

linXea · February 23, 2019, 10:14am

Hi TSU,

I am aware of the neat features of NSLOOKUP. Since all I have is a dual boot laptop, pasting cmd entries is a pain. I am not he original OP and I apologize for any hijacking of this thread but I think the original poster and I share the same problem. NSLOOKUP can resolve any given IP or address (e.g. www.youtube.com). Traceroute of IP resolve the address and so on. But in the desktop environment it refuse to work or when running ‘zypper refresh’ for instance. Trying to connect directly to IP in firefox does not seem to work, maybe because very few websites allow direct IP access, however it translate the IP to the correct address eg. to www.google.com. I get a error when using web address in forefox DNS_proble_finsihed_nxdomain. Not sure what that is.

My conclusion is that my DNS settings seem to work and my headache is worsening.

karlmistelberger · February 23, 2019, 7:17pm

linXea:

Hi TSU,

I am aware of the neat features of NSLOOKUP. Since all I have is a dual boot laptop, pasting cmd entries is a pain. I am not he original OP and I apologize for any hijacking of this thread but I think the original poster and I share the same problem. NSLOOKUP can resolve any given IP or address (e.g. www.youtube.com). Traceroute of IP resolve the address and so on. But in the desktop environment it refuse to work or when running ‘zypper refresh’ for instance. Trying to connect directly to IP in firefox does not seem to work, maybe because very few websites allow direct IP access, however it translate the IP to the correct address eg. to www.google.com. I get a error when using web address in forefox DNS_proble_finsihed_nxdomain. Not sure what that is.

My conclusion is that my DNS settings seem to work and my headache is worsening.

The easiest way to access internet is to configure your router as a DHCP server and all your machines and appliances as clients: Networking Articles - dummies Routers suppiled by internet providers will configure automatically and work out of the box.

Given the above prerequisites configuring the network with Yast2 is straight forward. Whether you are using wicked or NetworkManager, whether you use a cable or wired connection does not matter. Tell Yast2 to use DHCP supplying the domain and address (fritz.box and 192.168.178.1 in my case given above) and you are done.

StefanVater · February 25, 2019, 9:57am

Dear karlmistelberger, as linXea wrote, DNS works, in that our router is set up correctly. Neither NM nor wicked works with your suggest setup on the affected machine. So I seems that the problem does not have to do with the usual setup through Yast etc.

In my case, I can easily connect to the internet with another linux box. Also nslookup works fine on the affected machine. The problem comes in, when I use a browser or any other program that needs name resolution. So my guess is, that in setting up the internet, some internal command does not work. I cannot say so far if this is a permission problem or some broken script or configuration file…

As I wrote, when I compare to my working box, the only difference I found so far was in the lines

Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3811] policy: set 'homenetwork' (wlp2s0) as default for IPv4 routing and DNS
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3811] manager: PrimaryConnection now homenetwork
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] policy: set-hostname: updating hostname (routing and dns)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] policy: get-hostname: "linux"
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] policy: get-hostname: "linux"
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] policy: set-hostname: hostname already set to 'linux' (from system configuration)

where the “transient hostname retrieval failed” lines are not present in journalctl of the working box.

My question is now: Does “policy” refer to polkit in the surrounding lines. Can this be the problem. How do I check?

karlmistelberger · February 25, 2019, 10:40am

StefanVater:

Dear karlmistelberger, as linXea wrote, DNS works, in that our router is set up correctly. Neither NM nor wicked works with your suggest setup on the affected machine. So I seems that the problem does not have to do with the usual setup through Yast etc.

In my case, I can easily connect to the internet with another linux box. Also nslookup works fine on the affected machine. The problem comes in, when I use a browser or any other program that needs name resolution. So my guess is, that in setting up the internet, some internal command does not work. I cannot say so far if this is a permission problem or some broken script or configuration file…

As I wrote, when I compare to my working box, the only difference I found so far was in the lines
Feb 21 10:15:59 linux NetworkManager[1332]: <info>  [1550740559.3811] policy: set 'homenetwork' (wlp2s0) as default for IPv4 routing and DNS
Feb 21 10:15:59 linux NetworkManager[1332]: <debug> [1550740559.3811] manager: PrimaryConnection now homenetwork
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] policy: set-hostname: updating hostname (routing and dns)
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] policy: get-hostname: "linux"
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3813] hostname: transient hostname retrieval failed
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] policy: get-hostname: "linux"
Feb 21 10:15:59 linux NetworkManager[1332]: <trace> [1550740559.3814] policy: set-hostname: hostname already set to 'linux' (from system configuration)
where the “transient hostname retrieval failed” lines are not present in journalctl of the working box.

My question is now: Does “policy” refer to polkit in the surrounding lines. Can this be the problem. How do I check?

Policy does not refer to polkit. Make sure your router is properly set up: http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7360-avm/014/hilfe_clients

Check for clashes on the corresponding page of your router.
Make sure your machine is configured as client
If not succeeding post the output of the two commands below

erlangen:~ # journalctl -b -u NetworkManager | grep policy
Feb 25 05:49:27 erlangen NetworkManager[1023]: <info>  [1551070167.6245] policy: auto-activating connection 'FRITZ!Box Karl Mistelberger' (036bfd93-ed1b-452e-b982-2939fc8811f3)
Feb 25 05:49:28 erlangen NetworkManager[1023]: <info>  [1551070168.7353] policy: set 'FRITZ!Box Karl Mistelberger' (wlp3s0) as default for IPv4 routing and DNS
Feb 25 05:49:30 erlangen NetworkManager[1023]: <info>  [1551070170.9992] policy: set 'FRITZ!Box Karl Mistelberger' (wlp3s0) as default for IPv6 routing and DNS
erlangen:~ #

erlangen:~ # journalctl -b -u NetworkManager -p5
-- Logs begin at Wed 2018-10-17 14:00:43 CEST, end at Mon 2019-02-25 10:26:54 CET. --
-- No entries --
erlangen:~ #

StefanVater · February 25, 2019, 1:36pm

Dear karlmistelberger,

thank you for your continuous suggestions. I am not sure, how I can check 1. and 2. My router is not a Fritz.box, but when I connect to the router, it shows me that my box is connected as a client and has an ip.

Here is the output of the two commands:

linux:/home/user # journalctl -u NetworkManager  | grep policy
Feb 25 12:31:26 linux NetworkManager[14192]: <debug> [1551094286.9644] policy: re-enabling autoconnect for all connections (only clear no-secrets flag)Feb 25 12:32:46 linux NetworkManager[1318]: <trace> [1551094366.4421] policy: get-hostname: "linux" (from dbus)
Feb 25 12:32:46 linux NetworkManager[1318]: <trace> [1551094366.4421] policy: hostname-original: set to "linux"
Feb 25 12:32:46 linux NetworkManager[1318]: <debug> [1551094366.4424] policy: hostname-mode: full
Feb 25 12:34:29 linux NetworkManager[1318]: <debug> [1551094469.7692] policy: re-enabling autoconnect for all connections (only clear no-secrets flag)
Feb 25 12:35:00 linux NetworkManager[1318]: <trace> [1551094500.0892] device[0x55be9e46b2b0] (wlp2s0): ipv4.route-table = 254 (policy routing not enabled)
Feb 25 12:35:00 linux NetworkManager[1318]: <trace> [1551094500.1036] device[0x55be9e46b2b0] (wlp2s0): ipv6.route-table = 254 (policy routing not enabled)
Feb 25 12:35:00 linux NetworkManager[1318]: <info>  [1551094500.9868] policy: set 'homenetwork' (wlp2s0) as default for IPv4 routing and DNS
Feb 25 12:35:00 linux NetworkManager[1318]: <trace> [1551094500.9870] policy: set-hostname: updating hostname (routing and dns)
Feb 25 12:35:00 linux NetworkManager[1318]: <trace> [1551094500.9870] policy: get-hostname: "linux"
Feb 25 12:35:00 linux NetworkManager[1318]: <trace> [1551094500.9871] policy: get-hostname: "linux"
Feb 25 12:35:00 linux NetworkManager[1318]: <trace> [1551094500.9871] policy: set-hostname: hostname already set to 'linux' (from system configuration)
Feb 25 12:35:01 linux NetworkManager[1318]: <trace> [1551094501.5048] policy: set-hostname: updating hostname (ip6 conf)
Feb 25 12:35:01 linux NetworkManager[1318]: <trace> [1551094501.5049] policy: get-hostname: "linux"
Feb 25 12:35:01 linux NetworkManager[1318]: <trace> [1551094501.5049] policy: get-hostname: "linux"
Feb 25 12:35:01 linux NetworkManager[1318]: <trace> [1551094501.5049] policy: set-hostname: hostname already set to 'linux' (from system configuration)

linux:/home/svater # journalctl -b -u NetworkManager -p5-- Logs begin at Sun 2018-12-02 17:54:27 CET, end at Mon 2019-02-25 13:32:48 CET. --
Feb 25 12:35:46 linux NetworkManager[1318]: <warn>  [1551094546.6991] dhcp6 (wlp2s0): request timed out
Feb 25 13:12:00 linux NetworkManager[1318]: <warn>  [1551096720.9865] sup-iface[0x55be9e36c0d0,wlp2s0]: connection disconnected (reason -3)
Feb 25 13:12:59 linux NetworkManager[1318]: <warn>  [1551096779.3200] dhcp6 (wlp2s0): request timed out

On the working machine, I have also the “request timed out”, but not the sup-iface message.

Any clues?