[Gelöst] [Gelöst] OpenVPN on 7330. Wrong routing

[MaxMuster]

You might consider to allow the cpu some rest, e.g. "sleep"ing for some time after a ping ...

 

[PeterPawn]

voipd -R is not enought. after voipd do the registration but the calls still fail. This is my experience.

Every new finding invalidates each previous one, it seems. -R is used to register numbers (voipd -h) ... but if reloading configuration/restarting voipd is really necessary, this would point out, that some of the previous assumptions - how voipd works - could be right indeed.

It's a strange thing ... understanding voipd is not as easy as it could be, if a correct documentation would be available.

And if you want to take #21 into account (10 seconds timeout in case of missing answers is default as far as I know and so your single ping will be repeated every 10 seconds now), you can extend the "loop time" with an additional sleep and decrease it with the "-W timeout" option. The ICMP packet is sent and the wait time is only occuring, if it's not answered. After receiving the response, ping will terminate immediately. Any late response is highly improbable (the packet simply gets lost) ... so you may find a ten seconds delay in the worst case now.

And I do not know for sure, if there's a difference between reloading the voipd configuration only and stopping/starting the daemon. If you find some other side effects, you can still try to reload voipd's configuration only. The command sequence "voipd -s" and "voidp" is used by AVM too, you may find it in /etc/init.d/rc.voip (look for the "reload" part) ... but in my imagination there's a reason, why the voipd "reload" message exists and is the first attempt, instead of a restart in any case.

 

[stefanoIT]

Following the advices I modified the openvpn configuration in this way

proto tcp-client
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote iii.iii.iii.iii pppp
nobind
pull
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
script-security 2
up "/etc/init.d/rc.voip restart"

and debug.cfg in this way

cat > /var/vpn_alive.sh << EOF2
while true; do
  sleep 150
  if ! /bin/ping -c1 194.243.192.1 &> /dev/null; then
    /etc/init.d/rc.openvpn restart
  fi
done
EOF2
/bin/sh /var/vpn_alive.sh &

I tested it and it works. The last issue is linked to UMTS connectivity: if the traffic freezes (it happens) I should restart umts connection.
I'm trying with /etc/init.d/rc.dsld restart (I don't not have exact info on which rc.* file controls umts.

 

[MaxMuster]

You should remove the remote IP (or replace with "x") from the config posted (just to be sure).

If the config works this way, you can do this configuration (with "user" and "chroot") with the gui, too. If you check the "expert-settings-box" you may add "freetext" commands.

 

[PeterPawn]

The last issue is linked to UMTS connectivity: if the traffic freezes (it happens) I should restart umts connection.
I'm trying with /etc/init.d/rc.dsld restart (I don't not have exact info on which rc.* file controls umts.

The umtsd daemon is started from /etc/hotplug/udev-gsm-tty, if a supported COM device was found and is killed there, if the tty device vanishes due to removal of the physical USB device.

The umtsd does not know an option to stop it gracefully, you can send a SIGKILL instead.

There are two known options (always as far is I know), one to check the ability to use a TTY device for data transfers (umtsd --check device, invalid call yields a segmentation fault) and the other one may be useful under some circumstances to diagnose problems:

root:/# umtsd --info
PIN: empty, allow roaming: 0, home net: "26201"
manu: 'ZTE CORPORATION', model: 'MF190', rev: 'BD_MF190F3V1.0.0B02'
states: 0, 2, 1
ppp state: 0
pin state: 6, fail count: 0
established: 0, idle_mode_text: ''
AcT: 2
AT1: 37/0/'+CREG: 1, 37B0, 1224'
AT2: 0/1/'OK'
root:/# killall umtsd
root:/# umtsd --info
PIN: empty, allow roaming: 0, home net: "26201"
no valid status

I found, the ctlmgr_ctl results do not correspond always to "pin state" and "established" shown above. So it's an opportunity to distinct between different output values from different sources and you may detect a running/stale/not started umtsd too.

Another possible solution (restarting dsld is the poorest from my point of view) could it be to send a "reconnect_button" message to dsld. If the current WAN connection is a mobile connection, this should trigger a new PPP login too.

msgsend dsld reconnect_button

If this will not solve the connection problem, you can even try to kill and restart umtsd. And only the last try I would start, is restarting dsld ... usually with "rc.net reload". But this has a deep impact for much more daemons than dsld only, therefore I would try any (better each) other possible solution first.