Date: Tue, 7 May 1996 10:31:14 -0500 From: Russell Cattelan <cattelan@thebarn.com> To: freebsd-bugs@freebsd.org Subject: ppp-2.2 misperceives carrier loss under heavy loads Message-ID: <199605071531.KAA02802@kunzite.lcse.umn.edu>
next in thread | raw e-mail | index | archive | help
Upon ugrading to 2.2-960323-SNAP and thusly ppp 2.2 pppd is getting
carrier loss when ever a heavy load is applied to the link.
(note upgraded to 2.2-960501 last night, problem persists)
May 5 11:09:09 lupo pppd[8908]: local IP address 128.101.146.15
May 5 11:09:09 lupo pppd[8908]: remote IP address 128.101.146.5
May 5 11:09:09 lupo pppd[8908]: rcvd [CCP ConfAck id=0x1]
May 5 11:09:09 lupo pppd[8908]: rcvd [CCP ConfReq id=0x2]
May 5 11:09:09 lupo pppd[8908]: sent [CCP ConfAck id=0x2]
May 5 11:09:09 lupo pppd[8908]: No matching compression scheme, CCP disabled
May 5 11:09:09 lupo pppd[8908]: sent [CCP TermReq id=0x2]
May 5 11:09:09 lupo pppd[8908]: rcvd [CCP TermAck id=0x2]
May 5 11:09:24 lupo pppd[8908]: Hangup (SIGHUP)
May 5 11:09:24 lupo /kernel: ppp0: no carrier
May 5 11:09:24 lupo last message repeated 14 times
May 5 11:09:24 lupo pppd[8908]: Modem hangup
May 5 11:09:24 lupo pppd[8908]: Exit.
I've tracked this down a bit and the no carrier is showing up in
/sys/net/ppp_tty.c
And no it's not the modem, I commented out the section that cycles the
DTR modem stays connected but now I have a dead link.
One thing I found out after digging into the problem is that my serial
chips are 8250's uhgggg! I going to get a different board with 16550's
to see if that has any affect.
All of this ran quite well for weeks at a time under 2.1 and
ppp-2.1.2.
Some background: modem supra-fax 14,400
other end is a Sun 4.1.4 also running ppp-2.2.
I have tested the link using ijppp to one of our terminal servers and
it runs just fine... not strange carrier losses.
Unfortunately I can't get ijppp to talk to ppp-2.2.
Everything sets up, the link comes up but as soon as data is send
across the link it whines about:
05-06 22:06:26 [211] myaddr = 128.101.146.15 hisaddr = 128.101.146.5
05-06 22:06:26 [211] OsLinkup: 128.101.146.5
05-06 22:06:26 [211] CCP: Received Configure Reject (1) state = Req-Sent (6)
05-06 22:06:26 [211] CCP: RecvConfigRej.
05-06 22:06:26 [211] PRED1[2]
05-06 22:06:26 [211] CCP: SendConfigReq
05-06 22:06:26 [211] CCP: Received Configure Request (2) state = Req-Sent (6)
05-06 22:06:26 [211] CCP: SendConfigAck(Req-Sent)
05-06 22:06:26 [211] CCP: state change Req-Sent --> Ack-Sent
05-06 22:06:26 [211] CCP: Received Configure Ack (2) state = Ack-Sent (8)
05-06 22:06:26 [211] CCP: state change Ack-Sent --> Opend
05-06 22:06:26 [211] CCP: LayerUp.
05-06 22:06:26 [211] myproto = 0, hisproto = 0
05-06 22:07:29 [211] CCP: Received Reset Request (3) state = Opend (9)
05-06 22:07:29 [211] CCP: RecvResetReq
05-06 22:07:29 [211] CCP: SendResetAck
05-06 22:07:30 [211] CCP: Received Reset Request (4) state = Opend (9)
05-06 22:07:30 [211] CCP: RecvResetReq
05-06 22:07:30 [211] CCP: SendResetAck
05-06 22:07:31 [211] CCP: Received Reset Request (5) state = Opend (9)
05-06 22:07:31 [211] CCP: RecvResetReq
05-06 22:07:31 [211] CCP: SendResetAck
05-06 22:07:32 [211] CCP: Received Reset Request (5) state = Opend (9)
05-06 22:07:32 [211] CCP: RecvResetReq
05-06 22:07:32 [211] CCP: SendResetAck
05-06 22:07:33 [211] CCP: Received Reset Request (5) state = Opend (9)
05-06 22:07:33 [211] CCP: RecvResetReq
05-06 22:07:33 [211] CCP: SendResetAck
Any suggestions as to what I can start fiddling with to track down
that problem please let me know... At this point I'm guessing it has
something to do with the hardware tty drivers themselves.
--
Russell Cattelan
-------------------------------------------
Of all that works backward must be foreword!
-------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605071531.KAA02802>