What is the final outcome of the discussion?
Will any changes be made to the Portal to validate user input for default users?
Will there be a change in functionality w.r.t. having gateways with external address within AMPRnet?
Will incomplete gateway entries be deleted?
I hope we can have some outcome of the bad situation and following discussion, instead of leaving
everything as it is.
Rob
Although I wanted to provide a freely accessible demo for ALL ham
operators as an configuration example on an EdgeRouter, I'm starting to
have my doubts.
Especially to w6ray...
What is the use of hanging on a router web interface for 24h now? What
new information could it give you by watching its interface?
Marius, YO2LOJ
> I am happy to implement BK’s suggestion to limit the setting up of gateway endpoints that fall within the 44/8 range to co-ordinators.
> I am also happy to go through and remove any currently empty/incomplete gateways. Perhaps I could also setup a cronjob that purge such entries on a regular basis, e.g. any that are over a week old with no subnets?
> I can implement the above fairly quickly if that is what is wanted?
I would certainly appreciate that.
Even better would be to implement the addition of a new property 'advanced user' (initially copied from 'co-ordinator' and settable by you and Brian) and also the re-introduction of checking the subnets being routed by the gateway, depending on that property.
But even with only the changes mentioned above we should have some improvement in reliability.
Brian: I also wonder if the return if ICMP unreachable messages on RIP broadcasts is somehow logged or stored in a form that allows gateways that have done this for extended periods of time to be automatically disabled or deleted.
Rob
> 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
