David,
The -e can be explained because your script doesn't have #!/bin/bash as the
first line, so whatever shell the user is in will run it. If that's a
non-bash shell, echo may not have any options. See
under Builtins for more details and
portable alternatives.
Regards,
Scott
ki4cuw
On Mon, Feb 18, 2019, 11:56 AM David Ranch <amprgw(a)trinnet.net wrote:
Hello Pete,
Anyone looking at using that script. dont forget
( like I did) to
install the net-tools package as the script use it and debian 9
does not
install it by default. (apt-get install net-tools)
Ok.. I've made a comment about that in the script. I'll publish that
new version in a bit.
On the next run of the script I did got a few
interresting result:
root@44gateway:/home/ve2pf# sh manual-ampr-start.sh
-e
creating tunl0 interface
allowing TTL of 64 for traceroute support and Path-MTU discovery
adding default AMPR route to 169.228.34.84
Current number of routes in AMPR44 route table: 1
-e
-----------------------------------------------------------------------
default via 169.228.34.84 dev tunl0 src
44.135.51.1 onlink
-e
-----------------------------------------------------------------------
I'm not sure why you're seeing all these stray "-e" but the setup
seems
to be running ok/
Enable Policy routing for traffic from 44 goes
back to 44
RTNETLINK answers: File exists
RTNETLINK answers: File exists
Those are ok.
Ping tests for specific AMPR hosts: (known
previously working hosts)
-e
n1uro:
-e -------------------------------
PING 44.88.0.9 (44.88.0.9) 56(84) bytes of data.
--- 44.88.0.9 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4076ms
Many remote AMPR stations require to learn known good AMPR routes first
before they will respond to *any* traffic. What many they do is take
the route list either from the RIP announcements or ENCAPS file, parse
them, and then load them into an iptables firewall WHITELIST. This
sometimes can take some time and if your external IP address changes
often, you might have a challenge to have remote stations keep up in
allowing your traffic into their stations.
One station might NOT require that and that's the AMPRGW at 44.0.0.1.
I've added a ping check for that IP into my script.
ampr-ripd already running; killing and
restarting
-e It wont die.. error!
I've added a sleep statement in the script to hopefully deal with this
but it's nothing to worry about.
I can ping the ampr gateway (169.228.34.84) so
that mean at least that I
am not loosing net connectivity. But a traceroute show
that the traffic on
the gateway is not using the tunl0 I am connected by ssh to eth0 and what I
find odd is that eth1 loose its IP adress and seem down from the ip -c a
command.
With the setup created by this script, traffic going to an AMPR address
will automatically go through the tunl0 interface. One address you should
be able to ping is the AMPR default gateway. If you do that ping, you
should see:
$ ping 44.0.0.1
PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data.
64 bytes from 44.0.0.1: icmp_seq=1 ttl=62 time=31.2 ms
64 bytes from 44.0.0.1: icmp_seq=2 ttl=62 time=29.5 ms
64 bytes from 44.0.0.1: icmp_seq=3 ttl=62 time=28.5 ms
^C
--- 44.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 28.538/29.804/31.295/1.136 ms
If you run tcpdump in another terminal window on your AMPR station using
the interface connected to your external ISP, you would see all the
protocol 4 encapsulation and the ICMP ping traffic inside it:
tcpdump -n -i eth0 not port 22 and not port 53 and not ip6 and not arp
--
09:21:53.861892 IP 96.78.144.186 > 169.228.34.84: IP 44.4.10.41 > 44.0.0.1:
ICMP echo request, id 24614, seq 1, length 64 (ipip-proto-4)
09:21:53.892722 IP 169.228.34.84 > 96.78.144.186: IP 44.0.0.1 > 44.4.10.41:
ICMP echo reply, id 24614, seq 1, length 64 (ipip-proto-4)
09:21:54.863001 IP 96.78.144.186 > 169.228.34.84: IP 44.4.10.41 > 44.0.0.1:
ICMP echo request, id 24614, seq 2, length 64 (ipip-proto-4)
09:21:54.892171 IP 169.228.34.84 > 96.78.144.186: IP 44.0.0.1 > 44.4.10.41:
ICMP echo reply, id 24614, seq 2, length 64 (ipip-proto-4)
09:21:55.864410 IP 96.78.144.186 > 169.228.34.84: IP 44.4.10.41 > 44.0.0.1:
ICMP echo request, id 24614, seq 3, length 64 (ipip-proto-4)
09:21:55.892531 IP 169.228.34.84 > 96.78.144.186: IP 44.0.0.1 > 44.4.10.41:
ICMP echo reply, id 24614, seq 3, length 64 (ipip-proto-4)
--
It's critical that you see both the requests AND responses and with that
tcpdump command, you can also use remote sites like
http://yo2tm.ampr.org/nettools.php to ping your AMPR IP address and see
unsolicited protocol 4 / IPIP traffic is coming into your AMPR station. If
it's not, your ISP is probably blocking this traffic and you'll need to
either see if they are willing to unblock that traffic or setup a VPN with
a IPIP friendly VPN provider (
http://wiki.ampr.org/wiki/AMPRNet_VPN ).
--David
KI6ZHD
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net