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

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

stefanoIT schrieb:

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

Zum Vergrößern anklicken....

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.

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.

stefanoIT schrieb:

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.

Zum Vergrößern anklicken....

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:
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.
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.