Fedora 7 eth0 Can't Get IP Information Possible DHCP Problem

JoeLinux117 · 06-11-2007, 03:43 PM

To Anyone Willing To Help:

I'm currently running an Intel-based laptop with a WinXP/Fedora dual-boot. I recently (about a week ago) upgrade FC6 to Fedora 7, with great success so far, and many wonderful improvements. However, I am now having trouble with my wired network card, eth0(a Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express, according to "lspci" output). I can't get dhcpd to start, everytime I try I get a "FAILED" status. I don't know if this is the issue. I manually assigned eth0 an ipv4 address and netmask, as well assigning the proper DNS servers in /etc/resolv.conf, but I still was unable to ping the gateway. It was working earlier today, but then stopped all of a sudden. I will mention that it stopped at about the time I was trying to get netboot to work so that I could install Aurora from my laptop onto a SunBlade 1500 within the same subnet (which didn't happen because eth0 stopped working). All I did as far as netboot goes, is I added an entry into /etc/ethers, I modified the remote computer's address in /etc/hosts, and I turned dhcpd and tftp on using System --> Administration --> Server Settings --> Services. Shortly after I tried booting from my other computer and it began requesting IP information, my network card stopped working in the laptop. Very strange. Then again, maybe it's just coincidence. Either way, I NEED eth0 to work again, because I use the laptop for work. Someone please help!

--Joe

emasse · 06-13-2007, 08:43 AM

Having the same problem

I also have problem with dns since I installed FC7 (I can't access hosts in Windows Network with their name but only with their IP address). You too?

benjithegreat98 · 06-13-2007, 08:55 PM

dhcpd isn't required. That is necessary if you want to run a DHCP server.

Whenever you assigned the ip address did you do an ifconfig to make sure it was set into the system?

Your positive it isn't a bad cable or connection?

emasse · 06-14-2007, 05:25 AM

In my case I'm sure cable is ok.
The matter is that with FC6 I did't have any problems on starting eth0, while F7 can't do it despite I have the same configuration of FC6.

In this link:
https://bugzilla.redhat.com/bugzilla....cgi?id=242263

you can find a similar problem and maybe this is the demonstration that F7 has problems on eth0.
What do you think?

Bye

Chetanji · 06-14-2007, 02:49 PM

Quote:

Originally Posted by emasse

In my case I'm sure cable is ok.
The matter is that with FC6 I did't have any problems on starting eth0, while F7 can't do it despite I have the same configuration of FC6.

In this link:
https://bugzilla.redhat.com/bugzilla....cgi?id=242263

you can find a similar problem and maybe this is the demonstration that F7 has problems on eth0.
What do you think?

Bye

Are you using a x86 kernel or i386. This could be the problem as well as 64 bit kernels require different drivers.
Hope this helps

jovie · 07-25-2007, 03:11 AM

I have this problem with FC6 x86_64, the card worked briefly once then not again. If I need different drivers where do I get them? I tried googling

Code:

drivers x86_64 "Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express"

but it didn't help. If some one could point me in the direction of finding the drivers and what to do with them I'd be most grateful.

thanks

jovie · 07-25-2007, 04:49 AM

OK, I went to the DELL support page and they don't suport FC6 but under Redhat Enterprise 4 they had
Broadcom - Driver
Applies to: 57XX Gigabit Integrated Controller

so I downloaded that and once unpacked it was an rpm so
rpm -i tg3-3.52e-3dkms.noarch.rpm
and I needed dkms.2.0.3 so I found that and the rpm ran without error so I tried tg3 again and...

Code:

[root@localhost LinuxTG3_DKMS_Broadcom]# rpm -i tg3-3.52e-3dkms.noarch.rpm 

Creating symlink /var/lib/dkms/tg3/3.52e/source ->
                 /usr/src/tg3-3.52e

DKMS: add Completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area....
make KERNELRELEASE=2.6.18-1.2798.fc6 -C /lib/modules/2.6.18-1.2798.fc6/source BCMEXTSRCDIR=/lib/modules/2.6.18-1.2798.fc6/source 
SUBDIRS=/var/lib/dkms/tg3/3.52e/build modules....(bad exit status: 2)

Error! Bad return status for module build on kernel: 2.6.18-1.2798.fc6 (x86_64)
Consult the make.log in the build directory
/var/lib/dkms/tg3/3.52e/build/ for more information.
Could not locate pcitable.
pcitable update not performed.
[root@localhost LinuxTG3_DKMS_Broadcom]#

and in the make log...

Code:

DKMS make.log for tg3-3.52e for kernel 2.6.18-1.2798.fc6 (x86_64)
Wed Jul 25 09:55:52 BST 2007
make: Entering directory `/usr/src/kernels/2.6.18-1.2798.fc6-x86_64'
  CC [M]  /var/lib/dkms/tg3/3.52e/build/tg3.o
/var/lib/dkms/tg3/3.52e/build/tg3.c:18:26: error: linux/config.h: No such file or directory
/var/lib/dkms/tg3/3.52e/build/tg3.c: In function tg3_start_xmit 
/var/lib/dkms/tg3/3.52e/build/tg3.c:3752: error:  struct skb_shared_info  has no member named  tso_size 
/var/lib/dkms/tg3/3.52e/build/tg3.c: In function  tg3_start_xmit_dma_bug 
/var/lib/dkms/tg3/3.52e/build/tg3.c:3885: error:  struct skb_shared_info  has no member named  tso_size 
make[1]: *** [/var/lib/dkms/tg3/3.52e/build/tg3.o] Error 1
make: *** [_module_/var/lib/dkms/tg3/3.52e/build] Error 2
make: Leaving directory `/usr/src/kernels/2.6.18-1.2798.fc6-x86_64'

So do I conclude the the REdhat version won't work on FC6 and there doesn't seem to be an FC6 version so I'm stuffed

I also found this http://eh3.com/dell_D820.html which refers to FC6 on a DELL D820 and says the network card works with the default tg3 driver. Mines a DELL Precision 390 but if it's the same architecture and network card why would mine not work with the default tg3 module?

Much confused and thoughts appreciated.

JoeLinux117 · 07-26-2007, 07:18 AM

Hmmm... a little weird that the default tg3 driver does not work with your OS, jovie. The default tg3 driver worked for me. I don't know if this helps anyone, but I found out that when I ran dhcpd with my incorrect dhcpd.conf, at that exact moment the port that I was connected to at work became disabled. The network guys are stumped, but they managed to turn it back on for me. I, however, refuse to believe that an incorrectly configured dhcpd.conf caused the network port to fail (maybe conflicting private subnet under same router?). I'm guessing it's just a big coincidence.

jovie, I'm wondering if you wouldn't mind giving this a shot (after all, it's already not working for you, so you have nothing to lose). Make sure you don't have a "config.h" file in your /usr/include/linux directory (if the "linux" directory doesn't exist in /usr/include, even better). It appears from your output of make that the tg3.c file is looking for that header. I've used so many distros already that I get confused with the appropriate header packages, but try this:

Code:

# yum install linux-headers-`uname -r`

(Those aren't apostrophes of course but they are the tilde marks that are usually located on the same key as ~)

If I'm not mistaken, however, I believe that the linux/config.h file was removed, starting with the 2.6.19 kernel. So, if you are up to date on your kernel, you won't have this file, even though the driver asks for it (which speaks to the extent that Dell is actually willing to support Linux-based OSs).

If that's the case, then you can give this rough workaround a shot. Try googling for "linux/config.h" (it's a kernel header so it shouldn't be specific to any distro). Once you find it somewhere (maybe www.koders.com), download it to your system and place it in your /usr/include/linux directory.

If that STILL doesn't work, try commenting out the "#include linux/config.h" line in tg3.c by placing two forward-slashes "//" at the beginning of the offending line. Alternatively, you can place "/*" at the beginning of the line, and "*/" at the end of the line. Either way is fine.

If that STILL DOESN'T WORK, try using the default tg3 driver (maybe do "yum install tg3"), and if it fails to work, post whatever errors you get on here, and also post any relevant lines from the "dmesg" command here (maybe do "dmesg | tail -n 20").

I really hope this helps you, jovie. Let us know.

--Joe

jovie · 07-27-2007, 02:53 AM

Thanks for the responce Joe. I tried your sugestion and failed to get tg3 installed so I installed FC4 which has linux/config.h and then tg3 installed but it didn't help.

I was loathed to open up a brand new box and change the card but I did that this morning, put in an intel card and it works perfectly. Why didn't I just do that 4 days ago

The Broadcom card did connect on the very first attempt but maybe somethig blew on it after that and it was never going to work? Who knows.

Thanks again.

liegerm · 08-07-2007, 04:42 AM

I, too, have problems with my Broadcom card (it's built-in to the motherboard). If I leave it on DHCP, it won't acquire an address and Fedora won't boot any further. If I set a static address, it's fine. I'm using Fedora 7. The cable is good and the Broadcom NIC works fine with DHCP with other distros. The first boot using Fedora 7 worked, but not after that.

penguinpages · 08-07-2007, 08:31 AM

I noticed similar issues on my FC7 install. It was prevalent in the earlier versions (currently 2.6.22.1-41.fc7). I found the issues were related to DHCP (manual assignment was fix).

I was starting to debug it down the path of "Microsoft DHCP Server" vs at home with Linux DHCP (or other small coffee houses with wireless router DHCP systems) it worked ok, but the problem disappeared.

As stated, I did not finish root cause analysis of the issue but I did start to trace it down to be a routing issue. It would make bogus route tables without default gateways, or at least it was on occasion inconsistent. I was going to to a TCP trace on it to see if the DHCP server was giving out the correct GW, IP, Lease details and the client was dropping info, or that the info was taken but mucked up afterwards.

Just my $.02 (.05EU) which may help someone continue debugging this.

JoeLinux117 · 08-08-2007, 07:16 AM

Thanks for the input, penguinpages. Yes, apart from the possibility that the router is at fault, liegerm, it sounds like the problem lies with the dhcp package on your system. If you haven't messed with it since installing Fedora 7 (or if you upgraded, whatever you had before), then it should be working fine.

Now, here is another issue. penguinpages is absolutely right, when he says that sometimes some funny routing tables are created. Unfortunately, many users do not look in this area when they are wondering what is going on. If you type the command "route", you should be able to see a list of the routes on your system (currently). You can add or delete routes by using this syntax:

Code:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.254

or

Code:

route del -net 192.168.1.0 netmask 255.255.255.0

Note that you don't have to specify the gateway when you are deleting a route (sometimes not even the netmask). Also, if you specify a route without the "-net", then the system will assume a "-host" instead, in which case you will be specifying a single system, rather than a network range, and you will probably get some error that the network mask doesn't make sense. You can also add or delete default gateways by doing this:

Code:

route add default gw 192.168.1.254

or

Code:

route del default

Those should work for you with modifying your routes. Now, one thing I have also noticed is that sometimes (even when routes are not screwed up), you may have an instance of "dhclient" running, even if you don't have an ip address (maybe it was trying to get you one and the process never died). When you use a GUI-based networking method, you will usually never get this information (about dhclient already running). It will simply fail, because the system won't attempt to run to instances of dhclient for the same network interface. So, try this:

Code:

$ sudo pkill dhclient

That should kill off the dhclient process. Then, try this:

Code:

$ sudo ifup eth0

Now, hopefully that gets you an IP address. If it doesn't, then it's possible that your DHCP settings are messed up somewhere. You can always try reinstalling DHCP, but I would caution about this -- If you do so, ALL network connections that are running on DHCP will die. So, you'll simply have to manually specify an IP in order to get your network connections back. But I would tell you to uninstall DHCP, and then reinstall it. And make sure your routes are okay after DHCP runs (because it WILL modify them).

One more thing, make sure that /etc/resolv.conf has the correct nameservers in there. When I'm at home, my resolv.conf file looks like this:

Code:

search launchmodem.com
nameserver 192.168.1.254

And that's it. At work, it looks totally different. I have a script on my computer that I run whenever I connect at work, so that it will automatically adjust the routing table and also fix my resolv.conf file to match my local nameservers. Remember, DHCP automatically adjusts more than just your IP settings (which may or may not be a good thing depending on your situation). You're going to get that problem no matter what operating system you're using, especially if you have more than one network card and you're connecting to more than one network (because the OS can't guess which one is going to be the default and which network packets you want where).

Let me know if you have any questions, I hope I have contributed something to your search for the answer.

--Joe

P.S. Kudos to jovie who switched to an Intel card, the Broadcom card is such a piece of crap (I have a Broadcom NIC and a Broadcom Wireless NIC <== God help me).

ruckman17 · 09-14-2007, 08:03 PM

Thanks Joe,
I installed Fedora 7 and had the same problem.
With your advice I made up a script file as follows:

#!/bin/sh
ifdown eth1
pkill dhclient
ifup eth1

I put this in /etc/rc.d/rc.local
and it solves the problem.

Hope this helps.

John.

JoeLinux117 · 09-15-2007, 08:43 AM

Good on you, ruckman17, for getting your system to work. I'm going to guess that you wanted eth1 to be your primary interface. However, this may not be the end goal for everyone.

Let me explain something about the "rc" scripts that you may not know already. When you boot the computer, you get the BIOS, then Grub, then init, and then the rc scripts start.

The rc scripts start in 3 stages. First comes rc.sysinit. You can find this file (depending on your distribution) in /etc/rc.sysinit (or maybe /etc/rc.d/rc.sysinit). This file runs first, and contains things that need to happen (or you want them to happen) before the standard startup programs and such. Next, the scripts in /etc/rc"something".d are run. The "something" is whatever number run level you are booting to (if you boot to a graphical login screen, then it will be runlevel 5, and thus /etc/rc5.d scripts will be executed. Finally, the /etc/rc.local (or /etc/rc.d/rc.local) file will be run. This contains directives that you want your system to run LAST, after the startup programs are run, but before you log in to your system.

In this case, ruckman17, any interfaces that you have automatically initialize upon boot (such as eth0, which is typical) will be attempting to get their IP information through DHCP (if you haven't changed it) when the scripts in rc"something".d are run. Thus, when you put in something in rc.local, you are telling the system to initialize eth1 AFTER eth0 (using DHCP), and thus you will overwrite the /etc/resolv.conf file and the routing table that DHCP set up for eth0. This would make eth1 (usually) the default interface for the gateway, and would make your system use the nameservers that are assigned for that gateway, instead of whatever was for eth0.

If you only want to use eth1, but not eth0 (assuming they are connecting to the same subnet), then ruckman17's script will be just fine. If eth1 and eth0 are connecting to different gateways, then the script will probably be fine even then, as long as you're only using eth0 to connect to eth0's gateway. But in order to maximize usage of both interfaces, you would be better off modifying your routing table and/or /etc/resolv.conf file.

I'll post a tutorial about this on my website soon, to hopefully help with this. I hope I shed some light on this for everyone.

--JoeLinux

Learn About Linux - A World Without Windows