Bug 1565529 - Cannot access internal network through eth, when wifi connected
Summary: Cannot access internal network through eth, when wifi connected
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Beniamino Galvani
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-10 08:40 UTC by Tomas Popela
Modified: 2018-04-27 04:05 UTC (History)
13 users (show)

Fixed In Version: NetworkManager-1.10.6-2.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-27 04:05:37 UTC
Type: Bug


Attachments (Terms of Use)
journal log with 'nmcli general logging level debug domains all' (160.87 KB, text/x-vhdl)
2018-04-10 09:12 UTC, Tomas Popela
no flags Details
[PATCH] device: look at 'all' rp_filter value too to determine actual value (3.84 KB, patch)
2018-04-10 14:40 UTC, Beniamino Galvani
no flags Details | Diff

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.


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