> Bryan Liesner wrote:
> > On Wed, 29 Dec 1999, Werner Griessl wrote:
> >
> > <>
> > <>current's new ppp discards the "#0001"-part from my
> > <>german telekom account and makes it impossible to
> > <>connect to my provider.
> > <>
> >
> > While we are on the subject, ppp no longer runs an external chat
> > script. This used to work:
> >
> > set login "\"!chat \\\\-f /etc/ppp/login \\\\-r /var/log/connect.log\""
Urk ! The version you have is now *FIXED*. The above line should
read:
set login "\"!chat \\-f /etc/ppp/login \\-r /var/log/connect.log\""
as the - sign should only be escaped once for the chat parsing and
once for the argument parsing. I'll fix the docs and update
README.changes.
> Heh, I'll join in too.. I've been having ppp abort on me a few times. Today
> it died with "Error: Request for mbuf size 2329 denied" after I attempted to do
> a 'show links' on an already established pppctl connection:
>
> Dec 29 10:38:27 haywire ppp[882]: tun0: Phase: Unknown protocol 0x80fb (compression
>on single link in multilink group control)
> Dec 29 10:38:27 haywire ppp[882]: tun0: LCP: 1: SendProtocolRej(15) state = Opened
> Dec 29 10:39:24 haywire ppp[882]: tun0: Phase: 1: HDLC errors -> FCS: 0, ADDR: 0,
>COMD: 0, PROTO: 1
> (pppctl connects here)
> Dec 29 10:55:10 haywire ppp[882]: tun0: Phase: Connected to client from
>202.12.86.2:41555
> Dec 29 10:55:12 haywire ppp[882]: tun0: Command: 202.12.86.2:41555: passwd ********
> (and here I type 'show links')
> Dec 29 10:55:55 haywire ppp[882]: tun0: Phase: 1: HDLC errors -> FCS: 2, ADDR: 0,
>COMD: 0, PROTO: 0
> Dec 29 10:55:55 haywire ppp[882]: tun0: Warning: lqr_Input: magic 0x428bf108 is
>wrong, expecting 0x14ae603f
> Dec 29 10:55:56 haywire ppp[882]: tun0: Error: Request for mbuf size 2329 denied
I've no idea what tried to allocate this. It should be impossible to
allocate an mbuf this size because it's illegal for either side to
send a packet this size.... Even the CCP layer (which creates
packets of a pretty much random size) allocates mbufs in smaller chunks
and chains them, throwing the results away if they exceed the original
packet size.
Prior to my recent (user-)mbuf changes, this may have resulted in
corruption later on (I think).
Is there any chance of running under gdb and catching a stack trace
when ppp calls AbortProgram() from m_get() ? Specifically, I'm
interested in what's calling m_get() and why it's calling it with
such a large value.
> Dec 29 10:55:56 haywire ppp[882]: tun0: Phase: 202.12.86.2:41555: Client connection
>dropped.
> Dec 29 10:55:56 haywire ppp[882]: tun0: Phase: PPP Terminated (71).
Hmm, perhaps this message should be emitted at the end of
AbortProgram(). It looks silly here - before all the complaints
about shutting everything down in a hurry.
> Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: LayerDown: 202.12.86.2
> Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: SendTerminateReq(15) state =
>Opened
> Dec 29 10:55:56 haywire ppp[882]: tun0: IPCP: mp: State change Opened --> Closing
> Dec 29 10:55:56 haywire ppp[882]: tun0: CCP: mp: State change Stopped --> Closed
> Dec 29 10:55:56 haywire ppp[882]: tun0: CCP: mp: State change Closed --> Initial
> Dec 29 10:55:56 haywire ppp[882]: tun0: Warning: Del route failed: 0.0.0.0:
>Non-existent
> Dec 29 10:55:56 haywire ppp[882]: tun0: Error: Oops, destroying a datalink in state
>open
> (he's dead jim!)
> Dec 29 10:56:19 haywire ppp[882]: tun0: Phase: 1: Connect time: 1112 secs: 533725
>octets in, 386209 octets out
> Dec 29 10:56:19 haywire ppp[882]: tun0: Phase: total 827 bytes/sec, peak 4972
>bytes/sec on Wed Dec 29 10:56:19 1999
>
> > -Bryan
[.....]
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
--
Brian <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<http://www.Awfulhak.org> <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour ! <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
