Weird PPP problem

Weird PPP problem

Post by Rand Simbe » Fri, 01 Dec 2000 04:00:00



I have two machines, both running RH7.0, though one is running 2.2.15
and the other is running 2.2.16.  The one running 2.2.15 can establish
a good ppp connection.  The other one, using exactly the same ppp-on,
ppp-off, chat and options scripts, cannot.  It will dial up, make all
the standard modem noises, then go silent as normal, but I can't get a
network connection (i.e., nothing pingable).  Can anyone think of what
might be different between the two setups that allows one to connect
and the other not to?

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Clifford Kit » Fri, 01 Dec 2000 04:00:00



> I have two machines, both running RH7.0, though one is running 2.2.15
> and the other is running 2.2.16.  The one running 2.2.15 can establish
> a good ppp connection.  The other one, using exactly the same ppp-on,
> ppp-off, chat and options scripts, cannot.  It will dial up, make all
> the standard modem noises, then go silent as normal, but I can't get a
> network connection (i.e., nothing pingable).  Can anyone think of what
> might be different between the two setups that allows one to connect
> and the other not to?

Different hardware might mean a different configuration is needed
for the one that doesn't work.  Add the pppd option "debug" and the
chat -v options and post exact copies, including timestamps, of the
log messages, usually found in a file or files in /var/log.

It's not the kernel unless you got it from Red Hat and RH has modified
it, a pristine 2.2.16 compiled here worked fine for me.

--


 
 
 

Weird PPP problem

Post by Rand Simbe » Fri, 01 Dec 2000 04:00:00


On Thu, 30 Nov 2000 11:40:49 -0600, in a place far, far away, Clifford

such a way as to indicate that:

Quote:>Different hardware might mean a different configuration is needed
>for the one that doesn't work.  Add the pppd option "debug" and the
>chat -v options and post exact copies, including timestamps, of the
>log messages, usually found in a file or files in /var/log.

OK, here's the log (ignore the date--I really did do it today--the
clock's just screwed up on my machine, and I've had other problems...
<g>)

Nov 25 15:00:38 localhost pppd[1797]: pppd 2.3.11 started by root, uid
0
Nov 25 15:00:39 localhost chat[1798]: abort on (BUSY)
Nov 25 15:00:39 localhost chat[1798]: abort on (NO CARRIER)
Nov 25 15:00:39 localhost chat[1798]: send (ATZ^M)
Nov 25 15:00:39 localhost chat[1798]: expect (OK)
Nov 25 15:00:40 localhost chat[1798]: ATZ^M^M
Nov 25 15:00:40 localhost chat[1798]: OK
Nov 25 15:00:40 localhost chat[1798]:  -- got it
Nov 25 15:00:40 localhost chat[1798]: send (ATDT70#,896-0011^M)
Nov 25 15:00:40 localhost chat[1798]: expect (ONNECT)
Nov 25 15:00:40 localhost chat[1798]: ^M
Nov 25 15:00:59 localhost chat[1798]: ATDT70#,896-0011^M^M
Nov 25 15:00:59 localhost chat[1798]: CONNECT
Nov 25 15:00:59 localhost chat[1798]:  -- got it
Nov 25 15:00:59 localhost chat[1798]: send (^M)
Nov 25 15:00:59 localhost chat[1798]: expect (ogin:)
Nov 25 15:00:59 localhost chat[1798]:  115200^M
Nov 25 15:01:01 localhost chat[1798]: ^M
Nov 25 15:01:01 localhost chat[1798]: netcom login:
Nov 25 15:01:01 localhost chat[1798]:  -- got it

Nov 25 15:01:01 localhost chat[1798]: expect (assword:)

Nov 25 15:01:02 localhost chat[1798]: Password:
Nov 25 15:01:02 localhost chat[1798]:  -- got it
Nov 25 15:01:02 localhost chat[1798]: send (^password^M)
Nov 25 15:01:02 localhost chat[1798]: expect (PP session)
Nov 25 15:01:02 localhost chat[1798]:  ^M
Nov 25 15:01:02 localhost chat[1798]: Packet mode enabled: PPP session
Nov 25 15:01:02 localhost chat[1798]:  -- got it
Nov 25 15:01:02 localhost chat[1798]: send (/d/c^M)
Nov 25 15:01:02 localhost pppd[1797]: Serial connection established.
Nov 25 15:01:02 localhost pppd[1797]: Using interface ppp0
Nov 25 15:01:02 localhost pppd[1797]: Connect: ppp0 <--> /dev/ttyS1
Nov 25 15:01:03 localhost pppd[1797]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0x967252d2> <pcomp> <accomp>]
Nov 25 15:01:03 localhost pppd[1797]: rcvd [LCP ConfAck id=0x1
<asyncmap 0x0> <magic 0x967252d2> <pcomp> <accomp>]
Nov 25 15:01:05 localhost pppd[1797]: rcvd [LCP ConfReq id=0x2 <mru
1500> <asyncmap 0x0> <magic 0xff71a12c> <pcomp> <accomp>]
Nov 25 15:01:05 localhost pppd[1797]: sent [LCP ConfAck id=0x2 <mru
1500> <asyncmap 0x0> <magic 0xff71a12c> <pcomp> <accomp>]
Nov 25 15:01:05 localhost pppd[1797]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Nov 25 15:01:05 localhost pppd[1797]: rcvd [IPCP ConfReq id=0x1
<compress VJ 0f 00> <addr 163.179.37.84>]
Nov 25 15:01:05 localhost pppd[1797]: sent [IPCP ConfAck id=0x1
<compress VJ 0f 00> <addr 163.179.37.84>]
Nov 25 15:01:05 localhost pppd[1797]: rcvd [IPCP ConfNak id=0x1 <addr
205.184.165.241>]
Nov 25 15:01:05 localhost pppd[1797]: sent [IPCP ConfReq id=0x2 <addr
205.184.165.241> <compress VJ 0f 01>]
Nov 25 15:01:06 localhost pppd[1797]: rcvd [IPCP ConfAck id=0x2 <addr
205.184.165.241> <compress VJ 0f 01>]
Nov 25 15:01:06 localhost pppd[1797]: local  IP address
205.184.165.241
Nov 25 15:01:06 localhost pppd[1797]: remote IP address 163.179.37.84
Nov 25 15:01:06 localhost pppd[1797]: Script /etc/ppp/ip-up started
(pid 1801)
Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x1 < 11 05
00 01 04>]
Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x1 < 11 05
00 01 04>]
Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x2 < 11 05
00 01 03>]
Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x2 < 11 05
00 01 03>]
Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x3 < 11 05
00 00 00>]
Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x3 < 11 05
00 00 00>]
Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x4 < 12 06
00 00 00 01>]
Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x4 < 12 06
00 00 00 01>]
Nov 25 15:01:06 localhost pppd[1797]: Script /etc/ppp/ip-up finished
(pid 1801), status = 0x0
Nov 25 15:01:09 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:09 localhost pppd[1797]: rcvd [CCP TermReq id=0x6]
Nov 25 15:01:09 localhost pppd[1797]: sent [CCP TermAck id=0x6]
Nov 25 15:01:12 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:12 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:12 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:15 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:15 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:15 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:18 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:18 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:18 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:21 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:21 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:21 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:24 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:24 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:24 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:27 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:27 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:27 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:30 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
Nov 25 15:01:30 localhost pppd[1797]: rcvd [CCP TermReq id=0x0]
Nov 25 15:01:30 localhost pppd[1797]: sent [CCP TermAck id=0x0]
Nov 25 15:01:30 localhost pppd[1797]: Terminating on signal 2.
Nov 25 15:01:30 localhost pppd[1797]: Script /etc/ppp/ip-down started
(pid 1814)
Nov 25 15:01:30 localhost pppd[1797]: sent [LCP TermReq id=0x2 "User
request"]
Nov 25 15:01:30 localhost pppd[1797]: Script /etc/ppp/ip-down finished
(pid 1814), status = 0x0
Nov 25 15:01:30 localhost pppd[1797]: rcvd [LCP TermAck id=0x7]
Nov 25 15:01:30 localhost pppd[1797]: Connection terminated.
Nov 25 15:01:30 localhost pppd[1797]: Connect time 0.5 minutes.
Nov 25 15:01:30 localhost pppd[1797]: Sent 395 bytes, received 448
bytes.
Nov 25 15:01:31 localhost pppd[1797]: Hangup (SIGHUP)
Nov 25 15:01:31 localhost pppd[1797]: Exit.

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Clifford Kit » Fri, 01 Dec 2000 04:00:00



> On Thu, 30 Nov 2000 11:40:49 -0600, in a place far, far away,

> monitor glow in such a way as to indicate that:
>>Different hardware might mean a different configuration is needed
>>for the one that doesn't work.  Add the pppd option "debug" and the
>>chat -v options and post exact copies, including timestamps, of the
>>log messages, usually found in a file or files in /var/log.
> OK, here's the log (ignore the date--I really did do it today--the
> clock's just screwed up on my machine, and I've had other problems...
> <g>)
> Nov 25 15:00:38 localhost pppd[1797]: pppd 2.3.11 started by root, uid
> 0

There was nothing in the first part of the log to suggest the source
of the trouble.

Quote:> Nov 25 15:01:02 localhost chat[1798]: expect (PP session)
> Nov 25 15:01:02 localhost chat[1798]:  ^M
> Nov 25 15:01:02 localhost chat[1798]: Packet mode enabled: PPP session
> Nov 25 15:01:02 localhost chat[1798]:  -- got it
> Nov 25 15:01:02 localhost chat[1798]: send (/d/c^M)

You're not in Kansas anymore.  The send part of the expect-send beginning
with  ``PP session'' should be ``\d\c'' not ``/d/c''. :)  There is
a small chance that this is the origin of the problem, but it's really
very small.

Quote:> Nov 25 15:01:02 localhost pppd[1797]: Serial connection established.
> Nov 25 15:01:02 localhost pppd[1797]: Using interface ppp0
> Nov 25 15:01:02 localhost pppd[1797]: Connect: ppp0 <--> /dev/ttyS1
> Nov 25 15:01:03 localhost pppd[1797]: sent [LCP ConfReq id=0x1
> <asyncmap 0x0> <magic 0x967252d2> <pcomp> <accomp>]
> Nov 25 15:01:03 localhost pppd[1797]: rcvd [LCP ConfAck id=0x1
> <asyncmap 0x0> <magic 0x967252d2> <pcomp> <accomp>]
> Nov 25 15:01:05 localhost pppd[1797]: rcvd [LCP ConfReq id=0x2 <mru
> 1500> <asyncmap 0x0> <magic 0xff71a12c> <pcomp> <accomp>]
> Nov 25 15:01:05 localhost pppd[1797]: sent [LCP ConfAck id=0x2 <mru
> 1500> <asyncmap 0x0> <magic 0xff71a12c> <pcomp> <accomp>]

These all look normal.

Quote:> Nov 25 15:01:05 localhost pppd[1797]: sent [IPCP ConfReq id=0x1 <addr
> 0.0.0.0> <compress VJ 0f 01>]
> Nov 25 15:01:05 localhost pppd[1797]: rcvd [IPCP ConfReq id=0x1
> <compress VJ 0f 00> <addr 163.179.37.84>]
> Nov 25 15:01:05 localhost pppd[1797]: sent [IPCP ConfAck id=0x1
> <compress VJ 0f 00> <addr 163.179.37.84>]

Often the different VJ compression codes (0f 01 versus 0f 00) is a
sign of trouble to come.

Quote:> Nov 25 15:01:05 localhost pppd[1797]: rcvd [IPCP ConfNak id=0x1 <addr
> 205.184.165.241>]
> Nov 25 15:01:05 localhost pppd[1797]: sent [IPCP ConfReq id=0x2 <addr
> 205.184.165.241> <compress VJ 0f 01>]
> Nov 25 15:01:06 localhost pppd[1797]: rcvd [IPCP ConfAck id=0x2 <addr
> 205.184.165.241> <compress VJ 0f 01>]
> Nov 25 15:01:06 localhost pppd[1797]: local  IP address 205.184.165.241
> Nov 25 15:01:06 localhost pppd[1797]: remote IP address 163.179.37.84
> Nov 25 15:01:06 localhost pppd[1797]: Script /etc/ppp/ip-up started
> (pid 1801)

All looks to be okay to this point.  Both sides have an IP address.

Quote:> Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x1 < 11 05
> 00 01 04>]
> Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
> Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x1 < 11 05
> 00 01 04>]
> Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x2 < 11 05
> 00 01 03>]
> Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x2 < 11 05
> 00 01 03>]
> Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x3 < 11 05
> 00 00 00>]
> Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x3 < 11 05
> 00 00 00>]

The peer tries to get pppd to accept several varieties STAC LZS CCP.
Pppd rejects them all since STAC LZS requires a license and cannot be
GPLed for an open source distribution.

Quote:> Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x4 < 12 06
> 00 00 00 01>]
> Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x4 < 12 06
> 00 00 00 01>]
> Nov 25 15:01:06 localhost pppd[1797]: Script /etc/ppp/ip-up finished
> (pid 1801), status = 0x0

Then the peer requests a variety of MS-PCC CCP, which pppd cannot
support either, and pppd rejects these too.  This can be fatal but
it shouldn't be here, it's just not the right type for that to
happen.

Quote:> Nov 25 15:01:09 localhost pppd[1797]: sent [CCP ConfReq id=0x1]
> Nov 25 15:01:09 localhost pppd[1797]: rcvd [CCP TermReq id=0x6]
> Nov 25 15:01:09 localhost pppd[1797]: sent [CCP TermAck id=0x6]

This sequence keeps repeating until the INT signal to pppd.

Here things seem to really go wrong, pppd tries to complete
the CCP negotiations that the peer started by sending an "empty"
Configure-Request, and the peer sends a CCP Terminate-Request, which
is not permitted by the PPP state machine until the CCP protocol
negotiation reachs the open state.

The peer has only two choices, to accept the pppd request for CCP
with no options to complete the CCP negotiations, or to send a
Protocol-Reject.  The peer is broken with respect to CCP negotiations.

You can try adding the pppd noccp option which will cause pppd to
Protocol-Reject the peer's attempt to negotiate CCP at the very start
of CCP negotiation.  You won't lose anything since pppd and the peer
have no common CCP algorithm anyway.

You can also try adding novj to keep VJ compression from being
negotiated.

The interesting question is why the connection is successful under the
2.2.15 kernel, but not under the 2.2.16 one with the same scripts and
options, and presumably the same version of pppd - 2.3.11 here.  I'd be
very interested in seeing the traces for the successful connection under
the 2.2.15 kernel, and to know whether the same pppd version is used
or not.

--

/* Editing with vi is a lot better than using a huge swiss army knife.
   Use =} to wrap paragraphs in vi.  Or put   map ^] !}fmt -72^M   in
   ~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */

 
 
 

Weird PPP problem

Post by Bill Unr » Sat, 02 Dec 2000 04:00:00



]OK, here's the log (ignore the date--I really did do it today--the
]clock's just screwed up on my machine, and I've had other problems...
]<g>)

Put the option
noccp
into /etc/ppp/options. The two machines are talking past each other re CPP
when neitehr speaks the other's language. I do not know why your machine
keeps asing for compression after it has requested termination of
compression negotiation.
](pid 1801)
]Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x1 < 11 05
]00 01 04>]
]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfReq id=0x1]

This ConfReq is silly. Thee seems to be something wrong
]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x1 < 11 05
]00 01 04>]
]Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x2 < 11 05
]00 01 03>]
]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x2 < 11 05
]00 01 03>]
]Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x3 < 11 05
]00 00 00>]
]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x3 < 11 05
]00 00 00>]

The keep yelling at each other and not listening. Teminate ccp
negotiation!

 
 
 

Weird PPP problem

Post by Erik van Ooste » Sat, 02 Dec 2000 04:00:00


Rand,

Are you sure the problem is in PPP? To me this sounds like a
routing or ipchains problem.

    Erik.

Rand Simberg schreef:

> I have two machines, both running RH7.0, though one is running 2.2.15
> and the other is running 2.2.16.  The one running 2.2.15 can establish
> a good ppp connection.  The other one, using exactly the same ppp-on,
> ppp-off, chat and options scripts, cannot.  It will dial up, make all
> the standard modem noises, then go silent as normal, but I can't get a
> network connection (i.e., nothing pingable).  Can anyone think of what
> might be different between the two setups that allows one to connect
> and the other not to?

> ************************************************************************
> simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)
> interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

> "Extraordinary launch vehicles require extraordinary markets..."



 
 
 

Weird PPP problem

Post by Rand Simbe » Sat, 02 Dec 2000 04:00:00


On Thu, 30 Nov 2000 20:12:08 -0600, in a place far, far away, Clifford

such a way as to indicate that:

Quote:>The peer has only two choices, to accept the pppd request for CCP
>with no options to complete the CCP negotiations, or to send a
>Protocol-Reject.  The peer is broken with respect to CCP negotiations.

>You can try adding the pppd noccp option which will cause pppd to
>Protocol-Reject the peer's attempt to negotiate CCP at the very start
>of CCP negotiation.  You won't lose anything since pppd and the peer
>have no common CCP algorithm anyway.

I tried that, at Bill Unruh's suggestion, as you can see in my other
post.  No joy...

Quote:>You can also try adding novj to keep VJ compression from being
>negotiated.

OK, I'll put the ccp back in and try that.

Quote:>The interesting question is why the connection is successful under the
>2.2.15 kernel, but not under the 2.2.16 one with the same scripts and
>options, and presumably the same version of pppd - 2.3.11 here.  I'd be
>very interested in seeing the traces for the successful connection under
>the 2.2.15 kernel, and to know whether the same pppd version is used
>or not.

I'd be interested in seeing it, too, but <frustration>now, for some
reason, I can't get it to dial.</frustration>

      :-(

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Rand Simbe » Sat, 02 Dec 2000 04:00:00


On 1 Dec 2000 08:04:24 GMT, in a place far, far away,

in such a way as to indicate that:


>]OK, here's the log (ignore the date--I really did do it today--the
>]clock's just screwed up on my machine, and I've had other problems...
>]<g>)

>Put the option
>noccp
>into /etc/ppp/options. The two machines are talking past each other re CPP
>when neitehr speaks the other's language. I do not know why your machine
>keeps asing for compression after it has requested termination of
>compression negotiation.
>](pid 1801)
>]Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x1 < 11 05
>]00 01 04>]
>]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfReq id=0x1]

>This ConfReq is silly. Thee seems to be something wrong
>]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x1 < 11 05
>]00 01 04>]
>]Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x2 < 11 05
>]00 01 03>]
>]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x2 < 11 05
>]00 01 03>]
>]Nov 25 15:01:06 localhost pppd[1797]: rcvd [CCP ConfReq id=0x3 < 11 05
>]00 00 00>]
>]Nov 25 15:01:06 localhost pppd[1797]: sent [CCP ConfRej id=0x3 < 11 05
>]00 00 00>]

>The keep yelling at each other and not listening. Teminate ccp
>negotiation!

OK, results after putting in "noccp" in the option file...

**********************************************************************
Nov 26 15:02:10 localhost pppd[8753]: pppd 2.3.11 started by root, uid
0
Nov 26 15:02:11 localhost chat[8754]: abort on (BUSY)
Nov 26 15:02:11 localhost chat[8754]: abort on (NO CARRIER)
Nov 26 15:02:11 localhost chat[8754]: send (ATZ^M)
Nov 26 15:02:11 localhost chat[8754]: expect (OK)
Nov 26 15:02:12 localhost chat[8754]: ATZ^M^M
Nov 26 15:02:12 localhost chat[8754]: OK
Nov 26 15:02:12 localhost chat[8754]:  -- got it
Nov 26 15:02:12 localhost chat[8754]: send (ATDT70#,896-0011^M)
Nov 26 15:02:12 localhost chat[8754]: expect (ONNECT)
Nov 26 15:02:12 localhost chat[8754]: ^M
Nov 26 15:02:31 localhost chat[8754]: ATDT70#,896-0011^M^M
Nov 26 15:02:31 localhost chat[8754]: CONNECT
Nov 26 15:02:31 localhost chat[8754]:  -- got it
Nov 26 15:02:31 localhost chat[8754]: send (^M)
Nov 26 15:02:31 localhost chat[8754]: expect (ogin:)
Nov 26 15:02:31 localhost chat[8754]:  115200^M
Nov 26 15:02:33 localhost chat[8754]: ^M
Nov 26 15:02:33 localhost chat[8754]: netcom login:
Nov 26 15:02:33 localhost chat[8754]:  -- got it

Nov 26 15:02:33 localhost chat[8754]: expect (assword:)

Nov 26 15:02:34 localhost chat[8754]: Password:
Nov 26 15:02:34 localhost chat[8754]:  -- got it
Nov 26 15:02:34 localhost chat[8754]: send (password^M)
Nov 26 15:02:34 localhost chat[8754]: expect (PP session)
Nov 26 15:02:34 localhost chat[8754]:  ^M
Nov 26 15:02:34 localhost chat[8754]: Packet mode enabled: PPP session
Nov 26 15:02:34 localhost chat[8754]:  -- got it
Nov 26 15:02:34 localhost chat[8754]: send (/d/c^M)
Nov 26 15:02:34 localhost pppd[8753]: Serial connection established.
Nov 26 15:02:34 localhost pppd[8753]: Using interface ppp0
Nov 26 15:02:34 localhost pppd[8753]: Connect: ppp0 <--> /dev/ttyS1
Nov 26 15:02:35 localhost pppd[8753]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0x4735475c> <pcomp> <accomp>]
Nov 26 15:02:35 localhost pppd[8753]: rcvd [LCP ConfAck id=0x1
<asyncmap 0x0> <magic 0x4735475c> <pcomp> <accomp>]
Nov 26 15:02:37 localhost pppd[8753]: rcvd [LCP ConfReq id=0x2 <mru
1500> <asyncmap 0x0> <magic 0xedbdca28> <pcomp> <accomp>]
Nov 26 15:02:37 localhost pppd[8753]: sent [LCP ConfAck id=0x2 <mru
1500> <asyncmap 0x0> <magic 0xedbdca28> <pcomp> <accomp>]
Nov 26 15:02:37 localhost pppd[8753]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Nov 26 15:02:37 localhost pppd[8753]: rcvd [IPCP ConfReq id=0x1
<compress VJ 0f 00> <addr 163.179.37.72>]
Nov 26 15:02:37 localhost pppd[8753]: sent [IPCP ConfAck id=0x1
<compress VJ 0f 00> <addr 163.179.37.72>]
Nov 26 15:02:37 localhost pppd[8753]: rcvd [IPCP ConfNak id=0x1 <addr
207.223.169.69>]
Nov 26 15:02:37 localhost pppd[8753]: sent [IPCP ConfReq id=0x2 <addr
207.223.169.69> <compress VJ 0f 01>]
Nov 26 15:02:37 localhost pppd[8753]: rcvd [IPCP ConfAck id=0x2 <addr
207.223.169.69> <compress VJ 0f 01>]
Nov 26 15:02:37 localhost pppd[8753]: local  IP address 207.223.169.69
Nov 26 15:02:37 localhost pppd[8753]: remote IP address 163.179.37.72
Nov 26 15:02:37 localhost pppd[8753]: Script /etc/ppp/ip-up started
(pid 8755)
Nov 26 15:02:37 localhost pppd[8753]: rcvd [CCP ConfReq id=0x1 < 11 05
00 01 04>]
Nov 26 15:02:37 localhost pppd[8753]: Unsupported protocol
'Compression Control Protocol' (0x80fd) received
Nov 26 15:02:37 localhost pppd[8753]: sent [LCP ProtRej id=0x2 80 fd
01 01 00 09 11 05 00 01 04]
Nov 26 15:02:38 localhost pppd[8753]: Script /etc/ppp/ip-up finished
(pid 8755), status = 0x0
Nov 26 15:03:09 localhost pppd[8753]: Terminating on signal 2.
Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down started
(pid 8770)
Nov 26 15:03:09 localhost pppd[8753]: sent [LCP TermReq id=0x3 "User
request"]
Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down finished
(pid 8770), status = 0x0
Nov 26 15:03:09 localhost pppd[8753]: rcvd [LCP TermAck id=0x2]
Nov 26 15:03:09 localhost pppd[8753]: Connection terminated.
Nov 26 15:03:09 localhost pppd[8753]: Connect time 0.6 minutes.
Nov 26 15:03:09 localhost pppd[8753]: Sent 184 bytes, received 222
bytes.
Nov 26 15:03:10 localhost pppd[8753]: Hangup (SIGHUP)
Nov 26 15:03:10 localhost pppd[8753]: Exit.
**********************************************************************

Note that disabling ccp caused a new error...

Now what?

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Bill Unr » Sat, 02 Dec 2000 04:00:00



]On 1 Dec 2000 08:04:24 GMT, in a place far, far away,

]in such a way as to indicate that:
...
]OK, results after putting in "noccp" in the option file...

Well it is a much much different disconnection now. The negotiations all
finish, a ppp connection is set up, and now your pppd is stopping due to
"user request" Ie, you ( or something on your system ) is telling pppd
to shut down. That is vastly different from the endless yelling at each
other over CCP that occured befor. Leave the
noccp
option in. YOu will need it.

Now we just need to figure out why your system is requesting pppd to
die.
Notice that it now terminated 29 seconds after the connection was
established. Did you kill pppd thinking that nothing was happening?

or  Have you put something into /etc/ppp/ip-up or ip-up.local?

]Nov 26 15:02:38 localhost pppd[8753]: Script /etc/ppp/ip-up finished
](pid 8755), status = 0x0
]Nov 26 15:03:09 localhost pppd[8753]: Terminating on signal 2.
]Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down started
](pid 8770)
]Nov 26 15:03:09 localhost pppd[8753]: sent [LCP TermReq id=0x3 "User
]request"]
]Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down finished
](pid 8770), status = 0x0
]Nov 26 15:03:09 localhost pppd[8753]: rcvd [LCP TermAck id=0x2]
]Nov 26 15:03:09 localhost pppd[8753]: Connection terminated.
]Nov 26 15:03:09 localhost pppd[8753]: Connect time 0.6 minutes.
]Nov 26 15:03:09 localhost pppd[8753]: Sent 184 bytes, received 222
]bytes.
]Nov 26 15:03:10 localhost pppd[8753]: Hangup (SIGHUP)
]Nov 26 15:03:10 localhost pppd[8753]: Exit.

]Note that disabling ccp caused a new error...

Yes, of a totally different sort. PPP finished negotiating with the far
side and established a connection. The problem now is NOT ppp, but
something else.
Leave in the noccp option. It has definitely helped!

 
 
 

Weird PPP problem

Post by Rand Simbe » Sat, 02 Dec 2000 04:00:00


On 1 Dec 2000 21:05:38 GMT, in a place far, far away,

in such a way as to indicate that:

Quote:>]OK, results after putting in "noccp" in the option file...

>Well it is a much much different disconnection now. The negotiations all
>finish, a ppp connection is set up, and now your pppd is stopping due to
>"user request" Ie, you ( or something on your system ) is telling pppd
>to shut down. That is vastly different from the endless yelling at each
>other over CCP that occured befor. Leave the
>noccp
>option in. YOu will need it.

>Now we just need to figure out why your system is requesting pppd to
>die.

That's not hard.  I'm guilty...  :-)

Quote:>Notice that it now terminated 29 seconds after the connection was
>established. Did you kill pppd thinking that nothing was happening?

Yes, because I was not getting a useful connection (i.e., nothing
pingable on the net).  I normally get a fairly rapid connection.  For
Linux (as opposed to Windows) it's usually up within a few seconds.  I
assumed, based on this experience, that if it wasn't up in thirty
seconds, it wasn't going to happen.

Quote:>]Note that disabling ccp caused a new error...

>Yes, of a totally different sort. PPP finished negotiating with the far
>side and established a connection. The problem now is NOT ppp, but
>something else.
>Leave in the noccp option. It has definitely helped!

So this exchange:

Nov 26 15:02:37 localhost pppd[8753]: Unsupported protocol
'Compression Control Protocol' (0x80fd) received

isn't a problem?

I'll try again, and give it a few minutes.

<a few minutes later>

OK, here it is.  I gave it three minutes this time, with no luck
getting any network communications...

Nov 26 18:35:07 localhost pppd[8893]: pppd 2.3.11 started by root, uid
0
Nov 26 18:35:08 localhost chat[8894]: abort on (BUSY)
Nov 26 18:35:08 localhost chat[8894]: abort on (NO CARRIER)
Nov 26 18:35:08 localhost chat[8894]: send (ATZ^M)
Nov 26 18:35:08 localhost chat[8894]: expect (OK)
Nov 26 18:35:09 localhost chat[8894]: ATZ^M^M
Nov 26 18:35:09 localhost chat[8894]: OK
Nov 26 18:35:09 localhost chat[8894]:  -- got it
Nov 26 18:35:09 localhost chat[8894]: send (ATDT70#,896-0011^M)
Nov 26 18:35:10 localhost chat[8894]: expect (ONNECT)
Nov 26 18:35:10 localhost chat[8894]: ^M
Nov 26 18:35:28 localhost chat[8894]: ATDT70#,896-0011^M^M
Nov 26 18:35:28 localhost chat[8894]: CONNECT
Nov 26 18:35:28 localhost chat[8894]:  -- got it
Nov 26 18:35:28 localhost chat[8894]: send (^M)
Nov 26 18:35:28 localhost chat[8894]: expect (ogin:)
Nov 26 18:35:28 localhost chat[8894]:  115200^M
Nov 26 18:35:30 localhost chat[8894]: ^M
Nov 26 18:35:30 localhost chat[8894]: netcom login:
Nov 26 18:35:30 localhost chat[8894]:  -- got it

Nov 26 18:35:31 localhost chat[8894]: expect (assword:)

Nov 26 18:35:31 localhost chat[8894]: Password:
Nov 26 18:35:31 localhost chat[8894]:  -- got it
Nov 26 18:35:31 localhost chat[8894]: send (password^M)
Nov 26 18:35:31 localhost chat[8894]: expect (PP session)
Nov 26 18:35:31 localhost chat[8894]:  ^M
Nov 26 18:35:31 localhost chat[8894]: Packet mode enabled: PPP session
Nov 26 18:35:31 localhost chat[8894]:  -- got it
Nov 26 18:35:31 localhost chat[8894]: send (/d/c^M)
Nov 26 18:35:31 localhost pppd[8893]: Serial connection established.
Nov 26 18:35:31 localhost pppd[8893]: Using interface ppp0
Nov 26 18:35:31 localhost pppd[8893]: Connect: ppp0 <--> /dev/ttyS1
Nov 26 18:35:32 localhost pppd[8893]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0x2de31958> <pcomp> <accomp>]
Nov 26 18:35:32 localhost pppd[8893]: rcvd [LCP ConfAck id=0x1
<asyncmap 0x0> <magic 0x2de31958> <pcomp> <accomp>]
Nov 26 18:35:34 localhost pppd[8893]: rcvd [LCP ConfReq id=0x2 <mru
1500> <asyncmap 0x0> <magic 0x16ab6102> <pcomp> <accomp>]
Nov 26 18:35:34 localhost pppd[8893]: sent [LCP ConfAck id=0x2 <mru
1500> <asyncmap 0x0> <magic 0x16ab6102> <pcomp> <accomp>]
Nov 26 18:35:34 localhost pppd[8893]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Nov 26 18:35:34 localhost pppd[8893]: rcvd [IPCP ConfReq id=0x1
<compress VJ 0f 00> <addr 163.179.37.87>]
Nov 26 18:35:34 localhost pppd[8893]: sent [IPCP ConfAck id=0x1
<compress VJ 0f 00> <addr 163.179.37.87>]
Nov 26 18:35:34 localhost pppd[8893]: rcvd [IPCP ConfNak id=0x1 <addr
207.94.111.33>]
Nov 26 18:35:34 localhost pppd[8893]: sent [IPCP ConfReq id=0x2 <addr
207.94.111.33> <compress VJ 0f 01>]
Nov 26 18:35:35 localhost pppd[8893]: rcvd [IPCP ConfAck id=0x2 <addr
207.94.111.33> <compress VJ 0f 01>]
Nov 26 18:35:35 localhost pppd[8893]: local  IP address 207.94.111.33
Nov 26 18:35:35 localhost pppd[8893]: remote IP address 163.179.37.87
Nov 26 18:35:35 localhost pppd[8893]: Script /etc/ppp/ip-up started
(pid 8895)
Nov 26 18:35:35 localhost pppd[8893]: rcvd [CCP ConfReq id=0x1 < 11 05
00 01 04>]
Nov 26 18:35:35 localhost pppd[8893]: Unsupported protocol
'Compression Control Protocol' (0x80fd) received
Nov 26 18:35:35 localhost pppd[8893]: sent [LCP ProtRej id=0x2 80 fd
01 01 00 09 11 05 00 01 04]
Nov 26 18:35:35 localhost pppd[8893]: Script /etc/ppp/ip-up finished
(pid 8895), status = 0x0
Nov 26 18:38:31 localhost pppd[8893]: Terminating on signal 2.
Nov 26 18:38:31 localhost pppd[8893]: Script /etc/ppp/ip-down started
(pid 8914)
Nov 26 18:38:31 localhost pppd[8893]: sent [LCP TermReq id=0x3 "User
request"]
Nov 26 18:38:31 localhost pppd[8893]: Script /etc/ppp/ip-down finished
(pid 8914), status = 0x0
Nov 26 18:38:33 localhost pppd[8893]: Hangup (SIGHUP)
Nov 26 18:38:33 localhost pppd[8893]: Modem hangup
Nov 26 18:38:33 localhost pppd[8893]: Connection terminated.
Nov 26 18:38:33 localhost pppd[8893]: Connect time 3.0 minutes.
Nov 26 18:38:33 localhost pppd[8893]: Sent 187 bytes, received 225
bytes.
Nov 26 18:38:34 localhost pppd[8893]: Exit.

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Clifford Kit » Sat, 02 Dec 2000 04:00:00



> OK, results after putting in "noccp" in the option file...

Looked good...

Quote:> Nov 26 15:02:37 localhost pppd[8753]: local  IP address 207.223.169.69
> Nov 26 15:02:37 localhost pppd[8753]: remote IP address 163.179.37.72
> Nov 26 15:02:37 localhost pppd[8753]: Script /etc/ppp/ip-up started
> (pid 8755)
> Nov 26 15:02:37 localhost pppd[8753]: rcvd [CCP ConfReq id=0x1 < 11 05
> 00 01 04>]
> Nov 26 15:02:37 localhost pppd[8753]: Unsupported protocol
> 'Compression Control Protocol' (0x80fd) received
> Nov 26 15:02:37 localhost pppd[8753]: sent [LCP ProtRej id=0x2 80 fd
> 01 01 00 09 11 05 00 01 04]

The ProtRej stops any further CCP negotiation.

Quote:> Nov 26 15:02:38 localhost pppd[8753]: Script /etc/ppp/ip-up finished
> (pid 8755), status = 0x0
> Nov 26 15:03:09 localhost pppd[8753]: Terminating on signal 2.
> Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down started
> (pid 8770)
> Nov 26 15:03:09 localhost pppd[8753]: sent [LCP TermReq id=0x3 "User
> request"]

This seems to mean that you terminated the PPP connection.

Quote:> Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down finished
> (pid 8770), status = 0x0
> Nov 26 15:03:09 localhost pppd[8753]: rcvd [LCP TermAck id=0x2]
> Nov 26 15:03:09 localhost pppd[8753]: Connection terminated.
> Nov 26 15:03:09 localhost pppd[8753]: Connect time 0.6 minutes.
> Nov 26 15:03:09 localhost pppd[8753]: Sent 184 bytes, received 222
> bytes.
> Nov 26 15:03:10 localhost pppd[8753]: Hangup (SIGHUP)
> Nov 26 15:03:10 localhost pppd[8753]: Exit.
> **********************************************************************
> Note that disabling ccp caused a new error...

There isn't any new error that I can see and the old CCP negotiation
problem is gone.  The noccp got rid of the CCP negotiations which
could have caused the PPP connection to be inoperable.  It looks like
a perfectly good PPP connection.

The signal 2 looks to be an interrupt for pppd generated at the
keyboard with control-c, or by "kill -2 $(pidof pppd)", or the
equivalent.  Are you *not* killing pppd and the signal 2 is from
some unknown source?  Does the connection work at all with noccp?

If it still doesn't work with novj then you'll need to take a hard
look at the modem, the modem command configuration, and the device
file configuration.

The way you connect can change the way the ISP negotiates PPP too.
If the working machine/modem doesn't use password/login but rather
PAP or CHAP authentication then that might be the difference - except
you said you used the same scripts.


 
 
 

Weird PPP problem

Post by Rand Simbe » Sat, 02 Dec 2000 04:00:00


On Fri, 1 Dec 2000 15:34:23 -0600, in a place far, far away, Clifford

such a way as to indicate that:

Quote:>> Nov 26 15:02:38 localhost pppd[8753]: Script /etc/ppp/ip-up finished
>> (pid 8755), status = 0x0
>> Nov 26 15:03:09 localhost pppd[8753]: Terminating on signal 2.
>> Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down started
>> (pid 8770)
>> Nov 26 15:03:09 localhost pppd[8753]: sent [LCP TermReq id=0x3 "User
>> request"]

>This seems to mean that you terminated the PPP connection.

I did.  I saw no point in continuing a connection that wasn't doing
anything useful.

Quote:>> Nov 26 15:03:09 localhost pppd[8753]: Script /etc/ppp/ip-down finished
>> (pid 8770), status = 0x0
>> Nov 26 15:03:09 localhost pppd[8753]: rcvd [LCP TermAck id=0x2]
>> Nov 26 15:03:09 localhost pppd[8753]: Connection terminated.
>> Nov 26 15:03:09 localhost pppd[8753]: Connect time 0.6 minutes.
>> Nov 26 15:03:09 localhost pppd[8753]: Sent 184 bytes, received 222
>> bytes.
>> Nov 26 15:03:10 localhost pppd[8753]: Hangup (SIGHUP)
>> Nov 26 15:03:10 localhost pppd[8753]: Exit.
>> **********************************************************************

>> Note that disabling ccp caused a new error...

>There isn't any new error that I can see and the old CCP negotiation
>problem is gone.  The noccp got rid of the CCP negotiations which
>could have caused the PPP connection to be inoperable.  It looks like
>a perfectly good PPP connection.

>The signal 2 looks to be an interrupt for pppd generated at the
>keyboard with control-c, or by "kill -2 $(pidof pppd)", or the
>equivalent.  Are you *not* killing pppd and the signal 2 is from
>some unknown source?  

No, it's me.

Quote:>Does the connection work at all with noccp?

How do you define "work at all"?  I can't ping anything, at least by
name (I didn't try IP).  It doesn't seem to work any differently with
or without the "nocpp" except the log is prettier...

Quote:>If it still doesn't work with novj then you'll need to take a hard
>look at the modem, the modem command configuration, and the device
>file configuration.

OK, I'll try with "noccp" and "novj."

Quote:>The way you connect can change the way the ISP negotiates PPP too.
>If the working machine/modem doesn't use password/login but rather
>PAP or CHAP authentication then that might be the difference - except
>you said you used the same scripts.

Yeah, that's the problem.  I'm using scripts based on ones provided by
the ISP, and they don't use CHAP or PAP, unless they changed recently
and didn't tell me.

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Rand Simbe » Sat, 02 Dec 2000 04:00:00


On Fri, 01 Dec 2000 22:57:15 GMT, in a place far, far away,

monitor glow in such a way as to indicate that:

Quote:>>Does the connection work at all with noccp?

>How do you define "work at all"?  I can't ping anything, at least by
>name (I didn't try IP).  It doesn't seem to work any differently with
>or without the "nocpp" except the log is prettier...

>>If it still doesn't work with novj then you'll need to take a hard
>>look at the modem, the modem command configuration, and the device
>>file configuration.

>OK, I'll try with "noccp" and "novj."

OK, here's the attempt with both "noccp" and "novj".  Still no useful
connection.

**********************************************************************************
Nov 26 19:49:43 localhost pppd[8950]: pppd 2.3.11 started by root, uid
0
Nov 26 19:49:44 localhost chat[8951]: abort on (BUSY)
Nov 26 19:49:44 localhost chat[8951]: abort on (NO CARRIER)
Nov 26 19:49:44 localhost chat[8951]: send (ATZ^M)
Nov 26 19:49:44 localhost chat[8951]: expect (OK)
Nov 26 19:49:45 localhost chat[8951]: ATZ^M^M
Nov 26 19:49:45 localhost chat[8951]: OK
Nov 26 19:49:45 localhost chat[8951]:  -- got it
Nov 26 19:49:45 localhost chat[8951]: send (ATDT70#,896-0011^M)
Nov 26 19:49:46 localhost chat[8951]: expect (ONNECT)
Nov 26 19:49:46 localhost chat[8951]: ^M
Nov 26 19:49:55 localhost chat[8951]: ATDT70#,896-0011^M^M
Nov 26 19:49:55 localhost chat[8951]: BUSY
Nov 26 19:49:55 localhost chat[8951]:  -- failed
Nov 26 19:49:55 localhost chat[8951]: Failed (BUSY)
Nov 26 19:49:55 localhost pppd[8950]: Connect script failed
Nov 26 19:49:56 localhost pppd[8950]: Exit.
Nov 26 19:50:12 localhost pppd[8957]: pppd 2.3.11 started by root, uid
0
Nov 26 19:50:13 localhost chat[8958]: abort on (BUSY)
Nov 26 19:50:13 localhost chat[8958]: abort on (NO CARRIER)
Nov 26 19:50:13 localhost chat[8958]: send (ATZ^M)
Nov 26 19:50:13 localhost chat[8958]: expect (OK)
Nov 26 19:50:14 localhost chat[8958]: ATZ^M^M
Nov 26 19:50:14 localhost chat[8958]: OK
Nov 26 19:50:14 localhost chat[8958]:  -- got it
Nov 26 19:50:14 localhost chat[8958]: send (ATDT70#,896-0011^M)
Nov 26 19:50:14 localhost chat[8958]: expect (ONNECT)
Nov 26 19:50:14 localhost chat[8958]: ^M
Nov 26 19:50:33 localhost chat[8958]: ATDT70#,896-0011^M^M
Nov 26 19:50:33 localhost chat[8958]: CONNECT
Nov 26 19:50:33 localhost chat[8958]:  -- got it
Nov 26 19:50:33 localhost chat[8958]: send (^M)
Nov 26 19:50:33 localhost chat[8958]: expect (ogin:)
Nov 26 19:50:33 localhost chat[8958]:  115200^M
Nov 26 19:50:35 localhost chat[8958]: ^M
Nov 26 19:50:35 localhost chat[8958]: netcom login:
Nov 26 19:50:35 localhost chat[8958]:  -- got it

Nov 26 19:50:35 localhost chat[8958]: expect (assword:)

Nov 26 19:50:35 localhost chat[8958]: Password:
Nov 26 19:50:35 localhost chat[8958]:  -- got it
Nov 26 19:50:35 localhost chat[8958]: send (password^M)
Nov 26 19:50:35 localhost chat[8958]: expect (PP session)
Nov 26 19:50:36 localhost chat[8958]:  ^M
Nov 26 19:50:36 localhost chat[8958]: Packet mode enabled: PPP session
Nov 26 19:50:36 localhost chat[8958]:  -- got it
Nov 26 19:50:36 localhost chat[8958]: send (/d/c^M)
Nov 26 19:50:36 localhost pppd[8957]: Serial connection established.
Nov 26 19:50:36 localhost pppd[8957]: Using interface ppp0
Nov 26 19:50:36 localhost pppd[8957]: Connect: ppp0 <--> /dev/ttyS1
Nov 26 19:50:37 localhost pppd[8957]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0x52a46b1b> <pcomp> <accomp>]
Nov 26 19:50:37 localhost pppd[8957]: rcvd [LCP ConfAck id=0x1
<asyncmap 0x0> <magic 0x52a46b1b> <pcomp> <accomp>]
Nov 26 19:50:39 localhost pppd[8957]: rcvd [LCP ConfReq id=0x2 <mru
1500> <asyncmap 0x0> <magic 0x453e233f> <pcomp> <accomp>]
Nov 26 19:50:39 localhost pppd[8957]: sent [LCP ConfAck id=0x2 <mru
1500> <asyncmap 0x0> <magic 0x453e233f> <pcomp> <accomp>]
Nov 26 19:50:39 localhost pppd[8957]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0>]
Nov 26 19:50:39 localhost pppd[8957]: rcvd [IPCP ConfReq id=0x1
<compress VJ 0f 00> <addr 163.179.37.87>]
Nov 26 19:50:39 localhost pppd[8957]: sent [IPCP ConfRej id=0x1
<compress VJ 0f 00>]
Nov 26 19:50:39 localhost pppd[8957]: rcvd [IPCP ConfNak id=0x1 <addr
207.94.111.11>]
Nov 26 19:50:39 localhost pppd[8957]: sent [IPCP ConfReq id=0x2 <addr
207.94.111.11>]
Nov 26 19:50:39 localhost pppd[8957]: rcvd [IPCP ConfReq id=0x2
<compress VJ> <addr 163.179.37.87>]
Nov 26 19:50:39 localhost pppd[8957]: sent [IPCP ConfRej id=0x2
<compress VJ>]
Nov 26 19:50:39 localhost pppd[8957]: rcvd [IPCP ConfAck id=0x2 <addr
207.94.111.11>]
Nov 26 19:50:39 localhost pppd[8957]: rcvd [IPCP ConfReq id=0x3 <addr
163.179.37.87>]
Nov 26 19:50:39 localhost pppd[8957]: sent [IPCP ConfAck id=0x3 <addr
163.179.37.87>]
Nov 26 19:50:39 localhost pppd[8957]: local  IP address 207.94.111.11
Nov 26 19:50:39 localhost pppd[8957]: remote IP address 163.179.37.87
Nov 26 19:50:39 localhost pppd[8957]: Script /etc/ppp/ip-up started
(pid 8959)
Nov 26 19:50:39 localhost pppd[8957]: Script /etc/ppp/ip-up finished
(pid 8959), status = 0x0
Nov 26 19:50:39 localhost pppd[8957]: rcvd [CCP ConfReq id=0x1 < 11 05
00 01 04>]
Nov 26 19:50:39 localhost pppd[8957]: Unsupported protocol
'Compression Control Protocol' (0x80fd) received
Nov 26 19:50:39 localhost pppd[8957]: sent [LCP ProtRej id=0x2 80 fd
01 01 00 09 11 05 00 01 04]
Nov 26 19:51:53 localhost pppd[8957]: Terminating on signal 2.
Nov 26 19:51:53 localhost pppd[8957]: Script /etc/ppp/ip-down started
(pid 8976)
Nov 26 19:51:53 localhost pppd[8957]: sent [LCP TermReq id=0x3 "User
request"]
Nov 26 19:51:53 localhost pppd[8957]: Script /etc/ppp/ip-down finished
(pid 8976), status = 0x0
Nov 26 19:51:53 localhost pppd[8957]: rcvd [LCP TermAck id=0x2]
Nov 26 19:51:53 localhost pppd[8957]: Connection terminated.
Nov 26 19:51:53 localhost pppd[8957]: Connect time 1.3 minutes.
Nov 26 19:51:53 localhost pppd[8957]: Sent 198 bytes, received 271
bytes.
Nov 26 19:51:53 localhost pppd[8957]: Hangup (SIGHUP)
Nov 26 19:51:53 localhost pppd[8957]: Exit.
***********************************************************************

I may have spoken too soon about the other machine working.  It used
to work before I upgraded it from RH6.1 to RH7.0, but now I can't even
get it to dial.

The one that I've been trying to get working (i.e., the one that
produces the logs that I've been posting here, which is actually more
critical, because it's my server) has also been upgraded to RH7.0  It
was running RH6.2.

Is it possible that RH has done something in the network configuration
(in the course of the upgrade) that's causing problems?  What other
things might I look for?

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org

"Extraordinary launch vehicles require extraordinary markets..."


 
 
 

Weird PPP problem

Post by Bill Unr » Sun, 03 Dec 2000 04:00:00



Quote:>So this exchange:
>Nov 26 15:02:37 localhost pppd[8753]: Unsupported protocol
>'Compression Control Protocol' (0x80fd) received
>isn't a problem?

Nope. Your machine does not support any compression protocal ( that is
what noccp means) so any request for compression is unsupported. You tell
the remote machine you do not accept any cpp, and it is happy.

Quote:>I'll try again, and give it a few minutes.
>Nov 26 18:35:34 localhost pppd[8893]: rcvd [IPCP ConfReq id=0x1
><compress VJ 0f 00> <addr 163.179.37.87>]

Try doing
ping 163.179.37.87

Make sure that you have
defaultroute
in /etc/ppp/options

Also check your /etc/resolv.conf file that it has the right nameserver
names.

Show us what
ifconfig -a
says
Also
route -n

 
 
 

Weird PPP problem

Post by Clifford Kit » Sun, 03 Dec 2000 04:00:00



> On Fri, 01 Dec 2000 22:57:15 GMT, in a place far, far away,

> monitor glow in such a way as to indicate that:
>>>Does the connection work at all with noccp?

>>How do you define "work at all"?  I can't ping anything, at least by
>>name (I didn't try IP).  It doesn't seem to work any differently with

Try an IP address.  "ping 203.29.91.49" pings linuxcare.com.au and that
site should be up at all times.   Does ping with a FQDN, as opposed to
an IP address, just hang or does ping generate a message and then quit?

You may have resolver problems.  Do you know the nameserver IP addresses
in /etc/resolv.conf to be valid?

Something else which should have been asked earlier, except that
you said you were using the same scripts used for a working box:
Have you set the pppd defaultroute option?

Quote:>>or without the "nocpp" except the log is prettier...

It's also better because it eliminates the otherwise neverending CCP
negotiation that might interfere with data transfer.

Quote:>>>If it still doesn't work with novj then you'll need to take a hard
>>>look at the modem, the modem command configuration, and the device
>>>file configuration.

>>OK, I'll try with "noccp" and "novj."
> OK, here's the attempt with both "noccp" and "novj".  Still no useful
> connection.

The log looked exactly as expected.  The local and remote IP addresses
were successfully negotiated but without VJ header compression.  Since you
still have a problem accessing an Internet site you might as well drop
the novj option and get a little less overhead when whatever that is wrong
is fixed.  Everything in the log showed that successful PPP connection
was negotiated.

However you still haven't changed the chat expect-send
  'PP session' '/d/c'  to  'PP session' '\d\c'  to eliminate the
sending the incorrect '/d/c' string and carriage return (^M), and
instead actually add a 1 second delay with no carriage return.

[log elided]

Quote:> I may have spoken too soon about the other machine working.  It used
> to work before I upgraded it from RH6.1 to RH7.0, but now I can't even
> get it to dial.
> The one that I've been trying to get working (i.e., the one that
> produces the logs that I've been posting here, which is actually more
> critical, because it's my server) has also been upgraded to RH7.0  It
> was running RH6.2.
> Is it possible that RH has done something in the network configuration
> (in the course of the upgrade) that's causing problems?  What other
> things might I look for?

Yes, there is a real possiblility that Red Hat has modified the
standard track version in the pppd it ships and has broken it in
doing so.  If you're up to it you can get a pristine 2.4.0 source
package via ftp from linuxcare.com.au in the directory /pub/ppp and
compile it yourself.  Instructions for doing so are in the pppd top
directory file README.linux.

You can also try adding the "asyncmap a0000" option.  I don't think
it will help but I've been wrong about that once before.

--

/* A salute to Inspector Baynes, of the Surry Constabulary, the only
   police Inspector to ever best Mr. Sherlock Holmes at his own game.
   "The Adventure of Wisteria Lodge", by Sir Arthur Conan Doyle. */

 
 
 

1. Weird PPP problems

I've been trying to configure PPP for about two days and can't quite
seem to get the two machines talking.  I'm using kernel V1.3.71 and
PPP V2.2.0.   I've compiled the kernel with PPP (in the kernel, not
a module) and followed the directions that came with PPP to configure
it.  Below is what a log of what happens when I attemt to start a PPP
connection.

Mar 12 10:37:48 tdc chat[141]: choice -- got it
Mar 12 10:37:48 tdc chat[141]: send (4^M)
Mar 12 10:37:49 tdc pppd[140]: Serial connection established
Mar 12 10:37:49 tdc pppd[140]: Using interface ppp0
Mar 12 10:37:49 tdc pppd[140]: Connect: ppp0 <--> /dev/cua1
Mar 12 10:37:50 tdc pppd[140]: sent [LCP ConfReq id=0x1 <mru 1500>
<asyncmap 0x0> magic<0x3c882bf> <pcomp> <accomp>]
Mar 12 10:37:50 tdc pppd[140]: revd [LCP ConfAck id=0x1 <mru 1500>
<asyncmap 0x0> magic<0x3c882bf> <pcomp> <accomp>]
Mar 12 10:37:52 tdc pppd[140]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0>
<auth pap> <magic 0x71e32f6d> <pcomp> <accomp>]
Mar 12 10:37:52 tdc pppd[140]: sent [LCP ConfRej id=0x2 <auth pap>]
Mar 12 10:37:53 tdc pppd[140]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0>
<auth pap> <magic 0x84af3bdf> <pcomp> <auth pap>
Mar 12 10:37:53 tdc pppd[140]: sent [LCP ConfRej id=0x3 <auth pap>]
Mar 12 10:37:53 tdc pppd[140]: rcvd [LCP ConfReq id=0x4 <asyncmap 0x0>
<auth pap> <magic 0x80272b69> <pcomp> <accomp>]

And from there it gets in an endless loop of ConfRej and ConfReq with the
only things changing in the lines being the id #'s and the magic #'s.  Can
someone tell me what all this means and what the problem might be?

Thanks,
James

2. Free Expo Passes and More for ClusterWorld Conference & Expo

3. Weird PPP problem (non trivial)

4. Forte 9 ea...

5. Weird PPP Problem

6. SLS 1.01 - Does GCC work straight out of the package?

7. Weird PPP Problems

8. when to use script vs function

9. Weird ppp problem...

10. Weird PPP Problem

11. HELP! super weird PPP Problem

12. weird ppp problem

13. Weird PPP problem