NAME¶
pptp - PPTP driver
SYNOPSIS¶
pptp <pptp-server-IP> <pptp-options> [ppp-options] ...
DESCRIPTION¶
pptp establishes the client side of a Virtual Private Network (VPN) using
the Point-to-Point Tunneling Protocol (PPTP). Use this program to connect to
an employer's PPTP based VPN, or to certain cable and ADSL service providers.
By default,
pptp establishes the PPTP call to the PPTP server, and then
starts an instance of
pppd to manage the data transfer. However,
pptp can also be run as a connection manager within
pppd.
OPTIONS¶
The first non-option argument on the
pptp command line must be the host
name or IP address of the PPTP server.
All long options (starting with "--") are interpreted as pptp options,
and a fatal error occurs if an unrecognised option is used.
All command-line arguments which do not start with "-" are interpreted
as ppp options, and passed as is to
pppd unless
--nolaunchpppd
is given.
- --phone <number>
- Pass <number> to remote host as phone number
- --nolaunchpppd
- Do not launch pppd but use stdin as the network
connection. Use this flag when including pptp as a pppd
connection process using the pty option. See EXAMPLES.
- --quirks <quirk>
- Work around a buggy PPTP implementation, adopts special
case handling for particular PPTP servers and ADSL modems. Currently
recognised values are BEZEQ_ISRAEL only
- --debug
- Run in foreground (for debugging with gdb)
- --sync
- Enable Synchronous HDLC (pppd must use it too)
- --timeout <secs>
- Time to wait for reordered packets (0.01 to 10 secs)
- --nobuffer
- Completely disables buffering and reordering of packets.
Any --timeout specified will be ignored.
- --idle-wait <secs>
- Time to wait before sending a control connection echo
request. The RFC2637 default is 60 seconds.
- --max-echo-wait <secs>
- Time to wait for an echo reply before closing the control
connection. The RFC2637 default is 60 seconds.
- --logstring <name>
- Use <name> instead of 'anon' in syslog messages
- --localbind <addr>
- Bind to specified IP address instead of wildcard
- --loglevel <level>
- Sets the debugging level (0=low, 1=default, 2=high)
- --test-type <n>
- Enable packet reordering tests that damage the integrity of
the packet stream to the server. Use this only when testing servers. Zero
is the default, and means that packets are sent in the correct order. A
value of one (1) causes a single swap between two packets, such that the
sequence numbers might be 1 2 3 4 6 5 7 8 9. A value of two (2) causes ten
packets to be buffered, then sent out of order but ascending, such that
the sequence numbers might be 1 2 3 4 16 6 7 8 9 10 11 12 13 14 15 17 18
19 20. A value of three (3) causes ten packets to be buffered, then sent
in the reverse order, like this; 1 2 3 4 16 15 14 13 12 11 10 9 8 7 6 5 17
18 19 20.
- --test-rate <n>
- Sets the number of packets to pass before causing a
reordering test. Default is 100. Has no effect if test-type is zero. The
result of test types 2 and 3 are undefined if this value is less than ten.
QUIRKS¶
- BEZEQ_ISRAEL
- modifies packets to interoperate with Orckit ADSL modems on
the BEZEQ network in Israel.
EXAMPLES¶
Connection to a Microsoft Windows VPN Server
pppd noauth nobsdcomp nodeflate require-mppe-128 name domain\\\\username
remotename PPTP pty "pptp 10.0.0.5 --nolaunchpppd"
Note that the
chap-secrets file used by
pppd must include an entry
for domain\\username
STATISTICS¶
The pptp process collects statistics when sending and receiving GRE packets.
They are intended to be useful for debugging poor PPTP performance and for
general monitoring of link quality. The statistics are cumulative since the
pptp process was started.
The statistics can be viewed by sending a SIGUSR1 signal to the "GRE-to-PPP
Gateway" process, which will cause it to dump them to the system logs (at
the LOG_NOTICE level). A better way to present the statistics to applications
is being sought (e.g. SNMP?).
The following statistics are collected at the time of writing (April 2003):
- rx accepted
- the number of GRE packets successfully passed to PPP
- rx lost
- the number of packets never received, and presumed lost in
the network
- rx under win
- the number of packets which were duplicates or had old
sequence numbers (this might be caused by a packet-reordering network if
your reordering timeout is set too low)
- rx over win
- the number of packets which were too far ahead in the
sequence to be reordered (might be caused by loss of more than 300 packets
in a row)
- rx buffered
- the number of packets which were slightly ahead of
sequence, and were either buffered for reordering, or if buffering is
disabled, accepted immediately (resulting in the intermediate packets
being discarded).
- rx OS errors
- the number of times where the operating system reported an
error when we tried to read a packet
- rx truncated
- the number of times we received a packet which was shorter
than the length implied by the GRE header
- rx invalid
- the number of times we received a packet which had invalid
or unsupported flags set in the header, wrong version, or wrong
protocol.
- rx acks
- the number of pure acknowledgements received (without
data). Too many of these will waste bandwidth, and might be solved by
tuning the remote host.
- tx sent
- the number of GRE packets sent with data
- tx failed
- the number of packets we tried to send, but the OS reported
an error
- tx short
- the number of times the OS would not let us write a
complete packet
- tx acks
- the number of times we sent a pure ack, without data
- tx oversize
- the number of times we couldn't send a packet because it
was over PACKET_MAX bytes long
- round trip
- the estimated round-trip time in milliseconds
SEE ALSO¶
pppd(8)
Documentation in
/usr/share/doc/pptp
AUTHOR¶
This manual page was written by James Cameron <james.cameron@hp.com> from
text contributed by Thomas Quinot <thomas@debian.org>, for the Debian
GNU/Linux system. The description of the available statistics was written by
Chris Wilson <chris@netservers.co.uk>. Updates for the Debian
distribution by Ola Lundqvist <opal@debian.org>.