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;
On Sun, 2019-04-07 at 15:29 +0200, Rob Janssen wrote:
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)
For the ipip mesh this is not an issue, yet obviously some still get confused. My dotun script asks 3 simple questions that many still can't seem to properly answer even though it's commented. I think the command-line environment of linux is what scares many away. Windows natively can not handle ip protocol 4 as M$ has remapped it for another service so that takes the GUI away. I suppose I could write tool as I've done for other things such as the amprnet DNS robot, and how to forward ip frames to another source... but the more these sort of tools are created, the more human tools we create by not passing on our knowledge... and when the "village elders" move on to another dimension (aka: SK) the knowledge may become lost.
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.
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.
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.
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.
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.
As with any database, the data is only as good as how it's entered. I believe there's some checks already in place but I don't know what more can be done as I haven't seen the source - and that's also not to say that the end user config has or can be verified either.
On 7 Apr 2019, at 18:31, Brian n1uro@n1uro.ampr.org wrote:
Rob et al;
...
As with any database, the data is only as good as how it's entered. I believe there's some checks already in place but I don't know what more can be done as I haven't seen the source - and that's also not to say that the end user config has or can be verified either.
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
-
Brian -
Chris -
Rob Janssen