I jumped the gun a little and reloaded FED 9 (This used to work Perfect on this machine) This provided me with some interesting info When I loaded FED 9 back up I had the same problem no connectivity So I tried the machine with a dynamic IP and of course it worked So I took it back into the garage and tried a static IP with no success What is interesting about this run is that as soon as I booted the machine the security update alert popped up. So I tried to download the security updates and an alert came up and said there was no network connection This installation also would not hold any DNS information even though I would save the IP information and activate the hardware once I would reboot the machine any DNS settings would be lost I still performed the test that Jim suggested and here are the results
/etc/resolv.conf #No nameservers found; try putting DNS Servers into your #ifcg files in /etc/sysconfig/network-scripts like so: # #DNS1=xxx.xxx.xxx.xxx #DNS2=xxx.xxx.xxx.xxx #SEARCH=lab.foo.com bar.foo.com /etc/sysconfig/network-scripts/ifcfg-eth0 # VIA Technologies, Inc. VT6102 [Rhine-II] Device=eth0 BOOTPROTO=none HWADDR=00:17:31:d4:11c1 ONBOOT=yes DHCP_HOSTNAME=localhost.localdomain NM_CONTROLLED=yes TYPE=Ethernet USECTL=no PEERDNS=yes IPV6INIT=no IPADDR=xxx.xxx.xxx.66 NETMASK=255.255.255.224 GATEWAY=xxx.xxx.xxx.65 For whatever reason this machine wont save DNS settings at least that is how I interpret these results Any suggestions? Thanks, Michael > Date: Mon, 1 Dec 2008 19:18:18 -0800 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: Connecting with CentOS 5.2 > > Carl Lowenstein wrote: >> On Mon, Dec 1, 2008 at 4:07 PM, Michael Lynch wrote: >>> >>> The ethernet device is built into the motherboard >>> of this paricular computer >>> Do you think I would have better luck with >>> an installed PCI NIC? >>> >> >> Why don't you boot a memory-resident operating system, such as >> Knoppix. That will let you try your hardware with a different OS >> without having to reload everything. > > Booting to another OS is certainly easy and may be a good diagnostic (if > you have a Knoppix or other "live-cd" disk). > > And here are some other considerations. > > It doesn't make a whole lot of sense (to me) that there is a problem > with your server hardware or driver if it worked on the residential > system. Just changing from business/static to residential/dhcp would not > seem to explain the symptoms. Although, I suppose it could be a subtle > configuration error in the static setup. > > - How are you configuring the server? What config tools (programs) are > you using? You have already reported the content of /etc/resolv.conf, > but perhaps it would be useful to post the contents of > /etc/sysconfig/network-scripts/ifcfg-eth0 > > It has already been suggested that other components are worth noting. > You say your business line comes into the cisco and then thru a switch > to the server, if I recall correctly. > > - Is there _anything_ else plugged into the cisco or switch? If so can > you (perhaps temporarily) remove them and repeat the ping test? > > - Can you bypass the switch and plug directly into the cisco, and then > repeat the ping test? > > - Can you (then) change to a different the cable from server to cisco? > > And perhaps you could cut-n-paste the results of running > ifconfig -a > route -n > > (Note: If you wish to preserve privacy of your public IP space, you > could X-over the first couple/three portions of the IP values > displayed in the output from the above -- as, eg: XXX-XXX-XXX.17) > > For the record, you say a substitute for the server worked plugged into > teh business system where the server is, I think. > > - are you positive the substitute was net-configured the same as the server? > > - did you use the same cable and hookup (including exact same ports on > switch/cisco)? > > I presume the cisco is preconfigured by cox, and you haven't been asked > to do any configuring there, eh? > > If this seems tedious --it is! But these kind of problems can sometimes > be a very fussy challenge. But if we can figure out the cause it _will_ > be a learning experience! > > Regards, > ..jim > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-newbie -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-newbie
