pptpclient-devel — PPTP Client Development and Support

Re: [pptp-devel] Segfault in pptpcm

[James C. <qu...@la...>]

On Thu, Apr 16, 2015 at 09:46:20AM +0200, Lorenzo Maurizi - C.S.I.A. UniMC wrote:
> Thank you James for the deep analysis you made.
> 
> > There's a one way effect happening.  As soon as IPCP negotiation completes
> > (time = 6.872377), there are no further IP packets received by the client
> from
> > the server.
> > 
> > This blockage includes GRE and the TCP packets for port 1723.  GRE packets
> > are sent by the client but there is no acknowledgement received from the
> > server.  TCP port 1723 packets are retransmitted.
> > 
> > Later (time = 118.510242) the blockage ends with a TCP RST packet from the
> > server.
> > 
> > My guess now is that iptables or routing changes are happening when the
> > ppp0 interface comes up, and these changes are either;
> > 
> > - dropping the packets from the server, before they arrive at the eth0
> >   interface, or;
> > 
> > - dropping the packets from the client, after they have left the eth0
> >   interface.
> > 
> > Look at your iptables rules before connection, and during connection.
> 
> At the moment neither the client machine nor the receiving windows machine
> have a firewall enabled.

So iptables-save (if present) yields nothing.

> > 
> > You might also use Wireshark on the server to capture the other side of a
> > conversation.
> 
> I have run some wireshark captures at the windows server end, and they are
> interesting.
> I have run a small set of tests (a ping from the client to the internal LAN
> IP address of the receiving server 172.16.0.46, and a telnet connection to
> the same address to port 80) in two situations: one run from the linux
> client and one from a connection made by a windows machine.
> The tests from the windows machine are all positive. The wireshark capture
> at the server end shows a regular traffic between the hosts (packet from
> client to server, then packet from server to client in response).
> The test from the linux machine instead are all negative. The strange thing
> is that the server receives every packet sent from client, but there is no
> response packet sent from server to client.
> Observing the packet captures I think that the disconnection after the 1.5
> minutes is due to the lack of response to the polling to determine if the
> tunnel is up.

Yes.  There's a timeout due to lack of response.

> Maybe I'm saying something obvious, or something you said earlier, I'm
> sorry! I'm learning!
> 
> 
> I don't want to abuse of your time James, but if you want, I can send you
> the wireshark captures for the two test sessions.

No thanks, your description is clear.

Just to confirm though; in your packet capture on the server, after
IPCP ConfAck you see GRE packets from the server to the client, but
they are not in the packet capture on the client.

That suggests the packets are being lost in network gateway equipment,
and not the client or the server.

Some gateway equipment is tested with Microsoft Windows and not with
Linux.

When gateway equipment does this, the choices are to either:

- reconfigure the gateway,

- reverse engineer the successful packets and modify pptp to generate
  packets that are indistinguishable, or;

- switch to another tunnel protocol, such as OpenVPN.

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] Segfault in pptpcm

[Lorenzo M. - C.S.I.A. U. <lor...@un...>]

Thank you James for the deep analysis you made.

> There's a one way effect happening.  As soon as IPCP negotiation completes
> (time = 6.872377), there are no further IP packets received by the client
from
> the server.
> 
> This blockage includes GRE and the TCP packets for port 1723.  GRE packets
> are sent by the client but there is no acknowledgement received from the
> server.  TCP port 1723 packets are retransmitted.
> 
> Later (time = 118.510242) the blockage ends with a TCP RST packet from the
> server.
> 
> My guess now is that iptables or routing changes are happening when the
> ppp0 interface comes up, and these changes are either;
> 
> - dropping the packets from the server, before they arrive at the eth0
>   interface, or;
> 
> - dropping the packets from the client, after they have left the eth0
>   interface.
> 
> Look at your iptables rules before connection, and during connection.

At the moment neither the client machine nor the receiving windows machine
have a firewall enabled.
> 
> You might also use Wireshark on the server to capture the other side of a
> conversation.

I have run some wireshark captures at the windows server end, and they are
interesting.
I have run a small set of tests (a ping from the client to the internal LAN
IP address of the receiving server 172.16.0.46, and a telnet connection to
the same address to port 80) in two situations: one run from the linux
client and one from a connection made by a windows machine.
The tests from the windows machine are all positive. The wireshark capture
at the server end shows a regular traffic between the hosts (packet from
client to server, then packet from server to client in response).
The test from the linux machine instead are all negative. The strange thing
is that the server receives every packet sent from client, but there is no
response packet sent from server to client.
Observing the packet captures I think that the disconnection after the 1.5
minutes is due to the lack of response to the polling to determine if the
tunnel is up.
Maybe I'm saying something obvious, or something you said earlier, I'm
sorry! I'm learning!


I don't want to abuse of your time James, but if you want, I can send you
the wireshark captures for the two test sessions.

Thanks for all your help.
Regards from Lorenzo

Re: [pptp-devel] Segfault in pptpcm

[James C. <qu...@la...>]

On Wed, Apr 15, 2015 at 01:35:18PM +0200, Lorenzo Maurizi - C.S.I.A. UniMC wrote:
> I'll send you the binary dump I collected for the second test.

Thanks.

There's a one way effect happening.  As soon as IPCP negotiation
completes (time = 6.872377), there are no further IP packets received
by the client from the server.

This blockage includes GRE and the TCP packets for port 1723.  GRE
packets are sent by the client but there is no acknowledgement
received from the server.  TCP port 1723 packets are retransmitted.

Later (time = 118.510242) the blockage ends with a TCP RST packet from
the server.

My guess now is that iptables or routing changes are happening when
the ppp0 interface comes up, and these changes are either;

- dropping the packets from the server, before they arrive at the eth0
  interface, or;

- dropping the packets from the client, after they have left the eth0
  interface.

Look at your iptables rules before connection, and during connection.

You might also use Wireshark on the server to capture the other side
of a conversation.

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] Segfault in pptpcm

[Lorenzo M. - C.S.I.A. U. <lor...@un...>]

> Thanks.
> 
> Your tcpdump shows compressed ppp data.  I'm not sure how it is
> compressed though.  I'd have to open a binary dump in wireshark to be
sure.

I'll send you the binary dump I collected for the second test.

> 
> Is there an "enable compression" option you can turn off on the server?

>From a quick google search about this topic, when making a "client to LAN"
PPTP VPN from a windows machine, the setting to enable compression is on the
calling side, not on server side.
This settings window:
http://www.earthvpn.com/wp-content/uploads/2013/03/13.jpg
is displayed when configuring PPP options at client side.
In the setup I have at remote server I can't configure anything because I'm
using the simplest way to accept incoming connections:
http://www.howtogeek.com/135996/how-to-create-a-vpn-server-on-your-windows-c
omputer-without-installing-any-software/


> 
> --
> James Cameron
> http://quozl.linux.org.au/

Re: [pptp-devel] Segfault in pptpcm

[James C. <qu...@la...>]

Thanks.

Your tcpdump shows compressed ppp data.  I'm not sure how it is
compressed though.  I'd have to open a binary dump in wireshark to be
sure.

Is there an "enable compression" option you can turn off on the
server?

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] Segfault in pptpcm

[Lorenzo M. - C.S.I.A. U. <lor...@un...>]

> > >Acceptance of server using specific address.  (Can you ping that
> > >address
> > 172.16.0.10 once the tunnel is up?  I presume not.)
> >
> > You are right, I can't even ping the local ppp0 interface address...
> >
> > ~# ping 172.16.0.10
> > PING 172.16.0.10 (172.16.0.10) 56(84) bytes of data.
> > ^C
> > --- 172.16.0.10 ping statistics ---
> > 5 packets transmitted, 0 received, 100% packet loss, time 4016ms
> >
> 
> You mention local, but my question was about the remote, and your ping
> was of the remote address of the tunnel.  If you also cannot ping the
local
> address of the tunnel then that is very interesting.
> 
> Can you check that?  It is the "local  IP address" in the debug log.
Sorry you are correct... I misunderstood .
The client has a public IP address set on eth0 (not really the one I wrote
on the log in the ML).

Pinging that address from the client caused a reply (please consider that
192.168.0.112 is actually a public IP address).
root:~# ping 192.168.0.112
PING 192.168.0.112 (192.168.0.112) 56(84) bytes of data.
64 bytes from 192.168.0.112: icmp_req=1 ttl=64 time=0.043 ms
64 bytes from 192.168.0.112: icmp_req=2 ttl=64 time=0.053 ms
^C
--- 192.168.0.112 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.043/0.048/0.053/0.005 ms

Pinging the same address from the other side of the tunnel (Windows
receiving server) caused no reply (again, in place of 192.168.0.112 is the
public IP address of the remote client)
C:\Users\Administrator>ping 192.168.0.112

Pinging 192.168.0.112 with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 192.168.0.112:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C

Ping 172.16.0.10 from client caused no reply
root:~# ping 172.16.0.10
PING 172.16.0.10 (172.16.0.10) 56(84) bytes of data.
^C
--- 172.16.0.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3008ms

Ping 172.16.0.10 from vpn server side caused reply to ping.
C:\Users\Administrator>ping 172.16.0.10

Pinging 172.16.0.10 with 32 bytes of data:
Reply from 172.16.0.10: bytes=32 time<1ms TTL=128
Reply from 172.16.0.10: bytes=32 time<1ms TTL=128
Reply from 172.16.0.10: bytes=32 time<1ms TTL=128
Reply from 172.16.0.10: bytes=32 time<1ms TTL=128

Ping statistics for 172.16.0.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

> Received, thanks.
> 
> In your tcpdump, there is no GRE traffic after negotiation.  So there is
no sign
> of compression confusion.
> 
> Traffic from the server may occur.
> 
> Traffic from the client should occur when you make a connection or ping
> through the tunnel.
> 
> I guess I didn't ask you to generate traffic, sorry.

I'm sorry too... I should have imagined that!

> 
> This situation lasts for only three seconds though, according to the
tcpdump
> timing.
> 
> The client is the first to blink.  At 08:33:03.259147 it sends a CCRQ,
call clear
> request, three seconds after the last IPCP ConfAck at 08:33:00.212242.
> 
> There's no explanation in the pppd log about why the client decided to do
> this.
> 
> Please check logs in /var/log or syslog for pptp messages.
> 
> Please also check that the negotiated IP addresses "local  IP address"
> and "remote IP address" do not exist on any other network interfaces on
the
> client system.

As I said, "local IP address" is the real IP address of eth0 and in the real
situation is a public IP.
Remote IP address is assigned to ppp0 device.

I'm producing a log with some traffic (ping between hosts and a failed
telnet to port 80 from client to remote VPN server).
I'll send you right after.

Thanks a lot for your effort!

Re: [pptp-devel] Segfault in pptpcm

[James C. <qu...@la...>]

On Wed, Apr 15, 2015 at 08:38:56AM +0200, Lorenzo Maurizi - C.S.I.A. UniMC wrote:
> Thanks James, 
> 
> >Acceptance of server using specific address.  (Can you ping that address
> 172.16.0.10 once the tunnel is up?  I presume not.)
> 
> You are right, I can't even ping the local ppp0 interface address...
> 
> ~# ping 172.16.0.10
> PING 172.16.0.10 (172.16.0.10) 56(84) bytes of data.
> ^C
> --- 172.16.0.10 ping statistics ---
> 5 packets transmitted, 0 received, 100% packet loss, time 4016ms
> 

You mention local, but my question was about the remote, and your ping
was of the remote address of the tunnel.  If you also cannot ping the
local address of the tunnel then that is very interesting.

Can you check that?  It is the "local  IP address" in the debug log.

But see below; it should only exist for a very short time.

> I'll do this asap. Thank you very much for your support so far.

Received, thanks.

In your tcpdump, there is no GRE traffic after negotiation.  So there
is no sign of compression confusion.

Traffic from the server may occur.

Traffic from the client should occur when you make a connection or
ping through the tunnel.

I guess I didn't ask you to generate traffic, sorry.

This situation lasts for only three seconds though, according to the
tcpdump timing.

The client is the first to blink.  At 08:33:03.259147 it sends a CCRQ, call clear
request, three seconds after the last IPCP ConfAck at 08:33:00.212242.

There's no explanation in the pppd log about why the client decided to
do this.

Please check logs in /var/log or syslog for pptp messages.

Please also check that the negotiated IP addresses "local  IP address"
and "remote IP address" do not exist on any other network interfaces
on the client system.

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] Segfault in pptpcm

[Lorenzo M. - C.S.I.A. U. <lor...@un...>]

Thanks James, 

>Acceptance of server using specific address.  (Can you ping that address
172.16.0.10 once the tunnel is up?  I presume not.)

You are right, I can't even ping the local ppp0 interface address...

~# ping 172.16.0.10
PING 172.16.0.10 (172.16.0.10) 56(84) bytes of data.
^C
--- 172.16.0.10 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4016ms

>Thanks.  The log shows normal negotiation, though with a server-side
proposal to use MPPC which is successfully negotiated for removal.
>
>My guess is that despite agreeing to removal of MPPC, the server has begun
to use it regardless.
>
>This in turn causes traffic to cease, because the kernel cannot decrypt the
compressed packets.
>
>You may verify this by capturing the packets exchanged.
>
>http://pptpclient.sourceforge.net/howto-diagnosis.phtml#tcpdump
>
>Please make sure you capture a corresponding debug log at the same time you
capture a tcpdump.
>
>You have my permission to post the tcpdump and debug log to me off-list,
and I will summarise to the list.

I'll do this asap. Thank you very much for your support so far.

Re: [pptp-devel] Segfault in pptpcm

[James C. <qu...@la...>]

On Tue, Apr 14, 2015 at 01:28:12PM +0200, Lorenzo Maurizi - C.S.I.A. UniMC wrote:
> This is the output of the command
> 
> # pon meeting debug dump logfd 2 nodetach
> 
> 8<-----------------------------------------------
> pppd options in effect:
> debug           # (from command line)
> nodetach                # (from command line)
> persist         # (from /etc/ppp/peers/meeting)
> logfd 2         # (from command line)
> dump            # (from command line)
> noauth          # (from /etc/ppp/options.pptp)
> refuse-pap              # (from /etc/ppp/options.pptp)
> refuse-chap             # (from /etc/ppp/options.pptp)
> refuse-mschap           # (from /etc/ppp/options.pptp)
> refuse-eap              # (from /etc/ppp/options.pptp)
> name VPN_User           # (from /etc/ppp/peers/meeting)
> remotename meeting              # (from /etc/ppp/peers/meeting)
>                 # (from /etc/ppp/options.pptp)
> pty pptp meeting.myserver.org --nolaunchpppd                # (from
> /etc/ppp/peers/meeting)
> crtscts         # (from /etc/ppp/options)
>                 # (from /etc/ppp/options)
> asyncmap 0              # (from /etc/ppp/options)
> lcp-echo-failure 4              # (from /etc/ppp/options)
> lcp-echo-interval 30            # (from /etc/ppp/options)
> hide-password           # (from /etc/ppp/options)
> ipparam meeting         # (from /etc/ppp/peers/meeting)
> nobsdcomp               # (from /etc/ppp/options.pptp)
> nodeflate               # (from /etc/ppp/options.pptp)
> require-mppe-128                # (from /etc/ppp/options.pptp)
> noipx           # (from /etc/ppp/options)
> using channel 109
> Using interface ppp0
> Connect: ppp0 <--> /dev/pts/1
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb082ee47> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x0 <mru 1400> <auth chap MS-v2> <magic 0x79ef6932>
> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
> [local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
> sent [LCP ConfRej id=0x0 <callback CBCP> <mrru 1614>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb082ee47> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x79ef6932>
> <pcomp> <accomp> <endpoint
> [local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
> sent [LCP ConfAck id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x79ef6932>
> <pcomp> <accomp> <endpoint
> [local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
> sent [LCP EchoReq id=0x0 magic=0xb082ee47]
> rcvd [CHAP Challenge id=0x0 <4cd4618aecbeb5ef8084f058a0d29be6>, name =
> "MEETING"]
> sent [CHAP Response id=0x0
> <4c26875e385a24280d04bc1106119d1a00000000000000008c1166ea1219e6971a206ae4ccb
> fd2829df6f8426a5f573e00>, name = "VPN_User"]
> rcvd [LCP EchoRep id=0x0 magic=0x79ef6932]
> rcvd [CHAP Success id=0x0 "S=B4497E6F192782D563270E7E2257F6C5C085D8D6"]
> CHAP authentication succeeded
> sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
> rcvd [CCP ConfReq id=0x3 <mppe +H -M +S -L -D +C>]

Proposal to use MPPC.

> sent [CCP ConfNak id=0x3 <mppe +H -M +S -L -D -C>]

Counter-proposal to not use MPPC.
http://pptpclient.sourceforge.net/howto-diagnosis.phtml#confreqacknakrej

> rcvd [IPCP ConfReq id=0x4 <addr 172.16.0.10>]
> sent [IPCP TermAck id=0x4]
> rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
> rcvd [CCP ConfReq id=0x5 <mppe +H -M +S -L -D -C>]
> sent [CCP ConfAck id=0x5 <mppe +H -M +S -L -D -C>]

Acceptance.

> MPPE 128-bit stateless compression enabled
> sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.0.112>]

Proposal by client to use a specific address.

> rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
> sent [IPCP ConfReq id=0x2 <addr 192.168.0.112>]
> rcvd [IPCP ConfAck id=0x2 <addr 192.168.0.112>]
> rcvd [IPCP ConfReq id=0x6 <addr 172.16.0.10>]
> sent [IPCP ConfAck id=0x6 <addr 172.16.0.10>]

Acceptance of server using specific address.  (Can you ping that
address 172.16.0.10 once the tunnel is up?  I presume not.)

> local  IP address 192.168.0.112
> remote IP address 172.16.0.10
> Script /etc/ppp/ip-up started (pid 5366)
> Script /etc/ppp/ip-up finished (pid 5366), status = 0x0
> #### this ends the connection and the tunnel should be established... but,
> as I said, I can't route any traffic through it...

Thanks.  The log shows normal negotiation, though with a server-side
proposal to use MPPC which is successfully negotiated for removal.

My guess is that despite agreeing to removal of MPPC, the server has
begun to use it regardless.

This in turn causes traffic to cease, because the kernel cannot
decrypt the compressed packets.

You may verify this by capturing the packets exchanged.

http://pptpclient.sourceforge.net/howto-diagnosis.phtml#tcpdump

Please make sure you capture a corresponding debug log at the same
time you capture a tcpdump.

You have my permission to post the tcpdump and debug log to me
off-list, and I will summarise to the list.

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] Segfault in pptpcm

[Lorenzo M. - C.S.I.A. U. <lor...@un...>]

Thanks for the quick answer.

>This hangup is the critical issue.  Please enable debug logging and give us
another log to look at.

This is the output of the command

# pon meeting debug dump logfd 2 nodetach

8<-----------------------------------------------
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
persist         # (from /etc/ppp/peers/meeting)
logfd 2         # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/options.pptp)
refuse-pap              # (from /etc/ppp/options.pptp)
refuse-chap             # (from /etc/ppp/options.pptp)
refuse-mschap           # (from /etc/ppp/options.pptp)
refuse-eap              # (from /etc/ppp/options.pptp)
name VPN_User           # (from /etc/ppp/peers/meeting)
remotename meeting              # (from /etc/ppp/peers/meeting)
                # (from /etc/ppp/options.pptp)
pty pptp meeting.myserver.org --nolaunchpppd                # (from
/etc/ppp/peers/meeting)
crtscts         # (from /etc/ppp/options)
                # (from /etc/ppp/options)
asyncmap 0              # (from /etc/ppp/options)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
hide-password           # (from /etc/ppp/options)
ipparam meeting         # (from /etc/ppp/peers/meeting)
nobsdcomp               # (from /etc/ppp/options.pptp)
nodeflate               # (from /etc/ppp/options.pptp)
require-mppe-128                # (from /etc/ppp/options.pptp)
noipx           # (from /etc/ppp/options)
using channel 109
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb082ee47> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <auth chap MS-v2> <magic 0x79ef6932>
<pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP ConfRej id=0x0 <callback CBCP> <mrru 1614>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb082ee47> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x79ef6932>
<pcomp> <accomp> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP ConfAck id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x79ef6932>
<pcomp> <accomp> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP EchoReq id=0x0 magic=0xb082ee47]
rcvd [CHAP Challenge id=0x0 <4cd4618aecbeb5ef8084f058a0d29be6>, name =
"MEETING"]
sent [CHAP Response id=0x0
<4c26875e385a24280d04bc1106119d1a00000000000000008c1166ea1219e6971a206ae4ccb
fd2829df6f8426a5f573e00>, name = "VPN_User"]
rcvd [LCP EchoRep id=0x0 magic=0x79ef6932]
rcvd [CHAP Success id=0x0 "S=B4497E6F192782D563270E7E2257F6C5C085D8D6"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x3 <mppe +H -M +S -L -D +C>]
sent [CCP ConfNak id=0x3 <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x4 <addr 172.16.0.10>]
sent [IPCP TermAck id=0x4]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x5 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x5 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.0.112>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 192.168.0.112>]
rcvd [IPCP ConfAck id=0x2 <addr 192.168.0.112>]
rcvd [IPCP ConfReq id=0x6 <addr 172.16.0.10>]
sent [IPCP ConfAck id=0x6 <addr 172.16.0.10>]
local  IP address 192.168.0.112
remote IP address 172.16.0.10
Script /etc/ppp/ip-up started (pid 5366)
Script /etc/ppp/ip-up finished (pid 5366), status = 0x0
#### this ends the connection and the tunnel should be established... but,
as I said, I can't route any traffic through it...
#### after a minute the output continues...
Script pptp meeting.myserver.org --nolaunchpppd finished (pid 5356), status
= 0x0
Modem hangup
Connect time 1.5 minutes.
Sent 0 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 5392)
MPPE disabled
sent [LCP TermReq id=0x2 "MPPE disabled"]
Connection terminated.
using channel 110
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
Script /etc/ppp/ip-down finished (pid 5392), status = 0x0
sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x1e8e435f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <auth chap MS-v2> <magic 0x7ec1462c>
<pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP ConfRej id=0x0 <callback CBCP> <mrru 1614>]
rcvd [LCP ConfAck id=0x3 <asyncmap 0x0> <magic 0x1e8e435f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x7ec1462c>
<pcomp> <accomp> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP ConfAck id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x7ec1462c>
<pcomp> <accomp> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP EchoReq id=0x0 magic=0x1e8e435f]
rcvd [CHAP Challenge id=0x0 <d010d5961c193e999ead0e1378dcde9b>, name =
"MEETING"]
sent [CHAP Response id=0x0
<ed2799fe1275141110d2d202788e5586000000000000000088a88b9ca353d461dd7d41cdafd
dc3eb2eab755736f3caea00>, name = "VPN_User"]
rcvd [LCP EchoRep id=0x0 magic=0x7ec1462c]
rcvd [CHAP Success id=0x0 "S=0DEEFDEB6CA8CD6645681D74E977C3FADCC42F54"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x3 <mppe +H -M +S -L -D +C>]
sent [CCP ConfNak id=0x3 <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x4 <addr 172.16.0.10>]
sent [IPCP TermAck id=0x4]
rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x5 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x5 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 192.168.0.112>]
rcvd [IPCP ConfRej id=0x3 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x4 <addr 192.168.0.112>]
rcvd [IPCP ConfAck id=0x4 <addr 192.168.0.112>]
rcvd [IPCP ConfReq id=0x6 <addr 172.16.0.10>]
sent [IPCP ConfAck id=0x6 <addr 172.16.0.10>]
local  IP address 192.168.0.112
remote IP address 172.16.0.10
Script /etc/ppp/ip-up started (pid 5528)
Script /etc/ppp/ip-up finished (pid 5528), status = 0x0
Script pptp meeting.myserver.org --nolaunchpppd finished (pid 5399), status
= 0x0
Modem hangup
Connect time 1.5 minutes.
Sent 0 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 5878)
MPPE disabled
sent [LCP TermReq id=0x4 "MPPE disabled"]
Connection terminated.
using channel 111
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
Script /etc/ppp/ip-down finished (pid 5878), status = 0x0
sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x6a39b47f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <auth chap MS-v2> <magic 0x16533a84>
<pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP ConfRej id=0x0 <callback CBCP> <mrru 1614>]
rcvd [LCP ConfAck id=0x5 <asyncmap 0x0> <magic 0x6a39b47f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x16533a84>
<pcomp> <accomp> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP ConfAck id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x16533a84>
<pcomp> <accomp> <endpoint
[local:bd.40.6b.c8.dd.83.44.66.bd.ba.31.8b.a9.27.9d.70.00.00.00.00]>]
sent [LCP EchoReq id=0x0 magic=0x6a39b47f]
rcvd [CHAP Challenge id=0x0 <960682a8678b525aef41e973ecf61de6>, name =
"MEETING"]
sent [CHAP Response id=0x0
<cef58513248e19a03e07daa2c4aaf8f4000000000000000049e675d5de847b7fa24a24101f5
10ba045751575c413a8c500>, name = "VPN_User"]
rcvd [LCP EchoRep id=0x0 magic=0x16533a84]
rcvd [CHAP Success id=0x0 "S=4D51138C80D8C6A1F8AF8318C9FA1AAC13B0A837"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x3 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x3 <mppe +H -M +S -L -D +C>]
sent [CCP ConfNak id=0x3 <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x4 <addr 172.16.0.10>]
sent [IPCP TermAck id=0x4]
rcvd [CCP ConfAck id=0x3 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x5 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x5 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x5 <compress VJ 0f 01> <addr 192.168.0.112>]
rcvd [IPCP ConfRej id=0x5 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x6 <addr 192.168.0.112>]
rcvd [IPCP ConfAck id=0x6 <addr 192.168.0.112>]
rcvd [IPCP ConfReq id=0x6 <addr 172.16.0.10>]
sent [IPCP ConfAck id=0x6 <addr 172.16.0.10>]
local  IP address 192.168.0.112
remote IP address 172.16.0.10
Script /etc/ppp/ip-up started (pid 5895)
Script /etc/ppp/ip-up finished (pid 5895), status = 0x0

Re: [pptp-devel] Segfault in pptpcm

[James C. <qu...@la...>]

On Tue, Apr 14, 2015 at 11:34:59AM +0200, Lorenzo Maurizi - C.S.I.A. UniMC wrote:
> Dear all,
> I'm new here and I've just signed up to the mailing list to report a problem
> I am facing with pptpclient.
> 
> My setup is debian 7 Wheezy with pptp-linux package installed (1.7.2-7
> version)
> The ppp package installed for dependency is 2.4.5-5.1+deb7u1
> The counterpart of the connection is a Windows Server 2012 R2 with a simple
> incoming connection enabled (not RRAS). The connection from another windows
> 8.1 client is working without problems.
> 
> The problem is that connection drops after one minute and a half for a
> segfault in pptpcm module. As I made the connection persistent, the tunnel
> restores, but with the same error after the same amount of time.
> Moreover, in that 1.5 minutes window, I can't route any traffic inside the
> tunnel, despite I put a rule creating the route upon connection.
> 
> Here is the relevant part of the /var/log/messages file:
> 
> Apr 14 11:26:47 oldportal2 pppd[62659]: Using interface ppp0
> Apr 14 11:26:47 oldportal2 pppd[62659]: Connect: ppp0 <--> /dev/pts/2
> Apr 14 11:26:49 oldportal2 pppd[62659]: CHAP authentication succeeded
> Apr 14 11:26:49 oldportal2 pppd[62659]: MPPE 128-bit stateless compression
> enabled
> Apr 14 11:26:51 oldportal2 pppd[62659]: local  IP address 192.168.0.112
> Apr 14 11:26:51 oldportal2 pppd[62659]: remote IP address 172.16.0.10
> Apr 14 11:28:31 oldportal2 pppd[62659]: Modem hangup

This hangup is the critical issue.  Please enable debug logging and
give us another log to look at.

http://pptpclient.sourceforge.net/howto-diagnosis.phtml#debug

> Apr 14 11:28:31 oldportal2 kernel: [412887.322010] pptpcm[62669]: segfault
> at 7ffc9d9a42d0 ip 0000000000405634 sp 00007ffc9d645390 error 4 in
> pptp[400000+10000]

This is incidental, and probably fixed by patch "vector: remove
clobbered heap" ca29b846ccb924df388a1d396a25325c32b2e346, please check
that it has been applied.

Debian 1.7.2-7 doesn't include it.

> Apr 14 11:28:31 oldportal2 pppd[62659]: Connect time 1.7 minutes.
> Apr 14 11:28:31 oldportal2 pppd[62659]: Sent 0 bytes, received 0 bytes.
> Apr 14 11:28:31 oldportal2 pppd[62659]: Connection terminated.
> 
> This block of lines is then repeated until I "poff" the pptp connection.
> 
> What can I do to obtain correct operation of the PPTP tunnel?
> Thanks in advance.
> 
> Lorenzo

-- 
James Cameron
http://quozl.linux.org.au/

[pptp-devel] Segfault in pptpcm

[Lorenzo M. - C.S.I.A. U. <lor...@un...>]

Dear all,
I'm new here and I've just signed up to the mailing list to report a problem
I am facing with pptpclient.

My setup is debian 7 Wheezy with pptp-linux package installed (1.7.2-7
version)
The ppp package installed for dependency is 2.4.5-5.1+deb7u1
The counterpart of the connection is a Windows Server 2012 R2 with a simple
incoming connection enabled (not RRAS). The connection from another windows
8.1 client is working without problems.

The problem is that connection drops after one minute and a half for a
segfault in pptpcm module. As I made the connection persistent, the tunnel
restores, but with the same error after the same amount of time.
Moreover, in that 1.5 minutes window, I can't route any traffic inside the
tunnel, despite I put a rule creating the route upon connection.

Here is the relevant part of the /var/log/messages file:

Apr 14 11:26:47 oldportal2 pppd[62659]: Using interface ppp0
Apr 14 11:26:47 oldportal2 pppd[62659]: Connect: ppp0 <--> /dev/pts/2
Apr 14 11:26:49 oldportal2 pppd[62659]: CHAP authentication succeeded
Apr 14 11:26:49 oldportal2 pppd[62659]: MPPE 128-bit stateless compression
enabled
Apr 14 11:26:51 oldportal2 pppd[62659]: local  IP address 192.168.0.112
Apr 14 11:26:51 oldportal2 pppd[62659]: remote IP address 172.16.0.10
Apr 14 11:28:31 oldportal2 pppd[62659]: Modem hangup
Apr 14 11:28:31 oldportal2 kernel: [412887.322010] pptpcm[62669]: segfault
at 7ffc9d9a42d0 ip 0000000000405634 sp 00007ffc9d645390 error 4 in
pptp[400000+10000]
Apr 14 11:28:31 oldportal2 pppd[62659]: Connect time 1.7 minutes.
Apr 14 11:28:31 oldportal2 pppd[62659]: Sent 0 bytes, received 0 bytes.
Apr 14 11:28:31 oldportal2 pppd[62659]: Connection terminated.

This block of lines is then repeated until I "poff" the pptp connection.

What can I do to obtain correct operation of the PPTP tunnel?
Thanks in advance.

Lorenzo

Re: [pptp-devel] Window handling patch

[Brian S. <br...@Aw...>]

Hi,

By "buffering" I mean the pqueue buffering.  I've set the window size to
3000 locally (with --window 3000 on the command line), and that seems
to work fine, albeit opening up a larger window for attacks.

This is what the original problem looked like:

Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:411]: accepting packet 4857605  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:411]: accepting packet 4857606  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:411]: accepting packet 4857607  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857631 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857632 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857633 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857634 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857635 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857636 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857637 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857675 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857711 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857712 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857732 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857871 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca log[decaps_gre:pptp_gre.c:430]: buffering packet 4857875 (expecting 4857608, lost or reordered)  
Feb 7 05:32:12 gw pptp[31549]: ca warn[decaps_gre:pptp_gre.c:442]: discarding bogus packet 4857909 (expecting 4857608)  
Feb 7 05:32:12 gw pptp[31549]: ca warn[decaps_gre:pptp_gre.c:442]: discarding bogus packet 4857910 (expecting 4857608)  
Feb 7 05:32:12 gw pptp[31549]: ca warn[decaps_gre:pptp_gre.c:442]: discarding bogus packet 4857915 (expecting 4857608)  

After that, everything was considered bogus.  When the code looks at the
current pqueue buffer, it continues to buffer data rather than discarding,
so a value of 300 would have been sufficient with the above loss and the
proposed patch.

> On Feb 8, 2015, at 11:20 PM, James Cameron <qu...@la...> wrote:
> 
> Thanks, that's interesting.
> 
> Where is the buffering happening?
> 
> What value for --window worked for you?
> 
> On Sat, Feb 07, 2015 at 09:55:25PM -0800, Brian Somers wrote:
>> Hi,
>> 
>> I've been having difficulties using the pptp software under FreeBSD,
>> and it appears that it might handle the MISSING_WINDOW stuff better
>> in two ways;
>> 
>> 1. For fast links, when a scheduling "glitch" happens (this is a
>> different bug in FreeBSD-10), we can drop lots of GRE traffic.
>> 
>> The MISSING_WINDOW value should really be configurable so that
>> it can be set to a higher number for faster links.
>> 
>> 2. When pptp calculates whether the packet seq from read() is within
>> MISSING_WINDOW of seq_recv, it doesn't take into account any
>> buffered packets.  This magnifies the glitch effect, so, if for
>> example last_seq is 100 and we missed seq 101 and have seq 102-399
>> buffered, we discard seq 400 as bogus and the link essentially
>> dies -- everything's bogus after that.  We should really take
>> into account buffered data when doing the calculation.
>> 
>> Anyway, the attached patch seems to make things better for me.
>> 
>> Comments?
>> 
>> --
>> Brian
> 
> -- 
> James Cameron
> http://quozl.linux.org.au/
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> pptpclient-devel mailing list
> ppt...@li...
> https://lists.sourceforge.net/lists/listinfo/pptpclient-devel

--
Brian

Re: [pptp-devel] Window handling patch

[James C. <qu...@la...>]

Thanks, that's interesting.

Where is the buffering happening?

What value for --window worked for you?

On Sat, Feb 07, 2015 at 09:55:25PM -0800, Brian Somers wrote:
> Hi,
> 
> I've been having difficulties using the pptp software under FreeBSD,
> and it appears that it might handle the MISSING_WINDOW stuff better
> in two ways;
> 
> 1. For fast links, when a scheduling "glitch" happens (this is a
>    different bug in FreeBSD-10), we can drop lots of GRE traffic.
> 
>    The MISSING_WINDOW value should really be configurable so that
>    it can be set to a higher number for faster links.
> 
> 2. When pptp calculates whether the packet seq from read() is within
>    MISSING_WINDOW of seq_recv, it doesn't take into account any
>    buffered packets.  This magnifies the glitch effect, so, if for
>    example last_seq is 100 and we missed seq 101 and have seq 102-399
>    buffered, we discard seq 400 as bogus and the link essentially
>    dies -- everything's bogus after that.  We should really take
>    into account buffered data when doing the calculation.
> 
> Anyway, the attached patch seems to make things better for me.
> 
> Comments?
> 
> --
> Brian

-- 
James Cameron
http://quozl.linux.org.au/

[pptp-devel] Window handling patch

[Brian S. <br...@Aw...>]

Hi,

I've been having difficulties using the pptp software under FreeBSD,
and it appears that it might handle the MISSING_WINDOW stuff better
in two ways;

1. For fast links, when a scheduling "glitch" happens (this is a
   different bug in FreeBSD-10), we can drop lots of GRE traffic.

   The MISSING_WINDOW value should really be configurable so that
   it can be set to a higher number for faster links.

2. When pptp calculates whether the packet seq from read() is within
   MISSING_WINDOW of seq_recv, it doesn't take into account any
   buffered packets.  This magnifies the glitch effect, so, if for
   example last_seq is 100 and we missed seq 101 and have seq 102-399
   buffered, we discard seq 400 as bogus and the link essentially
   dies -- everything's bogus after that.  We should really take
   into account buffered data when doing the calculation.

Anyway, the attached patch seems to make things better for me.

Comments?

--
Brian



diff -ru pptp-1.8.0.orig/pptp.8 pptp-1.8.0/pptp.8
--- pptp-1.8.0.orig/pptp.8	2013-10-23 01:10:46.000000000 -0700
+++ pptp-1.8.0/pptp.8	2015-02-07 08:26:54.115321063 -0800
@@ -119,6 +119,10 @@
 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.
 
+.TP
+.B \-\-window <n>
+the largest gap in packet sequences to allow before considering the
+received packet to be bogus.
 
 .SH "ROUTING"
 When PPTP is used in conjunction with a default route on top of the
diff -ru pptp-1.8.0.orig/pptp.c pptp-1.8.0/pptp.c
--- pptp-1.8.0.orig/pptp.c	2013-10-23 01:10:46.000000000 -0700
+++ pptp-1.8.0/pptp.c	2015-02-07 08:02:26.041924752 -0800
@@ -79,6 +79,7 @@
 int disable_buffer = 0;
 int test_type = 0;
 int test_rate = 100;
+int missing_window = MISSING_WINDOW;
 
 struct in_addr get_ip_address(char *name);
 int open_callmgr(struct in_addr inetaddr, char *phonenr, int argc,char **argv,char **envp, int pty_fd, int gre_fd);
@@ -126,6 +127,7 @@
             "  --loglevel <level>	Sets the debugging level (0=low, 1=default, 2=high)\n"
             "  --test-type <type>	Damage the packet stream by reordering\n"
             "  --test-rate <n>		Do the test every n packets\n",
+            "  --window <n>		Assume data is bad/spoofed if more than <n> ahead\n",
 
             version, progname, progname);
     log("%s called with wrong arguments, program not started.", progname);
@@ -221,6 +223,7 @@
 	    {"test-rate", 1, 0, 0},
 	    {"rtmark", 1, 0, 0},
 	    {"nohostroute", 0, 0, 0},
+	    {"window", 1, 0, 0},
             {0, 0, 0, 0}
         };
         int option_index = 0;
@@ -309,6 +312,8 @@
 #endif
 		} else if (option_index == 16) { /* --nohostroute */
 		    nohostroute = 1;
+                } else if (option_index == 17) { /* --window */
+		    missing_window = atoi(optarg);
                 }
                 break;
             case '?': /* unrecognised option */
diff -ru pptp-1.8.0.orig/pptp_gre.c pptp-1.8.0/pptp_gre.c
--- pptp-1.8.0.orig/pptp_gre.c	2013-10-23 01:10:46.000000000 -0700
+++ pptp-1.8.0/pptp_gre.c	2015-02-07 08:21:55.840347197 -0800
@@ -341,6 +341,7 @@
     static int first = 1;
     unsigned int headersize;
     unsigned int payload_len;
+    pqueue_t *tail;
     u_int32_t seq;
 
     if ((status = read (fd, buffer, sizeof(buffer))) <= 0) {
@@ -421,8 +422,11 @@
                 seq, seq_recv + 1);
         stats.rx_underwin++;
     /* sequence number too high, is it reasonably close? */
-    } else if ( seq < seq_recv + MISSING_WINDOW ||
-                WRAPPED(seq, seq_recv + MISSING_WINDOW) ) {
+    } else if ( seq < seq_recv + missing_window ||
+                WRAPPED(seq, seq_recv + missing_window) ||
+                ((tail = pqueue_tail()) != NULL &&
+                 (seq < tail->seq + missing_window ||
+                  WRAPPED(seq, tail->seq + missing_window))) ) {
 	stats.rx_buffered++;
         if ( log_level >= 1 )
             log("%s packet %d (expecting %d, lost or reordered)",
diff -ru pptp-1.8.0.orig/pptp_gre.h pptp-1.8.0/pptp_gre.h
--- pptp-1.8.0.orig/pptp_gre.h	2013-10-23 01:10:46.000000000 -0700
+++ pptp-1.8.0/pptp_gre.h	2015-02-07 08:02:48.858713011 -0800
@@ -13,6 +13,7 @@
 
 extern int syncppp;
 extern int disable_buffer;
+extern int missing_window;
 
 typedef struct pack_track {
   uint32_t seq;       // seq no of this tracked packet
diff -ru pptp-1.8.0.orig/pqueue.c pptp-1.8.0/pqueue.c
--- pptp-1.8.0.orig/pqueue.c	2013-10-23 01:10:46.000000000 -0700
+++ pptp-1.8.0/pqueue.c	2015-02-07 08:18:07.671355623 -0800
@@ -223,6 +223,12 @@
 
 
 
+pqueue_t *pqueue_tail (void) {
+  return pq_tail;
+}
+
+
+
 int pqueue_expiry_time (pqueue_t *entry) {
   struct timeval tv;
   int expiry_time;

Re: [pptp-devel] PPTP Client and Dynamic IP

[James C. <qu...@la...>]

This has nothing to do with pptp.

So there is no way to fix it in pptp.

pptp relies on gethostbyname to get the IP address using server host
name.

You should figure out why gethostbyname is returning stale data after
the IP changes.

Examine your name resolver configuration; check if DD-WRT is using
dnsmasq, and ensure caches are reasonable.  Test with host lookup on
DD-WRT shell.

If, because of caching, you find DNS unreliable, then use another means
to find the new IP address.  One such method is to send the IP address
to a trusted third-party site with constant IP, such as a shell
account on a cloud server.

Another method may be to have the pptp server remember the client IP
address, and every minute send a UDP packet to the client outside the
tunnel.  That way, when the server IP address changes, the client can
detect it.  This is not part of pptp.

-- 
James Cameron
http://quozl.linux.org.au/

[pptp-devel] PPTP Client and Dynamic IP

[Tobias <tob...@ms...>]

Hi.

I am using PPTP Client with DD-WRT to make a site-to-site VPN between two houses.

My problem is that i don't have static IP, then, when the PPTP Server change his IP (domain provided by free no-ip service), PPTP Client don't recognize and still try to connect to the old IP. Even if the no-ip service already changed the domain name to the new ip.

There is no possibility to improve it to fix that or make some option to the option file to detect that?

Thanks.
 		 	   		  

Re: [pptp-devel] patch: fix call structure initialization

[Jaroslav S. <jsk...@re...>]

> A possible cause is identified.
> 
> Running vector_test under valgrind showed heap corruption in
> vector_remove, for which I've pushed a patch to git.  Now, valgrind
> reports no problems with vector_test.
> 
> Please include the patch in your packaging.  It is attached.
> 
Thanks, patch applied.

I also ran static analysis on the resulting code. It found one
minor and unrelated "use after free" problem. Possible patch is
attached.

Also I am going to close all "possible dupe" bug reports and let's
see what happen

thanks & regards

Jaroslav

Re: [pptp-devel] patch: fix call structure initialization

[James C. <qu...@la...>]

+CC C. Scott Ananian, original author.

On Wed, Jan 21, 2015 at 05:45:53AM -0500, Jaroslav Skarvada wrote:
> Hi James,
> 
> thanks for your analysis.
> 
> ----- Original Message -----
> > On Tue, Jan 20, 2015 at 10:22:50AM -0500, Jaroslav Skarvada wrote:
> > > I received the following crash report [1]. I think the problem
> > > is in improper initialization of the call structure,
> > > i.e. there can be random number in the call vector size.
> > 
> > Thanks.  But I'm not so sure.
> > 
> Well, I was too fast with patching :)
> 
> > Yes, you have evidence of random number in vector struct member size.
> > Your patch only affects the malloc of a PPTP_CALL, not the malloc of a
> > vector.  The malloc of a vector is in vector_create.  size is
> > explicitly initialised.  size is a count.
> > 
> > I've looked at the backtrace:
> > https://bugzilla.redhat.com/attachment.cgi?id=981451
> > 
> > In binary_search the local variable r is corrupt, the value is not
> > reasonable as a count, and this will have come from conn->call.
> > 
> > conn->call is set to return value of vector_create().
> > 
> > conn->call is not changed once set.
> > 
> > Either conn->call or vector->size have been corrupted.
> > 
> All agree.

A possible cause is identified.

Running vector_test under valgrind showed heap corruption in
vector_remove, for which I've pushed a patch to git.  Now, valgrind
reports no problems with vector_test.

Please include the patch in your packaging.  It is attached.

> > Both conn and call at pptp_call_destroy are addresses in [heap]
> > according to the maps:
> > https://bugzilla.redhat.com/attachment.cgi?id=981458
> > 
> > You have evidence of heap corruption, cause unknown.
> >
> > Suggest adding code to detect corrupt size, dump the vector, the call,
> > and the connection.
> > 
> All suggestions are welcome. No problem to add anything to debug
> the problem in Fedora testing branch.

I've no suggestion for this now.

> > Suggest looking for correlating evidence of remote attack.
> > 
> Maybe, but it seems to be quite common for undetected attack:
> https://retrace.fedoraproject.org/faf/reports/4805/
> 
> Fedora 20: 74 reports
> Fedora 19: 47 reports
> Fedora 18: 40 reports

No, I would call that not common enough.  Where heap corruption is
certain, the problem should be reported far more.

Looking at the uses of vector_remove in pptpctrl.c and pptp_callmgr.c,
the heap corruption is unlikely to occur unless;

1.  a memory allocation fails causing a retry, or

2.  a connection fails causing a retry.

So this probably explains the low frequency of problem.

> > > The attached patch should fix the problem
> > 
> > Given above, nak.  But thanks for looking into it.
> > 
> > I'm curious; does your patch actually fix the problem?
> > 
> I don't know, but probably not. I wasn't able to reproduce the problem,
> reopened the bug report

If you'd like to reproduce, you might try setting up for a malloc fail
or connection fail.

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] patch: fix call structure initialization

[Jaroslav S. <jsk...@re...>]

Hi James,

thanks for your analysis.

----- Original Message -----
> On Tue, Jan 20, 2015 at 10:22:50AM -0500, Jaroslav Skarvada wrote:
> > I received the following crash report [1]. I think the problem
> > is in improper initialization of the call structure,
> > i.e. there can be random number in the call vector size.
> 
> Thanks.  But I'm not so sure.
> 
Well, I was too fast with patching :)

> Yes, you have evidence of random number in vector struct member size.
> Your patch only affects the malloc of a PPTP_CALL, not the malloc of a
> vector.  The malloc of a vector is in vector_create.  size is
> explicitly initialised.  size is a count.
> 
> I've looked at the backtrace:
> https://bugzilla.redhat.com/attachment.cgi?id=981451
> 
> In binary_search the local variable r is corrupt, the value is not
> reasonable as a count, and this will have come from conn->call.
> 
> conn->call is set to return value of vector_create().
> 
> conn->call is not changed once set.
> 
> Either conn->call or vector->size have been corrupted.
> 
All agree.

> Both conn and call at pptp_call_destroy are addresses in [heap]
> according to the maps:
> https://bugzilla.redhat.com/attachment.cgi?id=981458
> 
> You have evidence of heap corruption, cause unknown.
>
> Suggest adding code to detect corrupt size, dump the vector, the call,
> and the connection.
> 
All suggestions are welcome. No problem to add anything to debug
the problem in Fedora testing branch.

> Suggest looking for correlating evidence of remote attack.
> 
Maybe, but it seems to be quite common for undetected attack:
https://retrace.fedoraproject.org/faf/reports/4805/

Fedora 20: 74 reports
Fedora 19: 47 reports
Fedora 18: 40 reports

> > The attached patch should fix the problem
> 
> Given above, nak.  But thanks for looking into it.
> 
> I'm curious; does your patch actually fix the problem?
> 
I don't know, but probably not. I wasn't able to reproduce the problem,
reopened the bug report

thanks & regards

Jaroslav

Re: [pptp-devel] patch: fix call structure initialization

[James C. <qu...@la...>]

On Tue, Jan 20, 2015 at 10:22:50AM -0500, Jaroslav Skarvada wrote:
> I received the following crash report [1]. I think the problem
> is in improper initialization of the call structure,
> i.e. there can be random number in the call vector size.

Thanks.  But I'm not so sure.

Yes, you have evidence of random number in vector struct member size.
Your patch only affects the malloc of a PPTP_CALL, not the malloc of a
vector.  The malloc of a vector is in vector_create.  size is
explicitly initialised.  size is a count.

I've looked at the backtrace:
https://bugzilla.redhat.com/attachment.cgi?id=981451

In binary_search the local variable r is corrupt, the value is not
reasonable as a count, and this will have come from conn->call.

conn->call is set to return value of vector_create().

conn->call is not changed once set.

Either conn->call or vector->size have been corrupted.

Both conn and call at pptp_call_destroy are addresses in [heap]
according to the maps:
https://bugzilla.redhat.com/attachment.cgi?id=981458

You have evidence of heap corruption, cause unknown.

Suggest adding code to detect corrupt size, dump the vector, the call,
and the connection.

Suggest looking for correlating evidence of remote attack.

> The attached patch should fix the problem

Given above, nak.  But thanks for looking into it.

I'm curious; does your patch actually fix the problem?

-- 
James Cameron
http://quozl.linux.org.au/

Re: [pptp-devel] patch: fix call structure initialization

[Jaroslav S. <jsk...@re...>]

----- Original Message -----
> On Tue, Jan 20, 2015 at 10:22 AM, Jaroslav Skarvada <jsk...@re...>
> wrote:
> 
> > Jaroslav
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1183627
> 
> Unfortunately your reference isn't useful to us, because of Red Hat
> privacy policy.
> 
> ...
> You are not authorized to access bug #1183627.
> 
> Most likely the bug has been restricted for internal development
> processes and we cannot grant access.
> ...
> 
> Perhaps you could convince RH management to clone bugs in Bugzilla,
> with the customer-private information removed from the clone, so that
> RH can properly collaborate with upstream on issues.
> 

Ups, sorry, I haven't noticed :)

It seems the automatic Fedora crash reports are now filled under Fedora
contributors group to protect possible sensitive data from reporters.

I made it public, so it should be accessible now

thanks & regards

Jaroslav

[pptp-devel] patch: fix call structure initialization

[Jaroslav S. <jsk...@re...>]

Hi,

I received the following crash report [1]. I think the problem
is in improper initialization of the call structure,
i.e. there can be random number in the call vector size.
The attached patch should fix the problem

thanks & regards

Jaroslav

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1183627

Re: [pptp-devel] Issue only with kernel 3.18

[Jan N. <jn...@hz...>]

Zitat von Charlie Brady <cha...@mi...>:

> It's not showing in your logs, but you should be seeing "LCP: timeout
> sending Config-Requests" - the logs show no response to
> Config-Requests.
Thank you Charlie, I verified using tcpdump and it turns out to be a  
difference in the netfilter connection tracking code between 3.17 and  
3.18, see my post here:  
http://marc.info/?l=netfilter&m=142167601625689&w=2

Jan

[pptp-devel] Issue only with kernel 3.18

[Jan N. <jn...@hz...>]

Hi list,

despite having the same kernel-config, I cannot connect to a certain  
VPN using kernel 3.18. The very same settings work flawlessly with  
kernel 3.17. This is the case using either network manager, or trying  
to connect manually.

Can someone give me advice as to what may cause this?

Kernel configs:
3.17: https://gist.github.com/2974aa489986d6fc26e3
3.18: https://gist.github.com/8f0c4d4b52cd63bbc053

Debug log created with kernel 3.18:
https://gist.github.com/4bbc18d95d44a0bf2db1

Perhaps you can give me some advice that might help the kernel devs  
spot the issue.

Regards
jan