Sometimes an invalid OpenVPN config file gets generated

[torte71]

As I didn't find a way to reproduce it yet, I can't tell if this is an upstream problem (quite probable) or not.

Device: RPi3 Firmware: Freifunk Berlin Hedy 1.0.0-alpha-SAm0815 1f0e9de Flavour: tunnel-berlin Setup/noteworthy changes:

• OpenVPN-mbedTLS replaced by OpenVPN-OpenSSL
• VPN keys and config changed to use VPN03 instead of tunnel-berlin (works reliably, running for months now)
• /etc/config/openvpn contains only ffuplink definitions (no BBB-VPN, etc.)

Symptom: OpenVPN can't be started, "logread" complains about an incorrect parameter: Mon Apr 30 11:45:27 2018 daemon.err openvpn(ffuplink)[4715]: Options error: Unrecognized option or missing or extra parameter(s) in openvpn-ffuplink.conf:17: cipherproto (2.4.4)

• I noticed this state after a reboot, but I don't know, how long the device was up after that reboot (i.e. if there has been reconnection attempts to the openvpn server, etc.).
• There was no manual configuration change after the reboot, i.e. the device ran into this state on its own.
• Executing "/etc/init.d/openvpn restart" fixed the problem
• After a reboot, the device came up with a correct configuration (but that might not always be the case)
• The auto-generated config file in "/tmp/etc/" was a mix of two config files (in the error case)

This is the config file, that was autogenerated from /etc/config/openvpn and logread complained about:

root@crossing-gmbh:/etc/config# cat /tmp/etc/openvpn-ffuplink.conf
route-nopull
client
ca /etc/openvpn/freifunk-ca.crt
cert /etc/openvpn/freifunk_crossing-gmbh-bln.crt
cipher none
comp-lzo no
dev ffuplink
persist-key
dev-type tun
route-nopull
keepalive 10 60
key /etc/openvpn/freifunk_crossing-gmbh-bln.key
local 192.168.64.6
mssfix 1300
ca /etc/openvpn/freifunk-ca.crt
cert /etc/openvpn/freifunk_crossing-gmbh-bln.crt
cipherproto none
 udp4
comp-lzo no
remote vpn03.berlin.freifunk.net 1194
remote vpn03-backup.berlin.freifunk.net 1194
dev ffuplink
remote-cert-tls server
dev-type tun
script-security 2
status /var/log/openvpn-status-ffuplink.log
keepalive 10 60
key /etc/openvpn/freifunk_crossing-gmbh-bln.key
localup 192.168.64.6
 /lib/freifunk/ffvpn-up.sh
mssfix 1300
proto udp4
remote vpn03.berlin.freifunk.net 1194
remote vpn03-backup.berlin.freifunk.net 1194
remote-cert-tls server
script-security 2
status /var/log/openvpn-status-ffuplink.log
up /lib/freifunk/ffvpn-up.sh

This file is a mix of two files. E.g. lines 17+18 read

cipherproto none
 udp4

but should read

cipher none
proto udp4

The same kind of mix can be seen in lines 29+30

localup 192.168.64.6
 /lib/freifunk/ffvpn-up.sh

And you can see, that this file is twice as long as in the default case and has almost every setting twice (except client and persist-key).

[SvenRoederer]

I assume you are aware, that you use an outdated and unreleased firmware-version. I assume you are aware, that such "converted" VPN-setups are unsupported.

But your openvpn-file looks like concated multiple times together; probably a race-condition?

[torte71]

I know that it's outdated. :)

The config file is not simply concated, it is mixed: The stuff got inserted into each other (that's why I mentioned lines 17+18 and 29+30). This looks to me, as if two instances of openvpn got started at once and simultaneously wrote to that config file (or a very strange caching problem). As I don't have any duplicate openvpn config files on that router (backups, etc.), I wonder how this (assumed duplicate openvpn process) should happen.

About the "converted setup": These were three changes. 1. Replaced certificates - it is very unlikely to be the cause. 2. Modified openvpn config - this is now identical to that of the vanilla vpn03 flavor. 3. Replaced openvpn - if this is the cause, then this might be interesting for those, that want to use e.g. the tunnel-berlin flavour together with bbb-vpn.

[SvenRoederer]

• try with a release-build of Hedy (not sure what changes were made to the openvpn-package)
• perhaps add some logging into "etc/init.d/openvpn"

[pmelange]

Is this still an issue? Can this be closed?