Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 150615 - kernel-2.6.10-1.770_FC3 makes WAN unreachable
kernel-2.6.10-1.770_FC3 makes WAN unreachable
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-08 17:13 EST by joe
Modified: 2015-01-04 17:17 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-08 18:36:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description joe 2005-03-08 17:13:08 EST
Description of problem:

WAN = "Network is unreachable" since I upgraded kernel from *766_FC3
to *770_FC3. Four other 686's on same LAN also upgraded and they can
reach internet, and can pinged by this 686. 

I removed kernel*770_FC3. When I restarted using old kernel*766_FC3 it
no longer could reach the WAN - even though it worked before.

resolv.conf same for all, eth0 dns same for all, can ping, ssh, sftp
from/to all on lan and can ping localhost so I do not think this is my
NIC.

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

kernel-2.6.10-1.770_FC3

How reproducible:

I removed and reinstalled kernel*770_FC3 - same problem

Steps to Reproduce:
1. rpm -e kernel-2.6.10-1.770_FC3
2. rpm -ivh kernel -2.6.10-1.770_FC3
3. ping 216.109.118.67 (yahoo and other WAN sites)

Actual results:

Network is unreachable

Expected results:

ping confirmation

Additional info:

cat /etc/resolv.conf
nameserver 4.2.2.4
nameserver 4.2.2.5
nameserver dyndns.com

Again this all worked untill kernel*770_FC3 upgrade
Comment 1 Dave Jones 2005-03-08 17:33:41 EST
I really have no idea what to suggest.  The only differences between
766 and 770 were related to USB probing, blacklisting a misbehaving
scsi device, and fixing a memory leak in the raid code.  Nothing
networking related at all.

The fact that the other three hosts have no problem with this kernel
(and that your problem now appears on a kernel that previously worked
fine) suggests to me that this is a localised incident, and that its
something out of my control.

I'd suggest looking into where the packets go once they leave your
machine, (ie, your router), and see if some configuration there has
changed recently.  Does a traceroute to 216.109.118.67 get outside
your local network ?
Comment 2 joe 2005-03-08 18:11:14 EST
I agree - but I just remembered that the others are 686's but the
problem is with a Athlon (corrected below) - could that be the difference?

Here is the trace route - and also a dig:

traceroute 216.109.118.67
socket: Network is unreachable

dig 216.109.118.67
dig: couldn't get address for 'dsl.verizon.net': failure

I can also resolve /etc/hosts names on my LAN.

And I do not think it is my router, because all the 686's work
Comment 3 Dave Jones 2005-03-08 18:13:25 EST
that its an athlon shouldnt make any difference at all.

it looks like you've lost your default route.
What does /sbin/route say ?
Comment 4 joe 2005-03-08 18:27:19 EST
There is a difference between the works/does not work route output -
see below. The difference is
default         192.168.1.1     0.0.0.0         UG    0      0       
0 eth0
How do I add this to my routing table on the Anthlon? That may be my
problem.

sbin/route

Works 686:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface
192.168.1.0     *               255.255.255.0   U     0      0       
0 eth0
169.254.0.0     *               255.255.0.0     U     0      0       
0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0       
0 eth0

Does not work Athlon:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface
192.168.1.0     *               255.255.255.0   U     0      0       
0 eth0
169.254.0.0     *               255.255.0.0     U     0      0       
0 eth0
Comment 5 Dave Jones 2005-03-08 18:36:43 EST
route add default gw 192.168.1.1

This is a local configuration problem (system-config-network should be
able to put it right).  Anyway, not a kernel bug.

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