> I would replace DROP by REJECT. DROP means the system will wait till the packet times out.
> For outgoing connections this may cause issues as the daemon that sends the unreachable will also wait till the packet times out before continuing
No, outgoing ICMP "destination unreachable" is not an outgoing connect and it makes no sense to REJECT them...
(this kind of packet should not be replied to)
Rob
>
> Given this, perhaps you could add a note suggesting that one or the list
> of blocks should be added when they reregister their gateway, that would
> eliminate any confusion... just my two cents.
This better:
—8< SNIP >8---
Hello {givenName},
This is a system generated email from the AMPRNet Portal.
This is a courtesy notice to advise you that your gateway entry has been removed.
Your gateway was removed by an automated process that looks for gateways that have had no attached subnets for at least one week.
Your gateway has met this criteria and has thus been removed.
It is important that the Portal data is kept up to date and accurate.
If you still want to run a gateway, please feel free to add your gateway back to the Portal.
Your gateway's details were:
Title: {gwTitle}
IP: {gwIP}
Host: {gwHost}
Notes: {gwNotes}
You have the following subnets allocated to you:
{listOfSubnets}
If you add your gateway back, please ensure that you allocate at least one subnet to it, otherwise this process will remove your gateway again in a week!
Kind Regards,
The AMPRNet Team
—8< SNIP >8—
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
