Bug 980785
| Summary: | External network not reachable after update to NetworkManager-0.9.8.2-4.fc19.x86_64 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Cristian Sava <cristis53> | ||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 19 | CC: | cristis53, dcbw, jklimes | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Cause:
Consequence:
Result:
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-02-17 15:48:44 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
Cristian Sava
2013-07-03 08:44:28 UTC
Mainly, this bug is due to kernel-3.9.8-300.fc19.x86_64 and downgrading to kernel-3.9.5-301.fc19.x86_64 solve the networking accessibility. The other points are still valid. Created attachment 768819 [details]
Tests to debug the reported problem
Different tests regarding network and NetworkManager services
As Adam Williamson suggested biosdevname=0 on the kernel line solve the interface name (as shown in the test case file already attached). Anyway, this parameter should not be needed if some bug is not present. Installing F19 Gnome Desktop in VirtualBox-4.2.14 under Win7_x64: route gives p2p1 and we have ifcfg-enp0s3 !!! [root@localhost ~]# uname -a Linux localhost.localdomain 3.9.9-301.fc19.x86_64 #1 SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# rpm -q NetworkManager NetworkManager-0.9.8.2-5.fc19.x86_64 [root@localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 193.x.y.193 0.0.0.0 UG 0 0 0 p2p1 193.x.y.192 * 255.255.255.224 U 1 0 0 p2p1 [root@localhost ~]# ls /etc/sysconfig/network-scripts ifcfg-enp0s3 ifdown-eth ifdown-post ifdown-tunnel ifup-eth ifup-isdn ifup-ppp ifup-wireless ifcfg-lo ifdown-ippp ifdown-ppp ifup ifup-ippp ifup-plip ifup-routes init.ipv6-global ifdown ifdown-ipv6 ifdown-routes ifup-aliases ifup-ipv6 ifup-plusb ifup-sit network-functions ifdown-bnep ifdown-isdn ifdown-sit ifup-bnep ifup-ipx ifup-post ifup-tunnel network-functions-ipv6 On installs where iface reported by "route" command is not the same with ifcfg-iface (pxpy instead of enpxsy or ethx) fail2ban will not start. Does not matter if biosdevname=0 or net.ifnames=0 on the kernel line. Tested this on real hardware and on VirualBox too. From /var/log/messages: fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not accessible for writing Fail2ban is ok on any other install. (In reply to Cristian Sava from comment #0) > With F19 install (no updates) it is the same with NM or with network service. > > 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ? > 2) Why "ifconfig" does show only the IPADDR0 without aliases? > 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not > on-line, the address 193.x.y.162 is assigned to the the server, it responds > to "ping 193.x.y.162" but it should be unreachable (or something equivalent) > because 192.168.1.73 is off. > Similar for 193.x.y.163 . > 1) because the interface names are p4p1 and p5p1 The interface names are handled by biosdevname/udev. 2) IP aliases and ifconfig are obsolete now. Interfaces can handle multiple IPs easily. So instead of creating interface aliases, all addresses are added to the same interface. 'ip' command is recommended instead of ifconfig. $ ip addr 3) not sure what you mean or trying to achieve TL;DR What is the actual problem? (In reply to Cristian Sava from comment #5) > On installs where iface reported by "route" command is not the same with > ifcfg-iface (pxpy instead of enpxsy or ethx) fail2ban will not start. > Does not matter if biosdevname=0 or net.ifnames=0 on the kernel line. > Tested this on real hardware and on VirualBox too. > From /var/log/messages: > fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not > accessible for writing > Fail2ban is ok on any other install. Announced as fixed in selinux (selinux was not complaining with AVC and I thought there was a networking problem). (In reply to Jirka Klimes from comment #6) > (In reply to Cristian Sava from comment #0) > > With F19 install (no updates) it is the same with NM or with network service. > > > > 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ? > > 2) Why "ifconfig" does show only the IPADDR0 without aliases? > > 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not > > on-line, the address 193.x.y.162 is assigned to the the server, it responds > > to "ping 193.x.y.162" but it should be unreachable (or something equivalent) > > because 192.168.1.73 is off. > > Similar for 193.x.y.163 . > > > 1) because the interface names are p4p1 and p5p1 > The interface names are handled by biosdevname/udev. > 2) IP aliases and ifconfig are obsolete now. Interfaces can handle multiple > IPs easily. > So instead of creating interface aliases, all addresses are added to the > same interface. > 'ip' command is recommended instead of ifconfig. > $ ip addr > 3) not sure what you mean or trying to achieve > > TL;DR > What is the actual problem? 1) Iface name reported by "route" is different from ifcfg-Iface (p5p1 vs. ifcfg-enp5s0) on some installs. All is correct on others (iface=enp5s0 and we have ifcfg-enp5s0). 2) OK, you're right 3) See my iptables. If an addres is used to DNAT: -A PREROUTING --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73 -A OUTPUT --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73 I think it's logical that if pinging 193.x.y.162 from outside when 192.168.1.73 is off to receive something like "unreachable" or similar (I know that the ip is the kernel's property) but I receive an answer from 193.x.y.162 (it forgot that is set DNAT). Maybe that is only my wish. The main point is 1) because it is potential source of trouble (e.g. using iptables "-o p5p1" is not "-o enp5s0" if debugging with biosdevname=0, etc.) I saw that on real hardware and in VirtualBox too. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |