On Wed, 25 Feb 1998, SamMaEl wrote:

> 	I tried to get both a dialup shell and PPP working again tonight,
> and both failed again. I DO get a connection, in both cases. But, either
> getty is not recognizing the connection, or something else is going wrong,
> because I have tried every terminal program that I have, with every form
> of flow control and tried both 1, 0, and auto stop bits... everything I
> could try. I went through the termcap manpage, the /usr/share/misc/termcap
> database (to find /etc/gettytab syntaxes, etc), the /etc/gettytab file and
> manpage, the manpage for /etc/ttys, the getty manpage... and nothing has
> helped. I took someone's suggestion and tried adding 'local' to the line
> in /etc/ttys, but that didn't help either. 8-( I also tried rtscts, and
> mdmbuf, but neither of those helped either.

Don't set 'local' on the tty if there is a dial-in modem on that line! If
you're setting up a dial-in situation, you do want all of the carrier
detection magic 'local' turns off.
> 	So... is there any way to see if getty is actually noticing the
> connection, or how can I tell what's going on from the NetBSD side?

What is running on that port? You need to have not set 'local', and have
getty on for that line. What error messages show up in the logs?

> 	As for PPP. I have gotten that to ALMOST work. Modem answers,
> FreePPP and pppd chat back and forth and decide that I am in fact who I
> say I am, and log me in. MacTCP Watcher gets the name lookups properly,
> and the Powerbook gets recognized as ppp0.woo.org (the name I set aside
> for the 1st ppp IP address), and therefore it is getting its IP address
> just fine. But, any TCP, UDP or ICMP tests to any host on the ETHERNET
> from the laptop (which IS disconnected from the Ethernet during this test,
> so can only communicate via ppp) fail. Name lookups work just fine
> however... and TCP/UDP/ICMP tests to IP's on the network fail as well. 
> 
> 	I am guessing it is a routing problem. But, since OT doesn't let
> you set your router with PPP... I have to rely on NetBSD telling the
> Powerbook where to look, and it isn't doing that obviously. I've tried
> using defaultroute in the options file, but all that does is creates a
> defaultroute from the NetBSD machine to the laptop 8-(

Don't use defaultroute. It's for client ppp. You're trying to set up the
server side, which is a bit different.

> 	Here is my options file:
> 
> #
> # Options file for DIALUP ppp
> #
> cdtrcts                    
> netmask 255.255.255.0
> domain woo.org           # my domain
> defaultroute             # try adding a default route?

As above, don't.

> passive
> modem
> silent
> proxyarp                 
> login
> persist
> #debug
> #kdebug 1
> login
> 
> 	And here is how I am invoking pppd, with a script:
> #
> # This will setup pppd and ready it for our dialup
> #
> 
> /usr/sbin/pppd file /etc/ppp/dialup-ppp/options 192.168.1.1:192.168.2.1
> /dev/tty01 57600 # this is on the same line as the above line...
> 
> 	Or, should I be using a different netmask, since the ppp IP's are
> in the 192.168.2.* network?

netmasks don't really matter for ppp. netmasks say what parts of the IP
address can be gotten to directly via that interface. I.E. IP addresses
not differing in the netmask all receive a packet sent out over this
interface. The only thing receiving packets on the ppp net is the
otherside, so netmasks don't make sense.

> 	Any help is appreciated. I'm thinking about adding yet another
> line so friends can log in and play games and send e-mail and stuff.
> Nothing TOO important, but it's proving to be a good experiment. I've
> already learned alot about terminal emulation ;-)

I gather the internet is hooked up via the ethernet (i.e. another router)?
Where did you set things up so the Ethernetted mac will accept IP packets
from the net for the address on the otherside of the router? I'm not sure
how to do that, but I think you need ailas addresses on the ethernet
interface (well, I'm sure you need that, but I'm not sure how to ensure
that the kernel knows what to do with the received packets).

> 	P.S. And once again... this would probably be a great candidate
> for a HOW-TO to be written, and would be pretty system independent (except
> maybe, modem devices, etc...) Hint, hint, hint... ;-)

I think I hear an author. Hint, Hint, Hint :-)