Bug 129365 - Missing lo entry in routing table in FC2
Summary: Missing lo entry in routing table in FC2
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: stunnel
Version: 3
Hardware: i686
OS: Linux
medium
low
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-06 23:51 UTC by Ian Laurie
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-05-31 22:14:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ian Laurie 2004-08-06 23:51:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040803

Description of problem:
My routing table is missing the default lo entry (in FC2 only):

orion# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface
10.105.108.0    *               255.255.255.0   U     0      0       
0 eth0
10.1.1.0        *               255.255.255.0   U     0      0       
0 eth1
169.254.0.0     *               255.255.0.0     U     0      0       
0 eth1
default         router          0.0.0.0         UG    0      0       
0 eth0
orion#
I would expect an enty like this to be there as well:

127.0.0.0       *               255.0.0.0       U     0      0        0 lo



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

How reproducible:
Always

Steps to Reproduce:
1. Install FC2.
2. Issue route command to examine route table.
3.
    

Actual Results:  Route table is missing the lo entry.

Expected Results:  I would expect to see an entry for the local
loopback interface.

Additional info:

Even though the loopback route is missing from the table, the system
seems to be fine without it.

Comment 1 Goh Kim Leng 2004-08-07 07:16:57 UTC
same here. I'm using iproute-2.4.7-14. I think it's a kernel 
networking problem. I'm using kernel-smp-2.6.6-1.435.2.3 and I have:

[root@hostname root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    
Use Iface
XXX.XXX.XXX.XX  *               255.255.255.XXX U     0      0        
0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        
0 eth0
default         xxxxxx-xxx-xx.x 0.0.0.0         UG    0      0        
0 eth0


I'm expecting something like

[root@hostname2 root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    
Use Iface
XXX.XXX.XXX.XX  *               255.255.255.XXX U     0      0        
0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        
0 lo
169.254.0.0     *               255.255.0.0     U     0      0        
0 eth0
default         xxxxxx-xxx-xx.x 0.0.0.0         UG    0      0        
0 eth0


Although the system seems to be fine without it, I've tried using tin 
(1.6.2 and 1.7.5) with stunnel (> 
http://www.redhat.com/archives/redhat-list/2002-July/msg01483.html).

Although I'm able to read postings, I'm unable to post any message 
successfully. I get the following message after quitting 
tin: "Warning Can't connect to server -- Article will be spooled."

If I didn't set up stunnel successfully I would have gott the 
message: 
tin 1.7.5 release 20040615 ("Gighay") [UNIX] (c) Copyright 1991-2004 
Iain Lea.
Connecting to 127.0.0.1:5432...
Connection to 127.0.0.1: Connection refused
Giving up...
Failed to connect to NNTP server 127.0.0.1. Exiting...

However, I was able to connect to the secure NNTP server successfully 
but unable to post successfully. I think this has to do with the 
missing lo entry (loopback entry).

I tried "route add -net 127.0.0.0" but got the message:
SIOCADDRT: Invalid argument

Not sure about the correct syntax but according to the man page of 
route, it assumes that the "lo" device was previously set up 
correctly with ifconfig. Any idea how to manually add the normal 
loopback entry or set up the "lo" device correctly with ifconfig?
           


Comment 2 Goh Kim Leng 2004-08-07 12:34:17 UTC
ok. now I tried the following:

"route add -host 127.0.0.1 lo"    followed by
"route add -net 127.0.0.0 netmask 255.255.0.0 lo"

I get the following in my routing table:

localhost.local *               255.255.255.255 UH    0      0        
0 lo
127.0.0.0       *               255.255.0.0     U     0      0        
0 lo


unfortunately that does not solve my problem. I could read but still 
not post with tin and stunnel:
Reading config file...
Warning Can't connect to server -- Article will be spooled.



Comment 3 Goh Kim Leng 2004-08-07 13:41:26 UTC
sorry, it should be:

route add -net 127.0.0.0 netmask 255.0.0.0 lo  (not 255.255.0.0)


only the above is needed.


I've tried downgrading to older kernel releases but it doesn't help.
Maybe there's some incompatibilty between tin and stunnel with Fedora
Core 2.

if I'm not wrong, the following don't work with (tin + stunnel):

kernel-smp-2.6.5-1.358
kernel-smp-2.6.6-1.435.2.3
kernel-smp-2.6.7-1.494.2.2

kernel-2.6.5-1.358
kernel-2.6.6-1.435.2.3
kernel-2.6.7-1.494.2.2

Comment 4 Goh Kim Leng 2004-08-10 02:58:41 UTC
maybe the problem lies with the stunnel I'm using:

stunnel-4.05-1

Comment 5 Robin M. 2004-08-31 16:28:16 UTC
When installing the default fedora core 2 the lo device is listed in 
the routing tables, but after doing an up2date -u the lo device no 
longer shows up in the routing table

Comment 6 Radek Vokál 2004-09-02 09:26:04 UTC
Bug also find with "ip route" command. Seems to me more like kernel
bug. I will keep on testing. 

Comment 7 Radek Vokál 2004-09-03 06:35:21 UTC
reassigned to stunnel

Comment 8 Ian Laurie 2004-09-08 08:15:02 UTC
OK now I'm worried.  I have this problem on Enterprise Linux 3 on two
systems, different h/w platforms.  I noticed the problem after the
"update 3" went on them, but can't be certain it didn't happen before
that.  Should I raise a bug against RHEL 3 or is this one enough?
For certain RHEL 3 off the CD does NOT have this problem.

Comment 9 Goh Kim Leng 2004-09-08 10:01:04 UTC
Ian Laurie, which bug are you referring to? the stunnel or missing lo 
entry bug? I also have RHEL3 Update 3 running but there is no missing 
lo entry and no stunnel bug problem. What I'm using specifically:

cat /etc/redhat-release
Red Hat Enterprise Linux ES release 3 (Taroon Update 3)


Comment 10 Ian Laurie 2004-09-08 21:00:23 UTC
Running Taroon Update 3... all updates applied.

I refer to the bug of this thread, missing lo entry.  I do not know if
this is a stunnel issue or not.

I have the issue on two different systems, different CPUs (well P IV
and P IV H/T, but they are different kernels as the latter is running
the SMP version).

I "noticed" the issue just after update 3, but as I said it could have
happened before.  However the lo entries were NOT missing when I
originally reported this bug against FC2 because at the time I used
the RHEL 3 boxes as a reference and they DID have the lo entry then. 
That was only a month ago.

BTW - both systems have a FULL CD set install on them (check box at
the bottom which says EVERYTHING)... dunno if that is a clue, I may
have more stuff on my system than you do.


Comment 11 John Hodrien 2004-11-02 11:42:36 UTC
I'm seeing this with an up to date FC2 running 2.6.8-1.521.  As of yet
no obvious problems caused by the routing table omission.  Despite it
not being listed everything seems to get routed to lo on 127.0.0.0/8.

Comment 12 Matthew Miller 2005-04-26 15:41:07 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 13 Miloslav Trmač 2005-05-31 22:14:41 UTC
$ /sbin/ip addr ls
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
...

127/8 is treated as a local host IP address, a routing table entry is
not necessary.


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