its working!!!!!
got over 700 route when I do
ip route list table 44
I can ping some of the 44 network where none responded before. but I dont seem to be reachable from the outside.
Anyone can ping 44.135.51.1?? from my windows machine I cant ping that adress and a traceroute end at the edcu network.
Again a big thank you to David for the help and script. And to all that works on the 44 network!
Pierre VE2PF
________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de David Ranch amprgw@trinnet.net Envoyé : 18 février 2019 12:53 À : AMPRNet working group Objet : Re: [44net] Can't seem to grasp something
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net