[prev in list] [next in list] [prev in thread] [next in thread] 

List:       poptop-server
Subject:    Re: [Poptop-server] LCP timeout
From:       James Cameron <james.cameron () hp ! com>
Date:       2007-04-20 0:17:23
Message-ID: 20070420001723.GC4574 () hp ! com
[Download RAW message or body]

G'day maimam,

I don't know about any other Linux PPTP server, but given the problem
you are experiencing I don't think any other server would do any
different.  Version 1.3.4 contains no fix for the problem you are
experiencing, so I would not expect that to change the symptom.  I don't
think there is any way to fix the problem by changing pptpd.

That you have the client and server successfully connecting in a lab
environment proves that the software is running correctly.  This is the
result I see when I run in my lab environment, and elsewhere.

Your observation about the different call id is not unusual.  The call
ids are unique to an end-point.  You are comparing the call id of one
end-point with the call id of the other end-point.  There is no need to
compare them ... this isn't of itself the source of your problem.

In the most recent logs you sent, I find the following:

- the control connection is initially negotiated correctly, (according
  to the tcpdump on the client),

- the control connection stalls due to control connection packets not
  being forwarded, (according to the tcpdump on the server, where the
  packet at 11:06:36.257465 is never acknowledged by the client)

- the control connection packet at byte offset 157 from the server never
  reaches the client, (according to the tcpdump on the client)

The remainder of the tcpdump and pppd logs show that GRE has not yet
begun to be exchanged correctly, probably because of the control
connection stall.

Missing from your output is what pptp says in the debug log on the
client.  This may confirm the control connection stall.

You should determine why the control connection on port 1723 stalls.  It
is most likely because of a misconfigured router or gateway between the
client and the server.

Some consumer-grade routers fail to forward PPTP connections, and this
symptom is one of the results we have seen before.  The firmware of the
routers may be defective in one of several ways:

1.  does not process the packets correctly, and drops them,

2.  does not work in the reverse direction,

3.  does not recognise the different vendor field in the packets.

Often this is because the routers were never tested with the Linux or
BSD PPTP implementation, because they were intended for a consumer
market before Linux became prevalent.

You should contact the firmware support team for the routers causing the
problem, or replace the routers.

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Poptop-server mailing list
Poptop-server@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/poptop-server
[prev in list] [next in list] [prev in thread] [next in thread]