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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960114184142.391A-100000>