Bug 446428 - No network with NetworkManager
No network with NetworkManager
Status: CLOSED DUPLICATE of bug 447489
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
12
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: 446529 447489
  Show dependency treegraph
 
Reported: 2008-05-14 11:46 EDT by Luya Tshimbalanga
Modified: 2010-09-14 07:40 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 447489 (view as bug list)
Environment:
Last Closed: 2010-04-12 18:27:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
ifcfg-eth0 file (239 bytes, text/plain)
2008-05-14 18:49 EDT, Luya Tshimbalanga
no flags Details
audit file (26.48 KB, text/plain)
2008-05-15 15:36 EDT, Luya Tshimbalanga
no flags Details
ifcfg-etho from installed i386 fedora 9 (201 bytes, text/plain)
2008-05-16 16:28 EDT, Luya Tshimbalanga
no flags Details
boot report from Fedora 10 (14.46 KB, text/plain)
2009-02-20 14:29 EST, Luya Tshimbalanga
no flags Details

  None (edit)
Description Luya Tshimbalanga 2008-05-14 11:46:06 EDT
Description of problem:
No network running on a frest instaall

Version-Release number of selected component (if applicable):


How reproducible:
Simply install Fedora 9 x86_64

Steps to Reproduce:
1.
2.
3.
  
Actual results:
No network

Expected results:
Network should be available

Additional info:
Comment 1 Dan Williams 2008-05-14 12:37:12 EDT
Please attach any ifcfg files from /etc/sysconfig/network-scripts/ that are on
your system, like ifcfg-eth0.

Also, if you could grab and install this NM update and report whether that helps:

http://koji.fedoraproject.org/koji/taskinfo?taskID=608593

Did you install from the LiveCD, and how did you configure the networking in the
installer?
Comment 2 Luya Tshimbalanga 2008-05-14 18:49:31 EDT
Created attachment 305412 [details]
ifcfg-eth0 file

Here is  the requested file.
Comment 3 Luya Tshimbalanga 2008-05-14 18:52:47 EDT
I have installed from the full DVD release. I have left the configuration to
dynamically use DHCP. For some reasons, the installation originally did not
recognize the network. I have updated NetworkManager to find out that SELinux
policies denied NetworkManager for some odd reasons. I will submit these bugs on
security team which are related. Currently, my Fedora 9 installation has no
online access.
Comment 4 Daniel Walsh 2008-05-15 14:27:14 EDT
Could you attach the audit.log?
Comment 5 Luya Tshimbalanga 2008-05-15 15:36:48 EDT
Created attachment 305527 [details]
audit file

For some reasons, dhcp_t got denied.
Comment 6 Adam Sobotka 2008-05-16 01:51:53 EDT
In my case, problem was solved by manual editing of ifcfg-eth0. I changed
NM_CONTROLLED=no to NM_CONTROLLED=yes and after reboot it works fine (solution
posted to FedoraForum by Marley Junior).
My opinion is that problem is created in moment when you specify fixed ip in
installation process, but I am unable to test it currently.
Mine is also installed from install DVD. 
Comment 7 Luya Tshimbalanga 2008-05-16 07:04:51 EDT
Tried the solution from #6.NM is connected but no Internet access.
Comment 8 Luya Tshimbalanga 2008-05-16 15:11:39 EDT
(In reply to comment #6)
> In my case, problem was solved by manual editing of ifcfg-eth0. I changed
> NM_CONTROLLED=no to NM_CONTROLLED=yes and after reboot it works fine (solution
> posted to FedoraForum by Marley Junior).
> My opinion is that problem is created in moment when you specify fixed ip in
> installation process, but I am unable to test it currently.
> Mine is also installed from install DVD. 

Testing the i386 version LiveUSB of Fedora 9, NetworkManager runs smoothly. This
result confirms the bug affects x86_64 platform.
Comment 9 Luya Tshimbalanga 2008-05-16 16:28:59 EDT
Created attachment 305746 [details]
ifcfg-etho from installed i386 fedora 9

I included the attachment from i386 installation. NetworkManager runs without
the issue. I have repeated the same test with the x86_64 were NetworkManager
will not work even using suggested workaround. For these reason, I will raise
the issue to high.
Comment 10 Adam Sobotka 2008-05-18 14:04:58 EDT
So this should be two bugs, one x64 related and one setup related.
Mine is very easily to reproduce:fill static IP in setup. It may depend on
secondary wireless connection.
I tried fresh setup, ignored setup dialog about network (leaving dhcp there) and
then I set everything in nm applet. It works fine now.
Comment 11 Luya Tshimbalanga 2008-05-19 02:23:19 EDT
(In reply to comment #10)
> So this should be two bugs, one x64 related and one setup related.

Big update, I found out about the cause of bug. My PC motherboard, a Gigabyte
GA-K8SNC-939 got the enabled support to 4GB because there is already 4 x 1 OCZ
Platinum GB DDR-RAM installed. What is surprising is once I disabled that
support, NetworkManager is able to connect without problem using the x86_64
Fedora 9 liveUSB. I never had that issue on the x86 version with the 4GB support
enabled.

In this case, it looks like the bug is critical than I thought especially for
people having more than 4GB in their workstations. Currently, I run x86_64 with
 4GB support disabled. I have reproduced the same thing on Fedora 8 and noticed
the same issue in the same architecture. That report should be investigated as
soon as possible because it appears to be hardware related. If the bug is not
critical, please let users know.
Comment 12 Luya Tshimbalanga 2008-05-19 02:37:45 EDT
I wonder if the issues is more kernel related than NetworkManager.
Comment 13 Dan Williams 2008-05-19 07:54:09 EDT
Probably more kernel-related; NM shouldn't care about the amount of memory, but
the drivers might care.  There have been bugs historically with broadcom wifi
cards having issues with > 2G or 3G, I forget which.
Comment 14 Randy Zagar 2008-05-19 13:46:24 EDT
I have the same GA-K8NSC-939 motherboard, along with a PCI nic.  Network Manager
marked both as "unmanaged" AND the network script in /etc/init.d was turned off.
 Once I did a "chkconfig --level=2345 network on", things began working as expected.
Comment 15 Luya Tshimbalanga 2008-05-19 22:27:04 EDT
(In reply to comment #13)
> Probably more kernel-related; NM shouldn't care about the amount of memory, but
> the drivers might care.  There have been bugs historically with broadcom wifi
> cards having issues with > 2G or 3G, I forget which.

It is a Marvell Yukon Ethernet in my case.
Comment 16 Luya Tshimbalanga 2008-05-19 23:40:58 EDT
I have submitted bug report https://bugzilla.redhat.com/show_bug.cgi?id=447489
Comment 17 Balaji G 2008-06-06 07:30:23 EDT
Should this bug status be changed to Duplicate/clone of #447489 ?

Cheers
Balaji
Comment 18 Randy Zagar 2008-06-06 11:37:06 EDT
My vote is no.  Although his bug may be a duplicate/clone of this one.  His bug
is highly specific, and may be a subset of this one.
Comment 19 Art Miller 2008-11-30 03:23:55 EST
Installed from yum upgrade from Fedora 9 x86_64. Initial install was fine but had to disable Network Manager. After doing the initial yum update, install went fine but then on reboot "no network connection" tried using system -> network to configure the properties. Entered all info still no connection after saving and restarting network. Proceeded to /etc/sysconfig/network-scripts and noticed that there was no ifcfg-eth0 only ifcfg-lo. So created ifcfg-eth0 with vi after saving in the network came up. cycled network  #service network restart error messase saying "could not bind <ip address> to eth0" network went down. Went back to terminal # cat ifcfg-eth0 network mask changed to the static ip address that was entered e.g.-netmask and ip address were the same. changed back with vi after saving network came back up. again recycle network again failure no error message this time. Opened ifcfg-eth0 again netmask had changed to same as ip address. Also anytime that you try to configure it with the Network GUI the ifcfg-eth0 file looks like a mixer has been through it with all entries the same ip address e.g.- ipaddr, netmask,gateway. This could not be fixed in Kernel 2.6.27.5-117.fc10.x86_64 so no connection to post bug from there. reverted back to 2.6.25-14.fc9.x86_64. Again initial install and configuration of yum upgrade all was well until reboot then no network connection. tried reinstalling twice once again from yum upgrade and one from CD both downloaded from the ANL mirrorsite.
Comment 20 Dan Williams 2009-02-20 09:54:07 EST
Is the original problem still an issue with latest NM and kernel updates?
Comment 21 Luya Tshimbalanga 2009-02-20 14:28:12 EST
(In reply to comment #20)
> Is the original problem still an issue with latest NM and kernel updates?

Alas yes. Worse, there is a regression case where gdm will not start with 4GB RAM support enabled (the screen will turn black after plymouth completed loading services at startup). See attachment called boot_messages where some odd reason: etho (with is Marvell Ethernet) deactivated itself:

Feb 20 10:35:48 kwetu NetworkManager: <info>  Device 'eth0' DHCP transaction took too long (>45s), stopping it.
Feb 20 10:35:48 kwetu NetworkManager: <info>  eth0: canceled DHCP transaction, dhcp client pid 2599
Feb 20 10:35:48 kwetu NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled...
Feb 20 10:35:48 kwetu NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Timeout) started...
Feb 20 10:35:48 kwetu NetworkManager: <info>  (eth0): device state change: 7 -> 9
Feb 20 10:35:48 kwetu NetworkManager: <info>  Marking connection 'System eth0' invalid.
Feb 20 10:35:48 kwetu NetworkManager: <info>  Activation (eth0) failed.
Feb 20 10:35:48 kwetu NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Timeout) complete.
Feb 20 10:35:48 kwetu NetworkManager: <info>  (eth0): device state change: 9 -> 3
Feb 20 10:35:48 kwetu NetworkManager: <info>  (eth0): deactivating device (reason: 0)

skge is still the issue found on bug #447489. BIOS for GA-K8NSC-939 was upgraded where the same problem occurred. I made an effort to contact Gigabyte manufacturers about the issue confirming a kernel issue. I compared with Microsoft Windows XP 64 bits and the problem was resolved with the latest driver from Marvell. It will be nice for either NM or Kernel team to contact Gigabyte Technologies as they appears to be very friendly to FOSS.
Comment 22 Luya Tshimbalanga 2009-02-20 14:29:28 EST
Created attachment 332745 [details]
boot report from Fedora 10
Comment 23 Dan Williams 2009-03-03 15:52:22 EST
Does the device still fail to get a DHCP address if you execute the following command (as root):

/sbin/dhclient -1 -d -v eth0


(Ctrl+C to kill it after about a minute or two)
Comment 24 Luya Tshimbalanga 2009-03-03 21:55:05 EST
Result:

# /sbin/dhclient -1 -d -v eth0
Internet Systems Consortium DHCP Client 4.0.0
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:14:85:1f:51:8b
Sending on   LPF/eth0/00:14:85:1f:51:8b
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
Unable to obtain a lease on first try.  Exiting.

Tested with 4GB RAM support enabled on Fedora 10. Disregard gdm issue on comment #20 as it turned out to be nvidia from RPMFusion, nouveau driver did not have that problem.
Comment 25 Luya Tshimbalanga 2009-06-13 17:49:19 EDT
Tested with newly installed Fedora 11 Leonidas with kernel 2.6.29.4-167.fc11.x86_64, here is the result

# /sbin/dhclient -1 -d -v eth1
Internet Systems Consortium DHCP Client 4.1.0
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth1/00:14:85:1f:51:8b
Sending on   LPF/eth1/00:14:85:1f:51:8b
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
Unable to obtain a lease on first try.  Exiting.

Same issue with the same Marvell Yukon Ethernet on the same motherboard.
Comment 26 Luya Tshimbalanga 2009-08-26 04:47:22 EDT
Still no dice with Fedora 12 Alpha

Aug 26 01:36:12 rawhide dhclient: Internet Systems Consortium DHCP Client 4.1.0p1
Aug 26 01:36:12 rawhide dhclient: Copyright 2004-2009 Internet Systems Consortium.
Aug 26 01:36:12 rawhide dhclient: All rights reserved.
Aug 26 01:36:12 rawhide dhclient: For info, please visit http://www.isc.org/sw/dhcp/
Aug 26 01:36:12 rawhide dhclient: 
Aug 26 01:36:12 rawhide NetworkManager: <info>  DHCP: device eth1 state changed normal exit -> preinit
Aug 26 01:36:12 rawhide dhclient: Listening on LPF/eth1/00:14:85:1f:51:8b
Aug 26 01:36:12 rawhide dhclient: Sending on   LPF/eth1/00:14:85:1f:51:8b
Aug 26 01:36:12 rawhide dhclient: Sending on   Socket/fallback
Aug 26 01:36:14 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Aug 26 01:36:21 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
Aug 26 01:36:31 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Aug 26 01:36:45 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Aug 26 01:36:57 rawhide NetworkManager: <info>  (eth1): DHCP transaction took too long, stopping it.
Aug 26 01:36:58 rawhide NetworkManager: <info>  (eth1): canceled DHCP transaction, dhcp client pid 2224
Aug 26 01:36:58 rawhide NetworkManager: <info>  Activation (eth1) Stage 4 of 5 (IP4 Configure Timeout) scheduled...
Aug 26 01:36:58 rawhide NetworkManager: <info>  Activation (eth1) Stage 4 of 5 (IP4 Configure Timeout) started...
Aug 26 01:36:58 rawhide NetworkManager: <info>  (eth1): device state change: 7 -> 9 (reason 5)
Aug 26 01:36:58 rawhide NetworkManager: <info>  Marking connection 'System eth1' invalid.
Aug 26 01:36:58 rawhide NetworkManager: <info>  Activation (eth1) failed.
Aug 26 01:36:58 rawhide NetworkManager: <info>  Activation (eth1) Stage 4 of 5 (IP4 Configure Timeout) complete.
Aug 26 01:36:58 rawhide NetworkManager: <info>  (eth1): device state change: 9 -> 3 (reason 0)
Aug 26 01:36:58 rawhide NetworkManager: <info>  (eth1): deactivating device (reason: 0).
Comment 27 Bug Zapper 2009-11-16 03:06:01 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Dan Williams 2010-02-08 20:28:17 EST
Is this still an issue?  It seems more and more like driver issues.  If anyone can get another machine on the segment and start up wireshark, we could find out if the machine that has problems is actually getting the DHCP requests out on the wire.  If it's not, then the kernel is likely the culprit.  If it does get the requests out, does the DHCP server respond?
Comment 29 Luya Tshimbalanga 2010-02-09 13:38:08 EST
Alas yes, it is still an issue. Here is the result:

# /sbin/dhclient -1 -d -v eth1
Internet Systems Consortium DHCP Client 4.1.0p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth1/00:14:85:1f:51:8b
Sending on   LPF/eth1/00:14:85:1f:51:8b
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
No DHCPOFFERS received.
Unable to obtain a lease on first try.  Exiting.

I also think this is kernel issue too since Fedora 9. Perhaps somebody should poke kernel developer to solve that problem and merge #447489.
Comment 30 Dan Williams 2010-04-12 18:27:36 EDT
Yeah, I think this is a direct result of the bug.  As such, I'm going to make it a duplicate of that.  If the kernel bug is fixed then this bug should get fixed.

*** This bug has been marked as a duplicate of bug 447489 ***

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