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
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)
Maybe if the portal can flags specific issues, it could can then display additional options like say:
- RFC1918 address space (10.x.x.x/8, 172.16.x.x/12, 192.168.x.x/16) is not an allowed gateway address as it's non-routable over the Internet
- Specifying a 44.x.x.x address for a gateway is illegal except for very limited situations (this 44.x.x.x gateways address is BGP hosted and you still want access to the IP-IP tunneled system)
- IPv6 address space is not supported today
- etc
then under all that, offer a "bypass checks" option to let them do things anyway?
--David KI6ZHD
Hello all, my name is Eloy and I’m new to the mailing list and to the 44/8 network. As a new user I can tell what my experience has been so far.
-First is that most of the information needed is available in the Wiki, I spent a few hours reading before doing anything else. I was lucky enough that the configuration for Ubiquiti’s Edgerouter was in the Wiki as I own one.
-I felt that I had enough information and proceeded to create an account in the portal, and then asked for some IPs. The answer took only two days.
-Adding the gateway was easy, but It seemed weird that I could have selected other networks not assigned to me.
-I then created the IPIP tunnel in one of the interfaces of my router using the instructions provided. I’m not scared of CLI but usually prefer GUI. It’s fine, no big deal. Instructions are well written and easy to follow, It did NOT work. I understood was I was doing to the router and knew that It should have been working, but still, I did not work.
- Then I remembered that I read in the Wiki that I had register the IPs in the DNS.
-I could not find a way of contacting my coordinator directly from the portal, which forced me to google his callsign and send him a direct email. He answered very fast and added my IPs.
-After that everything has been working fine. Except that I can reach some servers from my ISP but not from the tunnel, they respond to pings though.
If anyone could check that I did well, I would appreciate It. My network is 44.98.7.0/28, right now only the gateway (44.98.7.1) and one server (44.98.7.2) are online.
All the process I described took little more than a week, I found the information I needed or deduced It from some other.
Eloy W4ERP
On Apr 7, 2019, at 2:28 PM, David Ranch amprgw@trinnet.net wrote:
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)
Maybe if the portal can flags specific issues, it could can then display additional options like say:
RFC1918 address space (10.x.x.x/8, 172.16.x.x/12, 192.168.x.x/16) is not an allowed gateway address as it's non-routable over the Internet
Specifying a 44.x.x.x address for a gateway is illegal except for very limited situations (this 44.x.x.x gateways address is BGP hosted and you still want access to the IP-IP tunneled system)
IPv6 address space is not supported today
etc
then under all that, offer a "bypass checks" option to let them do things anyway?
--David KI6ZHD _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Eloy,
I can reach your commercial address with https but not 44.98.7.1 or 44.98.7.2 with ping/http, etc. I tried your 44 addresses from 44.135.85.151 near Toronto.
73,
Bob VE3TOK
On 2019-04-07 3:26 p.m., eritter via 44Net wrote:
If anyone could check that I did well, I would appreciate It. My network is 44.98.7.0/28, right now only the gateway (44.98.7.1) and one server (44.98.7.2) are online.
All the process I described took little more than a week, I found the information I needed or deduced It from some other.
Eloy W4ERP
That is to be expected, since the ER instruction only tell the reader how to set up a point to point tunnel to the ampr-gw.
There is nothing related to the mesh network, and there is no way for it to function with that setup.
I will try to find some time to do a complete rework for the EdgeRouter in the Wiki.
Marius, YO2LOJ
On 08.04.2019 00:23, Boudewijn (Bob) Tenty via 44Net wrote:
Eloy,
I can reach your commercial address with https but not 44.98.7.1 or 44.98.7.2 with ping/http, etc. I tried your 44 addresses from 44.135.85.151 near Toronto.
73,
Bob VE3TOK
On 2019-04-07 3:26 p.m., eritter via 44Net wrote:
If anyone could check that I did well, I would appreciate It. My network is 44.98.7.0/28, right now only the gateway (44.98.7.1) and one server (44.98.7.2) are online.
All the process I described took little more than a week, I found the information I needed or deduced It from some other.
Eloy W4ERP
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
On Apr 7, 2019, at 5:54 PM, Marius Petrescu marius@yo2loj.ro wrote:
That is to be expected, since the ER instruction only tell the reader how to set up a point to point tunnel to the ampr-gw.
There is nothing related to the mesh network, and there is no way for it to function with that setup.
I will try to find some time to do a complete rework for the EdgeRouter in the Wiki.
Marius, YO2LOJ
On 08.04.2019 00:23, Boudewijn (Bob) Tenty via 44Net wrote: Eloy,
I can reach your commercial address with https but not 44.98.7.1 or 44.98.7.2 with ping/http, etc. I tried your 44 addresses from 44.135.85.151 near Toronto.
73,
Bob VE3TOK
On 2019-04-07 3:26 p.m., eritter via 44Net wrote: If anyone could check that I did well, I would appreciate It. My network is 44.98.7.0/28, right now only the gateway (44.98.7.1) and one server (44.98.7.2) are online.
All the process I described took little more than a week, I found the information I needed or deduced It from some other.
Eloy W4ERP
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 08/04/19 05:26, eritter via 44Net wrote:
Hello all, my name is Eloy and I’m new to the mailing list and to the 44/8 network. As a new user I can tell what my experience has been so far.
My experience has been fairly straightforward, but I have been working with IP for decades, so I _should_ know better! LOL
I had no issues with the portal, again, I have extensive networking experience, including VPNs and tunnels on both IPv4 and IPv6. I used a Raspberry Pi as my tunnel endpoint, and got it going on the IPIP mesh in fairly short order.
I haven't bothered with DNS registration, as I don't really need Internet access (too many legal issues here, once I start adding actual radio links). I'm also not a fan of manual processes, they are a much higher barrier and I have to be in the right mood to deal with the formal correspondence. Sure, I did it for my BGP announced subnet, but that was of much higher priority than a couple of DNS entries. :)
On 08/04/19 04:28, David Ranch wrote:
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)
Maybe if the portal can flags specific issues, it could can then display additional options like say:
- RFC1918 address space (10.x.x.x/8, 172.16.x.x/12, 192.168.x.x/16) is not an allowed gateway address as it's non-routable over the Internet
- Specifying a 44.x.x.x address for a gateway is illegal except for very limited situations (this 44.x.x.x gateways address is BGP hosted and you still want access to the IP-IP tunneled system)
- IPv6 address space is not supported today
- etc
then under all that, offer a "bypass checks" option to let them do things anyway?
That might be the best of both worlds - potential issues are flagged, extra information given, then the user given the option to change their information or continue anyway. If they know what they're doing, this is simply an extra mouse click on the portal. If they don't, then hopefully it will prompt them to come here and ask questions, if they're stuck.
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
The default gateway entry behavior should as idiot proofed as possible I.e. Not letting one entry a 44 IP as a gateway address, and not letting you add subnets you aren't associated with.
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.
Those are my thoughts.