Bug 1565529

Summary: Cannot access internal network through eth, when wifi connected
Product: [Fedora] Fedora Reporter: Tomas Popela <tpopela>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: alexl, bgalvani, dcbw, fgiudici, john.j5live, lkundrak, mclasen, rhughes, rstrode, sandmann, thaller, tpopela, vbenes
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.10.6-2.fc28 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-27 04:05:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
journal log with 'nmcli general logging level debug domains all'
none
[PATCH] device: look at 'all' rp_filter value too to determine actual value none

Description Tomas Popela 2018-04-10 08:40:07 UTC
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

Comment 1 Tomas Popela 2018-04-10 09:12:56 UTC
Created attachment 1419780 [details]
journal log with 'nmcli general logging level debug domains all'

Comment 2 Tomas Popela 2018-04-10 09:14:05 UTC
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

Comment 3 Beniamino Galvani 2018-04-10 13:20:14 UTC
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.

Comment 4 Beniamino Galvani 2018-04-10 14:40:01 UTC
Created attachment 1419925 [details]
[PATCH] device: look at 'all' rp_filter value too to determine actual value

Comment 9 Thomas Haller 2018-04-12 07:21:16 UTC
(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

Comment 10 Beniamino Galvani 2018-04-12 13:04:06 UTC
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

Comment 11 Tomas Popela 2018-04-12 14:05:58 UTC
(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).

Comment 12 Tomas Popela 2018-04-17 06:34:07 UTC
(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!

Comment 13 Fedora Update System 2018-04-17 08:03:22 UTC
NetworkManager-1.10.6-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6b92080fcc

Comment 14 Fedora Update System 2018-04-17 18:09:01 UTC
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

Comment 15 Fedora Update System 2018-04-27 04:05:37 UTC
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.