Bug 168335 - iproute not populating routing table
iproute not populating routing table
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-14 21:54 EDT by Clyde E. Kunkel
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-18 19:51:56 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 Clyde E. Kunkel 2005-09-14 21:54:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050901 Fedora/1.7.11-4

Description of problem:
Could not access network after today's (9/14/05) rawhide update.  Question on fedora test list led to cause from Tom London.  Backed out iproute-2.6.14-1 and installed iproute-2.6.11-1.  Problem fixed.

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

How reproducible:
Always

Steps to Reproduce:
1.boot system
2.try to access network, any
3.
  

Actual Results:  could not access network

Expected Results:  should be able to access network

Additional info:
Comment 1 Dan Williams 2005-09-15 02:05:30 EDT
NetworkManager runs into this since it uses /sbin/ip to do routing table stuff
and a few other things...  The result is that NM is unable to add any entries to
the routing table.  I've yet to figure out what the actual problem here is.
Comment 2 Radek Vokal 2005-09-15 08:03:43 EDT
I've tested some ip route options and it seems to work. When exactly it fails?
Did you manage to figure this out? I don't use NM here and also I haven't found
any problem with iproute so far. 
Comment 3 Clyde E. Kunkel 2005-09-15 09:24:07 EDT
I don't know at which point it fails; however, I reinstalled rawhide
iproute-2.6.14-1 and stopped networkmanager and dispatcher, removed them from
startup, rebooted, and now the routing table is populated and resolv.conf is
correct and the network is reachable.  So, seems there is some relationship
between networkmanger andf iproute that may be broken.
Comment 4 Tom London 2005-09-15 10:09:27 EDT
I now see lots of these messages in /var/log/messages:

Sep 15 06:48:58 localhost NetworkManager: nm_ip4_config_get_broadcast: assertion
`config != NULL' failed
Sep 15 06:48:58 localhost NetworkManager: nm_ip4_config_get_netmask: assertion
`config != NULL' failed
Comment 5 Tom London 2005-09-15 10:39:50 EDT
Installed today's updates from rawhide (including iproute-2.6.14-1) and I
noticed the following behavior:

On boot (with networkManager) interface is up (i.e., has address from DHCP, but
no  routes).

If I select the NetowrkManager icon and reselect 'wired network', it now
correctly brings up the interface including routes. 

NetworkManager only sees my wired interface; doesn't see my wireless one.
'iwconfig eth1' says 'no such device', etc.

Following messages from /var/log/audit/audit.log:

type=AVC msg=audit(1126794443.402:21): avc:  denied  { read } for  pid=2972
comm="killall" name="mls" dev=selinuxfs ino=12
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:security_t:s0 tclass=file
type=SYSCALL msg=audit(1126794443.402:21): arch=40000003 syscall=5 success=no
exit=-13 a0=bfeac3b4 a1=8000 a2=0 a3=8000 items=1 pid=2972 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="killall"
exe="/usr/bin/killall"
type=CWD msg=audit(1126794443.402:21):  cwd="/"
type=PATH msg=audit(1126794443.402:21): item=0 name="/selinux/mls" flags=101 
inode=12 dev=00:0d mode=0100444 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1126794446.278:22): avc:  denied  { read } for  pid=2991
comm="killall" name="mls" dev=selinuxfs ino=12
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:security_t:s0 tclass=file
type=SYSCALL msg=audit(1126794446.278:22): arch=40000003 syscall=5 success=no
exit=-13 a0=bfafa6b4 a1=8000 a2=0 a3=8000 items=1 pid=2991 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="killall"
exe="/usr/bin/killall"
type=CWD msg=audit(1126794446.278:22):  cwd="/"
type=PATH msg=audit(1126794446.278:22): item=0 name="/selinux/mls" flags=101 
inode=12 dev=00:0d mode=0100444 ouid=0 ogid=0 rdev=00:00

Not sure if this is related.....
Comment 7 Tom London 2005-09-19 15:52:06 EDT
OK, I think I've tracked this down.....

NetworkManager is trying to execute 'ip' commands with an argument of 'address'.
This appears no longer to be accepted ('addr' is accepted).

Looks like either NetworkManager needs to change to use 'addr', or ip needs to
change to accept 'address'.

Below is a list of the /sbin/ip commands executed by selecting the
NetworkManager icon along with any output.

route flush dev eth0
address flush dev eth0
Object "address" is unknown, try "ip help".
route del default
RTNETLINK answers: No such process
address flush dev eth0
Object "address" is unknown, try "ip help".
route flush dev eth0
Nothing to flush.
neigh flush all
-6 address add fe80::208:dff:fe89:dbdc/64 dev eth0
Object "address" is unknown, try "ip help".

Scripting /sbin/ip to change 'address' to 'addr' makes it work.
Comment 8 Dan Williams 2005-09-19 16:37:45 EDT
Ok, fixed in CVS and we'll try to put out an NM update very very soon.  Thanks
for the help!
Comment 9 Tom London 2005-11-18 15:13:35 EST
Believe this is closed in RAWHIDE, no?
Comment 10 Clyde E. Kunkel 2005-11-18 19:51:56 EST
Yes.

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