hi,
im trying to setup a pptp-server on my wrt54gs for letting some winxp-clients connect to it, but im experiencing some problems with the protocol-negotiation.

most of the time, the client is stuck while negotiating about the encryption.
pptp keeps sending lcp ConfReq messages, but the client doesnt answer. these messages look like this:

Jan  1 01:51:53 (none) kern.debug pppd[865]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x55268212> <pcomp> <accomp>]

(-> pptp aborts w/ a timeout)
maybe every 10th-20th try, negotiation is completed but pptp sends wrong (0.0.0.0) ip-addresses to the client.

i tried to clients (xp pro) and both interfaces (wlan + lan ports), but its the same on all. moreover, i can connect with the clients to my pptpd on my debian-box w/o problems, so the prob is somewhere on the wrt.
i also ran ethereal on one client and noticed the lcp-packages from the wrt arrived there, also some gre-packets were recieved & sent.

does anyone have working config-files for something like this?

i read something about a special openwrt-firmware from nico is required for his pptp-package to work, but these threads were very old (> 6 months). is that still true? or does somebody managed to run a pptpd with the rodent firmware?

my pptp-server-options:

debug
lock
logfile /tmp/pptp-server.log
refuse-pap
refuse-chap
refuse-mschap
refuse-eap
require-mschap-v2
+mppe-128
nobsdcomp
ms-wins 10.21.0.2
ms-dns 10.21.0.2
chapms-strip-domain

pptpd.conf is only:

debug
option /etc/ppp/pptp-server-options
speed 115200
stimeout 10

(defaults by nico)

there is not much information about pptpd & openwrt on the web, is nobody running this thing? oder does nobody have the problems i have?
bye
  malte

ok, now it works- not sure why
i upgraded pptpd to v1.2.3 from http://nbd.vd-s.ath.cx/openwrt/packages/ but i think the point was, that i hadnt got an "<ip>: " entry in pptp-server-options, like

debug
#logfile /tmp/pptp-server.log
172.16.1.1:
auth
name "pptp-server"
...

my fault, but im really new to all that stuff. will play around with it now, thanks for alle the great work on openwrt, im really amazed by this distro!

ookeeey, i was a little bit too enthusiastic the last time.

the problem with the lcp-timeouts persists (but like above, its possible to connect every 10th try or so).

after connecting the ip-address is passed properly causing the client to be able to surf on the internet.
however, i got problems after that causing the wrt54gs to CRASH when visiting web-sites, or even creating some traffic on a remote ssh-session (while ping & slow typing over ssh was ok).
i found out that this only happens when mppc (compression) is enabled, so i wrote "nomppc" in the options and everything works fine. (strange, but in the readme for pppd 2.4.3 it says, that mppc is proprietary and not supported anyway, although a kmod exists for that???).

so, if anyone can help me out with that lcp-timeout-problem, i would be very happy. everything is working now but its not a statisfying solution to "dial" the vpn-server several times before a connection is possible.
any ideas or hints?

Malte,

can you post the versions of firmware and packages you're trying to use ?
You seem to be running experimental, right ?

--
Nico

hi nico,
thanks for replying, i am runnig rodent's version from http://rodent.za.net/files/openwrt/ (namely openwrt-gs-code.bin). i think its different from the experimental build. (it's based on openwrt buildtree of jan 5., with linksys drivers from the 3.37.2 tree).

i tested it with
pppd v2.4.3
pptpd v1.2.3
(from http://nbd.vd-s.ath.cx/openwrt/packages/)

but tonight i downgraded to the offical packages, but no luck either. the problem is still the same. current versions are now
kmod-ppp-mppe-mppc (2.4.20-1)
ppp-radius-plugin (2.4.2-1) (not used)
ppp (2.4.2-1)
pptp-server (1.1.3-1)
kmod-ppp-async (2.4.20-1)
ip (2.0)

heres a complete log for a failed connection:

using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0xdf9f369> <pcomp> <accomp>]
LCP: timeout sending Config-Requests
Connection terminated.
using channel 10
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x2 <mru 1400> <auth chap MS-v2> <magic 0x3edf15dd> <pcomp> <accomp>]
tcflush failed: Bad file descriptor
tcsetattr: Invalid argument (line 1001)

and this is another try with the same configuration, this time it's working:

using channel 12
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x69767205> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x764b43e1> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <mru 1400> <magic 0x764b43e1> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 1400> <auth chap MS-v2> <magic 0x69767205> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x69767205]
sent [CHAP Challenge id=0xd <8528fb197d764b30a6a0b59f001ee9b6>, name = "pptp-server"]
rcvd [LCP EchoRep id=0x0 magic=0x764b43e1]
rcvd [CHAP Response id=0xd <8a73130b547e4c71e6e8d0706c6c945c000000000000000093727a590c1eac08f554d810d2ad4da0c57ef2acc2c4a69500>, name = "wallstreet"]
sent [CHAP Success id=0xd "S=3BC89AB86D30148EF04F4D22203FD654069D2440 M=Access granted"]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.1.0.2>]
rcvd [CCP ConfReq id=0x1 <mppe +H +M +S +L -D -C>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfNak id=0x1 <mppe -H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x2 <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>]
sent [IPCP ConfRej id=0x2 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 10.1.0.2>]
rcvd [CCP ConfNak id=0x1 <mppe -H -M -S -L -D -C>]
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 ConfAck id=0x3 <mppe -H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfNak id=0x4 <addr 10.21.0.12> <ms-dns1 10.21.0.2> <ms-dns3 10.21.0.2>]
rcvd [IPCP ConfAck id=0x2 <addr 10.1.0.2>]
rcvd [CCP ConfAck id=0x2 <mppe -H -M +S -L -D -C>]
MPPE 128-bit stateful compression enabled
rcvd [IPCP ConfReq id=0x5 <addr 10.21.0.12> <ms-dns1 10.21.0.2> <ms-dns3 10.21.0.2>]
sent [IPCP ConfAck id=0x5 <addr 10.21.0.12> <ms-dns1 10.21.0.2> <ms-dns3 10.21.0.2>]
found interface vlan0 for proxy arp
local  IP address 10.1.0.2
remote IP address 10.21.0.12

in the last (working) case, the windows-client sends out the lcp-confreq at first, before any lcp-packets from the wrt arrive (i saw this with ethereal). maybe the lcp-packets from the wrt make the windows-pptp stuck? i also tested the "silent" option, which prevents pppd from sending any lcp-packets. but turned out to be not working, too. (although it behaves a bit different: when the connection is established (only possible every 4th try) the thing gets stuck while checkig the password (according to windows)).

so the question is: why does windows sometimes send lcp-packets and sometimes not???
btw, it tested it today with another notebook, so i checked with three different computers (2x XP Pro, 1x XP home with SP2) and all with different wlan-adapters (also checked via cable, like mentioned above).

...and i just noticed some interesting fact: the connection seems to be possible *exactly* every 4th try. i think this "counter" must be somewhere in windows, because its independent from the wrt. i can try 2x to connect, reboot the wrt and then try another time and the try after that will succeed (scheme: fail, fail, fail, success or: fail, fail, (reboot wrt), fail, success, etc.). same thing is when connecting parallel from different computers- they all succeed on *their* own 4th connection-try. its also possible to increase this mystic-counter by executing vpn-connections to completely different servers like: (wrt)fail, (connect to different server, doesnt matter wether successful or not), (wrt)fail, (wrt)success and so on.
this is consistent with my logfile-observation above. windows behaves 3x in a passive way and initiates lcp every 4th time.
however, windows is working with my debian-pptp very well (everytime), so windows can't be the problem. i will compare my debian-pptp-debug-logs with the wrt-ones tomorrow, maybe i get a clue from that.

Malte,

the problem lies in the firmware : it was build without in-kernel MPPE/MPPC support. The patch '150-mppe-mppc-0.98.patch' found in the stable CVS tree was not built in.

You should be running experimental, right ?

--
Nico

hm, well im confused about the versions, but i am not running the "offical" experimental release, but the modified stable version from TheRodent (see above). experimental is kernel 2.4.29 afaik, my kernel is 2.4.20.
i dont think that this build is affected by the missing patch since am able to connect (but only every 4th try) with mppe-128, and additionally, the problem should also be solved if i disable mppe/mppc which is not happening.
(i would try to get experimental patched by myself but i read that pppd is broken in that release, so i wouldnt be able to run pptpd anyway)

i also tried "dd-wrt", a firmware based von sveasoft with some code from openwrt (pptpd is build-in there), and the vpn-thing works, they are using pppd 2.4.2 (like me) but pptpd 1.1.4-b4. i dont know if the whole thing is related to pptpd but my last hope is to get it working with that version, so ill try to get this version running on openwrt.

oh btw, happy easter

ok, i retried it with the dd-wrt's version of pppd, pptpd & pptpctrl, but the result is the same. connection is possible but only every 4th try...

so maybe i now really try to run experimental and recompile it with that patch... why was it not applied before? are there compatiblity-issues with the kernel oder does simply nobody needed it?

and do you know what kind of problem is behind the "broken pppd"? is it because of the missing patch or is it something else?

i'm wondering if somebody has a working solution for a pptpd on a wrt54gs 1.1 / wrt54g 2.2 (with openwrt of course)????? am i the only person in the world trying to do that?

ok, now im using the experimental build and this connection-problem seems to be gone... however, mppe-support ist not present (like you said), resulting pppd to die with a "MPPE required, but kernel has no support."-message. but pptpd without mppe works- so i have to patch this thing now...

In order to use MPPE/MPPC, you must install the following packages from nbd's experimental repository :
· kmod-crypto
· kmod-ppp
· kmod-mppe
· ppp
· pptpd

You must then load the following modules :
· arc4
· sha1
· slhc
· ppp_generic
· ppp_mppe_mppc
· ppp_async

arc4, sha1 and ppp_mppe_mppc are needed for encryption

You can then start pptpd. Please note that the pptpd package doesn't allocate IP addresses by itself, it relies on ppp for this : you must add adresses for your clients in your chap-secrets file.

Edited : fix typo on slhc and ppp_async module requirement

--
Nico

wohoooooo!! thank you thank you, it works now!!!
even without the ppp_generic-module. infact, i think it doesnt work WITH it. i first had problems, because pppd reported errors while opening its channel (no such device, or something like that), then i unloaded the ppp-generic and now it runs without.

(and there is a typo, i think: it should be slhc, not shlc, but this module isnt used anyway).

you guys rock

I'm trying to set this up as well.  Does mppe need to be compiled in the kernel....or can it be loaded as a module?  I'm using experimental precompiled binaries right now, and inserted the modules listed....but i'm getting 619 errors from the clients.  Thanks.

-Brian

I should mention that this is a 54G 2.2.

no, it worked for me with the precompiled binaries. but did you skipped the ppp_generic module? that was essential for me.

enable debugging-mode in /etc/pptp.conf and /etc/ppp/pptp-server-options (just write "debug" in the first line of the files), restart pptpd and try to reconnect, than take a look at the syslog with "logread".
you will see the reason why pppd has died- maybe an issue with the modules or wrong parameters in pptp-server-options.
(the default config-file shipped with the pptpd-package had wrong syntax on my system, statements like "require-mppe-128" were not recognized, i had to change it to "mppe-128 required").

Thanks for the help Malte.  I'm closer to getting it working.  Right now, this is the error the pptpd server spits when a client connects

OpenWrt:/etc# logread -f
an  1 03:40:06 (none) syslog.info -- MARK --
an  1 03:40:07 (none) kern.info pptpd[622]: CTRL: Client 192.168.1.2 control
nection started
an  1 03:40:07 (none) kern.info pptpd[622]: CTRL: Starting call (launching p
 opening GRE)
an  1 03:40:07 (none) kern.notice pppd[623]: pppd 2.4.3 started by (unknown)
d 0
an  1 03:40:07 (none) kern.err pppd[623]: Couldn't set tty to PPP discipline
valid argument
an  1 03:40:08 (none) kern.info pppd[623]: Exit.
an  1 03:40:08 (none) kern.err pptpd[622]: GRE: read(fd=7,buffer=10000530,le
96) from PTY failed: status = -1 error = Input/output error, usually caused
nexpected termination of pppd, check option syntax and pppd logs
an  1 03:40:08 (none) kern.err pptpd[622]: CTRL: PTY read or GRE write faile
ty,gre)=(7,8)
an  1 03:40:08 (none) kern.debug pptpd[622]: CTRL: Reaping child PPP[623]
an  1 03:40:08 (none) kern.info pptpd[622]: CTRL: Client 192.168.1.2 control
nection finished

Am I right in thinking this has something to do with iptables?  See, I don't need this to be anything but a PPTP server.  I don't need the WAN interface, I don't need a firewall or DHCP.  It will behind another firewall accepting connections.  I'm something of a networking newbie, but proficient with linux.  Thanks for your help.
-Brian

soulcoughy,

you should also load the ppp_async module found in the kmod-ppp package.
I edited my post to add this requirement...

--
Nico

Thank you guys for all your help.  I have basic functionality up and working like a charm.