Oct 14 03:31:27 krt_rtread: Initial routes read from kernel (via
/proc/net/route
):
Oct 14 03:31:27 rt_add: host bits not zero 208.0.84.154/0.0.0.0 gw
208.0.84.142
Kernel
KRT READ REMNANT 208.0.84.154 mask 0.0.0.0 router 208.0.84.142
fla
gs <>0: queueing delete for rt_add() failure
Oct 14 03:31:27 rt_add: host bits not zero 208.0.84.187/0.0.0.0 gw
208.0.84.142
Kernel
KRT READ REMNANT 208.0.84.187 mask 0.0.0.0 router 208.0.84.142
fla
gs <>0: queueing delete for rt_add() failure
Oct 14 03:31:27 rt_add: host bits not zero 208.0.84.200/0.0.0.0 gw
208.0.84.142
Kernel
... [more lines like this]
KRT SEND DELETE 208.0.84.180 mask 0.0.0.0 router 208.0.84.142
flag
s <GW>2: Invalid argument
KRT SEND DELETE 208.0.84.215 mask 0.0.0.0 router 208.0.84.142
flag
s <GW>2: Invalid argument
KRT SEND DELETE 206.105.188 mask 0.0.0.0 router 206.105.188.4
flag
s <GW>2: Invalid argument
KRT SEND DELETE 206.105.188 mask 0.0.0.0 router 206.105.188.4
flag
s <GW>2: Invalid argument
What's odd is it's refering to the gateway address as the virtual interface,
and the mask is completely off. What changed? I checked /proc/net/route...
and the sscanf function shouldn't have any problems. Another odd thing is, I
appear to have two routing entries which are exactly the same in
/proc/net/route:
eth0 00BC69CE 00000000 0001 0 0 0
00FFFFFF
0 0 0
eth0 00BC69CE 00000000 0001 0 0 0
00FFFFFF
0 0 0
I'm pretty sure this sort of behavior shouldn't be allowed :)
Anyway, it's sort of important than I get OSPF up and running again, so I'd
appreciate it if someone could tell me what possibly could have changed to
affected gated this badly. If someone has a patch to make my life easier,
I'd appreciate it.
Jordan
-- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/