From owner-freebsd-questions  Sun Jan 14 16:18:21 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA03166
          for questions-outgoing; Sun, 14 Jan 1996 16:18:21 -0800 (PST)
Received: from yale.canweb.net (root@NS.CANWEB.NET [206.130.28.6])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA03160
          for <freebsd-questions@freebsd.org>; Sun, 14 Jan 1996 16:18:17 -0800 (PST)
Received: (from yossman@localhost) by yale.canweb.net (8.6.12/8.6.12) id TAA00480; Sun, 14 Jan 1996 19:20:20 -0500
Date: Sun, 14 Jan 1996 19:20:19 -0500 (EST)
From: The YossMan <yossman@yale.canweb.net>
To: freebsd-questions@freebsd.org
Subject: USR sportster dialin problems w/PPP
Message-ID: <Pine.BSF.3.91.960114184142.391A-100000@yale.canweb.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-questions@freebsd.org
Precedence: bulk

I have been trying for almost two weeks straight now to get dialin PPP 
working with some success.  I am using USR's 28k8 Sporsters with the 33k6 
upgrade.  I am dialing in from a test win95 box with a USR Sportster 
14k4.  This is FBSD2.1.0R controlling a BOCABOARD 16port job on IRQ10, 
base address 100.  

I can dial in and get a login prompt just fine almost 100% of the time.  
It's when I switch from the normal terminal mode to PPP mode that my 
problems start.  On the first or second call in, things work fine, I can 
ping my dialin box just fine.  After that if I try to dial in I get to 
the PPP part, things look like they are working fine but I can't even 
ping the dialin box, http doesn't work to anywhere, etc.


Relevant lines in /etc/ttys:

ttyd1   "/usr/libexec/getty std.38400"  dialup  on      insecure
ttyd2   "/usr/libexec/getty std.38400"  dialup  on      insecure
[...]
ttydg   "/usr/libexec/getty std.38400"  dialup  on      insecure


Relevant lines in /etc/gettytab:

std.38400|38400-baud:\
        :np:sp#38400:


Relevant lines in /etc/rc.serial:

modem() {
        # Modem that supports CTS and perhaps RTS handshaking.
        for i in $*
        do
                comcontrol /dev/ttyd$i dtrwait 500 drainwait 180
                stty </dev/ttyid$i crtscts 38400
                stty </dev/ttyld$i crtscts 38400
        done
}
modem           1 2 3 4 5 6 7 8 9 a b c d e g


Relevant lines in the kernel config file for the kernel I'm currently using:

options         COM_MULTIPORT           # multiport card support

device          sio1    at isa? port 0x100 tty flags 0x1005
device          sio2    at isa? port 0x108 tty flags 0x1005
[...]
device          sio16   at isa? port 0x178 tty flags 0x1005 irq 10 vector siointr
pseudo-device   tun     16


If you have any other questions about any of the files, don't hesitate to 
ask.

I'm beginning to think that it is something that happens to the ttyd* 
devices after the first or second connection to them.  When I do a 
'stty -a -f /dev/ttyd1', this is what I get:

speed 38400 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
        -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
        -nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk
        -brkint -inpck -ignpar -parmrk
oflags: -opost -onlcr -oxtabs
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -dsrflow
        -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
        min = 1; quit = ^\; reprint = ^R; start = ^Q; status = <undef>;
        stop = ^S; susp = ^Z; time = 0; werase = ^W;


The main thing that caught my eye right away was the 'hupcl'.  Why would I 
want FreeBSD to stop asserting modem control after last close?  
If I have the USRs setup to always expect modem control, doesn't that 
mean if FreeBSD is not asserting modem control anymore that something 
will definitely be broken after that?  And if that IS the case how come I 
can still dial in and get a login prompt in terminal mode, even though 
afterwards switching to PPP has stopped working?

In any case I am getting extremely frustrated with the entire effort 
here.  I know other people have gotten FreeBSD and BOCABOARDs working 
before, as I set mine up with the help of the Handbook.  If anyone can 
make any suggestions as to why this might be occuring I would appreciate 
it greatly.

If anyone else has a setup like mine could you please let me know what
your /etc/rc.serial, /etc/ttys, and /etc/gettytab files look like?  An
output of ATI4 (current settings) on one of your dialin USRs would be
muchly appreciated as well.  I know I am close to getting this working,
but why it stops working after the first couple times has me baffled
something fierce! 

thanks so much in advance, 
yossman