Hi Matthijs,
Il 23/08/2012 12:49, Matthijs Kooijman ha scritto:
Hi Carlo,
Did you know the Fonera comes shipped with the openvpn binaries as well?
I was thinking it was only for openvpn server... my mistake.
It supports both. The client support can be disabled, but I'm leaving it
enabled on purpose to allow people to experiment with stuff like this
;-)
Ok, good to know.
I can try a factory reset to test the firmware openvpn version from scratch.
I will upgrade to 2.3.7 when it will be in a stable version ;-)
Ok, makes sense.
I see nothing in the /tmp/openvpn-debub file, because I've already
redirected output in the /tmp/openvpn-log file
I was thinking that OpenVPN was perhaps throwing some error before it
got a chance to setup the log output file (since the openvpn-debug
redirect is handled by the shell just before starting openvpn, it should
always work). But if there is no output in there, openvpn is probablly
not outputting anything.
I see no error or messages even if I launch as:
[...]
/usr/sbin/openvpn --daemon --log /tmp/openvpn-log --config
/etc/openvpn/myvpn.ovpn 2>&1 > /tmp/openvpn-debug
[...]
or as:
[...]
/usr/sbin/openvpn --daemon --config /etc/openvpn/myvpn.ovpn 2>&1 >
/tmp/openvpn-debug
[...]
... I know, it's strange...
But this was a good hint because I saw that the log were truncated... the
VPN connection started and then, in the negotiation phase, ended without
terminate the full process.
Which log was truncated? How can you tell?
I analyzed the /tmp/openvpn-log log file. Since I know the shell output of
this command, I noticed that the negotiation process start in a correct way
and then stop about in the middle of the procedure. So I thought the script
has not enough time to end the vpn startup.
So I added the two delays and the Fonera start with the openvpn up and running.
The weird thing is that I have to insert both delays (before and after the
openvpn invocation); If I leave only one of this the openvpn doesn't start...
What error did you see, then?
No errors. Only standard output info messages.
I just added two "forced delay" in the script and now the VPN starts at
boot. OK, I know this isn't' a "clean way" to solve the problem, but for
now is enough.
Hmm, I don't think I understand exactly how these delays help here.
AFAIK the boot is not performed in parallel, so while this script is
sleeping, there is no other stuff running in the background which would
cause openvpn to work after those 15 seconds (though I'm not completely
sure).
Maybe before or after the init.d script (I put this at the end of the
startup script, at "position" 98, with link "/etc/rc.d/S98ovpnstart")
something restart the net, or kill this process... I dont't know. Are you
sure the init.d scripts are ran one after the other?
I will wait the stable new firmware (BTW: when?) to apply a clean
solution (as Jon "The Nice Guy" Spriggs suggested in the previous
e-mail).
I expect the stable firmware to be released by the end of this year.
Good!
And thanks for the hard work ;-)
Carlo
_______________________________________________
Development mailing list
[email protected]
http://fonosfera.org/mailman/listinfo/development
