On Wed, 10 Oct 2001 oinkfreebiker@att.net wrote:

> Unnumbered link is a new concept for me. I found some
> info on it at...
>
> http://support.intel.com/support/si/routers/accessport/
> apre2503.htm
>
> ...(URL -- sans the line break).
>
> I'm wondering, does this perhaps explain the strange
> behavior I've been wrestling with? In one of my pppd
> options for mgetty, I set this option on AutoPPP for
> mgetty...
>
> 192.168.1.100:192.168.1.101
>
> ...presuming that the server would have IP ...100 and the
> client would have IP ...101

Sure, since that's what you told it to do. I hope these aren't the
same numbers as your ethernet interfaces. In fact, they shouldn't even
be on the same subnet -- you could use 192.168.0/24 for the ethernet,
and 192.168.1/24 for the ppp "network", and then if you still have a
problem, it's a simple networking/routing problem, and has nothing to
do with either "mgetty" or "pppd".

> So I expected to be able to ping, ftp and telnet both
> ways (server->client and client->server). And indeed, I
> can ping both ways. But I can only ftp and telnet one
> way, server-to-client. From client-to-server, both ftp
> and telnet will time out.

Perhaps you have managed to set up different paths for packets to and
from. That's OK for some things, but when "ftp", e.g., opens a
connection, it'll bind to the address of one interface, and it expects
to get responses on that same interface it sends the packets out on.
Try "route get <otherhost>" on each host, to see which interface the
packets will go out on.

> The timeout happens whether or not I have LAN connected.

Just disconnecting the LAN doesn't change the routing table. You'd
have to manipulate the routes somehow in order for anything to change
-- at least bring the interface down.

> I have debug set at 9 for mgetty.

Your problem doesn't seem to have a whole lot to do with mgetty. (You
said you can ping.)

Frederick