Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Report of potential bug/enh in vpnstatus.sh & tbird.sh scripts
37 views
Skip to first unread message
James Dickson
Dec 28, 2015, 7:12:10 AM12/28/15
to
What is causing the vpnstatus.sh & tbird.sh scripts to break?
I have been successfully using Marek Novotny's most excellent
vpnstatus.sh & tbird.sh scripts for months, without err
(using vpngate.net ovpn config files).
However, testing a DIFFERENT free VPN service, the scripts break,
perhaps because of a tunnel naming convention difference.
0. Optional test of vpnstatus.sh & tbird.sh with vpngate.net ovpn files:
Everything works:
a. The vpnstatus.sh command watches over the VPN connection.
b. The tbird.sh command lets Thunderbird start only when NOT on VPN.
1. Now test the vpnbook free ovpn files:
http://www.vpnbook.com/freevpn
For example, the "Europe 1" bundle of free ovpn files:
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-Euro1.zip
$ unzip VPNBook.com-OpenVPN-Euro1.zip
inflating: vpnbook-euro1-tcp80.ovpn
inflating: vpnbook-euro1-tcp443.ovpn
inflating: vpnbook-euro1-udp53.ovpn
inflating: vpnbook-euro1-udp25000.ovpn
2. Run openvpn with any of those ovpn configuration files:
$ sudo openvpn --config vpnbook-euro1-udp25000.ovpn
Enter Auth Username: vpnbook
Enter Auth Password: Cr3rApes
Test the route once you see the message "Initialization Sequence Completed":
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.10.0.105 128.0.0.0 UG 0 0 0 tun2
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.10.0.1 10.10.0.105 255.255.255.255 UGH 0 0 0 tun2
10.10.0.105 0.0.0.0 255.255.255.255 UH 0 0 0 tun2
128.0.0.0 10.10.0.105 128.0.0.0 UG 0 0 0 tun2
176.126.237.217 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
3. Run the vpnstatus.sh script:
$ vpnstatus.sh
This script will cause an instant termination of running apps every time.
The actual vpn connection will remain solid, as evidenced by a "route -n"
having the same result both before and after running vpnstatus.sh.
But *something* is different with this VPN versus with vpngate.net vpn.
The same thing happens with the tbird.sh script, which allows thunderbird
to run, when it shouldn't allow that when on VPN.
I don't know enough to figure out why the vpn tunnel is different between
the free ovpn files from vpngate.net and the ovpn files from vpnbook.com.
I have been successfully using Marek Novotny's most excellent
vpnstatus.sh & tbird.sh scripts for months, without err
(using vpngate.net ovpn config files).
However, testing a DIFFERENT free VPN service, the scripts break,
perhaps because of a tunnel naming convention difference.
0. Optional test of vpnstatus.sh & tbird.sh with vpngate.net ovpn files:
Everything works:
a. The vpnstatus.sh command watches over the VPN connection.
b. The tbird.sh command lets Thunderbird start only when NOT on VPN.
1. Now test the vpnbook free ovpn files:
http://www.vpnbook.com/freevpn
For example, the "Europe 1" bundle of free ovpn files:
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-Euro1.zip
$ unzip VPNBook.com-OpenVPN-Euro1.zip
inflating: vpnbook-euro1-tcp80.ovpn
inflating: vpnbook-euro1-tcp443.ovpn
inflating: vpnbook-euro1-udp53.ovpn
inflating: vpnbook-euro1-udp25000.ovpn
2. Run openvpn with any of those ovpn configuration files:
$ sudo openvpn --config vpnbook-euro1-udp25000.ovpn
Enter Auth Username: vpnbook
Enter Auth Password: Cr3rApes
Test the route once you see the message "Initialization Sequence Completed":
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.10.0.105 128.0.0.0 UG 0 0 0 tun2
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.10.0.1 10.10.0.105 255.255.255.255 UGH 0 0 0 tun2
10.10.0.105 0.0.0.0 255.255.255.255 UH 0 0 0 tun2
128.0.0.0 10.10.0.105 128.0.0.0 UG 0 0 0 tun2
176.126.237.217 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
3. Run the vpnstatus.sh script:
$ vpnstatus.sh
This script will cause an instant termination of running apps every time.
The actual vpn connection will remain solid, as evidenced by a "route -n"
having the same result both before and after running vpnstatus.sh.
But *something* is different with this VPN versus with vpngate.net vpn.
The same thing happens with the tbird.sh script, which allows thunderbird
to run, when it shouldn't allow that when on VPN.
I don't know enough to figure out why the vpn tunnel is different between
the free ovpn files from vpngate.net and the ovpn files from vpnbook.com.
Marek Novotny
Dec 28, 2015, 9:40:50 AM12/28/15
to
number. Your old vpn uses tun0 and the report above shows tun2. So an
update is available and I finally posted this script to my github so you
can easily get the latest update.
https://github.com/marek-novotny/vpntools
As for tbird, you might try running the vpntest script which I just
posted in vpntools gitup and post the results, plus post what the
$HOME/.tbird hidden file shows. That's the approved list tbird creates
for you in the $HOME directory.
--
Marek Novotny
https://github.com/marek-novotny
James Dickson
Dec 28, 2015, 1:56:04 PM12/28/15
to
On Mon, 28 Dec 2015 06:40:52 -0800, Marek Novotny wrote:
> I've modified the vpnstatus.sh script to work with any single tun
> number. Your old vpn uses tun0 and the report above shows tun2. So an
> update is available and I finally posted this script to my github so you
> can easily get the latest update.
>
> https://github.com/marek-novotny/vpntools
Thank you very much Marek.
> I've modified the vpnstatus.sh script to work with any single tun
> number. Your old vpn uses tun0 and the report above shows tun2. So an
> update is available and I finally posted this script to my github so you
> can easily get the latest update.
>
> https://github.com/marek-novotny/vpntools
Your scripts help a lot of people!
The vpngate.net free openvpn config files all seem to use device "tun",
while the vpnbook.com free openvpn config files use device "tun0",
"tun1", "tun2", and "tun3" for some unknown reason.
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-Euro1.zip
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-Euro2.zip
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-US1.zip
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-US2.zip
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-CA1.zip
$ wget http://www.vpnbook.com/free-openvpn-account/VPNBook.com-OpenVPN-DE1.zip
$ for i in *.zip; do unzip $i; done
$ grep ^dev *.ovpn
vpnbook-ca1-tcp443.ovpn:dev tun1
vpnbook-ca1-tcp80.ovpn:dev tun3
vpnbook-ca1-udp25000.ovpn:dev tun2
vpnbook-ca1-udp53.ovpn:dev tun0
vpnbook-de233-tcp443.ovpn:dev tun1
vpnbook-de233-tcp80.ovpn:dev tun3
vpnbook-de233-udp25000.ovpn:dev tun2
vpnbook-de233-udp53.ovpn:dev tun0
vpnbook-euro1-tcp443.ovpn:dev tun1
vpnbook-euro1-tcp80.ovpn:dev tun3
vpnbook-euro1-udp25000.ovpn:dev tun2
vpnbook-euro1-udp53.ovpn:dev tun0
vpnbook-euro2-tcp443.ovpn:dev tun1
vpnbook-euro2-tcp80.ovpn:dev tun3
vpnbook-euro2-udp25000.ovpn:dev tun2
vpnbook-euro2-udp53.ovpn:dev tun0
vpnbook-us1-tcp443.ovpn:dev tun1
vpnbook-us1-tcp80.ovpn:dev tun3
vpnbook-us1-udp25000.ovpn:dev tun2
vpnbook-us1-udp53.ovpn:dev tun0
vpnbook-us2-tcp443.ovpn:dev tun1
vpnbook-us2-tcp80.ovpn:dev tun3
vpnbook-us2-udp25000.ovpn:dev tun2
vpnbook-us2-udp53.ovpn:dev tun0
When I manually modify the vpnbook files to use "tun", instead of "tun0",
"tun1", "tun2", or "tun3", your old vpnstatus.sh script works again, but,
not the tbird.sh script (which I haven't figured out why yet and which
I will take on after I test the new vpnstatus.sh first).
I will try your new vpnstatus.sh script, version: 2.8 (Mon Dec 28)
https://github.com/marek-novotny/vpntools/blob/master/vpnstatus.sh
And I will report back what happens after running a test on a sample
of the files above that include all the known tunnels.
I see the key difference is this first line:
if [[ ${devType[0]} == tun? || ${devType[0]} == ppp? ]] ; then
vpnOn
else
vpnOff
The old vpnstatus.sh assumed a specific tunnel & ppp number:
if [[ ${devType[0]} == "tun0" || ${devType[0]} == "ppp0" ]] ; then
I'm just curious about one thing: Why would "they" designate different
tunnel numbers? What advantage could there possibly be to changing the
tunnel numbers from nothing, to 0, to 1, to 2, and to 3?
Marek Novotny
Dec 28, 2015, 2:17:58 PM12/28/15
to
On 2015-12-28, James Dickson <JamesD...@example.com> wrote:
> On Mon, 28 Dec 2015 06:40:52 -0800, Marek Novotny wrote:
>
>> I've modified the vpnstatus.sh script to work with any single tun
>> number. Your old vpn uses tun0 and the report above shows tun2. So an
>> update is available and I finally posted this script to my github so you
>> can easily get the latest update.
>>
>> https://github.com/marek-novotny/vpntools
>
> Thank you very much Marek.
> Your scripts help a lot of people!
>
> The vpngate.net free openvpn config files all seem to use device "tun",
> while the vpnbook.com free openvpn config files use device "tun0",
> "tun1", "tun2", and "tun3" for some unknown reason.
// snip
>
>> I've modified the vpnstatus.sh script to work with any single tun
>> number. Your old vpn uses tun0 and the report above shows tun2. So an
>> update is available and I finally posted this script to my github so you
>> can easily get the latest update.
>>
>> https://github.com/marek-novotny/vpntools
>
> Thank you very much Marek.
> Your scripts help a lot of people!
>
> The vpngate.net free openvpn config files all seem to use device "tun",
> while the vpnbook.com free openvpn config files use device "tun0",
> "tun1", "tun2", and "tun3" for some unknown reason.
> I see the key difference is this first line:
> if [[ ${devType[0]} == tun? || ${devType[0]} == ppp? ]] ; then
> vpnOn
> else
> vpnOff
>
> The old vpnstatus.sh assumed a specific tunnel & ppp number:
> if [[ ${devType[0]} == "tun0" || ${devType[0]} == "ppp0" ]] ; then
>
> I'm just curious about one thing: Why would "they" designate different
> tunnel numbers? What advantage could there possibly be to changing the
> tunnel numbers from nothing, to 0, to 1, to 2, and to 3?
other number. It's better to stick to one so you can easily identify it.
As long as I know where the device name is to be listed, it doesn't
matter what they call it. But this is the first I've seen of someone
going with higher numbers. I've only ever seen tun0, ppp0 ..
The script could be written in such a way as to determine any name,
which is what I might end up doing if the names are going to differ from
provider to provider.
James Dickson
Dec 28, 2015, 4:43:19 PM12/28/15
to
On Mon, 28 Dec 2015 11:18:02 -0800, Marek Novotny wrote:
> There is no benefit to changing the device from tun0 to tun1 or any
> other number.
Thanks for responding as to "why" they bothered to change the tunnel
> There is no benefit to changing the device from tun0 to tun1 or any
> other number.
number. The vpngate.net site used "dev tun" (with no numerical suffix),
which (apparently) causes the actual tunnel to be called "tun0".
In stark contrast, the vpnbook.com team used a variety of numerical
suffixes, from 0 to 3, which caused the those specific tunnel
suffixes of tun{0-3}.
They must have had a reason, but I can't see any advantage to naming
the specific tunnel either.
> The script could be written in such a way as to determine any name,
> which is what I might end up doing if the names are going to differ from
> provider to provider.
can find, so, I will definitely let you know if I find other names
for the tunnel (although I can't see any advantage to the actual
name, as it can be named "foo" for all that it seems to matter).
> https://github.com/marek-novotny
I'm having a bit of trouble finding your latest "tbird.sh" script.
The one I have is dated "Mon Jun 22 2015 02:56PM".
https://github.com/marek-novotny?tab=repositories
The github search doesn't find it.
https://github.com/marek-novotny/dvdprep/search?utf8=%E2%9C%93&q=tbird.sh
What is the correct process to locate your latest "tbird.sh" script?
Marek Novotny
Dec 28, 2015, 5:15:36 PM12/28/15
to
James Dickson
Dec 28, 2015, 5:28:42 PM12/28/15
to
On Mon, 28 Dec 2015 11:18:02 -0800, Marek Novotny wrote:
> The script could be written in such a way as to determine any name,
> which is what I might end up doing if the names are going to differ from
> provider to provider.
Your response above gave me the idea to test your vpnstatus.sh script
> which is what I might end up doing if the names are going to differ from
> provider to provider.
against a given vpnbook ovpn config file for the various device names of
tunX, tunXYZ, tunnel, funnel, and foo.
Interestingly, your vpnstatus.sh script worked half way in that it
recognized the tunnel name but not the fact the tunnel worked when there
was more than one character after the three letters in the tunnel name.
Tunnel name:
1. tunX <--- vpnstatus.sh correctly reported "VPN status: on - tunX: 10.9.1.12"
2. tunXYZ <--- vpnstatus.sh incorrectly reported "VPN status: off - tunXYZ:10.9.1.18"
3. tunnel <--- vpnstatus.sh incorrectly reported "VPN status: off - tunnel: 10.9.1.34"
4. funnel <--- The openvpn command failed so the vpnstatus.sh command was not run
5. foo <--- The openvpn command failed so the vpnstatus.sh command was not run
Here are the details:
----------
dev tunX
$ sudo openvpn --config vpnbook-euro1-tcp443.ovpn
Mon Dec 28 12:24:22 2015 TUN/TAP device tunX opened
Mon Dec 28 12:24:22 2015 TUN/TAP TX queue length set to 100
Mon Dec 28 12:24:22 2015 /sbin/ip addr add dev tunX local 10.9.2.150 peer 10.9.2.149
$ vpnstatus.sh
VPN status: on - tunX: 10.9.2.150
VPN status: off - wlan0: 192.168.1.19
Terminating apps...
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.9.0.1 10.9.1.189 255.255.255.255 UGH 0 0 0 tunX
10.9.1.189 0.0.0.0 255.255.255.255 UH 0 0 0 tunX
128.0.0.0 10.9.1.189 128.0.0.0 UG 0 0 0 tunX
176.126.237.217 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
----------
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
dev tunXYZ
$ sudo openvpn --config vpnbook-euro1-tcp443.ovpn
Mon Dec 28 12:42:51 2015 TUN/TAP device tunXYZ opened
Mon Dec 28 12:42:51 2015 TUN/TAP TX queue length set to 100
Mon Dec 28 12:42:51 2015 /sbin/ip link set dev tunXYZ up mtu 1500
Mon Dec 28 12:42:51 2015 /sbin/ip addr add dev tunXYZ local 10.9.1.190 peer 10.9.1.189
$ vpnstatus.sh
VPN status: off - tunXYZ: 10.9.1.118
Terminating apps...
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.9.0.1 10.9.1.117 255.255.255.255 UGH 0 0 0 tunXYZ
10.9.1.117 0.0.0.0 255.255.255.255 UH 0 0 0 tunXYZ
128.0.0.0 10.9.1.117 128.0.0.0 UG 0 0 0 tunXYZ
176.126.237.217 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
----------
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
dev tunnel
$ sudo openvpn --config vpnbook-euro1-tcp443.ovpn
Mon Dec 28 12:53:36 2015 TUN/TAP device tunnel opened
Mon Dec 28 12:53:36 2015 TUN/TAP TX queue length set to 100
Mon Dec 28 12:53:36 2015 /sbin/ip link set dev tunnel up mtu 1500
Mon Dec 28 12:53:36 2015 /sbin/ip addr add dev tunnel local 10.9.1.222 peer 10.9.1.221
$ vpnstatus.sh
VPN status: off - tunnel: 10.9.1.14
Terminating apps...
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.9.0.1 10.9.1.13 255.255.255.255 UGH 0 0 0 tunnel
10.9.1.13 0.0.0.0 255.255.255.255 UH 0 0 0 tunnel
128.0.0.0 10.9.1.13 128.0.0.0 UG 0 0 0 tunnel
176.126.237.217 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
----------
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
dev funnel
$ sudo openvpn --config vpnbook-euro1-tcp443.ovpn
Mon Dec 28 12:55:36 2015 WARNING: 'dev-type' is used inconsistently, local='dev-type [unknown-dev-type]', remote='dev-type tun'
Mon Dec 28 12:55:29 2015 Error: problem with tun vs. tap setting
Mon Dec 28 12:55:29 2015 Exiting due to fatal error
----------
dev foo
$ sudo openvpn --config vpnbook-euro1-tcp443.ovpn
Mon Dec 28 12:56:35 2015 WARNING: 'dev-type' is used inconsistently, local='dev-type [unknown-dev-type]', remote='dev-type tun'
Mon Dec 28 12:56:18 2015 Error: problem with tun vs. tap setting
Mon Dec 28 12:56:18 2015 Exiting due to fatal error
----------
Please note that this was just a test, out of curiosity, of what devices
were accepted by openvpn. It seems the conclusion is that you can name
your device anything you want in the openvpn config file, as long as the
first 3 characters start with "tun".
James Dickson
Dec 28, 2015, 6:05:31 PM12/28/15
to
On Mon, 28 Dec 2015 14:15:39 -0800, Marek Novotny wrote:
> https://github.com/marek-novotny/tbird
Thanks for the URL to your latest tbird{a,b}.sh script!
That trick of appending the name of the script worked as follows:
1. WORKS https://github.com/marek-novotny/tbird
FAILS https://github.com/marek-novotny/vpntools/blob/master/tbirdb.sh
2. FAILS https://github.com/marek-novotny/vpntest
WORKS https://github.com/marek-novotny/vpntools/blob/master/vpntest.sh
3. FAILS https://github.com/marek-novotny/vpnstatus
WORKS https://github.com/marek-novotny/vpntools/blob/master/vpnstatus.sh
So, it wasn't obvious to me! :)
Given that there are two tbird scripts, I use mostly the tbirdb.sh
script, because my ISP changes, but I can understand the tbirda.sh
script is useful for those with a static list of IP addresses.
I'm on DSL so my IP address constantly changes whenever the IP
lease runs out, but when I'm on cable, I use tbirda.sh instead
because it's slightly safer in that it is restricted to a given
list of IP addresses instead of a given list of ISPs.
The related scripts I use are:
1. tbird{a,b}.sh <-- this checks what the IP address or ISP is,
allowing the set list of applications to start
only when the user is on the given set of IP
addresses or the given set of trusted ISPs
(although it seems similar to mlaunch.sh).
2. vpntest.sh <-- this runs openvpn on all the ovpn config files in
the current directory, allowing the user to kick
the ovpn files out or keep them depending on whether
they work or not (similar to ntest.sh in some ways).
3. vpnstatus.sh <-- this watches over the vpn session, causing an
immediate termination of a set list of apps, so
that the user's privacy isn't compromised when the
vpn fails while certain apps are still running.
> https://github.com/marek-novotny/tbird
Thanks for the URL to your latest tbird{a,b}.sh script!
That trick of appending the name of the script worked as follows:
1. WORKS https://github.com/marek-novotny/tbird
FAILS https://github.com/marek-novotny/vpntools/blob/master/tbirdb.sh
2. FAILS https://github.com/marek-novotny/vpntest
WORKS https://github.com/marek-novotny/vpntools/blob/master/vpntest.sh
3. FAILS https://github.com/marek-novotny/vpnstatus
WORKS https://github.com/marek-novotny/vpntools/blob/master/vpnstatus.sh
So, it wasn't obvious to me! :)
Given that there are two tbird scripts, I use mostly the tbirdb.sh
script, because my ISP changes, but I can understand the tbirda.sh
script is useful for those with a static list of IP addresses.
I'm on DSL so my IP address constantly changes whenever the IP
lease runs out, but when I'm on cable, I use tbirda.sh instead
because it's slightly safer in that it is restricted to a given
list of IP addresses instead of a given list of ISPs.
The related scripts I use are:
1. tbird{a,b}.sh <-- this checks what the IP address or ISP is,
allowing the set list of applications to start
only when the user is on the given set of IP
addresses or the given set of trusted ISPs
(although it seems similar to mlaunch.sh).
2. vpntest.sh <-- this runs openvpn on all the ovpn config files in
the current directory, allowing the user to kick
the ovpn files out or keep them depending on whether
they work or not (similar to ntest.sh in some ways).
3. vpnstatus.sh <-- this watches over the vpn session, causing an
immediate termination of a set list of apps, so
that the user's privacy isn't compromised when the
vpn fails while certain apps are still running.
Marek Novotny
Dec 28, 2015, 8:17:38 PM12/28/15
to
On 2015-12-28, James Dickson <JamesD...@example.com> wrote:
> On Mon, 28 Dec 2015 11:18:02 -0800, Marek Novotny wrote:
>
>> The script could be written in such a way as to determine any name,
>> which is what I might end up doing if the names are going to differ from
>> provider to provider.
>
> Your response above gave me the idea to test your vpnstatus.sh script
> against a given vpnbook ovpn config file for the various device names of
> tunX, tunXYZ, tunnel, funnel, and foo.
Adding the ? to the end is like adding a wild card but it can be only
>
>> The script could be written in such a way as to determine any name,
>> which is what I might end up doing if the names are going to differ from
>> provider to provider.
>
> Your response above gave me the idea to test your vpnstatus.sh script
> against a given vpnbook ovpn config file for the various device names of
> tunX, tunXYZ, tunnel, funnel, and foo.
one single character. So if it is tun0 or tun9 it would still work.
> Interestingly, your vpnstatus.sh script worked half way in that it
> recognized the tunnel name but not the fact the tunnel worked when there
> was more than one character after the three letters in the tunnel name.
the script which now doesn't use any pre-set name. But in order for it
to work you have to first run it without being connected to the VPN and
then you press any key so it can detect what the default device name is
without VPN. Then you connect to VPN and press any key and the script
detects if the default device changed and uses that changed name,
regardless of what it is.
https://github.com/marek-novotny/vpntools
I wrote some simple instructions into the script to make it easier. It
will tell you what to do and when to do it. Just follow it along and it
will detect whatever name the provider gives the device.
This is now version 2.9.
James Dickson
Dec 28, 2015, 10:26:15 PM12/28/15
to
Marek Novotny wrote:
> in order for it
> to work you have to first run it without being connected to the VPN and
> then you press any key so it can detect what the default device name is
> without VPN. Then you connect to VPN and press any key
I don't know if this is a good use model or not, but I think assuming a
> in order for it
> to work you have to first run it without being connected to the VPN and
> then you press any key so it can detect what the default device name is
> without VPN. Then you connect to VPN and press any key
single character (e.g., tun? => tun0 to tun9) is a reasonable assumption.
So, maybe the new use model isn't needed?
Anyway, I downloaded the new version 2.9 script and will test it and
report back in a few moments. I will test it with a couple of vpn services.
James Dickson
Dec 28, 2015, 10:35:10 PM12/28/15
to
Marek Novotny wrote:
> https://github.com/marek-novotny/vpntools
>
> I wrote some simple instructions into the script to make it easier. It
> will tell you what to do and when to do it. Just follow it along and it
> will detect whatever name the provider gives the device.
Here is the result of the first test.
> https://github.com/marek-novotny/vpntools
>
> I wrote some simple instructions into the script to make it easier. It
> will tell you what to do and when to do it. Just follow it along and it
> will detect whatever name the provider gives the device.
It worked exactly as advertised (it was tested with "tun0" in this test).
1. $ vpnsatus.sh
welcome to vpnStatus
----------------------------
this script needs to determine your default device name
and the vpn device name assigned by your provider
to do that we need to run two tests and compare the results
if you are not already disconnected from your vpn provider, disconnect now
press any key to continue
2. (we press "Enter")
default device detected as: wlan0
now we're going to determine the name of the tunnel
your vpn provider will use while connected to their vpn service
connect to your vpn provider now, and once connected...
press any key to continue
3. (in another window) $vpntest.sh
4. (back to the original window, we press "Enter")
you've been assigned the device: tun0
the script will alert you and take action if
the vpn provided device: tun0 drops at any time
VPN status: on - tun0: 10.211.1.5
Marek Novotny
Dec 29, 2015, 12:11:02 AM12/29/15
to
On 2015-12-29, James Dickson <JamesD...@example.com> wrote:
> Marek Novotny wrote:
>
>> in order for it
>> to work you have to first run it without being connected to the VPN and
>> then you press any key so it can detect what the default device name is
>> without VPN. Then you connect to VPN and press any key
>
> I don't know if this is a good use model or not, but I think assuming a
> single character (e.g., tun? => tun0 to tun9) is a reasonable assumption.
>
> So, maybe the new use model isn't needed?
Up to you. Github lets you grab any version committed.
> Marek Novotny wrote:
>
>> in order for it
>> to work you have to first run it without being connected to the VPN and
>> then you press any key so it can detect what the default device name is
>> without VPN. Then you connect to VPN and press any key
>
> I don't know if this is a good use model or not, but I think assuming a
> single character (e.g., tun? => tun0 to tun9) is a reasonable assumption.
>
> So, maybe the new use model isn't needed?
Here's how to download previous commits from github:
1. go to the repo:
https://github.com/marek-novotny/vpntools
2. click on the commits on the left side.
3. a list of commits will be listed with the newest on top, oldest on
the bottom. click on <> on the right side of the version you want.
4. click the Download ZIP button on the right side to down that
particular commit.
> Anyway, I downloaded the new version 2.9 script and will test it and
> report back in a few moments. I will test it with a couple of vpn services.
James Dickson
Dec 29, 2015, 1:46:28 AM12/29/15
to
Marek Novotny wrote:
> Here's how to download previous commits from github:
Thanks for that advice.
> Here's how to download previous commits from github:
I only use github to get your stuff, so, I'm unfamiliar with it.
I'm pretty much testing out your new use model, which is:
1. I run vpnstatus.sh to get it to recognize wlan0.
2. In another window, I run vpntest.sh in a directory filled with ovpn files.
3. This tries each ovpn config file, one by one, until one works.
4. When VPN is working on an ovpn file, I go back to vpnstatus.sh
5. In the end, I have two windows open when on VPN:
a. One window is the current vpn session, and,
b. The second window is the vpn status.
The best of both worlds would be to combine the scripts, where
the use model would simply be to cd into a directory filled with
potential ovpn files, and then run the command "vpnrun" or something.
But that's essentially what I'm doing with the two scripts anyway,
which is a great time saver, because only about 2/3 of the ovpn scripts
work at any one time, and about 1/5 of the vpn sessions die
prematurely.
So, vpntest.sh solves the 2/3rds problem while vpnstatus.sh solves
the 1/5th problem.
0 new messages