Smoothly restarting wireless radio, travelmate and openvpn?

Installing and Using OpenWrt Network and Wireless Configuration
1

Using a WRT1900ACS rev 1 and traveling quite a lot (in an RV) and have been successfully using travelmate and openvpn to keep online and reasonably safe.

One problem I've got is that some places where we camp have unreliable wifi and we end up getting disconnected randomly or the router ends up in a state where it thinks we're connected (radio is active and the client AP is showing good signal strength) but traffic goes nowhere.

Usually what I have to do is disable the radio, stop openvpn and then restart travelmate to bring the AP back up and then manually restart openvpn. I leave openvpn as a manual operation because sometimes I'm connected through my phone and don't feel a need to start openvpn. It's not that I trust our carriers, it's just that I'm more suspicious of camp wifi.

I'd like some recommendations on how to smoothly disable the AP, bring down openvpn and travelmate and restart them as they are through luci.

The scripting part I can handle.

It's the "right" way to bring the wifi and apps down and back up that I'm lacking.

I've found the wifi command but am unsure if I should bring the entire radio down or if I can just disable the active AP somehow. Again, I'm unsure what's happening with luci behind the scenes.

As far as the apps go, I can always 'kill' them but is there a more graceful way to end them?

I can also restart them based on how they show in 'ps' but is there a better way to bring them up the same as they would be from luci?

And yeah, I've looked for docs but either I've missed it or misunderstood what I've found. I won't be offended if you simply send me back to the right section.
TIA

2

I'd create a couple of desktop/menu launchers doing something like this:

ssh root@openwrt.lan "/etc/init.d/${SERVICE1} restart; sleep ${TIME}; /etc/init.d/${SERVICE2} restart"

https://openwrt.org/docs/guide-user/security/dropbear.public-key.auth

1 Like
3

I can't really start these from the service level as it bypasses the configuration settings used when I do the same kind operation from luci. I've done that manually as a test and found that for example openvpn starts with default params rather than the config I've specified in luci.

I also can't run this from the desktop (once it's working) as I need to have a kind of daemon script running on the router so that a lost connection will be automatically renewed. This part, I've got a good handle on.

4

OpenVPN service shouldn't restart disabled instances, so most likely you haven't configured it properly.

You can also manage instances separetly:

/etc/init.d/openvpn restart ${INSTANCE}
1 Like
5

I don't know what you mean by "disabled instances"

I only have one instance configured in luci. For nordvpn.

"service openvpn restart" it restarts using a "default" that doesn't show in luci.

Normally I end up with an instance that shows the following in 'ps'

/usr/sbin/openvpn --syslog openvpn(nordvpn) --status /var/run/openvpn.nordvpn.status --cd /etc/openvpn/nordvpn --config /etc/openvpn/nordvpn.cfg

when I use "service openvpn restart" I end up with

/usr/sbin/openvpn --syslog openvpn(default) --status /var/run/openvpn.default.status --cd /etc/openvpn --config /etc/openvpn/default.conf

Even if I specify " service openvpn restart nordvpn"

I end up with "openvpn(default)"

6

That's because you have config "default" which is not present in UCI.

Either remove/rename the config:

service openvpn stop
mv /etc/openvpn/default.conf /etc/openvpn/default.bak
service openvpn start

Or create a UCI-section to manage it:
https://openwrt.org/docs/guide-user/services/vpn/openvpn/extras#instance_management

1 Like
7

Thanks. The nordvpn setup docs had me create a default.conf an reference it from the etc/config/openvpn instance. I've renamed it and things are working better.

8

Apparently this is the wrong way to do what I'm after. It works the first time but after the second run, something is in a bad state and I have to reboot the router

#restart_camp_wifi.sh

echo bringing radio down

wifi down radio1

echo killing apps

killall openvpn

export pid=pgrep -f travelmate
kill $pid

echo bringing radio up

sleep 5

wifi up radio1

sleep 30

echo bringing travelmate up

/usr/bin/travelmate.sh &

sleep 30

echo bringing openvpn up

#/etc/init.d/openvpn restart nordvpn

9

Which travelmate version did you use?
Travelmate never directly change the state of your AP, it only controls the action of the configured STAs. It's definitely wrong to start travelmate directly via /usr/bin/... please only use the init script placed in /etc/init.d for this purpose. Said that, actually I haven't understood your problem you're trying to fix with your scripting. Could you provide (debug) logs which better explain, what's going on on your machine?
Sounds to me like a 'usual' OpenVPN restart problem, after the tunnel collapsed.

2 Likes
10

This is definitely not a proper way to manage services such as OpenVPN.

11

Re. Dibdot:

I'm using the latest official version available via the public packages.

Ok, I hadn't seen any docs on how to restart travelmate outside of luci. Is the script you referenced what's called when 'restart' is clicked in luci?

Normally I disable the STA in luci. Is there a command line way to accomplish the same?

There's never anything useful in the logs of my router. I don't have logs from the other side so have no idea what's happening there.

I'm not sure how I can explain it better than in my first post above. Happy to answer specific questions and very much appreciate the help.

12

(quoting isn't working for me)

Re. vgaetera, & improper shutdowns:

Yeah, I started out doing that because of some behavior I was seeing and knew I'd have to change it before long.

Unfortunately today is moving day in the RV so I won't be able to do further testing until tonight when we reach the next camp.

13

@michaelh99 if you are using nordvpn guide, maybe you are missing the reconnect.sh scripts in /etc/openvpn/reconnect.sh

#!/bin/sh
n=10
while sleep 50; do
        t=$(ping -c $n 8.8.8.8 | grep -o -E '\d+ packets r' | grep -o -E '\d+')
        if [ "$t" -eq 0 ]; then
                /etc/init.d/openvpn restart
        fi
done

then after creating it make the scripts executable and add a line in /etc/rc.local

/etc/openvpn/reconnect.sh &

restart your router and chek if the scripts is runnig

14

Please use the latest snapshot version (1.4.1), linked in the first post of the travelmate support thread. Update both packages (backend & LuCI) and clean up the LuCI cache afterwards (rm -rf /tmp/luci-*)

You mean under System => Startup? Yep!

If your STAs are under control of travelmate, then please do not manually stop or start wireless stations - this will be done automatically by travelmate.
I would suggest, that you start with a fresh configuration ... and please start with travelmate in the first place. If the (re-)connection stuff runs smoothly go forward with openvpn - don't try both things at the same time. As a good starting point take a look at this post (Using device as "Hotspot-Router" (WISP-Mode)? - #18 by RK_aus_S), where a user described all required steps.

Good luck!

15

if you are using nordvpn guide, maybe you are missing the reconnect.sh scripts in /etc/openvpn/reconnect.sh

I've found that I can't use that script by itself. Most of the problems I've run into result in the upstream connection dying, not just openvpn.
But otherwise, you're right. I should have started with the restart method they supplied. I've done so now.

16

I'll give that a shot

No, I mean under the Services | TravelMate | Options | "Restart" button

I'll give this another try with the snapshot version but I'm pretty sure that in the past this hasn't been sufficient.

I'll take a look at the references and trying what you've suggested.

17

Unfortunately the wifi at our new location is completely saturated and unusable so I'll be unable to do any real testing until our next camp.

If I can get some alone time with the network I'll try scripting though since I've never had the base problem when using my phone, I doubt that I'll have any difficulty.

18

@dibdot

I just encountered these in the log. It was over a period where no TravelMate configured APs were active.

I'm using TM 1.4.1

Wed Mar 13 09:31:06 2019 daemon.err travelmate.sh[6530]: /usr/bin/travelmate.sh: line 1: /sbin/uci: Argument list too long
Wed Mar 13 09:31:06 2019 daemon.err travelmate.sh[6530]: /usr/bin/travelmate.sh: line 1: ubus: Argument list too long
19

Why do you keep starting the program directly via /usr/bin/...?

2 Likes
20

I'm not. These literally appeared while I was away from the network and the script I'm working toward can only be run manually. Whatever was triggering these are part of a standard install as far as I can tell.