linux-ppp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Cameron <james.cameron@hp.com>
To: linux-ppp@vger.kernel.org
Subject: Re: Spontaneous LCP ConfReq after connection made
Date: Mon, 15 Aug 2005 06:57:50 +0000	[thread overview]
Message-ID: <20050815065750.GQ11613@hp.com> (raw)
In-Reply-To: <20050812073342.GL28862@hp.com>

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On Sat, Aug 13, 2005 at 02:22:10PM -0400, James Carlson wrote:
> If it's not for a mobile station (assuming so, since you mentioned
> DSL), the one means you didn't suggest was cable.  I take it that's
> not an option.

Yes.  I'm six hours drive from the nearest city with cable.  I'm using
satellite too, but it has data limits (500Mb per month) whereas the CDMA
service has none.  They only have a time limit (50 hours per month).

> Here's another possibility: I once saw a bug in a particular embedded
> implementation where they apparently accidentally left a timer running
> after setting LCP to Opened state that caused renegotiation.

I've excluded this based on the apparent random timing, but I will give
"silent" a try.

One thing I've noticed with testing past few days ... the renegotiation
is very probable if a GRE packet for PPTP is sent over the PPP link.  

The peer provides a NAT service, and supports the use of PPTP.  PPTP
over NAT requires the peer implement stateful inspection and connection
tracking.

Normally a PPTP tunnel runs inside an OpenVPN tunnel over the satellite
service.  When the CDMA service comes up, my if-up scripts change the
route to the PPTP tunnel server so that packets for the active tunnel go
via the link in question.  Breaks the tunnel, of course.

The presumably buggy peer receives a GRE packet out of the blue that it
cannot relate to any active connection.  It might be crashing and
restarting.

It occurs to me that this might be causing problems for other users.
The service provider did say that other users had reported a similar
problem.  If I can reproduce it reliably, I'll let the service provider
know.

Thanks for the suggestion to capture the Windows client negotiation;
first I'll see if I can isolate the problem to orphan PPTP frames.

-- 
James Cameron
http://ftp.hp.com.au/sigs/jc/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2005-08-15  6:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-12  7:33 Spontaneous LCP ConfReq after connection made James Cameron
2005-08-12 14:17 ` James Carlson
2005-08-12 23:32 ` James Cameron
2005-08-13  5:27 ` Gilles Espinasse
2005-08-13 18:22 ` James Carlson
2005-08-15  6:57 ` James Cameron [this message]
2005-08-31  5:33 ` James Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050815065750.GQ11613@hp.com \
    --to=james.cameron@hp.com \
    --cc=linux-ppp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).