Date: Sun, 14 Jan 1996 18:01:49 -0700 From: Nate Williams <nate@sri.MT.net> To: The YossMan <yossman@yale.canweb.net> Cc: freebsd-questions@freebsd.org Subject: Re: USR sportster dialin problems w/PPP Message-ID: <199601150101.SAA29794@rocky.sri.MT.net> In-Reply-To: <Pine.BSF.3.91.960114184142.391A-100000@yale.canweb.net> References: <Pine.BSF.3.91.960114184142.391A-100000@yale.canweb.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 = <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?199601150101.SAA29794>