> I would propose an alternate solution. Since the number of such
> valid gateways is so very few, perhaps it would work well enough that
> someone must *be* a coordinator to set up a gateway whose outside-world
> address is in network 44.
Note it also involves routing subnets that belong to others...
I don't know how difficult it would be to add an extra property to a user
record, should be a minute of work in a LAMP environment, I guess.
Maybe a shortcut would be to add the "advanced user" property and initially set
it equal to the value of the "coordinator" property.
Then it can start operation quickly and should it turn out that really users
require this without being a coordinator then later some kind of UI can be
added to allow setting that. (by the users themselves, by coordinators, or
by admins, whatever seems best)
Rob
> I think somewhere less obvious (like under ones user profile) there
> should be a place to check a box to enable "advanced user options."
> And if that is checked then such abnormal things would be accepted?
> Not sure how feasible/easy that sort of thing is for Chris to code though.
I think that is actually the best idea. Adding a flag to each user (default false)
and using it to enable those things (checks that were present before!) should not
be that difficult.
At least it should be easier than adding an extra step in the workflow.
Rob
> and who would be responsible for turning the flag on/off?
> The user themselves? In which case aren’t we back to square one (with some/most users at least).
> or perhaps a coordinator?
> Do they want the extra responsibility?
When you fear that will be a problem I would suggest to set the flag to false
for everyone except experienced users like VE3TOK, DG8NGN, N1URO etc, and await requests to
enable it for others. I would be OK with managing that for my area as a coordinator.
I don't think that users are especially malicious, they just don't know what they want and
what they are doing. An extra procedure provides the opportunity to explain things more
clearly (in native language) and most users would not require the extra functions anyway.
I also suggest to remove all gateways that have no subnets (those are likely the result of experiments
that never went anywhere) and all gateways related to user accounts that have expired.
They are easy enough to re-add when desired.
There could be logging which gateways returned "ICMP - dest unreach" on the RIP broadcasts,
if so those that did so for a long time could be removed as well.
Then it is easier to have a closer look at what remains, to check if there are likely config errors.
Rob
All,
I'm getting consistent traffic from these gateways:
19:09:47.158200 IP (tos 0x0, ttl 244, id 38837, offset 0, flags [none], proto IPIP (4), length 150) 89.67.160.225 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 130) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 102
19:10:27.498793 IP (tos 0x28, ttl 241, id 46236, offset 0, flags [none], proto IPIP (4), length 159) 66.109.219.132 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 139) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 111
19:10:37.633539 IP (tos 0x0, ttl 242, id 10069, offset 0, flags [none], proto IPIP (4), length 166) 91.241.24.251 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 118
19:11:07.231425 IP (tos 0x0, ttl 246, id 59661, offset 0, flags [none], proto IPIP (4), length 174) 72.192.148.49 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 126
Is this a discovery protocol of some sort?
Do we have knowledge on how to turn it off?
73,
- Lynwood
KB3VWG
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
>
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
> 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
> 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
> 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
> 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
