On Thu, 8 Jul 2004, Ron Rosson wrote:

> >I have attatched 3 files:
> >    1. tcpdump from powerbook of the PPTP connection attempt
> >    2. the log from OSX's PPTP client
> >    3. the log entries from m0n0wall
> >    
> 
> I was afraid of that

Was it your email client or the listserver that stripped the
attachments?  The trouble with sending tcpdump output as embedded text is
that the line wrap makes it practically illegible.

In any case, none of these logs contains enough information to see what
the problem is.

> Here is the tcpdump:
The decoding in tcpdump doesn't seem to descend into the PPTP payload to
show the actual PPP negotations.

[...]
> adsl-67-119-235-38.dsl.sndg02.pacbell.net.pptp: P 325:349(24) ack 189
> win 65535 <nop,nop,timestamp 4105863719 112108>: pptp CTRL_MSGTYPE=SLI
> PEER_CALL_ID(31907) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
[...]

Though there's enough decoding to show a really dumb choice of ACCM
values. :-)

> Here is the OSX PPTP:
[...]

This only has really basic info.

> and here is the m0n0wall log:
[...]

The most informative of the three, but still not enough.  It does show
that apparently there was a lack of common ground on some LCP parameter,
but it doesn't say which one.

I'd suggest doing another capture to a file, making sure the snaplen is
large enough to get entire packets (e.g. the semi-round 1536).  Since the
PPTP control-connection exchange doesn't seem to be at fault, the GRE
packets alone should be sufficient.  E.g.:

	tcpdump -w pptperr.cap -s 1536 -i <interface> proto 47

Send me the (binary) file and I'll take a look.  There should be no
cleartext passwords in it, since it's using MSCHAPv2 authentication.

					Fred Wright