PPTP with poptop - unclear error messages

Hi, im trying to set up a vpn using poptop but somehow got in trouble...

This is what i did already:

- got 2.4.23 kernel source from www.kernel.org
- got the mppe_mppc kernel patch from http://www.polbox.com/h/hs001/linux-...-0.98.patch.gz
- patched, configured, compiled the kernel with no problems (MPPE/MPPC appeared under Network devices -> ppp; checked to be compiled as a module)
- booted the kernel; module (mppe_mppc.o) loads perfectly...
- got pppd from http://www.polbox.com/h/hs001/ppp-2....0030715.tar.gz
- got patches for pppd from http://www.polbox.com/h/hs001/ppp-2....-0.82.patch.gz and http://www.polbox.com/h/hs001/ppp-2....0.82a.patch.gz
- patched pppd with both; configured, compiled, installed <= no probs untill here
- got pptpd from http://sourceforge.net/project/shown...lease_id=95963
- configured (--with-prefix=/usr/local/poptop --with-libwrap --with-pppd-ip-alloc), compiled, installed

my /etc/pppd.conf

option /etc/ppp/options.pptpd
localip XXX.XXX.XXX.26
remoteip XXX.XXX.XXX.10-15

my /etc/ppp/options.pptpd

name smoker
lock
debug
mtu 1450
mru 1450
multilink
ktune
proxyarp
auth
ipcp-accept-local
ipcp-accept-remote
record /tmp/pppd.rec
lcp-echo-failure 3
lcp-echo-interval 5
ms-dns XXX.XXX.XXX.4
local

<---The XXX sequences are always the same--->

Configured a Win2K Client as described in http://poptop.sourceforge.net/dox/pptp_win2k/

When i try to establish a connection i get this log from the server...
/var/log/messages (extract)

Dec 5 21:10:44 smoker pptpd[2061]: CTRL: Starting call (launching pppd, opening GRE)
Dec 5 21:10:44 smoker pppd[2062]: pppd 2.4.2b3 started by root, uid 0
Dec 5 21:10:44 smoker pppd[2062]: Starting negotiation on /dev/pts/3
Dec 5 21:10:44 smoker pptpd[2061]: GRE: Discarding duplicate packet *
Dec 5 21:10:46 smoker pptpd[2061]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! *
Dec 5 21:10:46 smoker pppd[2062]: Using interface ppp0
Dec 5 21:10:46 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
Dec 5 21:10:47 smoker pppd[2062]: MPPC/MPPE 128-bit stateless compression enabled
Dec 5 21:10:47 smoker pppd[2062]: LCP terminated by peer (kM-v^\M-3^@<M-Mt^@^@^@^@)
Dec 5 21:10:47 smoker pppd[2062]: Modem hangup
Dec 5 21:10:47 smoker pppd[2062]: Connection terminated.
Dec 5 21:10:47 smoker pppd[2062]: Connect time 0.1 minutes.
Dec 5 21:10:47 smoker pppd[2062]: Sent 134 bytes, received 118 bytes.
Dec 5 21:10:47 smoker /etc/hotplug/net.agent: NET unregister event not supported
Dec 5 21:10:48 smoker pptpd[2061]: CTRL: Client 130.75.178.6 control connection finished
Dec 5 21:10:48 smoker pppd[2062]: Connect time 0.1 minutes.
Dec 5 21:10:48 smoker pppd[2062]: Sent 134 bytes, received 118 bytes.
Dec 5 21:10:48 smoker pppd[2062]: Exit.

I have tried many variations in the options.pptpd and several configurations of the win2k machine.
Nothing really helped and i must admit that i don't really understand some of this errors.(f.i why the modem hangs up... there is no modem intalled...)
I think that the problem appears in the lines marekd with * but i don't know whot they mean.

If you need more information i'l serve them...

Please help me if you can, i dont know what to do...


Martin

Martin Mleczko <(E-Mail Removed)> wrote:

> When i try to establish a connection i get this log from the server...
> /var/log/messages (extract)

> Dec 5 21:10:44 smoker pptpd[2061]: CTRL: Starting call (launching pppd, opening GRE)
> Dec 5 21:10:44 smoker pppd[2062]: pppd 2.4.2b3 started by root, uid 0
> Dec 5 21:10:44 smoker pppd[2062]: Starting negotiation on /dev/pts/3
> Dec 5 21:10:44 smoker pptpd[2061]: GRE: Discarding duplicate packet *
> Dec 5 21:10:46 smoker pptpd[2061]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! *

This looks like pptpd doesn't line ACCMs negotiated. Probably during
PPP link negotiation but I'm not certain. Try adding the pppd option
default-asyncmap (the pppd _implementation_ default ACCM is 0, which
might be the ACCM to which the pptpd message refers.

> Dec 5 21:10:46 smoker pppd[2062]: Using interface ppp0
> Dec 5 21:10:46 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
> Dec 5 21:10:47 smoker pppd[2062]: MPPC/MPPE 128-bit stateless compression enabled
> Dec 5 21:10:47 smoker pppd[2062]: LCP terminated by peer (kM-v^\M-3^@<M-Mt^@^@^@^@)

Dunno much about PPTP but this is a termination of the PPP negotiations
by the peer.

Add the pppd debug option (in /etc/ppp/options.pptpd) and post the logs
of the PPP negotiations. That might or might not help since you are
using an almost brand-new, albeit "stable," kernel, a bleeding-edge pppd,
and apparently a U.S.-illegal patch to get MPPC.

> Dec 5 21:10:47 smoker pppd[2062]: Modem hangup

The modem hangup is technically incorrect here but not relevant.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Better is the enemy of good enough. */

Hello

your tip with defaukt-asnycmap helped; the message about ACCM disappeared.
but the client can't still login...
here are the logs now (debug is on)




Dec 9 13:42:09 smoker pptpd[11928]: MGR: Manager process started
Dec 9 13:42:22 smoker pptpd[11929]: CTRL: Client 130.75.178.3 control connection started
Dec 9 13:42:22 smoker pptpd[11929]: CTRL: Starting call (launching pppd, opening GRE)
Dec 9 13:42:22 smoker pppd[11930]: pppd 2.4.2b3 started by root, uid 0
Dec 9 13:42:22 smoker pppd[11930]: Using interface ppp0
Dec 9 13:42:22 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
Dec 9 13:42:22 smoker pppd[11930]: Connect: ppp0 <--> /dev/pts/2
Dec 9 13:42:22 smoker pptpd[11929]: GRE: Discarding duplicate packet
Dec 9 13:42:24 smoker pppd[11930]: MPPC/MPPE 128-bit stateless compression enabled
Dec 9 13:42:25 smoker pppd[11930]: LCP terminated by peer (vM-@pb^@<M-Mt^@^@^@^@)
Dec 9 13:42:25 smoker pppd[11930]: Modem hangup
Dec 9 13:42:25 smoker pppd[11930]: Connection terminated.
Dec 9 13:42:25 smoker pppd[11930]: Connect time 0.1 minutes.
Dec 9 13:42:25 smoker pppd[11930]: Sent 134 bytes, received 162 bytes.
Dec 9 13:42:25 smoker /etc/hotplug/net.agent: NET unregister event not supported
Dec 9 13:42:25 smoker pppd[11930]: Connect time 0.1 minutes.
Dec 9 13:42:25 smoker pppd[11930]: Terminating on signal 2.
Dec 9 13:42:25 smoker pptpd[11929]: CTRL: Client 130.75.178.3 control connection finished
Dec 9 13:42:25 smoker pppd[11930]: Sent 134 bytes, received 162 bytes.
Dec 9 13:42:25 smoker pppd[11930]: Exit.


and here the /etc/ppp/options.pptpd


name smoker
lock
debug
mtu 1450
mru 1450
#multilink

ktune
proxyarp
auth
ipcp-accept-local
ipcp-accept-remote
record /tmp/pppd.rec
lcp-echo-failure 3
lcp-echo-interval 5
default-asyncmap
ms-dns 130.75.178.4
#local

Can you tell what tis line means?
Dec 9 13:42:22 smoker pptpd[11929]: GRE: Discarding duplicate packet

Martin Mleczko <(E-Mail Removed)> wrote:

> Dec 9 13:42:22 smoker pppd[11930]: pppd 2.4.2b3 started by root, uid 0
> Dec 9 13:42:22 smoker pppd[11930]: Using interface ppp0
> Dec 9 13:42:22 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
> Dec 9 13:42:22 smoker pppd[11930]: Connect: ppp0 <--> /dev/pts/2
> Dec 9 13:42:22 smoker pptpd[11929]: GRE: Discarding duplicate packet
> Dec 9 13:42:24 smoker pppd[11930]: MPPC/MPPE 128-bit stateless
> compression enabled
> Dec 9 13:42:25 smoker pppd[11930]: LCP terminated by peer
> (vM-@pb^@<M-Mt^@^@^@^@)

These are not the debug messages. There's a recipe for a special
chat/pppd log file in my signature if the LCP/IPCP/CCP debug log
messages aren't to be found in any file in /var/log.

....

> Can you tell what tis line means?
> Dec 9 13:42:22 smoker pptpd[11929]: GRE: Discarding duplicate packet

It's easy to *say* what it means: pptpd received a duplicate General
Record Encapsulation packet. But I can't say why a duplicate was sent
except that the sender deemed it was appropriate - I just don't know
enough about Microsoft's PPTP to guess.

-- Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
/* Recipe for a unified PPP debug log file: Add the line
" local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
to /etc/syslog.conf, and do " kill -HUP $(pidof syslogd) "
so that syslogd rereads it. */

Am Tue, 09 Dec 2003 07:29:17 -0600 schrieb Clifford Kite:

> Martin Mleczko <(E-Mail Removed)> wrote:
>
>> Dec 9 13:42:22 smoker pppd[11930]: pppd 2.4.2b3 started by root, uid 0
>> Dec 9 13:42:22 smoker pppd[11930]: Using interface ppp0
>> Dec 9 13:42:22 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
>> Dec 9 13:42:22 smoker pppd[11930]: Connect: ppp0 <--> /dev/pts/2
>> Dec 9 13:42:22 smoker pptpd[11929]: GRE: Discarding duplicate packet
>> Dec 9 13:42:24 smoker pppd[11930]: MPPC/MPPE 128-bit stateless
>> compression enabled
>> Dec 9 13:42:25 smoker pppd[11930]: LCP terminated by peer
>> (vM-@pb^@<M-Mt^@^@^@^@)
>
> These are not the debug messages. There's a recipe for a special
> chat/pppd log file in my signature if the LCP/IPCP/CCP debug log
> messages aren't to be found in any file in /var/log.
>
> ...
>
>> Can you tell what tis line means?
>> Dec 9 13:42:22 smoker pptpd[11929]: GRE: Discarding duplicate packet
>
> It's easy to *say* what it means: pptpd received a duplicate General
> Record Encapsulation packet. But I can't say why a duplicate was sent
> except that the sender deemed it was appropriate - I just don't know
> enough about Microsoft's PPTP to guess.

Is there a way to tell pptpd to throw the first one away and take the
second? I've read anywhere that Microsoft's implementation is broken. Thus
it sends a broken packet and afterwards is sends a correct one. I don't
know any more wheather it referred to GRE, but it had to do with PPTP.
>
> -- Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
> /* Recipe for a unified PPP debug log file: Add the line
> " local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
> to /etc/syslog.conf, and do " kill -HUP $(pidof syslogd) "
> so that syslogd rereads it. */


The client's (Win2k)answer is always the same.
It stats that it could not agree on a PPP controll protocoll
(TCP/IP CP) with the server. On Win2k it is error 732.

/var/log/ppp-debug.log


Dec 9 14:47:37 smoker pptpd[12507]: MGR: Launching /usr/local/poptop-1.1.4/sbin/pptpctrl to handle client
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: pppd options file = /etc/ppp/options.pptpd
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 1)
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Made a START CTRL CONN RPLY packet
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: I wrote 156 bytes to the client.
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Sent packet to client
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 7)
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Set parameters to 1525 maxbps, 64 window size
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Made a OUT CALL RPLY packet
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: pty_fd = 5
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: tty_fd = 6
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: I wrote 32 bytes to the client.
Dec 9 14:47:37 smoker pptpd[12508]: CTRL (PPPD Launcher): Connection speed = 115200
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Sent packet to client
Dec 9 14:47:37 smoker pppd[12508]: pppd 2.4.2b3 started by root, uid 0
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 15)
Dec 9 14:47:37 smoker pppd[12508]: using channel 76
Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Dec 9 14:47:37 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
Dec 9 14:47:37 smoker pppd[12508]: Connect: ppp0 <--> /dev/pts/2
Dec 9 14:47:37 smoker pppd[12508]: sent [LCP ConfReq id=0x1 <mru 1450> <auth eap> <magic 0x2124c1a9> <pcomp> <accomp>]
Dec 9 14:47:37 smoker pppd[12508]: rcvd [LCP ConfNak id=0x1 <mru 1500> <auth chap MS-v2>]
Dec 9 14:47:38 smoker pppd[12508]: sent [LCP ConfReq id=0x2 <auth chap MS-v2> <magic 0x2124c1a9> <pcomp> <accomp>]
Dec 9 14:47:38 smoker pppd[12508]: rcvd [LCP ConfAck id=0x2 <auth chap MS-v2> <magic 0x2124c1a9> <pcomp> <accomp>]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP ConfReq id=0x1 <magic 0x8fc0c7b> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint [local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
Dec 9 14:47:39 smoker pppd[12508]: sent [LCP ConfRej id=0x1 <callback CBCP> <mrru 1614>]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP ConfReq id=0x2 <magic 0x8fc0c7b> <pcomp> <accomp> <endpoint [local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
Dec 9 14:47:39 smoker pppd[12508]: sent [LCP ConfAck id=0x2 <magic 0x8fc0c7b> <pcomp> <accomp> <endpoint [local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
Dec 9 14:47:39 smoker pppd[12508]: sent [LCP EchoReq id=0x0 magic=0x2124c1a9]
Dec 9 14:47:39 smoker pppd[12508]: sent [CHAP Challenge id=0x81 <d8acca80cd469a810da9caa4c65b7ff2>, name = "smoker"]
Dec 9 14:47:39 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 15)
Dec 9 14:47:39 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP code=0xc id=0x3 08 fc 0c 7b 4d 53 52 41 53 56 35 2e 30 30]
Dec 9 14:47:39 smoker pppd[12508]: sent [LCP CodeRej id=0x3 0c 03 00 12 08 fc 0c 7b 4d 53 52 41 53 56 35 2e 30 30]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP code=0xc id=0x4 08 fc 0c 7b 4d 53 52 41 53 2d 31 2d 54 4f 41 53 54 45 52]
Dec 9 14:47:39 smoker pppd[12508]: sent [LCP CodeRej id=0x4 0c 04 00 17 08 fc 0c 7b 4d 53 52 41 53 2d 31 2d 54 4f 41 53 54 45 52]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP EchoRep id=0x0 magic=0x8fc0c7b]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [CHAP Response id=0x81 <544198025022bcdf1f4e9a7beb0a92c30000000000000000f 11306c7d66b3b5080c23026c1d2101d39cc900a35be821600> , name = "gatrobe"]
Dec 9 14:47:39 smoker pppd[12508]: sent [CHAP Success id=0x81 "S=56ED64C8B08D7E0FD958BE7908E7D346B466401E M=Access granted"]
Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfReq id=0x1 <mppe +H +M +S +L -D +C>]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfReq id=0x5 <mppe +H -M -S -L -D +C>]
Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfNak id=0x5 <mppe +H +M +S +L -D +C>]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [IPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
Dec 9 14:47:39 smoker pppd[12508]: sent [IPCP TermAck id=0x6]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfNak id=0x1 <mppe +H -M +S -L -D +C>]
Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D +C>]
Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfReq id=0x7 <mppe +H -M +S -L -D +C>]
Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfAck id=0x7 <mppe +H -M +S -L -D +C>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D +C>]
Dec 9 14:47:40 smoker pppd[12508]: MPPC/MPPE 128-bit stateless compression enabled
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x3 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x3 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x4 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x4 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x5 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x5 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x6 <addrs 0.0.0.0 130.75.178.11>]
Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP TermReq id=0x8 08 fc 0c 7b 00 3c cd 74 00 00 02 dc]
Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP TermAck id=0x8]
Dec 9 14:47:40 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 15)
Dec 9 14:47:40 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Dec 9 14:47:40 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 12)
Dec 9 14:47:40 smoker pppd[12508]: rcvd [LCP TermReq id=0x9 08 fc 0c 7b 00 3c cd 74 00 00 00 00]
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Made a CALL DISCONNECT RPLY packet
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Received CALL CLR request (closing call)
Dec 9 14:47:41 smoker pppd[12508]: sent [LCP TermAck id=0x9]
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: I wrote 148 bytes to the client.
Dec 9 14:47:41 smoker pppd[12508]: Modem hangup
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Sent packet to client
Dec 9 14:47:41 smoker pppd[12508]: Connection terminated.
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Received PPTP Control Message (type: 3)
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Made a STOP CTRL CONN RPLY packet
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Received STOP CTRL CONN request (disconnecting)
Dec 9 14:47:41 smoker pppd[12508]: Waiting for 1 child processes...
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: I wrote 16 bytes to the client.
Dec 9 14:47:41 smoker /etc/hotplug/net.agent: NET unregister event not supported
Dec 9 14:47:41 smoker pppd[12508]: script pppd (charshunt), pid 12509
Dec 9 14:47:41 smoker pptpd[12507]: CTRL: Sent packet to client
Dec 9 14:47:41 smoker pppd[12508]: Script pppd (charshunt) finished (pid 12509), status = 0x0
Dec 9 14:47:42 smoker pptpd[12507]: CTRL: Closing child BCrelay with pid 0
Dec 9 14:47:42 smoker pptpd[12507]: CTRL: Closing child ppp with pid 12508
Dec 9 14:47:42 smoker pptpd[12507]: CTRL: Exiting now
Dec 9 14:47:42 smoker pptpd[11928]: MGR: Reaped child 12507

This looks rather funny ;o) but it says nothing to me ( Can you tell me
in what happens here?

I'm looking for docu about ppp other than RFC's?
Do you know any links?

Clifford Kite <(E-Mail Removed)> wrote:

> It's easy to *say* what it means: pptpd received a duplicate General
> Record Encapsulation packet.

And easier for me to make mistakes; that should be "General Routing
Encapsulation."

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"

Martin Mleczko <(E-Mail Removed)> wrote:

> Is there a way to tell pptpd to throw the first one away and take the
> second? I've read anywhere that Microsoft's implementation is broken. Thus
> it sends a broken packet and afterwards is sends a correct one. I don't
> know any more wheather it referred to GRE, but it had to do with PPTP.

Again, I know very little about PPTP, in fact, I only know that it is
Microsoft's Point-to-Point Tunneling Protocol. But since you asked, it
looks to me more like the packet pptpd threw away was good since it wasn't
silently discarded, as I'd expect to be the case for a broken packet.

> /var/log/ppp-debug.log

....

> Dec 9 14:47:37 smoker pppd[12508]: pppd 2.4.2b3 started by root, uid 0
> Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Received PPTP Control Message
> (type: 15)
> Dec 9 14:47:37 smoker pppd[12508]: using channel 76
> Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet
> with standard ACCMs
> Dec 9 14:47:37 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
> Dec 9 14:47:37 smoker pppd[12508]: Connect: ppp0 <--> /dev/pts/2
> Dec 9 14:47:37 smoker pppd[12508]: sent [LCP ConfReq id=0x1 <mru 1450>
> <auth eap> <magic 0x2124c1a9> <pcomp> <accomp>]
> Dec 9 14:47:37 smoker pppd[12508]: rcvd [LCP ConfNak id=0x1 <mru 1500>
> <auth chap MS-v2>]
> Dec 9 14:47:38 smoker pppd[12508]: sent [LCP ConfReq id=0x2 <auth chap
> MS-v2> <magic 0x2124c1a9> <pcomp> <accomp>]
> Dec 9 14:47:38 smoker pppd[12508]: rcvd [LCP ConfAck id=0x2 <auth chap
> MS-v2> <magic 0x2124c1a9> <pcomp> <accomp>]

At this point pppd and the peer have agreed that pppd will use MS-CHAP
version 2 to authenticate the peer, among other things.

> Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP ConfReq id=0x1 <magic
> 0x8fc0c7b> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
> [local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
> Dec 9 14:47:39 smoker pppd[12508]: sent [LCP ConfRej id=0x1 <callback
> CBCP> <mrru 1614>]
> Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP ConfReq
> id=0x2 <magic 0x8fc0c7b> <pcomp> <accomp> <endpoint
> [local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
> Dec 9 14:47:39 smoker pppd[12508]: sent [LCP ConfAck
> id=0x2 <magic 0x8fc0c7b> <pcomp> <accomp> <endpoint
> [local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]

Here pppd and the peer negotiated some things that pppd can do, as well
as a seemingly useless MP (Multilink PPP) endpoint. I'd suggest adding
the pppd option nomp which keep useless negotiations from taking place.

> Dec 9 14:47:39 smoker pppd[12508]: sent [LCP EchoReq id=0x0
> magic=0x2124c1a9]
> Dec 9 14:47:39 smoker pppd[12508]: sent [CHAP Challenge id=0x81
> <d8acca80cd469a810da9caa4c65b7ff2>, name = "smoker"]
> Dec 9 14:47:39 smoker pptpd[12507]: CTRL: Received PPTP Control Message
> (type: 15)
> Dec 9 14:47:39 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet
> with standard ACCMs
> Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP code=0xc id=0x3 08 fc 0c
> 7b 4d 53 52 41 53 56 35 2e 30 30]
> Dec 9 14:47:39 smoker pppd[12508]: sent [LCP CodeRej id=0x3 0c 03 00
> 12 08 fc 0c 7b 4d 53 52 41 53 56 35 2e 30 30]

Here pppd rejects the Identification code, which is used, among other
things, to send an unauthenticated identification string that let's a
PPP implementation identify itself to the peer. It should be unnecessary
and pppd doesn't implement that code in LCP - hence the Code-Reject to
tell the peer that pppd doesn't know or implement that code.

> Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP code=0xc id=0x4 08 fc 0c
> 7b 4d 53 52 41 53 2d 31 2d 54 4f 41 53 54 45 52]
> Dec 9 14:47:39 smoker pppd[12508]: sent [LCP CodeRej id=0x4 0c 04 00
> 17 08 fc 0c 7b 4d 53 52 41 53 2d 31 2d 54 4f 41 53 54 45 52]

The peer is broken since it doesn't know what Code-Reject means and
tries another, and different, Identification code.

> Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP EchoRep id=0x0
> magic=0x8fc0c7b]
> Dec 9 14:47:39 smoker pppd[12508]: rcvd [CHAP Response id=0x81
> <544198025022bcdf1f4e9a7beb0a92c30000000000000000f 11306c7d66b3b5080c23026c1d2101d39cc900a35be821600> ,
> name = "gatrobe"]
> Dec 9 14:47:39 smoker pppd[12508]: sent [CHAP Success id=0x81
> "S=56ED64C8B08D7E0FD958BE7908E7D346B466401E M=Access granted"]

The peer successfully authenticates itself to you.

> Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfReq id=0x1 <mppe +H
> +M +S +L -D +C>]
> Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfReq id=0x5 <mppe +H
> -M -S -L -D +C>]
> Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfNak id=0x5 <mppe +H
> +M +S +L -D +C>]
> Dec 9 14:47:39 smoker pppd[12508]: rcvd [IPCP ConfReq id=0x6 <addr
> 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins
> 0.0.0.0>]
> Dec 9 14:47:39 smoker pppd[12508]: sent [IPCP TermAck id=0x6]

The peer requests that pppd supply it with an IP address for it to use
for the PPP link. Pppd terminates IPCP - I'm not sure why, but later
reopens it.

> Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfNak id=0x1 <mppe +H
> -M +S -L -D +C>]
> Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfReq id=0x2 <mppe +H
> -M +S -L -D +C>]
> Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfReq id=0x7 <mppe +H
> -M +S -L -D +C>]
> Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfAck id=0x7 <mppe +H
> -M +S -L -D +C>]
> Dec 9 14:47:40 smoker pppd[12508]: rcvd [CCP ConfAck id=0x2 <mppe +H
> -M +S -L -D +C>]
> Dec 9 14:47:40 smoker pppd[12508]: MPPC/MPPE 128-bit stateless
> compression enabled

The peer and pppd agree on MPPC/MPPE after some bickering.

> Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x1 <compress
> VJ 0f 01> <addr 0.0.0.0>]
> Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x1 <compress
> VJ 0f 01> <addr 0.0.0.0>]

Pppd reopens IPCP negotiation. The peer returns a Configure-Reject for
VJ header compression, and a request from pppd that the peer supply the
IP address for pppd to use during the PPP connection. I'd suggest using
the pppd option novj.

> Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x2 <addrs
> 0.0.0.0 130.75.178.11>]
> Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x2 <addrs
> 0.0.0.0 130.75.178.11>]

Pppd drops back and tries an old IP addresses option (addrs) which
is rejected by the peer - no surprise. The request still asked the
peer to supply the IP address it (pppd) should use for the PPP link.
But that doesn't work.

It looks to me like neither peer or pppd knew it's IP address (although
pppd requested that the peer use 30.75.178.11 in the old IP addresses
option above, but option was rejected entirely). For some strange reason
pppd continued requesting the same addrs option, but to no avail.

From a previous post,

my /etc/pppd.conf

option /etc/ppp/options.pptpd
localip XXX.XXX.XXX.26
remoteip XXX.XXX.XXX.10-15

which must be a configuration file for pptpd to use. There is no pppd
options "option", localip, or remoteip, and no provision for pppd to
use a /etc/pppd.conf file.

Perhaps the local and remote IP addresses are not being supplied to
pppd by pptpd for some reason, or need to be put in options.pptpd as
XXX.XXX.XXX.26:XXX.XXX.XXX.10-15 (although I really don't understand
that "-15").

Anyway, the failure to negotiate IP addresses appears to almost certainly
be the cause of the PPP link negotiation failure.

....

> I'm looking for docu about ppp other than RFC's?
> Do you know any links?

Sorry, not for using pppd with PPTP. Maybe google?

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Emacs vs vi:
Sort of like a Swiss Army knife versus a rapier. */

Clifford Kite wrote:
> Martin Mleczko <(E-Mail Removed)> wrote:
>
>
>>Is there a way to tell pptpd to throw the first one away and take the
>>second? I've read anywhere that Microsoft's implementation is broken. Thus
>>it sends a broken packet and afterwards is sends a correct one. I don't
>>know any more wheather it referred to GRE, but it had to do with PPTP.
>
>
> Again, I know very little about PPTP, in fact, I only know that it is
> Microsoft's Point-to-Point Tunneling Protocol. But since you asked, it
> looks to me more like the packet pptpd threw away was good since it wasn't
> silently discarded, as I'd expect to be the case for a broken packet.
>
>
>>/var/log/ppp-debug.log
>
>
> ...
>
>
>>Dec 9 14:47:37 smoker pppd[12508]: pppd 2.4.2b3 started by root, uid 0
>>Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Received PPTP Control Message
>>(type: 15)
>>Dec 9 14:47:37 smoker pppd[12508]: using channel 76
>>Dec 9 14:47:37 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet
>>with standard ACCMs
>>Dec 9 14:47:37 smoker /etc/hotplug/net.agent: assuming ppp0 is already up
>>Dec 9 14:47:37 smoker pppd[12508]: Connect: ppp0 <--> /dev/pts/2
>>Dec 9 14:47:37 smoker pppd[12508]: sent [LCP ConfReq id=0x1 <mru 1450>
>><auth eap> <magic 0x2124c1a9> <pcomp> <accomp>]
>>Dec 9 14:47:37 smoker pppd[12508]: rcvd [LCP ConfNak id=0x1 <mru 1500>
>><auth chap MS-v2>]
>>Dec 9 14:47:38 smoker pppd[12508]: sent [LCP ConfReq id=0x2 <auth chap
>>MS-v2> <magic 0x2124c1a9> <pcomp> <accomp>]
>>Dec 9 14:47:38 smoker pppd[12508]: rcvd [LCP ConfAck id=0x2 <auth chap
>>MS-v2> <magic 0x2124c1a9> <pcomp> <accomp>]
>
>
> At this point pppd and the peer have agreed that pppd will use MS-CHAP
> version 2 to authenticate the peer, among other things.
>
>
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP ConfReq id=0x1 <magic
>>0x8fc0c7b> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
>>[local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [LCP ConfRej id=0x1 <callback
>>CBCP> <mrru 1614>]
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP ConfReq
>>id=0x2 <magic 0x8fc0c7b> <pcomp> <accomp> <endpoint
>>[local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [LCP ConfAck
>>id=0x2 <magic 0x8fc0c7b> <pcomp> <accomp> <endpoint
>>[local:91.08.7b.c5.eb.39.44.5a.84.b1.c1.91.04.0e.5e .55.00.00.00.23]>]
>
>
> Here pppd and the peer negotiated some things that pppd can do, as well
> as a seemingly useless MP (Multilink PPP) endpoint. I'd suggest adding
> the pppd option nomp which keep useless negotiations from taking place.
>
>
>>Dec 9 14:47:39 smoker pppd[12508]: sent [LCP EchoReq id=0x0
>>magic=0x2124c1a9]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [CHAP Challenge id=0x81
>><d8acca80cd469a810da9caa4c65b7ff2>, name = "smoker"]
>>Dec 9 14:47:39 smoker pptpd[12507]: CTRL: Received PPTP Control Message
>>(type: 15)
>>Dec 9 14:47:39 smoker pptpd[12507]: CTRL: Got a SET LINK INFO packet
>>with standard ACCMs
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP code=0xc id=0x3 08 fc 0c
>>7b 4d 53 52 41 53 56 35 2e 30 30]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [LCP CodeRej id=0x3 0c 03 00
>>12 08 fc 0c 7b 4d 53 52 41 53 56 35 2e 30 30]
>
>
> Here pppd rejects the Identification code, which is used, among other
> things, to send an unauthenticated identification string that let's a
> PPP implementation identify itself to the peer. It should be unnecessary
> and pppd doesn't implement that code in LCP - hence the Code-Reject to
> tell the peer that pppd doesn't know or implement that code.
>
>
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP code=0xc id=0x4 08 fc 0c
>>7b 4d 53 52 41 53 2d 31 2d 54 4f 41 53 54 45 52]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [LCP CodeRej id=0x4 0c 04 00
>>17 08 fc 0c 7b 4d 53 52 41 53 2d 31 2d 54 4f 41 53 54 45 52]
>
>
> The peer is broken since it doesn't know what Code-Reject means and
> tries another, and different, Identification code.
>
>
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [LCP EchoRep id=0x0
>>magic=0x8fc0c7b]
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [CHAP Response id=0x81
>><544198025022bcdf1f4e9a7beb0a92c3000000000000000 0f11306c7d66b3b5080c23026c1d2101d39cc900a35be82160 0>,
>>name = "gatrobe"]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [CHAP Success id=0x81
>>"S=56ED64C8B08D7E0FD958BE7908E7D346B466401E M=Access granted"]
>
>
> The peer successfully authenticates itself to you.
>
>
>>Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfReq id=0x1 <mppe +H
>>+M +S +L -D +C>]
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfReq id=0x5 <mppe +H
>>-M -S -L -D +C>]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfNak id=0x5 <mppe +H
>>+M +S +L -D +C>]
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [IPCP ConfReq id=0x6 <addr
>>0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins
>>0.0.0.0>]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [IPCP TermAck id=0x6]
>
>
> The peer requests that pppd supply it with an IP address for it to use
> for the PPP link. Pppd terminates IPCP - I'm not sure why, but later
> reopens it.
>
>
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfNak id=0x1 <mppe +H
>>-M +S -L -D +C>]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfReq id=0x2 <mppe +H
>>-M +S -L -D +C>]
>>Dec 9 14:47:39 smoker pppd[12508]: rcvd [CCP ConfReq id=0x7 <mppe +H
>>-M +S -L -D +C>]
>>Dec 9 14:47:39 smoker pppd[12508]: sent [CCP ConfAck id=0x7 <mppe +H
>>-M +S -L -D +C>]
>>Dec 9 14:47:40 smoker pppd[12508]: rcvd [CCP ConfAck id=0x2 <mppe +H
>>-M +S -L -D +C>]
>>Dec 9 14:47:40 smoker pppd[12508]: MPPC/MPPE 128-bit stateless
>>compression enabled
>
>
> The peer and pppd agree on MPPC/MPPE after some bickering.
>
>
>>Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x1 <compress
>>VJ 0f 01> <addr 0.0.0.0>]
>>Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x1 <compress
>>VJ 0f 01> <addr 0.0.0.0>]
>
>
> Pppd reopens IPCP negotiation. The peer returns a Configure-Reject for
> VJ header compression, and a request from pppd that the peer supply the
> IP address for pppd to use during the PPP connection. I'd suggest using
> the pppd option novj.
>
>
>>Dec 9 14:47:40 smoker pppd[12508]: sent [IPCP ConfReq id=0x2 <addrs
>>0.0.0.0 130.75.178.11>]
>>Dec 9 14:47:40 smoker pppd[12508]: rcvd [IPCP ConfRej id=0x2 <addrs
>>0.0.0.0 130.75.178.11>]
>
>
> Pppd drops back and tries an old IP addresses option (addrs) which
> is rejected by the peer - no surprise. The request still asked the
> peer to supply the IP address it (pppd) should use for the PPP link.
> But that doesn't work.
>
> It looks to me like neither peer or pppd knew it's IP address (although
> pppd requested that the peer use 30.75.178.11 in the old IP addresses
> option above, but option was rejected entirely). For some strange reason
> pppd continued requesting the same addrs option, but to no avail.
>
> From a previous post,
>
> my /etc/pppd.conf
>
> option /etc/ppp/options.pptpd
> localip XXX.XXX.XXX.26
> remoteip XXX.XXX.XXX.10-15
>
> which must be a configuration file for pptpd to use. There is no pppd
> options "option", localip, or remoteip, and no provision for pppd to
> use a /etc/pppd.conf file.
>
> Perhaps the local and remote IP addresses are not being supplied to
> pppd by pptpd for some reason, or need to be put in options.pptpd as
> XXX.XXX.XXX.26:XXX.XXX.XXX.10-15 (although I really don't understand
> that "-15").
>
> Anyway, the failure to negotiate IP addresses appears to almost certainly
> be the cause of the PPP link negotiation failure.
>
> ...
>
>
>>I'm looking for docu about ppp other than RFC's?
>>Do you know any links?
>
>
> Sorry, not for using pppd with PPTP. Maybe google?
>

Hi
Good news; it started working. The point was to add an ip to
/etc/ppp/options.pptpd to be given to the client. PPTPD should do this
but it does not *grrr*
Now i can establish a vpn connection but i got in further troube.
How hot make the server to establish several connections to clients as
there is only one remote ip given in /etc/ppp/options.pptpd? Got some
ideas with symbolic links and scripts but i don't know wheather it'l
work nor if it is worth. (Mayby I schould kick pptp and use IpSec/FreesWan).
I need broadcasts to be relayed between the Ethernet and the vpn's.
Bcrelay semms to work only in one direction... maybe iptalbes or
bridge-utils...???

Stay tuned...

Martin

Martin mleczko <(E-Mail Removed)> wrote:
> Now i can establish a vpn connection but i got in further troube.
> How hot make the server to establish several connections to clients as
> there is only one remote ip given in /etc/ppp/options.pptpd?

Perhaps you want a VPN? Using a "client" with that remote IP address
as a network gateway for the others? I've never done it but that sounds
reasonable.

You can restrict the VPN to a particular subnet by using the fourth field
of the secrets file. Read man pppd, and in particular the AUTHENTICATION
section.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

i had a similar error it was that i moved the pptpctrl from /usr/local/sbin
to /usr/sbin and pptp could not find pptpctrl, it was in the path but hey
who know may be a compiled command