I have a weird situation after updating to F28. The current status quo is: * I have a laptop that is connected through the ethernet port to the internal network * The same laptop is connected to the public wifi With this setup I can't reach any internal servers (i.e. GOA is not obtaining my Kerberos ticket). What makes it to work is to turn off the wifi in the panel and everything is ok. Also at this point there is a question mark over the ethernet status icon in the top right menu. If I turn the wifi back on then the question mark stays there, but I can connect to internal servers with wifi connected to the public network. I'm on Fedora Workstation and using NetworkManager-1.10.6-1.fc28.x86_64
Created attachment 1419780 [details] journal log with 'nmcli general logging level debug domains all'
With Vlada Benes we indentified that it's NetworkManager-config-connectivity-fedora-1.10.6-1.fc28.noarch what's causing the issues. 130 $ ip r default via 10.200.159.254 dev wlp3s0 proto dhcp metric 600 default via 10.43.12.254 dev enp0s25 proto dhcp metric 20100 10.43.12.0/24 dev enp0s25 proto kernel scope link src 10.43.12.76 metric 100 10.200.152.0/21 dev wlp3s0 proto kernel scope link src 10.200.154.229 metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
It's a problem with rp_filter, which should be set to 0 (disabled) or 2 (loose) for the ethernet and wifi to coexist nicely. The regression is due to a change in the default sysctl configuration and how NM handles it. On F27: $ grep -r rp_filter /usr/lib/sysctl.d/ /usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.rp_filter = 1 /usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.all.rp_filter = 1 On F28: $ grep -r rp_filter /usr/lib/sysctl.d/ /usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.all.rp_filter = 1 This means that the default rp_filter for wlp3s0 on F28 is zero, which is good. But the kernel uses for wlp3s0 the maximum value between: net/ipv4/conf/wlp3s0/rp_filter net/ipv4/conf/all/rp_filter which is 1 and is bad. Moreover, since the current value is 0 for the interface, NM doesn't change it [1]. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device.c?id=43dee5f1925f2d2b406eeee9ee27d4d28c6c64b7#n3194 I think NM should be more smart and overwrite the 0 rp_filter value with 2 if the effective value is 1.
Created attachment 1419925 [details] [PATCH] device: look at 'all' rp_filter value too to determine actual value
(In reply to Beniamino Galvani from comment #4) > Created attachment 1419925 [details] > [PATCH] device: look at 'all' rp_filter value too to determine actual value lgtm
Applied to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=150cf44d501c82810e7033b7a8278713919d1d89 and nm-1-10. Can you please check if the following scratch build resolves the issue? https://koji.fedoraproject.org/koji/taskinfo?taskID=26325258
(In reply to Beniamino Galvani from comment #10) > Can you please check if the following scratch build resolves the issue? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=26325258 Thank you for the build! I installed it and will try it once I got to the office (on Tuesday).
(In reply to Beniamino Galvani from comment #10) > Can you please check if the following scratch build resolves the issue? Yes, it resolves the issue! Thank you!
NetworkManager-1.10.6-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6b92080fcc
NetworkManager-1.10.6-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6b92080fcc
NetworkManager-1.10.6-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.