On Thu, 26 Feb 1998, SamMaEl wrote:

> 	First off, I noticed in my authlog that there had been a failed
> login on tty00, so I tried moving the modem over to the modem port and
> getty started executing login. BUT... my remote terminal was sending a
> bunch of garbage to the NetBSD over the link somehow... because when I
> connected, getty executed login and I saw (with a ps -x) that dtdtdtdtdtd
> (or something similar... a bunch of d's and t's) was trying to login ;-)
> Any ideas on what might cause this? I tried using mdmbuf in the /etc/ttys
> line, but that didn't help any. I also tried turning off error correction
> and compression on the modem that was dialing up, but that didn't fix
> anything either. I accidentally used 'cu' on the modem port while getty
> was running, and I got a login prompt ;-) So, I KNOW that getty is doing
> it job properly.

You're modem is echoing everything it receives to getty, which then echoes
everything back because it thinks someone's logging in.

> 	I have the modem port set to 57600 in the booter, and dmesg says
> it is running at 57600 at bootup. I tried using std.38400, but that didn't
> change anything. Should it make a difference if I run the port at a higher
> speed than the modems are running at? I wouldn't think so... although,
> when I run a serial line to another Mac I won't get a login prompt unless
> I have both set at the same speed, and otherwise I get some of the same
> garbage I am getting now... suggestions, ideas? 

There are two baud rates in the problem. The baud rate between modems, and
the baud rate between the computer and the modem.

As long as the modem can handle the baud rate to the Mac, that part's ok.
Make sure, though, that the baud rate isn't too high as you'll generate
silo overflows and floods. That will severely degrade performance.

You need to set up the modem to do all the right things and save the
settings. Compression's ok if you have transfer rates & flow control set
right. You also need to get the modem's idea of the flow control saved, so
that you don't have to talk to it each time it powers up.

Ignore mdmbuf. Since there's a modem there, you want to use DCD as carrier
detect.

Don't set 'local' in /etc/ttys. getty WON'T work right. If there's a
carrier detection problem, fix your modem's settings (probably fine unless
you set something weird) and check the modem cable.

Remember, how getty deals with modems is simple. Normally it fires up it's
connection line, and gives the prompt. Then it starts looking for an input
user name. With a modem, it blocks until there's actually a carrier, THEN
it sents the login prompt. w/ 'local', it won't wait for the other modem
to be there. Chances are that the modem will then echo everyting it sees
right back to getty, causing much mayhem.

Decide if you want/can hang up the modem by dropping DTR. Advantage: you
can hang up cleanly. Disadvantage: With mac serial ports, you can't
simultaniously shut the modem up w/ flow control and also be able to hang
up. Both functions use DTR. If you don't need to throttle the modem, use
DTR to drop the connection. Then you can use crtscts flow control (we'll
stop sending if the modme asks by dropping CTS). If you need to throttle
the modem, use cdtrcts flow control. CTS will get us to hush as above, and
DTR will get the modem to hush.

For cdtrcts (dtrcts in /etc/ttys), you'll need to make sure your modem
will either use DTR for flow control, or it will use RTS and your modem
cable links the two. Also, the modem should NOT drop carrier on loss of
DTR. :-)

> 	As for PPP, I was able to get connections again. I got connection,
> authentication and login. Still, I wasn't able to communicate between the
> ppp client and any of the rest of the network, including the ppp server.
> The ppp server was adding the route between it and the client. Here is the
> new options I used:
> 
> cdtrcts
> #netmask 255.255.255.0
> domain woo.org
> #defaultroute
> passive
> modem
> silent
> proxyarp
> login
> persist
> debug
> 
> 	At Bill's suggestion I commented out defaultroute and netmask, but
> that didn't help any unfortunately. 
> 
> 	Nothing out of the ordinary appeared in the logs, except that
> since I am giving the remote client an IP of 192.168.2.1, and the ethernet
> is on the 192.168.1.* network, and there is no net interface on
> 192.168.2.*, it couldn't find a device for the 'proxyarp' option. I tried
> giving the client the address 192.168.1.5, and proxyarp was able to use my
> ethernet address, but it didn't help the client communicate with the rest
> of the LAN.
> 
> 	So, right now the client can ping all 3 other hosts on the
> network. The client can lookup names, so it is talking to the domain name
> server, which is also the ppp server. But, TCP and UDP tests (via MacTCP
> Watcher) fail, and I cannot telnet to the ppp server, or my IIcx.

Wait. If the client can ping hosts, ppp is up quite well. Are you
telnetting by IP address or name? Try IP address. If that doesn't work
when pinging does, your telnet client is broken.

> 	It still sounds to me like the client isn't getting told its
> defaultroute. And, as it is impossible to manually configure that with
> FreePPP/PPP/MacPPP.... the client NEEDS to get the routing information. I
> remember that MacTCP always had the gateway field... I don't remember if
> it would let you change it if you were getting your IP from the server...
> 	
> 	Any ideas on either topic? I am totally stumped. If PPP works
> (except for the routing), I don't see why a dialup shell shouldn't be
> working too, and I've gone over the pppd man page 20 times so far, looking
> or options which will set the router... and there IS one if you're using
> IPX, but not one for regular IP 8-(

How is pppd getting fired up on the host computer?

Take care,

Bill