From owner-freebsd-questions Sun Jan 14 16:59:49 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA04613 for questions-outgoing; Sun, 14 Jan 1996 16:59:49 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA04608 for ; Sun, 14 Jan 1996 16:59:44 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA29794; Sun, 14 Jan 1996 18:01:49 -0700 Date: Sun, 14 Jan 1996 18:01:49 -0700 From: Nate Williams Message-Id: <199601150101.SAA29794@rocky.sri.MT.net> To: The YossMan Cc: freebsd-questions@freebsd.org Subject: Re: USR sportster dialin problems w/PPP In-Reply-To: References: Sender: owner-questions@freebsd.org Precedence: bulk > 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. I suspect the infamous 'ARP' bug. Basically, your remote host is trying to send all the packets to the ethernet device instead of to the ppp/tun device. Is the IP address you are using in the same 'class' as the ethernet? Nate > } > 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 = ; > eol2 = ; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; > min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ; > 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