Pedja;
On Mon, 2019-07-22 at 23:27 +0200, Pedja YT9TP via 44Net wrote:
Well, the best step would be to make connecting easier, meaning, anything but IPIP.
That seems to be the vocal preference no?
I believe complexity of connecting, requirement for very specific and/or custom hardware and software to get connected it one of the strongest factors that keeps people away of 44net.
For IPIP I've made it extremely simple however this excludes windows clients.
Until there is simple option to connect using plain, stardard and widespread equipment, there will be no significant expansion.
Many hams are using RPi units as 'routers' now, and this allows for greater flexibility.
I disagree. Inventing new protocol is shooting not in the foot but in the head.
Not if it's done correctly.
We already have problem with IPIP that requires very odd configurations. Inventing new protocol that would not be supported in any existing routers is nonsense.
If an RPi is used it'd be quite simple actually. Also some routers allow for you to place a daemon in them as well and run it, most of them are linux based.
We need the very opposite - to use protocols that are wide spread and available in almost every device.
We as a community have developed protocols in the past that are in use today. Why couldn't we come up with something such as AGP (Amprnet Gateway Protocol for example) that could pass through most ISP filters on a device such as a Pi. We could then keep our "ASN" number as our callsign-ssid to identify who we are and keep it from propagating to the global internet and only for our own usage.
For the end user then, they could (for example) ifconfig eth0.1 44.x.x.x and push their amprnet block through their lan. This would also satisfy the lack of ipencap natively in windows for those who wish to use it as well. The RPi could incorporate local policy routing so that traffic to the global internet even from a windows device goes out eth0 while amateur traffic goes out eth0.1 for example...
or in the case of a VPN hub it could broadcast to that and the hub could route amprnet for the end user. The VPN host would know if the end user is up/down. Just a passing thought but you get the jist of it. Any protocol we were to come up with at least we could control and perhaps we could get it into hardware devices in the future once proven a valid protocol just as we got ax.25 into the native linux kernel stack.