Hi Richard,
I apologize that I'm glad that you describe exactly but independently
in every respect the same phenomenons as I watch on my system since yesterday.
Independently because we never had contact before, we are running a Linux of
different vendors' distributions, we use different hardware and there may be
something else different as there were kernel version, diald version, and so
on.
We should compare these as quickly as possible, because I'm really sad about
that I cannot reach the Internet via diald (version 0.14) anymore; it
worked very well a few weeks, though, but then ... :-(
Nevertheless I know for certain that it's a super tool; it would be extremly
advantageous to fix the problems with it.
It would also be useful if we exchanged our relevant network config files, but
not on the list and for now I want to mail this quickly!
And now let's dive in!
Richard L. Peskin wrote:
>
> I'm a novice at setting up diald services and and having a terrible time.
> I'm running Linux 5.0.1 (RedHat) on a (dual) Pentium system. My objective
> was to use diald and IP masquerading to connect a local (isolated) network
> to my ISP's internet services. My kernel was successfully rebuilt (mostly
> for the dual processor support) and includes all the necessary modules
> (ppp, slip, ipfwadm, etc.)
I have a single processor system (Pentium 133) with a rebuilt kernel (2.0.33)
and is running perfectly for months.
> The IP masquerading works fine, without diald running. If I jsut start ppp,
> everything appears normal. That is, the external route to the ISP is added
> to the route table and via masquerading, all systems can get to the IPS
> services.
I don't know much about IP masquerading but if having system addresses which
differ from that of the ppp-device when connected to the ISP (dynamic
assignment) then I can say that mine works fine together with running the
ppp-demon.
> But, if I start diald (assuming ppp is not started), and then request an
> address outside my internal network, say do a 'ping' on an external
> address, the routing seems to hang. That is, 'route' hangs and no routing
> table is presented. 'ifconfig' shows the expected "slip" interface added to
> the default (loc and internal) interfaces.
Have you watched, after typing 'route', the output a bit longer?
At my system it takes nearly a minute to get one line, then a minute again and
so on. But you're right, it obviously hangs (the same with 'netstat -r').
Typing 'netstat -rn' results in a fast output, so I had the suspicion of having
to do with name resolving, but I do not longer believe in.
The same on my system with 'ifconfig' as on yours.
> So it appears that my diald configuration successfully makes the "connect"
> and sets up the "bogus" slip interface. But it screws up the routing. IP
> forwarding is on.
Yes, this observation coincides with mine too.
> Can anyone throw any light on possible problems or configuration issues
> that I might have overlooked? I have a default gateway device (eth0) but no
> default gateway set.
May be a problem within diald itself or a bad interference with kernel code.
But whatever it is, I think it must be something basic as we independently
watched this on different systems.
Have other people watched a similar strange behavior?
> On more thing, once diald is run, the routing table appears to be messed up
> to the point of need to reboot.
Where do you make the difference to your observation (above) by typing 'route'?
I do nearly get no routing table, at least very slow output without a ppp0
device to see.
> (To keep bandwidth down, please feel free to mail me directly rather than
> respond to the list.)
I think this phenomenons around diald may become so important that we should
keep the dialog on the list.
I'll send you a few file listings of my network configuration very soon.
Best regards, Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
