GNOME Bugzilla – Bug 790423
Cannot connect to Ethernet network with 1.10.0
Last modified: 2017-11-17 12:49:16 UTC
Created attachment 363784 [details] NetworkManger log I just updated NetworkManger from 1.8.4 to the newest 1.10.0. However after the update,I cannot connect to ethernet via static IP. My distribution is Arch Linux x86_64 with linux kernel 4.13.11-1-ARCH. My ethernet device is "03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)". And the NetworkManager logs are in the attachment.
Created attachment 363785 [details] dmesg output, but with information about 1.8.4 mixed.
How do you determine that the static ethernet connection fails? From the attached logs it seems to succeed: device (enp3s0f1): Activation: starting connection 'staticIP' (c6a7fc6c-e735-4f9e-8781-f753c7fc6afa) ... device (enp3s0f1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') device (enp3s0f1): Activation: successful, device activated. Can you show the output of 'nmcli; ip a; ip r' after the failure?
(In reply to Beniamino Galvani from comment #2) > How do you determine that the static ethernet connection fails? From the > attached logs it seems to succeed: > > device (enp3s0f1): Activation: starting connection 'staticIP' > (c6a7fc6c-e735-4f9e-8781-f753c7fc6afa) > ... > device (enp3s0f1): state change: secondaries -> activated (reason 'none', > sys-iface-state: 'managed') > device (enp3s0f1): Activation: successful, device activated. > > Can you show the output of 'nmcli; ip a; ip r' after the failure? After I upgraded to 1.10.0, I cannot browse and ping any websites. Chrome just shows that there is no network connected, and there is a question mark on the tray icon of network manager. However, when I downgraded it to 1.8.4, the network worked again. I upgraded to 1.10.0 again just now, and I still cannot connect to the ethernet, but I can connect to wifi. The output of nmcli: enp3s0f1: connected to staticIP "Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" ethernet (r8169), 38:D5:47:3E:5B:95, hw, mtu 1500 ip6 default inet4 49.140.86.131/24 route4 49.140.86.0/24 inet6 2001:da8:b000:6603:70a2:9b4:e031:3a9/64 inet6 fe80::96a0:bdaf:e26f:ec20/64 route6 2001:da8:b000:6603::/64 route6 ::/0 route6 ff00::/8 route6 fe80::/64 route6 fe80::/64 wlp2s0: unavailable "Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter" wifi (ath9k), C2:8C:EB:AB:A6:5D, hw, mtu 1500 lo: unmanaged "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 10.10.10.10 interface: enp3s0f1 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.enp3s0f1: connected to staticIP "Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" ethernet (r8169), 38:D5:47:3E:5B:95, hw, mtu 1500 ip6 default inet4 49.140.86.131/24 route4 49.140.86.0/24 inet6 2001:da8:b000:6603:70a2:9b4:e031:3a9/64 inet6 fe80::96a0:bdaf:e26f:ec20/64 route6 2001:da8:b000:6603::/64 route6 ::/0 route6 ff00::/8 route6 fe80::/64 route6 fe80::/64 wlp2s0: unavailable "Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter" wifi (ath9k), C2:8C:EB:AB:A6:5D, hw, mtu 1500 lo: unmanaged "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 10.10.10.10 interface: enp3s0f1 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. The output of ip a: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 38:d5:47:3e:5b:95 brd ff:ff:ff:ff:ff:ff inet 49.140.86.131/24 brd 49.140.86.255 scope global noprefixroute enp3s0f1 valid_lft forever preferred_lft forever inet6 2001:da8:b000:6603:70a2:9b4:e031:3a9/64 scope global dynamic noprefixroute valid_lft 2591970sec preferred_lft 604770sec inet6 fe80::96a0:bdaf:e26f:ec20/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether c2:8c:eb:ab:a6:5d brd ff:ff:ff:ff:ff:ff The output of ip r: 49.140.86.0/24 dev enp3s0f1 proto kernel scope link src 49.140.86.131 metric 100
Can you also attach the log.txt file produced by these commands: nmcli general logging level trace nmcli connection up staticIP journalctl -u NetworkManager --since "2 minutes ago" > log.txt And also, can you please downgrade to 1.8.4, connect to the ethernet network and then paste the output of 'nmcli; ip a; ip r'? Thanks!
(In reply to Beniamino Galvani from comment #4) > Can you also attach the log.txt file produced by these commands: > > nmcli general logging level trace > nmcli connection up staticIP > journalctl -u NetworkManager --since "2 minutes ago" > log.txt > > And also, can you please downgrade to 1.8.4, connect to the ethernet network > and then paste the output of 'nmcli; ip a; ip r'? Thanks! I just downgraded to 1.8.4, and now I give you the output of nmcli and ip. Then I will upgrade to 1.10.0 and give you the log. Below is output of 1.8.4 The output of nmcli: enp3s0f1: connected to staticIP "Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" ethernet (r8169), 38:D5:47:3E:5B:95, hw, mtu 1500 ip4 default, ip6 default inet4 49.140.86.131/24 inet6 2001:da8:b000:6603:70a2:9b4:e031:3a9/64 inet6 fe80::96a0:bdaf:e26f:ec20/64 route6 2001:da8:b000:6603::/64 wlp2s0: unavailable "Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter" wifi (ath9k), BE:2F:71:AA:79:AB, hw, mtu 1500 lo: unmanaged "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 10.10.10.10 interface: enp3s0f1 The output of ip a: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 38:d5:47:3e:5b:95 brd ff:ff:ff:ff:ff:ff inet 49.140.86.131/24 brd 49.140.86.255 scope global enp3s0f1 valid_lft forever preferred_lft forever inet6 2001:da8:b000:6603:70a2:9b4:e031:3a9/64 scope global dynamic noprefixroute valid_lft 2591926sec preferred_lft 604726sec inet6 fe80::96a0:bdaf:e26f:ec20/64 scope link valid_lft forever preferred_lft forever 3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether be:2f:71:aa:79:ab brd ff:ff:ff:ff:ff:ff The output of ip r: default via 49.140.86.254 dev enp3s0f1 proto static metric 100 49.140.86.0/24 dev enp3s0f1 proto kernel scope link src 49.140.86.131 metric 100 I will add the logging level log of 1.10.0 in a minute.
Created attachment 363824 [details] The debug level log The log file produced by nmcli general logging level trace nmcli connection up staticIP journalctl -u NetworkManager --since "2 minutes ago" > log.txt
One last thing, please also attach the output of 'nmcli connection show staticIP'. Thanks.
Created attachment 363825 [details] nmcli connection show staticIP output
Created attachment 363898 [details] [review] [PATCH] core: don't reset gateway route when ipvx.ignore-auto-routes=yes This should fix the issue. To make the connection work again without upgrading you could also do: nmcli connection modify staticIP ipv4.ignore-auto-routes no which should not have any other observable effect for connections with static IP.
(In reply to Beniamino Galvani from comment #9) > Created attachment 363898 [details] [review] [review] > [PATCH] core: don't reset gateway route when ipvx.ignore-auto-routes=yes > > This should fix the issue. > > To make the connection work again without upgrading you could also do: > > nmcli connection modify staticIP ipv4.ignore-auto-routes no > > which should not have any other observable effect for connections with > static IP. it seems, if we don't want to use auto-routes, we shouldn't merge them in the first place. Instead of resetting them in nm_ip4_config_merge_setting(). That should already happen correctly via NM_IP_CONFIG_MERGE_NO_ROUTES. Can you not just drop nm_ip4_config_reset_routes() in nm_ip4_config_merge_setting()?
(In reply to Beniamino Galvani from comment #9) > Created attachment 363898 [details] [review] [review] > [PATCH] core: don't reset gateway route when ipvx.ignore-auto-routes=yes > > This should fix the issue. > > To make the connection work again without upgrading you could also do: > > nmcli connection modify staticIP ipv4.ignore-auto-routes no > > which should not have any other observable effect for connections with > static IP. Thanks so much! I used the shell command you gave, and then I can connect to the ethernet network again with 1.10.0. I didn't use the patch, but I think you can add it to your next version. The command solved my problem.Now I can use the newest 1.10.0 happily. You know, as an Archer, I always like the newest things. Thanks again.
Created attachment 363909 [details] [review] [PATCH v2 1/2] vpn: avoid adding unneeded routes when ipvx.ignore-auto-routes=yes
Created attachment 363910 [details] [review] [PATCH v2 2/2] core: don't reset existing routes when merging IP setting
(In reply to Thomas Haller from comment #10) > it seems, if we don't want to use auto-routes, we shouldn't merge them in > the first place. Instead of resetting them in nm_ip4_config_merge_setting(). > > That should already happen correctly via NM_IP_CONFIG_MERGE_NO_ROUTES. Can > you not just drop nm_ip4_config_reset_routes() in > nm_ip4_config_merge_setting()? The VPN code added routes without checking the ignore-auto-routes setting. I fixed that and then the reset can be dropped. How about v2? I don't have a strong preference between the previous solution (v1) and this.
v2 lgtm
v2 applied to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=8f677a77728c1f4434283d1a39f501c48eaef654 https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a0cd75b20c4bda0eb38c1c4b356d5da95822f592 and nm-1-10.