Can everyone verify their AMRPRNet tunl0 route tables do not include the following value:

"proto 44"

This appears to have somehow entered some stations routing tables, the value should be "table 44" for routers using a separate routing table, as defined in STARTAMPR; or by using '-t' switch with RIP44d.

The ROUTING PROTOCOL value "proto 44" is invalid for routing on AMPRNet, and I understand it should be zero (0) or unspecified.

- Lynwood KB3VWG

The 'proto 44' you see listed by the 'ip route list' is an internal netlink identificator and has nothing to do with the protocol on the network. It is used by ampr-ripd to identify the routes set by itself, to be able to avoid altering other routes set by other tools, and has no other meaning.

Marius, YO2LOJ

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Sunday, August 02, 2015 23:48 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing

(Please trim inclusions from previous messages) _______________________________________________ Can everyone verify their AMRPRNet tunl0 route tables do not include the following value:

"proto 44"

This appears to have somehow entered some stations routing tables, the value should be "table 44" for routers using a separate routing table, as defined in STARTAMPR; or by using '-t' switch with RIP44d.

The ROUTING PROTOCOL value "proto 44" is invalid for routing on AMPRNet, and I understand it should be zero (0) or unspecified.

- Lynwood KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

All,

OK, I've taken a look at my end, please test again, I found two issues:

- there was a phantom iptables rule preventing all outbound on the unencapsulated Public IP

- In the new script, I failed to properly add the rules for LANs on eth0. There should be a to and from rule to the network located on eth0:

TO

ip rule to <LAN/24> priority 10 ip rule from <LAN/24> priority 11

This rule must exist, exactly as noted. it should not specify a from/to your 44LAN.

- Lynwood

Marius,

I'm seeing odd behavior when I traceroute to you. My traffic destined for you is encapsulated properly, but (unless I need a valid IP), the packets seem to leave you unenscapsulated (perhaps using Masquerade NAT???) and travel toward the Main AMPR Gateway:

- first, I verified my route

user@kb3vwg-001:~$ ip route get 44.182.0.0 44.182.0.0 via 89.122.215.236 dev tunl0 src 44.60.44.2 cache window 840

- next, that source and destination would use the proper table:

user@kb3vwg-001:~$ ip rule show 0: from all lookup local 10: from all to 192.168.0.0/16 lookup main 11: from 192.168.0.0/16 lookup main 15: from all to 44.24.221.1 lookup main ****FROM YOU*** 22: from all to 44.60.44.0/24 lookup 42 **** 43: from all to 44.24.240.0/20 lookup 43 ****TO YOU***44: from all to 44.0.0.0/8 lookup 44 *** 45: from 44.0.0.0/8 lookup 44 4400: from 44.60.44.0/24 lookup 40 7777: from all to 44.0.0.0/8 lookup 7777 7778: from 44.0.0.0/8 lookup 7777 32766: from all lookup main 32767: from all lookup default

- finally, I traceroute from my tunnel: user@kb3vwg-001:~$ traceroute 44.182.0.12 -s 44.60.44.2 traceroute to 44.182.0.12 (44.182.0.12), 30 hops max, 60 byte packets

1 * * * !*!*!*!*!* 2 89.122.214.254 (89.122.214.254) 156.075 ms 157.348 ms 158.606 ms !*!*!*!*!* 3 10.0.225.49 (10.0.225.49) 160.229 ms 161.495 ms 162.890 ms 4 10.0.245.209 (10.0.245.209) 186.365 ms 188.425 ms 191.056 ms 5 10.0.200.138 (10.0.200.138) 192.674 ms 194.866 ms 196.200 ms 6 193.231.106.82 (193.231.106.82) 197.768 ms 175.030 ms 175.328 ms 7 tge1-2.fr4.ams.llnw.net (69.28.171.54) 185.121 ms 185.355 ms 177.489 ms 8 tge2-6.fr4.lga.llnw.net (69.28.189.49) 261.977 ms 260.528 ms 269.815 ms 9 tge1-2.fr4.ord.llnw.net (69.28.172.198) 287.947 ms 288.808 ms 285.129 ms 10 tge1-3.fr4.sjc.llnw.net (69.28.172.77) 345.404 ms 346.292 ms 329.787 ms 11 paix-px1--limelight-10ge.cenic.net (198.32.251.193) 335.805 ms 327.859 ms * 12 dc-lax-agg6--svl-agg4-100ge.cenic.net (137.164.11.0) 338.919 ms dc-svl-agg4--paix-px1-10g.cenic.net (137.164.47.21) 326.279 ms 332.317 ms 13 dc-riv-agg4--lax-agg6-100ge.cenic.net (137.164.11.3) 337.663 ms dc-lax-agg6--svl-agg4-100ge.cenic.net (137.164.11.0) 340.068 ms dc-riv-agg4--lax-agg6-100ge.cenic.net (137.164.11.3) 344.378 ms 14 dc-sdg-agg4--riv-agg4-10ge-2.cenic.net (137.164.47.15) 345.599 ms dc-riv-agg4--lax-agg6-100ge.cenic.net (137.164.11.3) 344.061 ms dc-sdg-agg4--riv-agg4-10ge.cenic.net (137.164.47.111) 344.344 ms 15 dc-sdg-agg4--riv-agg4-10ge-2.cenic.net (137.164.47.15) 352.518 ms dc-sdg-agg4--riv-agg4-10ge.cenic.net (137.164.47.111) 344.658 ms 352.857 ms 16 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 339.536 ms dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 347.626 ms nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 341.363 ms 17 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 414.562 ms ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 345.084 ms nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 387.159 ms 18 ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 350.108 ms 347.151 ms amprgw.sysnet.ucsd.edu (169.228.66.251) 348.789 ms 19 amprgw.sysnet.ucsd.edu (169.228.66.251) 342.078 ms 341.454 ms * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

It appears the traffic is entering your device, and then travling onward to the Main AMPR Gateway. I verified the traffic is encapsulated, by using Wireshark to monitor the line.

- Lynwood KB3VWG

Lynwood,

Thank you for pointing out the issue. It allowed unknown traffic coming from ampr machines to reach the GW, which is wrong. I corrected it in the firewall rules. Anyway, this should not prevent my gw from working. As I said, you can traceroute 44.182.21.1, 44.182.21.254 or 44.182.30.1 (the later not always up).

Could you please check again? Ttrace to 44.182.0.12 should die at hop 1 without forwarding.

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Tuesday, August 04, 2015 16:00 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing

(...)

- finally, I traceroute from my tunnel: user@kb3vwg-001:~$ traceroute 44.182.0.12 -s 44.60.44.2 traceroute to 44.182.0.12 (44.182.0.12), 30 hops max, 60 byte packets

1 * * * !*!*!*!*!* 2 89.122.214.254 (89.122.214.254) 156.075 ms 157.348 ms 158.606 ms !*!*!*!*!* 3 10.0.225.49 (10.0.225.49) 160.229 ms 161.495 ms 162.890 ms 4 10.0.245.209 (10.0.245.209) 186.365 ms 188.425 ms 191.056 ms 5 10.0.200.138 (10.0.200.138) 192.674 ms 194.866 ms 196.200 ms 6 193.231.106.82 (193.231.106.82) 197.768 ms 175.030 ms 175.328 ms 7 tge1-2.fr4.ams.llnw.net (69.28.171.54) 185.121 ms 185.355 ms 177.489 ms

(...)

Correction, the full command is:

ip tunnel change ttl 64 mode ipip tunl0

- Lynwood

Lynwood,

This has been discussed innumerable times here on this list, where myself and other BGP subnet operators have weighed in.

1. Some IPIP users route 44/8 through amprgw. Now that amprgw can reach us, this fixes their connectivity issues. 2. IPIP users who route properly by NATing out 44-net subnets that they don't have an IPIP tunnel for will reach us fine, and could reach us before.

This is not a matter of what the source IP is. This is a matter of amprgw could not reach non-IPIP subnets prior to now. Now it can, and traffic flowing through it can as well.

If an IPIP operator wants to *not* NAT out 44-net subnets that are *not* in the IPIP mesh and not have a default 44/8 route through amprgw, then they have no route, and can't reach us anyway.

Nigel K7NVH

(Please trim inclusions from previous messages) _______________________________________________ Nigel,

It does?

We considered a lot of these issues before (mainly when developing the first version of the boot script). Brian is able to ping because, as I recall, his actual Public IP address is 44...those who IPIP, our IPs are not.

• IPIP subnets would be required to configure masquerading, making our

Public IPs the one that actually reaching his device, or to require no further configuration;

• have traffic for BGPed subnets sent through the Main AMPRGW at

44.0.0.1 (on our table 44).

Also, the Security Update and Notes section of the startampr wiki covers issues for IPENCAP operators with: -reaching BGP subnets; and

• 44 subnets behind a tunnel with a 44 IP.

(read the last point in the NOTES section - Rob is the one who discovered it years ago, if you read his email earlier regarding more specific routes)

http://wiki.ampr.org/index.php/Startampr#2.0_Security_Update

• Lynwood

...

This is incredible news! WOOOOOOOOOO!

Thank you much for the work in that regard. This simplifies so much of the interconnectivity between BGP routed subnets, and IPIP users.

Nigel K7NVH

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Lynwood,

So, you are still reachable only via internet since there is no reply on requests via your tunnel.. Could you provide access to the script via internet (I would really see it - private mail is out of scope since aol does not like my provider...)? In fact if someone can reach your network via AMPR, than he has a working setup and doesn't need that script anymore, isn't it ;-)

Marius, YO2LOJ

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Wednesday, August 05, 2015 00:18 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing

...

Also, if you could look ay my script? Is it properly configured to reach your subnet? http://44.60.44.10/amprnet_docs/start_ampr_version2/startampr

...

Lynwood,

Please feel free to use my router at 44.12.6.1 to test against. It will respond to pings and reject UDP to show up in a traceroute. It is BGP announced only, and works properly from the public internet, and can reach AMPRGW.

Nigel K7NVH

(Please trim inclusions from previous messages) _______________________________________________ I should be reachable over the tunnel AND the Internet.

The script is still needed, it just wouldn't include instructions to reach subnets that are only accessible over BGPed 44 addresses. My 44.60.44.0/24 is configured to use a AMPRGW as its default route.

I am also able to ping you now (after I corrected the TO/FROM rule I improperly copied). I've always been properly configured (except for Saturday and Sunday, when I re-wrote my script).

When Brian made the route change on AMPRGW, it should have started to work.

• Lynwood

Marius wrote:

Lynwood,

So, you are still reachable only via internet since there is no reply on requests via your tunnel.. Could you provide access to the script via internet (I would really see it

private mail is out of scope since aol does not like my provider...)? In fact if someone can reach your network via AMPR, than he has a working setup and doesn't need that script anymore, isn't it ;-)

Marius, YO2LOJ

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Nigel,

user@kb3vwg-001:/usr/local/sbin$ ip route get 44.12.6.1 from 44.60.44.2 44.12.6.1 from 44.60.44.2 via 169.228.66.251 dev tunl0 cache

This appears to be correct, as you mentioned:

"This is not a matter of what the source IP is. This is a matter of amprgw could not reach non-IPIP subnets prior to now. Now it can, and traffic flowing through it can as well."

I'm unable to ping or traceroute.

When you mention: "It is BGP announced only, and works properly from the public internet, and can reach AMPRGW..." do you mean you're running an IPIP tunnel, or some other way of forwarding packets destined to 44.60.44.0/24, BACK to AMPRGW, or directly to me???

- Lynwood KB3VWG

Hi Lynwood and all,

the latest lessons learned specially from Tom and Rob concern and imply the standard use of the IPIP encap tunnels (i.e. tunl0) to effectively link the other, BGP-announced or not, gateways or amprnets and the amprgw at ucsd.edu/portal.ampr.org.

Adding all BGP routes are not effective being from here, on my site.

Quote from Tom:

We are properly BGP routed, so any machine on the internet (and not behind amprgw) should be able to access it.

so, it is impossible, for now, access the hamwan.org being behind amprgw, as explained.

gus

Gus, Nigel, Tom, et. al,

So are you saying that:

I CAN, or CANNOT send encap traffic to BGPed subnets:

via 169.228.66.251 dev tunl0
        cache

My understanding is that there was a routing change at AMPRGW that made this possible.

If not, it is still remains necessary:

• to manually add all ALL BGP routes (which I'm willing to do, I just

need to KNOW them all), or;

• that they operate an IPENCAP tunnel using a COMMERCIAL IP ADDRESS.

• Lynwood

Gus,

I was corrected by Brian. amprgw has been fixed so it can now relay packets to BGP networks like HamWAN. HamWAN.org should currently be accessible for all hosts on AMPR and the Internet at large.

Tom KD7LXL

Hi Tom,

Confirm again the no-reachability from here :(

root@ir0rm-7:/# ping HamWAN.org -c 5 PING hamwan.org (44.24.241.98) 56(84) bytes of data.

--- hamwan.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms

gus

OK,

I think I discovered the issue...

only the following IPs are available:

44.60.44.3 (DNS) 44.60.44.10 (HTTP) 44.60.44.14 (a PC, should be able to ping)

Stop there! All your 44 IPs are pingable and services become accessible:)

root@ir0rm-7:/# ping 44.60.44.1 PING 44.60.44.1 (44.60.44.1) 56(84) bytes of data. 64 bytes from 44.60.44.1: icmp_req=1 ttl=64 time=293 ms 64 bytes from 44.60.44.1: icmp_req=2 ttl=64 time=290 ms 64 bytes from 44.60.44.1: icmp_req=3 ttl=64 time=291 ms 64 bytes from 44.60.44.1: icmp_req=4 ttl=64 time=292 ms 64 bytes from 44.60.44.1: icmp_req=5 ttl=64 time=293 ms 64 bytes from 44.60.44.1: icmp_req=6 ttl=64 time=290 ms ^C --- 44.60.44.1 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5001ms rtt min/avg/max/mdev = 290.542/292.077/293.782/1.495 ms

root@ir0rm-7:/# ping 44.60.44.10 PING 44.60.44.10 (44.60.44.10) 56(84) bytes of data. 64 bytes from 44.60.44.10: icmp_req=1 ttl=63 time=292 ms 64 bytes from 44.60.44.10: icmp_req=2 ttl=63 time=292 ms 64 bytes from 44.60.44.10: icmp_req=3 ttl=63 time=292 ms 64 bytes from 44.60.44.10: icmp_req=4 ttl=63 time=293 ms 64 bytes from 44.60.44.10: icmp_req=5 ttl=63 time=291 ms ^C --- 44.60.44.10 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 291.261/292.501/293.274/0.826 ms root@ir0rm-7:/#

On Wed, Aug 5, 2015 at 3:53 PM, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:

I'm still having the same issue as Gus (can't reach BGPed subnets thru AMPR). I also confirm that I'm correctly encapsulating packets:

Brian,

Is there a rule on amprgw that blocks forwarding packets between 44 networks? I have heard discussion of such a rule in the past. The intent, as I understood it, was to require IPIP users to use the full mesh routes rather than relying on amprgw to act as a hub. If this rule in implemented on 44/8, it will blackhole BGP networks who don't take part in the mesh. (Maybe this was the intent?)

Tom KD7LXL

Testing shows that traffic between encap'd and BGP'd subnets of network 44 is now possible. There was a bug in the ipfw rules that fed the encapsulator that has been corrected and it seems to work now. - Brian

Nigel, please try the ping and traceroute to 44.134.32.240 and 44.134.32.233

gus

I can confirm I can reach Lynwood's host via AMPRGW through HamWAN now. ping 44.60.44.1 PING 44.60.44.1 (44.60.44.1): 56 data bytes 64 bytes from 44.60.44.1: icmp_seq=0 ttl=47 time=130.450 ms 64 bytes from 44.60.44.1: icmp_seq=1 ttl=47 time=119.830 ms

Nigel K7NVH

On 08/07/2015 01:37 PM, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ On Fri, Aug 07, 2015 at 08:37:35AM +0200, Gustavo Ponza wrote:

...

Nigel, please try the ping and traceroute to 44.134.32.240 and 44.134.32.233 gus

Gus, I can't ping or traceroute either of those addresses from the Internet. I can, however, reach both from n1uro's tracer test page indicating that you can be reached by the tunnel mesh.

Those addresses are not routed externally to ampr.org environment and so remain unknown as commercial/public addresses on the Internet.

Interestingly, I cannot ping your gateway 79.35.233.106. I can traceroute to your gateway. I suspect you have some sort of filter or firewall problem, possibly in your home router.

• Brian

Just checked the home router setup and found enabled the "SPI Firewall Protection" and "Block Anonymous internet requests"; now they are disabled and furthermore confirm no other access restricting are enabled now.

gus

Gus, Your route setup seems ok, but please note that your host IP (44.134.32.240) needs to be registered in the AMPR DNS to be forwarded by AMPRGW.

root@ir0rm-7:/# ip route|grep 44.0.0 44.0.0.1 via 169.228.66.251 dev tunl0 onlink window 840 44.0.0.0/8 dev tunl0 proto kernel scope link src 44.134.32.240

If those conditions are met and it still doesn't work, please provide a traceroute from your gateway to hamwan.org maybe we can see what's wrong.

Marius, YO2LOJ

...

Your route setup seems ok, but please note that your host IP (44.134.32.240) needs to be registered in the AMPR DNS to be forwarded by AMPRGW.

$ host 44.134.32.240 240.32.134.44.in-addr.arpa domain name pointer ir0rm-7.ampr.org.

confirmed by Brian

...

If those conditions are met and it still doesn't work, please provide a traceroute from your gateway to hamwan.org maybe we can see what's wrong. Marius, YO2LOJ

The traceroute to hamwan.org persists to show empty tracks:

root@ir0rm-7:/# traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ir0rm-7:/#

gus

John,

Yes, you should be able to send encapsulated data via amprgw and get the correct replies, but only for specific BGP announced and registered subnets.

Arbitrary 44net targets not in those BGP announced networks are NOT forwarded via amprgw, and only DNS registered hosts will be able to use the gateway (as you correctly assume).

Hosts with no DNS entries can only use the IPIP mesh system, since there is usually no check for that criteria on the gateways, and any subnet match is accepted.

Marius, YO2LOJ

(Please trim inclusions from previous messages) _______________________________________________ Brian,

I've been trying to follow these discussions, but am not sure I understand how it should work.

Should I be able to send encapsulated traffic for a BGP connected 44 address to amprgw.sysnet.ucsd.edu and have it de-capulated (if that is a word!) and sent over the Internet to the target host?

Would return packets follow the normal gating rules, and only be encapsulated and send over a tunnel to me if my address is in the DNS? Or would having sent a packet somehow enable a reverse path without a DNS Entry?

If I have to have a DNS entry for this to work, would it be possible for you to add a DNS entry for 44.131.56.7 host nottm.g8bpq.ampr.org so I can continue testing?

Thanks, John G8BPQ

...

But...exactly HOW do BGPed networks forward packets to IPENCAP gateways via AMPRGW...since they are not directly adjacent to AMPRGW (without a IPENCAP tunnel)???

AMPRGW would have to masquerade (or encapsulate, meaning the BGPed subnet still needs an IPENCAP tunnel) for us, right???

Any internet host (including a non-encap host like hamwan) trying to get to 44-net non-BGP'd hosts send their packets to UCSD where they get routed to amprgw. Amprgw looks up the gateway for the destination host and encapsulates the packet and forwards it to the gateway. The sending host doesn't have to be adjacent to UCSD; the Internet backbone takes care of the routing to UCSD.

Any encapped packet sent to amprgw from a host on a known gateway will be de-capsulated and placed on the Internet with the source address that of the sending host. In that sense, amprgw is masquerading as the sending host. Reply packets come back as above.

The design is indeed perfect but the practice reveals some faults.

Tests made on the latest days from here at 'ir0rm-7.ampr.org' towards the about 480 ampr hosts reveal that a lot of gateways under amprgw cannot be reached due to perhaps wrong or super-genius faulty setups.

Some tests, as known, gave the right results after some modification to their setups: so it is demonstrated that the amprgw and the RIP2 broadcast hosts operate correctly.

So as per my motto recommend "the simpler, the better".

When troubleshooting routing problems, traceroute can be a lot more helpful than ping. Often you can see how far the packet got.

• Brian

TNX for the info.

On this purpose, I discovered that *all* the reachable hosts like as per the following example show the same hidden path from position 1 to position 11 so it is a mystery the track/path followed. Furthermore the 44.0.0.1 like the hamwan.org results not pingable and then not traceable.

gus

----------------- root@ir0rm-7:# traceroute n1uro.ampr.org traceroute to n1uro.ampr.org (44.88.0.9), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 n1uro.ampr.org (44.88.0.9) 346.790 ms 346.975 ms 351.388 ms

Gustavo, are you able to reach (ping, traceroute, etc) any of the BGP-routed hosts (hamwan.org, wr6jpl.ampr.org, etc) via amprgw?

• Brian

Unfortunately not, Brian. Replies are the following

gus

----------------- root@ir0rm-7:# ping hamwan.org -c 5 PING hamwan.org (44.24.241.98) 56(84) bytes of data.

--- hamwan.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms

root@ir0rm-7:# ping wr6jpl.ampr.org -c 5 PING wr6jpl.ampr.org (44.16.15.5) 56(84) bytes of data.

--- wr6jpl.ampr.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms

root@ir0rm-7:# traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ir0rm-7:# traceroute wr6jpl.ampr.org traceroute to wr6jpl.ampr.org (44.16.15.5), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ir0rm-7:# ----------------

On Thu, Aug 06, 2015 at 12:05:22PM +0200, Gustavo Ponza wrote:

...

Tests made on the latest days from here at 'ir0rm-7.ampr.org' towards the about 480 ampr hosts reveal that a lot of gateways under amprgw cannot be reached due to perhaps wrong or super-genius faulty setups.

Some tests, as known, gave the right results after some modification to their setups: so it is demonstrated that the amprgw and the RIP2 broadcast hosts operate correctly.

So as per my motto recommend "the simpler, the better".

Another lesson learned: very TNX Marius!

From here now it results:

traceroute to n1uro.ampr.org (44.88.0.9), 30 hops max, 60 byte packets 1 gw.ct.ampr.org (44.88.0.1) 169.293 ms 175.416 ms 175.593 ms 2 n1uro.ampr.org (44.88.0.9) 180.007 ms * *

gus

Gus, Those 1 to 11 mistery hops are due to the fact that the TTL on your internet connection is inherited from the tunnel, which is the default tunnel behavior. If you set a ttl value on the tunnel interface, then these two become decoupled and the trace will become:

traceroute to n1uro.ampr.org (44.88.0.9), 30 hops max, 60 byte packets 1 n1uro.ampr.org (44.88.0.9) 346.790 ms 346.975 ms 351.388 ms

The tunnel accounting for a single hop.

Marius, YO2LOJ

All,

For your information, my colleague Tom was kind enough to write a tool that should let you run traceroutes from our network. If you can’t reach us via 44-net, you’ll obviously need to access via public internet.

http://trace.hamwan.net/ http://trace.hamwan.net/

Feel free to use it to test if you’re reachable from BGP announced subnets like ours.

Nigel K7NVH

On Aug 7, 2015, at 06:51, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:

(Please trim inclusions from previous messages) _______________________________________________

Gus,

I had errors and collisions before I reviewed my configuration. Now that's everything properly configured, I don't see them.

It may be helpful to note the only TWO reasons the collision and error count increases on a tunnel interface:

If the next hop of the encapsulated packet is the same tunnel interface: ipip.c line 437.

If the path MTU of the next hop for the encapsulated packet is less than 68:ipip.c line 447.

• Lynwood

-----Original Message----- note that (I'm not aware why) on the tunl0 interface there are many errors/collisions on the TX tunnel side.

Lynwood,

my tunl0 interface shows the following values:

tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.134.32.240 Mask:255.0.0.0 UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 RX packets:827174 errors:0 dropped:0 overruns:0 frame:0 TX packets:50426 errors:757836 dropped:0 overruns:0 carrier:0 collisions:757836 txqueuelen:0 RX bytes:75933090 (72.4 Mb) TX bytes:4817617 (4.5 Mb)

I'm not able to analyze what kinda packets are concerned on producing collisions...

gus

On 08/07/2015 03:51 PM, lleachii--- via 44Net wrote:

(Please trim inclusions from previous messages) _______________________________________________

Gus,

I had errors and collisions before I reviewed my configuration. Now that's everything properly configured, I don't see them.

It may be helpful to note the only TWO reasons the collision and error count increases on a tunnel interface:

If the next hop of the encapsulated packet is the same tunnel interface: ipip.c line 437.

If the path MTU of the next hop for the encapsulated packet is less than 68:ipip.c line 447.

• Lynwood

-----Original Message----- note that (I'm not aware why) on the tunl0 interface there are many errors/collisions on the TX tunnel side.

I've also restored my ping and traceroute programs.

You'll now find four tools:

ping ping44 trace trace44

ping/trace44 uses my AMPR IP address, ping uses my gateway's commercial IP.

- Lynwood

I purchased an OpenWRT-compatible Gigabit Ethernet router that has enough memory and storage to run AMPR Gateway on my border device.

What model?

El 13/08/15 a las 01:33, lleachii--- via 44Net escribió:

(Please trim inclusions from previous messages) _______________________________________________ All,

Has anyone successfully setup an IPENCAP tunnel and rip44d (or) ampr-ripd on an OpenWRT device?

If so, please provide information, packages installed, list of procedures (if you have them), etc.

I purchased an OpenWRT-compatible Gigabit Ethernet router that has enough memory and storage to run AMPR Gateway on my border device.

Dear Lynwood,

I have an OpenWRT router running as my AMPR/Hamnet gateway at router.ea4gpz.es.ampr.org.

I have ampr-ripd on it. I installed it a while ago, so I don't recall the details of how I cross-compiled it, but I guess that, being a simple C file it would be enough to just set up a cross-compiler and not the whole OpenWRT buildchain. My router happens to be PPC instead of the more common MIPS. If your router is also PPC by chance, then I can send you the ampr-ripd binary to save you the process of cross-compiling.

My script to start the tunnel and ampr-ripd goes like this:

-------------

ip tunnel add ampr0 mode ipip local 88.26.246.131 ttl 255 ip link set dev ampr0 up ifconfig ampr0 multicast ifconfig ampr0 44.133.28.155 netmask 255.255.255.255 ip rule add from 44.133.28.155 to 44.0.0.0/8 table 44 priority 5 ip route add default dev ampr0 via 169.228.66.251 onlink table 44

/root/ampr-ripd -s -i ampr0 -a 88.26.246.131 -t 44 -p pLaInTeXtpAsSwD

-----------------

Probably you would want to change the rules to route via table 44, which in my case are custom because there is both Hamnet and ampr-ripd routing at the site.

The script is mainly taken from the ampr wiki.

It seems to me that, apart from ampr-ripd, the only packages you need installed are ip and kmod-ipip, which I don't know if they come installed by default or not.

I hope you find this info useful.

73,

Dani EA4GPZ.

Who makes it? Sounds useful. What is the link to purchase one on Amazon?

I'll have to look at the board for the model.

It has:

• 16 MB Flash
• 128 MB RAM
• 5 GigE Ports
• 2 USB 2.0 Ports
• Serial Port
• VLAN Capable

I've also noticed another anomaly.

I recently switched to Verizon from Comcast, and began using their border device:

Three times I've noticed that when I'm using their FiOS Quantum Gateway - model G1100, that port forwardings for ICMP-Echo-Request and IPENCAP have disappeared from my forwarding table.

I cannot be certain why; but I will be removing their device from my border later today. It should also be noted that Verizon has access to their border devices; so I'll be rectifying that today.

- Lynwood

Test 2

Lynwood,

Your system does the encapsulation wrong.

If I ping it via the tunnel to 96.255.40.79, the reply are returned ipip encapsulated from ucsd (169.228.66.251) instead of having been originated from 96.255.40.79, and thus get dropped by most systems which expects the same endpoints for responses. Return/outgoing traffic from your system has to be originated from your GW address and sent directly to the recipient, according to the encap table, not via the gateway.

Marius, YO2LOJ

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Gustavo Ponza Sent: Monday, August 03, 2015 10:02 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing

(Please trim inclusions from previous messages) _______________________________________________

The files and README are located here for those on AMPRNet:

http://44.60.44.10/amprnet_docs/start_ampr_version2

No link from here to your address... but this fault remain the same, as normal, for several other sites i.e. N1URO, etc.

Setup here is the standard IPIP tunnel (tunl0) on 44.134.32.240 IP address and ampr-ripd v 1.13 with any kinda filters used.

As per other previous messages: I can confirm to Brian Kantor the very good setup of RIP2 service at ucsd.edu server for the *RIP time/rate broadcast* and for the very *short reaction* on portal.ampr.org when a dynamic IP address change occurs. Very TNX.

73, gus i0ojj _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net