Federico Heinz wrote:
> Kick,
> > Kernel IP routing table
> > Destination Gateway Genmask Flags Metric Ref Use Iface
> > 195.96.96.97 * 255.255.255.255 UH 0 0 0 sl1
> > 195.96.96.97 * 255.255.255.255 U 0 0 0 sl1
> > 192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
> > 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> > default * 0.0.0.0 U 0 0 0 sl1
>
> The output of my route -n looks A LOT like that. I figured it wouldn't be such a
> big deal, though, so I didn't pay much attention. I also noticed that when diald
> brings up the connection, I also get three routing entries for ppp0, two of them
> identical. However, if I kill diald, all routing info regarding sl0 and ppp0
> disappear, so I figure if I delete one of the routing entries, it will be
> reinstated the next time diald starts up (upon next reboot, for instance). Did
> you find a way to configure diald so that it will not set up the two routing
> entries in the first place?
Actually, this problem is not really caused by diald. If I remember
correctly, I had the exact same problem using ISDN after I upgraded to a
2.2.x kernel. With the 2.0.x kernel series you had to set the route to
the remote end by hand, so apparently pppd took care of that (ipppd in
the case of isdn). Now when you start a ppp/slip link with a 2.2.x
kernel, the kernel sets the route to the remote end for you, so what
happens here is that the route to the remote end gets set by the kernel,
and once again by pppd/diald (last one in case of SLIP). This is
probably already fixed in recent versions of pppd, so in your case you
should determine your version of pppd, and if necessary, install a
recent version.
In my case however the SLIP link is brought up by diald itself, so the
problem lies within diald. I guess I will have to go through the source,
and try and find the section where diald adds this route. So if anyone
on this list has a patch for this, let me know...
Kick
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
