44net April 2014

44net@mailman.ampr.org

62 participants
77 discussions

Re: [44net] AMPRNet BGP vs non-BGP routing
by Bryan Fields 11 Apr '14

11 Apr '14

On 4/11/14, 11:32 AM, Bart Kus wrote: > It allows our microwave network to remain connected to the rest of > AMPRnet as long as we have at least 1 ISP that isn't dead. The > microwave network peers with the Internet at 2 different points at > present, but more points will come in the future. It's a robustness > improvement in the face of partial failures, like in a natural disaster > when an ISP's fiber gets torn or their building collapses. So this is a hack to correct for the hack of AMPRnet IPIP tunnels. Argh, it makes my head hurt. If AMPRnet was treated like any other network on the internet, this problem would go away. At worst anyone not redundantly connected to the global internet would lose connectivity if their small gateway went down. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
by Brian Kantor 11 Apr '14

11 Apr '14

As far as I know, because of routing restrictions on the amprgw network connectivity, hosts on BGP-announced subnets of 44/8 will be unable to communicate with hosts on tunnel-routed subnets of 44/8 unless the BGP-announced subnet also runs a listed tunnel router gateway with a non-44/8 gateway address. This is because the building-level router one hop upstream from amprgw has a fixed route directing all 44/8 traffic to amprgw. This building-level router does not speak BGP and so cannot learn about BGP-announced subnets of 44/8. This is a historical artifact; it predates the availability of BGP-announced 44/8 subnets by many years. We hope to change this topology in the future to connectivity with the border router that DOES speak BGP, but indications are that that change will not be able to be done soon. In the meantime, gateway tunnel routers with a non-44 gateway address (that's all of them, except HamWan's proposed gateway) are the workaround to this restriction. I'm sorry for this difficulty but it's what we're stuck with for now. - Brian

6 12

Portal doesn't allow IPIP anycast via 44net
by Bart Kus 10 Apr '14

10 Apr '14

Hi, In trying to migrate HamWAN to IPIP anycast as discussed in a previous thread. I have run across a problem at the very last step. The relevant screenshot is at http://imgur.com/X2BfziT . Cannot attach the PNG due to message size restrictions. Basically, when I try to change the Gateway IP for our 44.24.240.0/20 subnet to be 44.24.221.1, I get the error message "Invalid gateway IP address". I'm sure this was intentionally coded at some point, but I believe this to be a design error. Here's why: 1) 44.24.221.1 is outside the associated prefix list for this gateway (44.24.240.0/20 only). 2) 44.24.221.0/24 will not be configured to have an IPIP gateway as it is being announced directly on the Internet. Given those two conditions, anyone with traffic for 44.24.240.0/20 can send it via Internet or IPIP to 44.24.221.1. When sending to 44.24.221.1 (outer IPIP header dst-addr), there should be no conflicting route and the default route should be taken, resulting in proper packet delivery to HamWAN. Can someone add this gateway manually and then fix the portal interface problem? Our tunnels are re-configured into the new desired state and awaiting packets. :) We are presently in AMPR tunnel downtime mode until that gateway is set + propagated. Thanks! --Bart

7 12

Can't communicate with 44.0.0.1 from 44-space?
by Bart Kus 09 Apr '14

09 Apr '14

Hi, I have a couple traces to share: [eo@Seattle-ER1] > /tool traceroute address=44.0.0.1 src-address=209.189.196.68 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 209.189.196.65 0% 10 1.9ms 0.8 0.4 1.9 0.5 2 209.189.202.195 0% 10 0.7ms 73.1 0.4 261 108.6 3 206.81.80.99 0% 10 0.7ms 5.1 0.5 10.7 3.9 4 69.28.171.145 0% 10 28ms 26.6 20 38.1 5.2 5 69.28.171.210 0% 10 22.8ms 21.4 18.6 31.9 3.9 6 198.32.176.33 0% 10 21.6ms 19.5 19.1 21.6 0.7 7 137.164.47.19 0% 10 21.4ms 24.1 21.4 29 2 8 137.164.46.67 0% 10 25.1ms 25.1 23.6 27.1 0.9 9 137.164.46.244 0% 10 34.7ms 33.5 32.4 35.6 1.2 10 137.164.47.15 0% 10 39.4ms 39.7 39.3 41.5 0.6 11 137.164.23.54 0% 10 39.7ms 40.2 39.5 43.2 1 12 132.239.254.163 0% 10 40.5ms 41.5 39.7 49.1 2.7 13 132.239.255.131 0% 10 39.6ms 40.2 39.6 43.1 1 14 44.0.0.1 10% 10 39.7ms 39.9 39.6 40.5 0.3 [eo@Seattle-ER1] > /tool traceroute address=44.0.0.1 src-address=44.24.242.22 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 209.189.196.65 0% 5 0.7ms 1.3 0.5 2.5 0.7 2 209.189.201.195 0% 5 3.5ms 1.5 0.5 3.5 1.2 3 206.81.80.99 0% 4 0.4ms 4.1 0.4 8.1 3.5 4 69.28.171.145 0% 4 25.7ms 24.7 19.6 29.6 3.6 5 69.28.171.210 0% 4 34.7ms 25.3 21.5 34.7 5.5 6 198.32.176.33 0% 4 19.5ms 20.4 19.3 23.2 1.6 7 137.164.47.19 0% 4 23.7ms 23.6 21.9 25.4 1.3 8 137.164.46.1 0% 4 24.4ms 26.3 24.4 27.5 1.2 9 137.164.46.248 0% 4 36.1ms 33.8 32.1 36.1 1.5 10 137.164.47.111 0% 4 42.9ms 40.3 39.1 42.9 1.6 11 137.164.23.54 0% 4 41.2ms 45.8 39.8 61.6 9.1 12 100% 4 timeout 13 100% 4 timeout 14 100% 4 timeout 15 100% 4 timeout 16 100% 4 timeout They'll look like crap without monospace font, and I don't wanna use HTML cuz the content of my message will be torn out of the email and replaced with a web link. So, adjust your fonts + screen size accordingly to properly view the traces. The only difference between them is the source address. Both addresses are bound to that router. That router holds IPIP tunnels to every ENCAP.txt network. Since 44.0.0.1 is not one of these networks, there is no tunnel that covers that IP, so the packets go over the regular internet. We BGP announce 44.24.242.22, so the trace from that IP should succeed in theory. Can someone explain what's breaking here and how to fix it? Thanks, --Bart

2 2

Linux Gateway Tutorial
by Neil Johnson 07 Apr '14

07 Apr '14

I'm trying to decide how to write a "How To" guide for setting up a Linux Gateway for the Wiki. I'm planning on basing it on the excellent guide found here (with Credit): http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/ But I'm wondering what level of Linux Administration and IP Networking Expertise I should assume. If I assume zero, it's going to be a looong guide, probably too long. Below is a link to the diagram I was planning to base the guide off of. AMPRNet Gateway Diagram - https://docs.google.com/drawings/d/1xAcMbROBpbuRFY0tVf1VdBrAP0ZQwTsE6Eqokn2… Comments welcome. Thanks -Neil

13 24

Wiki Updates
by Neil Johnson 07 Apr '14

07 Apr '14

All, I finished by volunteer stint at a youth robotics competition, so I have been poking around the Wiki making some changes. Mainly I have been adding some small pieces of content to eliminate the Wiki links that go to empty pages, but I have also rearranged some of the content on the main page. If you run across any issues, please let me know. I hope that is okay with everyone. -Neil -- Neil Johnson, N0SFH http://erudicon.com

1 0

Pi bug for ipencap?
by Brian Rogers 06 Apr '14

06 Apr '14

Greetings; I've noticed recently after doing a package update on the iproute packages I can no longer configure my tunnel interface tunl0. Mainly I'm trying to reset the ttl to 64 for traceroute to properly work. Everything I've searched comes up empty. Here's what I see: root@gw:/usr/local/bin# iptunnel show tunl0: ip/ip remote any local any ttl inherit nopmtudisc root@gw:/usr/local/bin# ifconfig tunl0 tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.88.0.1 Mask:255.255.255.255 UP RUNNING NOARP MULTICAST MTU:0 Metric:1 ttl is stuck on inherit and MTU autoconfigs to 0. This I know is set by nopmtudisc however if I try to adjust things: root@gw:/usr/local/bin# ip tunnel change tunl0 ttl 64 ttl != 0 and noptmudisc are incompatible root@gw:/usr/local/bin# ip tunnel change pmtudisc mode ipip add tunnel tunl0 failed: No such file or directory Why would it try to ADD? the command is CHANGE. Has anyone else suffered this before and if so what was the fix? Thanks in advance. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

4 6

Re: [44net] 44Net Digest, Vol 3, Issue 67
by Steve Wright 06 Apr '14

06 Apr '14

> The key here is access to "Amateur Radio Frequencies", e.g. getting on the > air / RF. Well, you cannot possibly open the door to the Internet, then close it again, or have half of it open and the other half closed, then change it again tomorrow, or change it when someone gets upset - all you are going to have is a 44net dominated by strong negative feelings and a whole lot of arguing - probably exactly what you have already. The decision has been made already to continue with an amateur PUBLIC 44net. If Members want to firewall off all incoming !44/8, then that is their choice, and they should do that, and no one should comment on their choice, and should certainly not be disparaging about it. Same rule applies to all others doing as they choose as well. Let's fix this wiki and get the documentation sorted. Steve ZL1BHD

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 66
by Bryan Fields 04 Apr '14

04 Apr '14

On 4/4/14, 3:13 PM, Steve Wright wrote: > This is going to go nowhere. Go play with your netrom nodes and have fun > pinging each other at 1200baud, and keep being hostile to wireless ISPs who > just offered the use of tens of thousands of $$ worth of outdoor 100mbit > gear for no charge. TBH, 99% of WISP's run gear in the 100's of dollars range, it's not professional or even ham radio grade IMO. I've seen some real poor installations and even seen them kicked off sites. We should strive to be better than the average WISP. I'd say there is not implied guarantee that some one using a 44/8 IP is going to be a licensed ham radio operator. You as a control operator of the station are ultimately responsible for the transmissions. I don't get to concerned about it personally. I cannot police 100% of the traffic transiting my nodes, and I don't think anyone can. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 66
by Steve Wright 04 Apr '14

04 Apr '14

> Hmm, even here you may notice several people with quite networking > experience wanted to get involved but when they asked for help because > it is not that easy to understand how 44net works as there is tremendous > lack of information, they got pretty rude replies, like, they should > write documentation themselves. > > It's like there is some kind of elitism. If you are not involved in > development since mid 70's, and if you actually need to read > documentation, then you are not in a game. Yup, exactly. > I'd like to grant access to Amateur Radio frequencies if the source ip > is within 44.0.0.0/8. I assume that only radio amateurs are "behind" > net44 addresses. You see, but that is completely useless, because you just firewalled the entire internet. This is going to go nowhere. Go play with your netrom nodes and have fun pinging each other at 1200baud, and keep being hostile to wireless ISPs who just offered the use of tens of thousands of $$ worth of outdoor 100mbit gear for no charge. Think about it. S

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2014