44net April 2019

44net@mailman.ampr.org

35 participants
33 discussions

Re: [44net] 44Net Digest, Vol 8, Issue 57
by Roger Andrews 09 Apr '19

09 Apr '19

Eloy, I had the same issue and you need to do MSS Clamping. At least that’s what I was told and it fixed mine. Roger VA7LBB > > > > From: Eloy Ritter de Monredont <eritter(a)me.com> > Subject: Re: [44net] RIP problems? > Date: April 7, 2019 at 3:47:13 PM PDT > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > Bob, following your reply I remembered that that the gateway (44.98.7.1) is setup to not respond to pings and that, for now, the 44.98.7.2 is assigned to the WAN interface of a virtual router running Untangle which also does not respond to pings. I though the management interface of the hypervisor was connected and using that IP but that was a confusion on my side, it’s using my ISP’s IP. > I’ll be changing that later on. > > Now the issue is that the virtual machines on the LAN side of the virtual Router do browse the internet fine when the WAN is connected to the VLAN that correspond to my ISP, but when connected to the 44/8 network most sites load well but some don’t, I can ping them though. > The issue is the same using my personal computer when connected to the 44/8 network. > > Anyways, I just wanted to comment on my experience as a new user. I think that it could help improve the site. > The browsing issue could be addressed in a different thread. > > Eloy > W5ERP >

2 1

OpenWRT Routing Daemon
by M6XCV (Mike) 08 Apr '19

08 Apr '19

Hi, A while back I wrote a routing daemon for receiving RIP broadcasts and installing them in to the routing table. I turned this in to a complete setup script which worked on OpenWRT without needing to compile architecture-specific binaries. I kind of stopped working on it after I got it working, as my prefix is BGP routed so I don't have much need for it myself, however I just got back to it and have created a package for easy install. This single package should work on any OpenWRT/LEDE device as it only contains platform independent scripts and dependencies that are in the standard repositories. http://wiki.ampr.org/wiki/RIP44.lua If anyone is interested in testing it, I would appreciate any feedback. If it works well then it might be easier for new users to install than the current OpenWRT instructions requiring a binary build of ampr-ripd. The source is up on github (although technically the package contains the "source", as it's a Lua script!) if anyone wants to take a look. It does a very rudimentary job of executing the required commands to set up the interface, binding to a UDP socket, then parsing the received routes. https://github.com/NotMikeDEV/RIP44/ Thanks, Mike, M6XCV

1 0

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> I was just going through some of the portal pages and Chris has some > extensive online help next to the various text/check boxes in the "?" > circles. We can't hold Chris accountable for people not comprehending > what they read on the portal. The online help did seem pretty accurate > and well written. It is not to hold Chris accountable, but some extra text above the form (that also explains what a gateway is and that setting up a one may not be what you want to do as a beginner) could be helpful. Still, there can be problems. > People will always make mistakes. I've seen some enter in their internal > 192 or 10-net space IP as their commercial IP. Perhaps some sort of data > checker can be put in place? That may help. I hope the RFC1918 check is already made. If not it could be added. As I wrote before, there have been reasonable checks in place but people here have asked them to be removed because they wanted to do what the checks prevented. (like setting up a gateway with external address in net-44) Rob

8 8

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> If there are any additional checks that can be put into the Portal, I’m happy to add them if we can reach a consensus on what those checks should be... > Regards, > Chris Do you think it is viable to add another manual validation step for any gateway config that has one of these properties: - external gateway address is within 44.0.0.0/8 - advertised subnet is not owned by the gateway operator This would at least prevent mishaps like we had this week, because especially a gateway address within 44.0.0.0/8 should be throughly validated so that it is properly BGP routed to somewhere, and the operator of that destination can properly process the IPIP packets and not route them in a loop. Rob

1 0

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> The portal has made it easier for those to request blocks and for > routing to become a bit more efficient through RIP vs having to download > the encap.txt file and having to reload it every so often so the > automation is definitely welcomed in this regard. The whole concept of > ip encapsulation under ip is what confuses most people. Take OpenVPN for > example - people don't want to know it's using ip encapsulation, they > just want to configure it and have it work. Well, that is the issue. We provide OpenVPN certificates for local amateurs to connect to our gateway, and there rarely is any issue with that. (apart from people making 2 connections at the same time, which of course does not work because the certificate is directly bound to the user's IP address) But I think what happens is: people hear about this AMPRnet/HAMNET thing, they google a bit for information, and they get lost in technical documents not in their language, talking about something that is not their expertise, and expecting them to enter information in forms that they do not understand at all. Then it is not so surprising that some bogus information ends up in the system unless validation is improved, either in the software or in a manual step. The whole thing with RIP was definitely a good idea, and much better than regularly downloading and loading an encap.txt file. However, what can be improved is the entering and maintenance of the data that actually gets transmitted there. > That could turn into something a bit too time consuming as well for > those who would be in charge of taking responsibility for the > functioning systems of others such as coordinators. I'm not too worried about that, the assignment of IP addresses is also mostly a manual process here (from mail to hosts file), helped with some scripts to mail the update to the DNS robot and to place updated files on the server. The number of updates is relatively small, I get maybe one a week or up to 3 a week when it is a busy time. For gateways, this should be even less. Rob

3 2

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> Rob et al; > This user is flagged RADIO only in his config and should not be a listed > "gateway" at all: > ... > If this is causing an issue, let me know and I'll send him a note asking > him what he's looking to do and point him to a few things that may help > him out. Well, the recurring issue is that users do not really understand the whole system and still are expected to manage it themselves via the portal. This does not work well. They experiment with entering some data, see it appear listed under their account, but do not understand what it is for. They leave it there and move on to another experiment. I do not blame them, it is a complicated matter and there are many options of connecting to the network. On my own pages I strongly advise against using the portal and instead mail me with the request they have, usually they do not want to use IPIP anyway and registering on the portal does more harm than good. Of course it could be improved in the portal user interface, but it has been claimed before that restricting people to making valid entries (i.e. the external gateway address is NOT in net-44 and the advertised subnets are owned by the gateway operator) causes issues in some niche situations. Hence those checks have been removed, and users are no longer guided towards what they should and should not (and probably don't want to) do. Users get an address from me, and register a gateway in the portal with that address as external address (this is what caused the mishap this week!). Moreover, they have to add advertised networks and they do not understand that they first have to request a network to be assigned to them, and they pick a random network from the pulldown list (this happened with the same user). So I am all for a change towards a system where people like coordinators or other experienced users have to validate the entered gateway configuration before it becomes active. But recognizing that this would require more programming work in the portal (and thus in practice will not happen), I am for a reduction of the complexity and vulnerability of the system by removing dangerous capabilities that almost nobody uses, such as having the gateway address within net-44 and the advertisement of networks not owned by the user. They could still be allowed for existing users and could still be modified by administrators of the portal, but not by end-users. Rob

2 1

Re: [44net] RIP problems?
by Brian 06 Apr '19

06 Apr '19

Rob et al; This user is flagged RADIO only in his config and should not be a listed "gateway" at all: 44.118.1.1 2018-03-01 18:16:04 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1403> 44.118.1.2 2018-03-01 18:16:12 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1404> 44.118.1.3 2018-03-01 18:16:19 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1405> 44.130.104.1 2017-10-02 18:34:13 DG8NGN View If this is causing an issue, let me know and I'll send him a note asking him what he's looking to do and point him to a few things that may help him out. I know in Maine, they prefer to use M$ and software that's 100% GUI based. The problem however becomes that the sysop doesn't learn what they're doing because the GUI hides the technical information. -- I won't be like a Texas official and call Ocasio-Cortez a bimbo but she does think Roe vs Wade are two different ways to cross a river. ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

1 0

Re: [44net] RIP problems?
by Rob Janssen 06 Apr '19

06 Apr '19

Well, after a week of frantic searching how this problem came about, it has finally been pinpointed. It turned out to be an unfortunate consequence of someone setting up a bad gateway entry with the external IP within out 44.137.0.0/16 network, combined with strict firewalling that returns ICMP messages on bad traffic, a bug in the handling of those messages, and the way ampr-ripd handles the above type of gateways. Finally when Marius discovered that ICMP messages were going back to the gateway in his test setup, and when this happened amprgw abruptly ended the sequence of RIP packets, combined with the observation that putting delay between the packets actually made things worse, and removing of the bad gateway fixed it, finally lead to resolution of the problem. Now there are some bugs to fix, but also I looked in the gateway list and I found several more of those bad gateways! It looks like the gateway concept is difficult enough for people to understand as it originally was, and adding the possibility to have a gateway address inside net-44 really pushes complexity beyond what can be handled. And because it is (under strict conditions) allowed, the check in the gateway that simply rejects such entries has been removed. Look at what we have now: 44.2.11.1 2018-01-17 20:55:30 KK6NHN View <https://portal.ampr.org/gateways_list.php?a=view&id=1555> 44.2.11.2 2018-01-17 20:56:07 KK6NHN View <https://portal.ampr.org/gateways_list.php?a=view&id=1556> 44.24.172.41 2018-01-04 23:09:44 KG7PNQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1546> 44.24.241.98 2017-04-26 06:31:05 KD7LXL View <https://portal.ampr.org/gateways_list.php?a=view&id=1378> 44.94.17.129 2018-09-04 05:12:02 N0NCE View <https://portal.ampr.org/gateways_list.php?a=view&id=1695> 44.102.222.16 2019-03-24 22:27:29 W8HRV View <https://portal.ampr.org/gateways_list.php?a=view&id=1760> 44.118.1.1 2018-03-01 18:16:04 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1403> 44.118.1.2 2018-03-01 18:16:12 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1404> 44.118.1.3 2018-03-01 18:16:19 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1405> 44.130.104.1 2017-10-02 18:34:13 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1481> 44.130.104.2 2018-04-15 16:36:26 DL2QT View <https://portal.ampr.org/gateways_list.php?a=view&id=1613> 44.130.105.1 2017-10-02 18:35:03 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1482> 44.130.106.1 2017-10-02 18:35:32 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1483> 44.130.107.1 2017-10-02 18:35:55 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1484> 44.131.14.253 2017-05-06 07:29:35 M6XCV View <https://portal.ampr.org/gateways_list.php?a=view&id=1382> 44.136.150.2 2019-03-11 01:55:46 VK4AA View <https://portal.ampr.org/gateways_list.php?a=view&id=1386> 44.137.8.1 2018-10-01 09:41:51 PA0HWB View <https://portal.ampr.org/gateways_list.php?a=view&id=1707> 44.137.44.118 2018-01-14 23:25:39 PD2LED View <https://portal.ampr.org/gateways_list.php?a=view&id=1551> 44.137.48.78 2019-03-01 09:26:45 PE1OWG View <https://portal.ampr.org/gateways_list.php?a=view&id=1806> 44.144.46.240 2017-11-07 13:21:48 ON7AVC View <https://portal.ampr.org/gateways_list.php?a=view&id=1505> 44.151.38.60 2018-05-13 11:24:03 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1631> 44.151.38.61 2018-05-13 11:25:42 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1632> 44.151.38.62 2018-05-13 11:26:32 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1633> 44.159.112.16 2018-08-17 19:28:16 9V1AN View <https://portal.ampr.org/gateways_list.php?a=view&id=1683> Most of them have "no subnets" and I think they were only created by experimenting people who tried some options in the gateway and finally gave up for the day. Only these actually have subnets routed: 44.24.172.41 44.94.17.129 44.130.104.1 44.130.105.1 44.130.106.1 44.130.107.1 44.131.14.253 44.136.150.2 Several of those route a subnet that contains the actual gateway... often subnets so small that they cannot be BGP-routed on internet, so likely invalid as well. This whole thing causes quite some risk of malfunction, loops, etc. as was demonstrated this week. I propose that the existing gateways in the above list with no gateways (those not in the second list) to be removed, and the portal changed to again disallow the creation of new gateways within net-44. Then, the valid users should be encouraged to find a gateway IP outside of net-44 and this whole thing be phased out. Too much time has been wasted on debugging this problem already, and what advantage does it really bring? Rob

4 4

Re: [44net] RIP problems?
by Rob Janssen 06 Apr '19

06 Apr '19

> Until a decision is made about what to do long term here, maybe the AMPR > Portal web interface can change this name from "gateway" to "public > Internet IP (gateway)". I think that would help some people avoid this > issue. Either that, and/or a descriptive text above the form that explains what a gateway is, why you want to have it (and why not), and where to read more about it. There are those "hover" type help texts but I am afraid it is not enough. I think several "gateways" now listed (with no subnets) are the result of people wanting to register/publish their system information in a way that is more like what HamnetDB does. It should be clearer that creating a gateway here actually sets up routes and when done incorrectly can mess things up pretty badly. The announced subnets list has similar risks. For a while it was limited to subnets registered by the person logged in, there were people wanting to route subnets for others (probably to forward them internally) and this check was removed, and now people who do not completely understand what is going on are randomly announcing other people's subnets without anyone knowing. Perhaps best would be when all gateway setup had to be validated by someone with more experience (a coordinator, an old hat in AMPRnet, etc) before it becomes finalized, similar to the subnet allocation. Rob

1 0

Re: [44net] RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

Talked to network people at the ISP, they indicate that they have changed something w.r.t. the routing via Eurorings. It should be researched and hopefully fixed. In the meantime I am thinking about relaying the RIP packets from my own colo host to our gateway as an extra safeguard against things like this. I see that ampr-ripd has options -E and -F that should relay the raw packets to a specified address, good. That should work. But I don't think it is possible to make ampr-ripd receive and act upon those relayed packets, isn't it? Should I NAT them at the receiving system so they again have 224.0.0.9 as destination? Has anyone tried such a setup and does it work without nasty issues? (normally all RIP packets will be received twice in this case) Rob

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2019