Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Oct 2002 02:30:50 -0700
From:      "Leonard Chung" <leonardc@cs.berkeley.edu>
To:        "Archie Cobbs" <archie@dellroad.org>
Cc:        <freebsd-net@FreeBSD.ORG>
Subject:   RE: MPD PPTP tunneling intermittantly fails
Message-ID:  <AEEMJFAIHDPJNCAKCHHBIEJBCHAA.leonardc@cs.berkeley.edu>
In-Reply-To: <200210142144.g9ELi3AT084595@arch20m.dellroad.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I'm just using Windows clients, so there are no OS X clients.

Here's the ngctl output:

chung# ngctl msg ng0:inet.ppp.link0 getstats
Rec'd response "getstats" (3) from "ng0:inet.ppp.link0":
Args:   { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345
recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 }

As you can tell, the connection hasn't transmitted much data before it's
already become problematic. The drop count to packet count on transmits and
timeouts on recv's seems awfully high given everything is just on a local
area network. Here's my physical topology:

Inside 10.0.0.0/8 <--------> {10.0.0.1 - MPD Machine - 192.168.0.1}
<-------> 192.168.0.0/24 Protected clients
                                                        |
                                                        | Outside Internet
IP
                                                        ->


Each net address on the MPD machine has its own Ethernet card. In addition,
pinging the MPD machine from either side results in no packet loss and <1ms
latency.

Here's some more information if that helps:

chung# kldstat
Id Refs Address    Size     Name
 1   10 0xc0100000 2bce78   kernel
 2    9 0xc0b71000 9000     netgraph.ko
 3    1 0xc0b7a000 3000     ng_socket.ko
 4    1 0xc0b7d000 3000     ng_iface.ko
 5    1 0xc0b80000 6000     ng_ppp.ko
 6    1 0xc0b86000 4000     ng_bpf.ko
 7    1 0xc0b8a000 4000     ng_vjc.ko
 8    1 0xc0b8e000 4000     ng_pptpgre.ko
 9    1 0xc0b93000 4000     ng_ksocket.ko
10    1 0xc0b98000 3000     ng_mppc.ko
chung# uname -a
FreeBSD chung.yikes.com 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 28
00:07:12 PDT 2002
leonard@chung.yikes.com:/usr/obj/usr/src/sys/CHUNG_KERN_FW  i386

Thanks for your help,

Leonard

-----Original Message-----
From: Archie Cobbs [mailto:archie@dellroad.org]
Sent: Monday, October 14, 2002 2:44 PM
To: Leonard Chung
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: MPD PPTP tunneling intermittantly fails

Leonard Chung writes:
> The problem that I'm having is that MPD starts properly and I can
> successfully connect to the service using Windows clients. However, when I
> ping internal hosts, the first five or so work fine, and then beyond that
> packets start getting lost, with a loss rate of around 50%. These tests
are
> run over a local network with two subnets, so packet loss shouldn't be a
> problem. So although I can currently connect and create a tunnel, it isn't
> very useful as beyond any initial DNS queries, file transfers, etc. fail
> completely.

Are you using Mac OS X clients? If so, you may need the
latest patch to ng_pptpgre(4) to work around a problem:


http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c.diff?r1=
1.25&r2=1.26

Otherwise, I haven't heard of anyone else having that particular problem..
See if you have errors reported by 'ngctl msg ng0:inet.ppp.link0 getstats'
(replace 'ng0' with the appropriate inteface name).

> Also, is there any way to get DHCP to work with MPD rather than hard wire
> IPs directly into MPD's config files?

Unfortunately not.

> I'm guessing this is probably just something easy that I'm missing. My
> config files and an MPD trace are below.

These look reasonable.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEEMJFAIHDPJNCAKCHHBIEJBCHAA.leonardc>