Bug 150615 - kernel-2.6.10-1.770_FC3 makes WAN unreachable
Summary: kernel-2.6.10-1.770_FC3 makes WAN unreachable
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3
Hardware: athlon Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-08 22:13 UTC by joe
Modified: 2015-01-04 22:17 UTC (History)
2 users (show)

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

Attachments (Terms of Use)

Description joe 2005-03-08 22:13:08 UTC
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

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


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 (yahoo and other WAN sites)

Actual results:

Network is unreachable

Expected results:

ping confirmation

Additional info:

cat /etc/resolv.conf
nameserver dyndns.com

Again this all worked untill kernel*770_FC3 upgrade

Comment 1 Dave Jones 2005-03-08 22:33:41 UTC
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 get outside
your local network ?

Comment 2 joe 2005-03-08 23:11:14 UTC
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:

socket: Network is unreachable

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 23:13:25 UTC
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 23:27:19 UTC
There is a difference between the works/does not work route output -
see below. The difference is
default         UG    0      0       
0 eth0
How do I add this to my routing table on the Anthlon? That may be my


Works 686:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface     *        U     0      0       
0 eth0     *          U     0      0       
0 eth0
default         UG    0      0       
0 eth0

Does not work Athlon:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface     *        U     0      0       
0 eth0     *          U     0      0       
0 eth0

Comment 5 Dave Jones 2005-03-08 23:36:43 UTC
route add default gw

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.