Posted: Sat Jan 07, 2012 22:42 Post subject: PPTP Client Fix
In case anyone else has problems with the PPTP Client... I believe there were a few posts about that.
The problem is in the first option in the /tmp/pptpd_clients/options.vpn:
The option that reads:
Code:
logfd2
should read:
Code:
logfd 2
There is a space missing. A three days worth of space.
What wasted most of my time was that I was unsure how to get the debug output from the PPTP client and PPP. I wasn't able to get any sort of output or log or anything useful.
The most I was able to do was to turn on the syslogd service and redirect it to my windows machine's syslogd service that I later modified to a syslogd console application.
Note that it is also possible to turn on the syslogd service in dd-wrt and not enter a remote Server. This implicitly means that the logs go to the system log in /var/log/messages. And the kernel startup log can be examined with dmesg.
What I found out later is that the lack of information from PPTP client means that there is something wrong in the /tmp/pptpd_clients/options.vpn config file.
The best way to debug your PPTP Client problems is to ssh to your router and test them by hand. You first stop whatever VPN madness is already running and then start the VPN debug stage. You do this like this:
This very likely means that there is something wrong with the syntax of your PPTP client configuration and not with the values you entered in the dd-wrt admin web pages. And while an attempt is made to connect to the other side, the PPTP connection will soon be dropped.
This means that PPTP Client understood all your options in the options.vpn file and you are ready to start tweaking your file.
Now... With a bit of bad luck I managed to waste two days on this part... Hopefully nobody else has to.
But what I wasted another day on... Was making this bloody space appear in the options.vpn file. The problem is that the configuration files for the PPTP Client are not copied to /tmp during the the first stage of the startup of dd-wrt. I presume a few things have priority over that and that is OK... But it was quite tricky to start a script after dd-wrt creates the pptpd_client folder.
Of course the options.vpn file is re-created every time you change any settings in the admin pages so keep that in mind. I ended up writing two mechanisms - a delayed script from jffs triggered on ipup with an extra delay of 30s before options.vpn fixup. And if the settings are modified at a later time I scheduled a cron job to try and fixup the file every 60s if it contains the invalid option.
But to make things more complicated the cron refused to execute tasks for some reason. I suspect that this has to do with time synchronisation with a NTP server or simply because dd-wrt doesn't know the correct time and assumes it is 1.Jan.1970. This was fixed with another 20s delayed cron restart, and I have a sync to an NTP server configured.
Anyhow... I hope somebody can come up with a simpler solution but until then my PPTP Client is now up and running. I am tempted to mod the 18000 build for my E4200 and add that space... But perhaps it is better if we get an official build from Eko.
The simplest solution, if you have enough NVRAM, is to attempt a delayed fixup. I believe the best way is to use the NVRAM Startup script as it gets run only once, while the firewall script gets run four times on my system:
It is not a great script but his should get you up and running. If your router is slower to start you may increase the delay from 35s to whatever works for you. And don't forget to restart the router if you change any PPTP Client settings in the web admin pages.
But I recommend a JFFS filesystem solution. Create three files:
/jffs/etc/fix_pptpc:
Code:
#!/bin/sh
if [ "$1" != "" ]; then
sleep $1
fi
if [ -f "/tmp/pptpd_client/options.vpn" ]; then
echo "PPTP Client file exists."
else
echo "PPTP Client file does not exist yet... Exiting."
exit
fi
Next, enter the cron job in the admin web interface (Aministration -> Management -> Cron)
Code:
* * * * * root /jffs/etc/fix_pptpc
This approach allows you to modify PPTP settings in the web interface and have them working in up to 60s without a router restart. And the settings will also be fixed up if the router is restart for some reason.
Right... This post is getting too long... Here is also the syslogd console application I tweaked for easier diagnostics: http://bxl.nano-ware.com/dd-wrt/. Requires .NET 3.5. If anyone wants sources let me know.
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Sun Jan 08, 2012 17:03 Post subject: Re: PPTP Client Fix
omahena wrote:
Anyhow... I hope somebody can come up with a simpler solution but until then my PPTP Client is now up and running. I am tempted to mod the 18000 build for my E4200 and add that space... But perhaps it is better if we get an official build from Eko.
A simpler solution would be to report the problem as a bug here, http://svn.dd-wrt.com:8000/timeline, with documentation and the like so that Eko or BS can fix it in the source. _________________ E3000 22200M KongVPN K26
WRT600n v1.1 refirb mega 18767 BS K24 NEWD2 [not used]
WRT54G v2 16214 BS K24 [access point]
Try Dropbox for syncing files - get 2.5gb online for free by signing up.
Read! Peacock thread
*PLEASE* upgrade PAST v24SP1 or no support.
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Mon Jan 09, 2012 5:06 Post subject:
MrFidget wrote:
But he wouldn't have learnt what he did by getting his hands dirty. Isn't that what community software is
about
More of it I say
Cheers
Chris
Not true. He learned what he did *because* of the bug, yes. But he can help get it fixed by reporting the issue and the solution to the developers. _________________ E3000 22200M KongVPN K26
WRT600n v1.1 refirb mega 18767 BS K24 NEWD2 [not used]
WRT54G v2 16214 BS K24 [access point]
Try Dropbox for syncing files - get 2.5gb online for free by signing up.
Read! Peacock thread
*PLEASE* upgrade PAST v24SP1 or no support.
Joined: 24 Oct 2008 Posts: 1079 Location: Latin America
Posted: Tue Jan 10, 2012 12:12 Post subject:
Flashed a f7d3302 from 15508 NEWD-2 K.26 big (working fine) to 17990 NEWD-2 K.26 big.
Had to reset to factory defaults several times because the WiFi didn't come up at first tries.
As other people have reported, milkfish doesn't come up:
Code:
SER Uptime:
Error opening openser's FIFO /tmp/openser_fifo
Make sure you have line fifo=/tmp/openser_fifo in your config
And something in both builds it's not logical to me:
If I set mode mixed (i.e. b/g/n), channel to auto, and bandwidth 20MHz, the router broadcast at 40MHz! (Note that in bandwitdh there are the options: "Auto", "10MHz", "20MHz" and "40MHz"). I Think, as the GUI suggest, that auto channel and auto bandwidth should be different things. _________________ If you want support, please read first the announcements and forum rules.
Si usted desea ayuda, por favor lea primero los anuncios y las reglas del foro.
But he wouldn't have learnt what he did by getting his hands dirty. Isn't that what community software is
about
More of it I say
Cheers
Chris
Not true. He learned what he did *because* of the bug, yes. But he can help get it fixed by reporting the issue and the solution to the developers.
I am sorry to have upset you. I did actually try to report it and found that somebody already has reported it. So I extended the problem description here: http://svn.dd-wrt.com:8000/ticket/2350. I also added a suggestion how to avoid further problems and make dd-wrt less susceptible to bad user input.
I was however sure that few users find their solutions in the SVN timeline. Most of them look in the forums. And since E4200 is a very nice piece of kit and the previous recommended dd-wrt version was rather aged... I thought I'd help the community out a bit as well. This bug was a show-stopper for me and meant money wasted. I won't even get into the time is money train of thought.
But I can start a new thread next time and post a link to it here if that is more desirable. I was just trying to help. Please PM me next time and I will be happy to move the message to a new thread. Thanks.
As other people have reported, milkfish doesn't come up:
Code:
SER Uptime:
Error opening openser's FIFO /tmp/openser_fifo
Make sure you have line fifo=/tmp/openser_fifo in your config
Telnet to the box
type
Code:
openser -f /var/openser/milkfish_openser.cfg
You should see a segfault. It never gets to create a fifo file. I have even tried to create one.
Joined: 24 Oct 2008 Posts: 1079 Location: Latin America
Posted: Wed Jan 11, 2012 2:13 Post subject:
MrFidget wrote:
Code:
openser -f /var/openser/milkfish_openser.cfg
You should see a segfault. It never gets to create a fifo file. I have even tried to create one.
Time for Kamailio I say
/C
Right. I did it and it returns:
Code:
Segmentation fault
This also happened to me on build 15508 when I had the WAN disconnected at boot time (but that isn't the case here). _________________ If you want support, please read first the announcements and forum rules.
Si usted desea ayuda, por favor lea primero los anuncios y las reglas del foro.
Joined: 24 Oct 2008 Posts: 1079 Location: Latin America
Posted: Wed Jan 11, 2012 16:56 Post subject:
I downgraded to build bs bcm 17967 K26 big. Milkfish is working there, so something went wrong from one build to the other (I was using eko's build).
EDIT: After a while, I downgraded to eko bcm 17598M K26 big. Milkfish doesn't start there, and WiViz doesn't show any wireless equipments. _________________ If you want support, please read first the announcements and forum rules.
Si usted desea ayuda, por favor lea primero los anuncios y las reglas del foro.
This is a heads up to the developers, but I ran into a bit of a problem after upgrading to this build. My router is the linksys wrt160n v.3, and prior to this I had been using the 17084 build for just about a year with no problems at all. After upgrading to this build, I noticed that my download rates had been capped at around 350-400kbs. I performed a 30-30-30 reset and reverted back to the 17084 build, re uploading my config settings and all was well again. I'm not a complete rookie with ddwrt but I'm not an expert either so I'm not sure what the problem was, but it seemed very much like that was a bug in this build. QoS was not the issue, I ruled that out. I could have tried to re-configure everything from scratch but I didn't feel like sitting there for an hour trying to do all that. Just wanted to report that, just in case it helps any or aligns with other similar reported issues. Thanks and have a good one.
Joined: 24 Oct 2008 Posts: 1079 Location: Latin America
Posted: Wed Jan 18, 2012 15:55 Post subject:
bmjr42@gmail.com wrote:
I could have tried to re-configure everything from scratch but I didn't feel like sitting there for an hour trying to do all that.
You should do that everytime you jump from one build to another. It's not recommended to load a saved nvrambak.bin from a different build. _________________ If you want support, please read first the announcements and forum rules.
Si usted desea ayuda, por favor lea primero los anuncios y las reglas del foro.
Noted. Here's the thing that I should have pointed out: after performing a 30-30-30 reset and uploading the 17990 firmware, without uploading any kind of .bin configuration file I tried a download right out of the gate, just with the barebone, default settings, and my download rate was still capped at 350-400kbs. I normally would be getting about 1100kbs. Just wanted to clarify that, but you are right about the reconfiguring, thanks.