killing a pptp tunnel with a single ping

killing a pptp tunnel with a single ping

[Marco d'Itri]

After running this command from a remote host:

ping -M dont $MY_TUNNEL_IP -c 1 -s 1496

this was logged by the kernel:

Mar 25 00:13:13 wonderland kernel: mppe_decompress[1]: osize too small! (have: 1504 need: 1505)

and traffic over the tunnel stopped flowing. pppd logged this:

Mar 25 00:13:13 wonderland pppd[23476]: read /dev/ppp: Value too large for defined data type
Mar 25 00:13:13 wonderland pppd[23476]: rcvd [Compressed data] 90 4b a1 a3 07 58 cc 64 ...
Mar 25 00:13:13 wonderland pppd[23476]: sent [CCP ResetReq id=0x2]
Mar 25 00:13:32 wonderland pppd[23476]: rcvd [Compressed data] 90 4c c9 fd 23 23 04 88 ...
Mar 25 00:13:32 wonderland pppd[23476]: sent [CCP ResetReq id=0x3]
Mar 25 00:13:44 wonderland pppd[23476]: read /dev/ppp: Value too large for defined data type
Mar 25 00:13:44 wonderland pppd[23476]: rcvd [Compressed data] 90 4e e9 ae 40 72 3e ac ...
Mar 25 00:13:44 wonderland pppd[23476]: sent [CCP ResetReq id=0x4]
Mar 25 00:13:54 wonderland pppd[23476]: read /dev/ppp: Value too large for defined data type
Mar 25 00:14:03 wonderland pppd[23476]: rcvd [Compressed data] 90 50 f3 43 59 c2 d4 67 ...
Mar 25 00:14:03 wonderland pppd[23476]: sent [CCP ResetReq id=0x5]
Mar 25 00:14:05 wonderland pppd[23476]: rcvd [Compressed data] 90 51 8f 07 e1 73 3a ca ...
Mar 25 00:14:05 wonderland pppd[23476]: sent [CCP ResetReq id=0x6]
Mar 25 00:14:12 wonderland pppd[23476]: rcvd [Compressed data] 90 52 ea b4 ae ec a9 25 ...
[...]

pppd version 2.4.4b1
pptp version 1.7.0
Linux wonderland 2.6.16 #18 Mon Mar 20 19:44:13 CET 2006 i686 GNU/Linux


The other side is running 12.4(3) IOS.
No MTU is explicitly set on either side.

-- 
ciao,
Marco

Re: killing a pptp tunnel with a single ping

[Ray Van Dolson]

On Sat, Mar 25, 2006 at 12:21:28AM +0100, Marco d'Itri wrote:
> The other side is running 12.4(3) IOS.
> No MTU is explicitly set on either side.

Any reason not to explicitly set the MTU to something like 1450?  MPPE has
some overhead so it'd be nice to see that 1496 packet get fragmented.

Ray

Re: killing a pptp tunnel with a single ping

[James Cameron]

I've tried but failed to reproduce this.  Could you obtain and post the
pppd debug dump log showing the negotiation of the tunnel?  That will
help to narrow the scope.

I've also done a test that excludes pptp, by using pppd over ssh, such
as:

# echo "test test test *" >> /etc/ppp/chap-secrets
# ssh peer 'echo "test test test *" >> /etc/ppp/chap-secrets'
# pppd noauth silent require-mppe name test remotename test debug dump
  logfd 2 nodetach pty "ssh -t -e none peer pppd name test
  require-mschap-v2 require-mppe 10.0.5.1:10.0.5.2"

But the ping as described did nothing wrong.  2.6.16 kernel.org.

Then again, what's the -M dont?  My ping (Debian) doesn't have that.

-- 
James Cameron

Re: killing a pptp tunnel with a single ping

[Marco d'Itri]

On Mar 25, James Cameron <james.cameron@hp.com> wrote:

> I've tried but failed to reproduce this.  Could you obtain and post the
> pppd debug dump log showing the negotiation of the tunnel?  That will
> help to narrow the scope.


pppd 2.4.4b1 started by root, uid 0
using channel 15
Using interface ppp1
Connect: ppp1 <--> /dev/pts/14
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xab0eb1ff> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <auth chap MS-v2> <magic 0xbcb7d017>]
sent [LCP ConfAck id=0x1 <auth chap MS-v2> <magic 0xbcb7d017>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xab0eb1ff> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xab0eb1ff]
rcvd [CHAP Challenge id=0x1 
sent [CHAP Response id=0x1 
rcvd [LCP EchoRep id=0x0 magic=0xbcb7d017]
rcvd [CHAP Success id=0x1 
CHAP authentication succeeded
kernel does not support PPP filtering
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x1 <addr 213.254.>]
sent [IPCP TermAck id=0x1]
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [IPV6CP ConfReq id=0x1 <addr fe80::0210:7bff:fecf:37c0>]
sent [IPV6CP TermAck id=0x1]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 213.254.>]
sent [IPV6CP ConfReq id=0x1 <addr fe80::fdd2:3496:581b:1b03>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 213.254.>]
rcvd [IPV6CP ConfAck id=0x1 <addr fe80::fdd2:3496:581b:1b03>]
rcvd [IPCP ConfAck id=0x2 <addr 213.254.>]
rcvd [LCP EchoReq id=0x1 magic=0xbcb7d017 ab 0e b1 ff]
sent [LCP EchoRep id=0x1 magic=0xab0eb1ff ab 0e b1 ff]
rcvd [IPCP ConfReq id=0x2 <addr 213.254.>]
sent [IPCP ConfAck id=0x2 <addr 213.254.>]
local  IP address 213.254.
remote IP address 213.254.
Script /etc/ppp/ip-up started (pid 23477)
Script /etc/ppp/ip-up finished (pid 23477), status = 0x0
rcvd [IPV6CP ConfReq id=0x2 <addr fe80::0210:7bff:fecf:37c0>]
sent [IPV6CP ConfAck id=0x2 <addr fe80::0210:7bff:fecf:37c0>]
local  LL address fe80::fdd2:3496:581b:1b03
remote LL address fe80::0210:7bff:fecf:37c0
Script /etc/ppp/ipv6-up started (pid 23478)
Script /etc/ppp/ipv6-up finished (pid 23478), status = 0x0
read /dev/ppp: Value too large for defined data type
rcvd [Compressed data] 90 4b a1 a3 07 58 cc 64 ...
sent [CCP ResetReq id=0x2]

I verified that if MPPE is enabled I can send pings up to 1499 bytes,
but a 1500 bytes ping (ping -M dont -s 1472) will reliably kill the
tunnel.

> Then again, what's the -M dont?  My ping (Debian) doesn't have that.
It requests not setting the DF flag. Actually my goal was to *set* it
(ping -M do) because I wanted to measure the tunnel MTU, but I used the
wrong flag.
If you do not use it then you may not be able to send large packets.
I recommend you replace the old netkit-ping with iputils-ping.

But my strategy does not work: after creating a new tunnel without MPPE
the packets are fragmented by PPP anyway because the link MTU is 1500 on
both sides.

This is the reason for me not initially setting the tunnel MTU, I
did not want to compute the overhead myself. I think that a section
in your PPTP FAQ explaining how to do this would be very useful.

-- 
ciao,
Marco

Re: killing a pptp tunnel with a single ping

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Mar 25, Marco d'Itri <md@Linux.IT> wrote:

> This is the reason for me not initially setting the tunnel MTU, I
> did not want to compute the overhead myself. I think that a section
> in your PPTP FAQ explaining how to do this would be very useful.
I tried setting "mtu 1456" on the cisco side and now large pings do not
kill the tunnel anymore even with MPPE enabled, but I do not understand
why pppd on the other side sets the tunnel uses 1452 as the link MTU.
Only the MRU is negotiated:

rcvd [LCP ConfReq id=0x1 <mru 1456> <auth chap MS-v2> <magic 0xbf448cfd>]
sent [LCP ConfAck id=0x1 <mru 1456> <auth chap MS-v2> <magic 0xbf448cfd>]

How can I fix this without forcing the MTU on the Linux side?

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]