44net July 2019

44net@mailman.ampr.org

86 participants
91 discussions

Re: [44net] Connecting to 44net
by Brian Kantor 05 Sep '19

05 Sep '19

Cathryn, I see your ping requests arriving at 169.228.34.84 no problem, and they are being encapsulated at sent to 50.79.209.150, again, no problem. Nothing is coming back from 50.79.209.150. This suggests that something is filtering out protocol 4 (IPIP) between 169.228.34.84 and 50.79.209.150. A traceroute from 169.228.34.84 to 50.79.209.150 using ordinary UDP works, completing after 18 hops. The last few hops in that path look like this: 14 162.151.87.226 12.097 ms 12.315 ms 12.088 ms 15 162.151.79.134 12.735 ms 12.744 ms 12.773 ms 16 68.87.227.122 13.080 ms 12.983 ms 12.920 ms 17 * * * 18 50.79.209.150 37.676 ms 42.664 ms 33.084 ms A traceroute from 169.228.34.84 to 50.79.209.150 using protocol 4 (IPIP) does not complete, and there are no responses beyond hop 15. The last few hops are: 12 68.86.84.150 11.117 ms 12.601 ms 12.734 ms 13 68.86.94.154 11.761 ms 11.743 ms 11.340 ms 14 162.151.87.226 12.469 ms 12.162 ms 12.392 ms 15 162.151.79.134 12.757 ms 12.800 ms 12.797 ms 16 * * * 17 * * * 18 * * * This suggests that hop 16, 68.87.227.122, is not accepting/passing protocol 4 packets. The hostname for that host is lag-2-240-acr07.pinole.ca.sfba.comcast.net. I hate to throw you to the wolves of comcast's customer service line, but you may need to find out from them if they suddenly started filtering out inbound IPIP packets at that router. - Brian On Sat, Jun 29, 2019 at 09:50:40AM -0700, Cathryn Mataga via 44Net wrote: > Date: Sat, 29 Jun 2019 09:50:40 -0700 > From: Cathryn Mataga <cathryn(a)junglevision.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Subject: Connecting to 44net > > I'm not connected to 44net anymore, when I ping, to me at least, my > outgoing packets look correct, but I get no response ever. > > I'm trying to put together as much as I can. My gateway ips 44.4.28.50 > at 50.79.209.150, I have a static IP. > > I'm current on the portal, far as I can tell with no error messages. > > > ping 44.0.0.1 > PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. > *no response ever > > I see the outgoing, but never the ping back. > > tcpdump -vv -i enp4s0 host 169.228.34.84 > tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size > 262144 bytes > 09:39:25.982188 IP (tos 0x0, ttl 64, id 54479, offset 0, flags [DF], > proto IPIP (4), length 104) > hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64, > id 14161, offset 0, flags [DF], proto ICMP (1), length 84) > ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 105, > length 64 > 09:39:27.006173 IP (tos 0x0, ttl 64, id 54594, offset 0, flags [DF], > proto IPIP (4), length 104) > hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64, > id 15137, offset 0, flags [DF], proto ICMP (1), length 84) > ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 106, > length 64 > > I occasionally see one of these, which hints to me that ipip is making > it to my gateway. > > 09:39:15.386222 IP (tos 0x20, ttl 48, id 32657, offset 0, flags [none], > proto IPIP (4), length 60) > amprgw.ucsd.edu > hamradio.junglevision.com: IP (tos 0x0, ttl 237, > id 33644, offset 0, flags [none], proto TCP (6), length 40) > no-reverse-dns-configured.com.46324 > ke6i.ampr.org.finger: Flags > [S], cksum 0x039d (correct), seq 2046795537, win 1024, length 0 > > > ip tunnel list tunl0 > tunl0: any/ip remote any local any ttl 64 > > ifconfig tunl0 > > tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480 > inet 44.4.28.50 netmask 255.255.255.255 > tunnel txqueuelen 1000 (IPIP Tunnel) > RX packets 2259 bytes 305270 (298.1 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 2874 bytes 233904 (228.4 KiB) > TX errors 232 dropped 0 overruns 0 carrier 0 collisions 232 > > ifconfig enp4s0 > enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 50.79.209.150 netmask 255.255.255.240 broadcast > 50.79.209.159 > ether 8c:89:a5:64:04:4c txqueuelen 1000 (Ethernet) > RX packets 140452 bytes 25244334 (24.0 MiB) > RX errors 0 dropped 473 overruns 0 frame 0 > TX packets 53461 bytes 5807456 (5.5 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > ampr-ripd -d -t 44 -a 44.4.28.50/32 -s -L ke6i@cm87uu > Using gateway 50.79.209.158 for direct 44net endpoints via interface enp4s0. > Calling home > Waiting for RIPv2 broadcasts... > Simple password: *********** > > > ip rule list > > 0: from all lookup local > 44: from all to 44.0.0.0/8 lookup hamradio > 45: from all iif tunl0 lookup hamradio > 45: from 44.4.28.50 lookup hamradio > 32766: from all lookup main > 32767: from all lookup default > > > ip route list table hamradio > 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840 > 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840 > 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840 > ... > > I don't think it's a firewall issue, I've turned off firewall and it > doesn't fix anything. > > My route table looks healthy, so I think ampr-ripd is worrking correctly? > > Tried to include as much information as I can, thanks for any help! > > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

4 5

Re: [44net] mailman.ampr.org new IP address (Jay Nugent)
by Rob Janssen 30 Jul '19

30 Jul '19

> It *should* be a multi-step process: Why so difficult? The TTL in the ampr.org zone is one hour, and it has been for a long time. Rob

4 3

mailman.ampr.org new IP address
by Brian Kantor 29 Jul '19

29 Jul '19

Host mailman.ampr.org (where this and other mailing lists are hosted) has moved from address 199.249.230.93 to 44.76.7.7. This change was made because the 199.249.230.93 address was being blocked by too many blacklists due to other activity on the subnet. Unfortunately, whenever a mail handler such as 'mailman' gets a new address, it loses all the good will and reputation it has previously earned in various spam filters, so some recipients may miss out on a few messages because of over-enthusiastic spam filtering. There is nothing I know of to enhance its reputation except time. Your patience is appreciated. - Brian

5 9

Network Routers for Harsh Environments
by Jason McCormick 28 Jul '19

28 Jul '19

Hello all, I am looking for some recommendations on network routers for harsh environments. By harsh, I mean hot but not particularly dirty. I know there's a number of people on this list who use Mikrotik and Ubiquit EdgeRouters for your deployments and I am looking for thoughts on those product lines, as well as any other similar products. I am looking for a reasonably low-cost device. The key items I am looking for are: - Wide operating temperatures. Some of the sites are tower buildings that don't have A/C and during last week's heatwave the in-room temperature in one of the buildings was 105F-110F (killed an SRX power supply). None of the rooms will freeze in the winter but the temp will get quite low. - RELIABLE -- some of our sites have limited access and frequent power cycles, port failures, etc. are show stoppers - IPv6 support for basic routing and switching functions - Support for BGP and OSPFv3 (routing tables < 100 items) - VLAN tagging - IPSec or OpenVPN tunnels as clients - No firewalling or the ability to pass traffic without firewalls - note I don't mean a "permit any/any", I mean literally the device operates as a router or traffic can bypass a firewall-like function. - The device is a pre-packaged commercial system; I don't want to have to mess around with custom Linux/BSD installs, etc. - A device that can operate as both a router and switch would be nice, but not required As background, our club has a wide-area network around southwest Akron, Ohio-area stretching out to Rittman, Ohio and southeast to Alliance, Ohio with legs planned in other directions. This network supports a number of ham repeaters as well as other related services for the repeaters plus some of the site operations for the tower locations. Most of the gear is showing its age and we're going to start a wholesale replacement of most of it later this summer/autumn. All of the sites are connected with narrow-beam WiFi using point-to-point dishes, currently N but upgrading to AC AirMAX when we do the hardware refresh. Each site has a router or switch or both (depending on size and needs). The gear is a mix of Juniper SSG5s, Juniper SRXs, HP ProCurve switches, and some other random items. As part of the work, we're going to do a complete renumbering of the networks (which have grown up ad-hoc over the years), incorporate better use of 44Net space, and overlay IPv6 across the whole network. The reason for not wanting firewalling between the sites is we've run into problems with link reliability over UDP (losing a few packets) and also certain network device behaviors that don't survive multiple hops through stateful firewalls for a variety of reasons. Any thoughts in this community? I've been looking at the Mikrotik hEX S and the Ubiquiti EdgeRouter X as example devices. I don't have experience with Mikrotik gear although I hear it mentioned here a lot. Thanks Jason N8EI

4 3

Re: [44net] Is this a worry ?
by Rob Janssen 25 Jul '19

25 Jul '19

> < IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 106 > > They say a little knowledge is dangerous ! > At the moment at my tunl0 ( remote location ) I am getting groups of five of the above line every minute in my recently installed gateway. > I have tried without success to stop it appearing using iptables with < -A INPUT -p udp -i tunl0 --sport 5678 -j DROP >. Well, there is no need to do that really. Those packets are not dangerous, they sometimes may be even useful. This is a router discovery protocol that will inform you about manufacturer, version number of software, router name etc of the device sending it. When you have a device that supports it (sends it), you will also have some overview table in the user interface there which shows the decoded info received in the last 2 minutes or so. At first I also disabled this everywhere I saw it, and I am still not sending it on IPIP tunnels (where it actually is a bit troublesome for some cases because every minute such a packets would go out on all 500 tunnels at the same time and would result in a traffic burst that may overflow some queues somewhere and would result in packet loss of other usage). But on the VPN links that we use with our new style connections, I now keep it enabled. It provides a nice overview about who is connected and what software they are running, and I occasionally mail people that never upgrade their software to urge them to do so. As the mechanism for enabling/disabling these broadcasts has changed a little in the recent past in MikroTik firmware, and people not always update their software, some people that run an older YO2LOJ (Marius) script version may unknowingly be sending these things. But they are not dangerous and should not cause any noticable traffic volume. Rob

2 1

Re: [44net] 44 net connectivity
by Rob Janssen 25 Jul '19

25 Jul '19

> But, afer almost 20 years playing around witht his topic, I think the lack of specific network services on 44net is the actual element preventing the spread of its usage. > The original goal was conectivity, global if possible. > But there simply is no incentive for using it anymore. Dx clusters are reachable on the regular internet, repeaters and reflectors too. Specialized sites dedicated to contesting are homebrew stuff, or whatever, use regular internet access. They can not rely on a network where only 10k users are reachable. And BBS systems are outdated and replaced by forums, mailing lists and discussion groups on various platforms. > Unless we can find desirable services that really need a "private" globally routeable network for them to work, there will be no real new users influx beyond the occasional network enthusiast. I agree with that, it does not make much sense to run it as an isolated network. However, the 44net address space has enabled us to build a radio linked network and have infrastucture like repeaters, WebSDR, VoIP exchanges etc attached to it and also connect interested users to the same network. Without NAT issues. For that network to be useful though, it needs to be connected to internet in a reasonably efficient way. That is why we announced our country network on internet, and now we can use the services both on the radio network and from internet. (of course as far as firewall rules permit, you really don't want to route all traffic from internet to your radio network...) Still it is difficult to interest new users. However, when we get an interested user and he wants to setup some new service or experiment with what is there, shouldn't we make access to the network easy for new users, instead of making them fight with their router settings? The 44net also often makes things easier by having transparent routing. E.g. to setup a system with echolink usually is a nightmare because of the port forwarding requirements. By connecting to 44net and putting the echolink system on a 44net address, the filtering in the ISP router is eliminated and it is much easier to make it working. Rob

7 8

Re: [44net] 44 net connectivity
by Rob Janssen 25 Jul '19

25 Jul '19

> So that we don't have to have the same conversations twice -- let's move > this thread to 44ngn at mailman.ampr.org <https://mailman.ampr.org/mailman/listinfo/44net> I was against the creation of that second list, but I was too late to respond: it already was created. This inevitably creates such problems. I vote for deleting it. Now I have to find some way to use that new list, while using this one already is so difficult. With two lists it is becoming even more problematic... Rob

1 0

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 24 Jul '19

24 Jul '19

> >/Because we are trying to draft a new solution that would not work only for /> >/you, but also for others. You do not seem to be interested in that. / > Please quote me showing me saying I'm not interested in something new. > If there's something I *could* do where I don't have to increase my cost > not even $0.01/yr that's well documented I'd be quite happy to try > something out. Not once did I say I'm not interested, I have however > said don't scrap what's there that's working for me. The problem is that the new proposal will not work as smoothly and will be much more difficult to implement when the old system is to be left in place. That is because the new system is to be using automatic routing (with BGP or maybe OSPF when others can convince my that would work better), while the old system uses manual static routing managed by the portal. > >/Come on, it costs like $5-$10 per month per location to host such a service. / > Even this is still $5-10 per month more than I'm willing to spend. *you* are not supposed to be spending that money. It is to be spent by those that deploy the VPN servers. Hopefully ARDC. > >/And that is only when it is paid for. Last time I asked here for volunteers /> >/to host an echolink proxy farm, there were like 10 volunteers that would /> >/do (and did) it for free. It is likely that they would add such a VPN /> >/server feature to their already existing hosted system, if we would kindly /> >/ask it to them. / > Again, you're in the Netherlands, I am not. You most likely use 220v a/c > @50hz where we use 120v a/c at 60hz. Things are not the same here as > they are where you are and doubtful in other parts of the world as well. But NONE of those volunteers were from the Netherlands!! (they did not need to be, because I already host such a proxy farm in the Netherlands and the call for volunteers was to get more of them running across the world) The spread of volunteers was not as good as it could have been, but there were several from California, from Canada, from Australia, etc. Probably there are not so affected by backward internet connectivity (or lack of money) as you are. I don't know if they end up spending the $5/month for the benefit of amateur radio or if they got their hosting for free as part of some other deal. But they do offer the service! Voluntarily, without complaining. > Why would it be a waste of money? > I've wanted to see actual drafts and test environments where something new works. Because I think it is a waste of money (or a waste of time) to do a lot of research do potentially get a new product or another innovation started, for a community that is not interested in innovation and will make up any motivation to resist it. (including age, expense, "lack of reliability of the new system", and so on) You very well know that a system like the proposed one is operating in many other places, and the only proposed change is to interconnect those systems and make more of them, to replace the old and static system with something more flexible and more usable. > Why do I need internet connectivity from 44-net systems? It's a bonus > sure but I don't *need* it. Maybe you are mostly stuck in the usage scenario where AMPRnet is mostly used to emulate the old packet radio system, e.g. for BBS forwarding, DX cluster, telnet chat, etc. However, most new users who already know the internet want to do other things, like WebSDR, audio and video streaming (e.g. to YouTube), running amateur-oriented web services like a Mattermost server, etc. Internet connectivity is a must for most of these. > Often we forget many factors, some which we don't necessarily physically > see. No matter the solution, there will always be a very large amount of > points of failure. There's nothing you can do about that. But you can at least try! I remember seeing the questions here about having an IPIP gateway with more than one external address (e.g. using two different ISP links) to have redundancy at that level. Not possible, Sir! An IPIP tunnel endpoint has no way of seeing that the other side is down. With the newly proposed system this function would be no problem. BGP sees that a link is down and switches over to the alternate. Even within a second, when you configure BFD with it. But as long as the IPIP advocates get it their way, this will not happen. > One argument against IPIP however is it's deployment in the home. > Has anyone tried to simplify this? I have, and I've updated my system to > reflect the 2 subnets. All you do is set your device as the DMZ of your > router and run the install script which will ask for your 44-net info. I could deploy it to my home, but I have no need to do that. I already have a 5GHz WiFi link to our nearby (5 miles) access point so I get my AMPRnet over radio, thank you very much. And I have a VPN as a backup in case it somehow fails. In fact I have backup in 2 directions: when my VDSL connection fails, I can still surf the web via my amateur radio connection. If only to check the ISP website to see if there are any known interruptions. And there are several other stations here with the same setup. Not only do they have the above advantages, their systems also provide backup to the links between the access points. When the interlink to my accesspoint fails (another radio link), it would be automatically backed up via my own VPN and radio link. BGP does all that. The IPIP system can't. Rob

16 21

Re: [44net] Reverse DNS broken
by Cory (NQ1E) 24 Jul '19

24 Jul '19

Indeed, rdns for HamWAN is still broken (44.25.0.0/16). It appears to be because second level delegations were made on ARIN's DNS servers for every "44.x" label. Since that's at the same level as our delegation, DNS servers see it as an invalid "horizontal" delegation. Can you please see that the "25.44.in-addr.arpa." record is updated in ARIN's DNS servers to point to: a.ns.hamwan.net. b.ns.hamwan.net. Thank you, -Cory, NQ1E HamWAN $ dig +trace 25.44.in-addr.arpa. <snip> 44.in-addr.arpa. 86400 IN NS z.arin.net. 44.in-addr.arpa. 86400 IN NS x.arin.net. 44.in-addr.arpa. 86400 IN NS r.arin.net. ;; Received 92 bytes from 200.10.60.53#53(200.10.60.53) in 232 ms 25.44.in-addr.arpa. 86400 IN NS ns2.threshinc.com. 25.44.in-addr.arpa. 86400 IN NS ampr-dns.in-berlin.de. 25.44.in-addr.arpa. 86400 IN NS a.coreservers.uk. 25.44.in-addr.arpa. 86400 IN NS ampr.org. 25.44.in-addr.arpa. 86400 IN NS munnari.oz.au. ;; Received 181 bytes from 199.180.180.63#53(199.180.180.63) in 498 ms 25.44.in-addr.arpa. 3600 IN NS a.ns.hamwan.net. 25.44.in-addr.arpa. 3600 IN NS c.ns.hamwan.net. 25.44.in-addr.arpa. 3600 IN NS b.ns.hamwan.net. ;; BAD (HORIZONTAL) REFERRAL ;; Received 97 bytes from 192.109.42.4#53(192.109.42.4) in 269 ms 25.44.in-addr.arpa. 3600 IN SOA a.ns.hamwan.net. hostmaster.hamwan.net. 2019071706 900 180 604800 900 ;; Received 98 bytes from 44.24.245.2#53(44.24.245.2) in 11 ms On Fri, Jul 19, 2019 at 7:40 AM Tom Hayward via 44Net < 44net(a)mailman.ampr.org> wrote: > > > > ---------- Forwarded message ---------- > From: Tom Hayward <esarfl(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Fri, 19 Jul 2019 07:38:57 -0700 > Subject: Re: [44net] Reverse DNS broken > Seems 44.25.0.0/16 is still broken. It was previously delegated to [abc]. > ns.hamwan.net. > > Tom KD7LXL > > On Fri, Jul 19, 2019, 05:07 Job Snijders <job(a)ntt.net> wrote: > > > I think this is resolved now. > > > > On Fri, Jul 19, 2019 at 02:37 Job Snijders <job(a)ntt.net> wrote: > > > > > Some good debugging information was provided to me offlist , I've now > > > been in touch with ARIN staff and some changes were made. It may take a > > > few hours for the changes to be visible on the Internet, new zone file > > > needs to be generated & pushed out. > > > > > > My initial assessment is that the delegations for the remaining /10 and > > > /9 towards AMPRnet DNS servers didnt exist. I don't know whose > > > responsiblity it would've been to ensure that existed. I can't guess > why > > > they were missing, perhaps a coordination issue in the transfer process > > > from the previous state to the current state. > > > > > > The AMPRnet reverse DNS administators may want to verify that the > > > authoritative dns servers are configured not for for 44.in-addr.arpa, > > > but for the individual /16s within 44/8 that still are AMPRnet. I don't > > > know who manages that so I hope this message finds them. > > > > > > I'm running on fumes and only have 4 hours of sleep opportunity ahead > of > > > me - so signing off, I think things will probably restore in the next > > > few hours. > > > > > > Good luck! > > > > > > Job > > > > > > On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote: > > > > To help speed up the resolution process, it would be beneficial if > > > > someone provides me with data what exactly is broken, and what the > > > > values / parameters previously were. > > > > > > > > was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net, > > and > > > > r.arin.net? If not, where was it delegated? Where should it be > > > > delegated? > > > > > > > > Any tangible data about what the state currently is, and what it > should > > > > be; will help speed up recovery. > > > > > > > > Kind regards, > > > > > > > > Job > > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > > > > > ---------- Forwarded message ---------- > From: Tom Hayward via 44Net <44net(a)mailman.ampr.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: Tom Hayward <esarfl(a)gmail.com> > Bcc: > Date: Fri, 19 Jul 2019 07:38:57 -0700 > Subject: Re: [44net] Reverse DNS broken > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

3 4

Is this a worry ?
by gm4upx＠gb7jd.co.uk 24 Jul '19

24 Jul '19

< IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 106 > Hello, They say a little knowledge is dangerous ! At the moment at my tunl0 ( remote location ) I am getting groups of five of the above line every minute in my recently installed gateway. I have tried without success to stop it appearing using iptables with < -A INPUT -p udp -i tunl0 --sport 5678 -j DROP >. It shows as dropped when I monitor iptables but still appears when using tcpdump at the same time. It can be stopped by removing my ipencap entry but that stops my ampr-ripd reception was well. Is this just something I have to accept or is there a solution ? Regards, Ian..

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net July 2019