Incompatability between pptpd, pptp-linux, kernel-patch-mppe and kernel-source-2.4.9
Long-ish report with a few questions, please bear with me...
I was upgrading a sid machine I use as a vpn gateway from kernel 2.2.17 to
2.4.9. Poptop stopped working with pptp-linux from the machine that's the
other end of the pptp tunnel (sid, kernel 2.2.17).
Now it's a very convoluted story which is why I really don't know what
package to report a bug against.
Perhaps a little table will help:
Server (poptop)
Client | linux-2.2 | linux-2.4.7 | linux-2.4.9
-------------+-----------+-------------+-------------
linux-2.2.19 | works | works | FAILS(1)
linux-2.4.7 | works | works | FAILS(1)
linux-2.4.9 | works | works | FAILS(2)
win2k | works | works | works
(1) server gets Modem hangup, client doesn't - it retries until it fails.
(2) both server and client get Modem hangup. Client gets SIGHUP and
realises it should stop trying.
Note that I'm also testing with a win2k client "dialling in" and it always
works, which is annoying (and I certainly won't be telling anyone about
this except the other linux admin here).
Doing a bit of tcpdumping while all this was going on leads me to the
following conclusions:
3 scenarios are important here:
1. Linux pptp client connecting to poptop on my 2.2 or 2.4.7 kernel.
2. Linux pptp-client connecting to poptop on my 2.4.9 kernel.
3. win2k connecting to poptop on my 2.4.9 kernel.
1.
Control connection established. Server tries to contact client via GRE
tunnel. Client doesn't have it open yet. Server retries and client does
have it open this time. Handshaking occurs everyone is happy. doesn't
matter what kernel version the client is running on.
2.
Control connection established. Server tries to contact client via GRE
tunnel. Client doesn't have it open yet. Server retries immediately, still
not available, aborts connection. If the client is on a 2.2 or 2.4.7
kernel, it doesn't know that the server has aborted and retries until it
reaches it's limit (usually 10). If the client is on a 2.4.9 kernel, it
realises that the server has given up and does the same.
3.
Control connection established. Server tries to contact client via GRE
tunnel. Client has gre protocol open and everything goes according to
plan.
Big question here is why does the kernel version seem to change the
behaviour of pptpd and/or pptp-client? Perhaps a change in the ipv4 code?
Perhaps a subtle timing issue?
I'm not sure if pptp-linux even opens up the gre socket. Is there a
netstat/fuser/lsof that groks arbitrary protocols(e.g. gre) and not just
tcp or udp?
The bit that makes it weird is that it look more lik pptp-linux on the
client is the component that's failing, yet its failing is dependant on
the kernel version on the server machine.
I'm not sure about kernel-2.4.8 and the linux boxen are production
machines, so I'm not going to have another downtime at such short notice
just to test it out.
And, yes, I know - use freeswan/ipsec, it's better. I'm currently testing
this out on a few machines before I migrate it to our production boxes.
I've tried multiple versions of ppp (everything from 2.4.0f upwards),
pptpd (compiled my own newer versions) and pptp-linux. The only thing that
fixes/breaks connection is the kernel version that pptpd is running on.
Any ideas which packages I should submit bug reports against?
Martin.
Reply to: