/Because we are trying to draft a new solution that would not work only for /> >/you, but also for others. You do not seem to be interested in that. /
Please quote me showing me saying I'm not interested in something new. If there's something I *could* do where I don't have to increase my cost not even $0.01/yr that's well documented I'd be quite happy to try something out. Not once did I say I'm not interested, I have however said don't scrap what's there that's working for me.
The problem is that the new proposal will not work as smoothly and will be much more difficult to implement when the old system is to be left in place. That is because the new system is to be using automatic routing (with BGP or maybe OSPF when others can convince my that would work better), while the old system uses manual static routing managed by the portal.
/Come on, it costs like $5-$10 per month per location to host such a
service. /
Even this is still $5-10 per month more than I'm willing to spend.
*you* are not supposed to be spending that money. It is to be spent by those that deploy the VPN servers. Hopefully ARDC.
/And that is only when it is paid for. Last time I asked here for
volunteers /> >/to host an echolink proxy farm, there were like 10 volunteers that would /> >/do (and did) it for free. It is likely that they would add such a VPN /> >/server feature to their already existing hosted system, if we would kindly /> >/ask it to them. /
Again, you're in the Netherlands, I am not. You most likely use 220v a/c @50hz where we use 120v a/c at 60hz. Things are not the same here as they are where you are and doubtful in other parts of the world as well.
But NONE of those volunteers were from the Netherlands!! (they did not need to be, because I already host such a proxy farm in the Netherlands and the call for volunteers was to get more of them running across the world) The spread of volunteers was not as good as it could have been, but there were several from California, from Canada, from Australia, etc. Probably there are not so affected by backward internet connectivity (or lack of money) as you are. I don't know if they end up spending the $5/month for the benefit of amateur radio or if they got their hosting for free as part of some other deal. But they do offer the service! Voluntarily, without complaining.
Why would it be a waste of money? I've wanted to see actual drafts and test environments where something new works.
Because I think it is a waste of money (or a waste of time) to do a lot of research do potentially get a new product or another innovation started, for a community that is not interested in innovation and will make up any motivation to resist it.
(including age, expense, "lack of reliability of the new system", and so on)
You very well know that a system like the proposed one is operating in many other places, and the only proposed change is to interconnect those systems and make more of them, to replace the old and static system with something more flexible and more usable.
Why do I need internet connectivity from 44-net systems? It's a bonus sure but I don't *need* it.
Maybe you are mostly stuck in the usage scenario where AMPRnet is mostly used to emulate the old packet radio system, e.g. for BBS forwarding, DX cluster, telnet chat, etc. However, most new users who already know the internet want to do other things, like WebSDR, audio and video streaming (e.g. to YouTube), running amateur-oriented web services like a Mattermost server, etc. Internet connectivity is a must for most of these.
Often we forget many factors, some which we don't necessarily physically see. No matter the solution, there will always be a very large amount of points of failure. There's nothing you can do about that.
But you can at least try! I remember seeing the questions here about having an IPIP gateway with more than one external address (e.g. using two different ISP links) to have redundancy at that level. Not possible, Sir! An IPIP tunnel endpoint has no way of seeing that the other side is down. With the newly proposed system this function would be no problem. BGP sees that a link is down and switches over to the alternate. Even within a second, when you configure BFD with it. But as long as the IPIP advocates get it their way, this will not happen.
One argument against IPIP however is it's deployment in the home. Has anyone tried to simplify this? I have, and I've updated my system to reflect the 2 subnets. All you do is set your device as the DMZ of your router and run the install script which will ask for your 44-net info.
I could deploy it to my home, but I have no need to do that. I already have a 5GHz WiFi link to our nearby (5 miles) access point so I get my AMPRnet over radio, thank you very much. And I have a VPN as a backup in case it somehow fails. In fact I have backup in 2 directions: when my VDSL connection fails, I can still surf the web via my amateur radio connection. If only to check the ISP website to see if there are any known interruptions.
And there are several other stations here with the same setup. Not only do they have the above advantages, their systems also provide backup to the links between the access points. When the interlink to my accesspoint fails (another radio link), it would be automatically backed up via my own VPN and radio link. BGP does all that. The IPIP system can't.
Rob
Rob;
I'm taking this off list as I think we've pretty much beaten a dead horse beyond it's glue stage :)
On Mon, 2019-07-22 at 19:42 +0200, Rob Janssen via 44Net wrote:
The problem is that the new proposal will not work as smoothly and will be much more difficult to implement when the old system is to be left in place.
What we would need to have happen then is for those looking to migrate to the new system to continue (as you do) to run an IPIP gateway if they wish to have connectivity to those who are on IPIP until such a migration is complete. You don't want to cut off those who are on an existing link for the sake of just new topologies. It'd be like your ISP cutting off your PPP link for an ATM link because everyone else said they wanted an ATM link. It'd make no sense for them to just cut you off like that. I would think the same logic would apply here.
That is because the new system is to be using automatic routing (with BGP or maybe OSPF when others can convince my that would work better), while the old system uses manual static routing managed by the portal.
When I helped set up one ISP, we used BGP to our peers and OSPF internally. We found OSPF to be a tad faster in route updating than BGP. Not much but enough where it was noticable.
On our legacy packet system we use pc/FlexNet as our "backbone" as it handles ax.25 (even with IP encapsulated underneath) as BGP does on global internet. Works very slick even at slow speeds.
*you* are not supposed to be spending that money. It is to be spent by those that deploy the VPN servers. Hopefully ARDC.
I don't think it's the duty or function of ARDC to do this. Sure, this is a personal opinion of mine but I think funding can be better spent elsewhere such as new ham recruitment for example. We're leased a static block from the goodness of their heart, it should be our own responsibility in connecting to the network. Again we're fortunate that ARDC/BK has an IPIP server available. Years ago this was not the case if you recall.
But NONE of those volunteers were from the Netherlands!! (they did not need to be, because I already host such a proxy farm in the Netherlands and the call for volunteers was to get more of them running across the world) The spread of volunteers was not as good as it could have been, but there were several from California, from Canada, from Australia, etc. Probably there are not so affected by backward internet connectivity (or lack of money) as you are. I don't know if they end up spending the $5/month for the benefit of amateur radio or if they got their hosting for free as part of some other deal. But they do offer the service! Voluntarily, without complaining.
There's a small handful of users who's ISP filters them from even having more than 1 ipip socket open which I host for them on my system, free of charge. Initially I was going to use OpenVPN but it was more headache than it was worth and I didn't want to bother managing it. There's another I'm dealing with who's ISP is using watchdog timers to in a sense kill any type of network socket he's trying to maintain including SSH. He has an old router he's supposed to be putting OpenWRT on which should help so he can put his CPE into bridge mode and disable the watchdog timers.
Here, the ISPs deploy CPEs with watchdog timers fully enabled and the menu to disable them deleted from the firmwares for a couple of reasons, one of which is that they use the cheapest of gear with the least amount of ram in them and the watchdogs are supposed to help keep old NAT sessions flushed from ram. Another of course is to try and discourage you from running any sort of server services or additional networking through them. As I mentioned before, this is spreading like a cancer here... like SAFe did a couple of decades ago and we had to jump over that hurdle!
Because I think it is a waste of money (or a waste of time) to do a lot of research do potentially get a new product or another innovation started, for a community that is not interested in innovation and will make up any motivation to resist it.
I've seen your website and some of the projects you've done - very impressive! I don't think it'd be a waste of time at all! I think once a good draft is made, some sort of script to help those less network-inclinded to help migrate.. and it'd be all good. The portal (for now) could contain a tick box under "direct" perhaps for VPN, and that could push a newly requested block to a hub you propose via BGP - I'm assuming you propose internal usage BGP of sorts for this? Then we set up a time table as to when a cut off of IPIP may take place but until then we'd have to leave an IPIP gateway up either at the hubs or somehow push those on IPIP to UCSD for routing. It wouldn't happen overnight by all means!.. but it could be done over time.
You very well know that a system like the proposed one is operating in many other places, and the only proposed change is to interconnect those systems and make more of them, to replace the old and static system with something more flexible and more usable.
Correct, I'm very well aware of this... and a bit envious I can't do that here!
Maybe you are mostly stuck in the usage scenario where AMPRnet is mostly used to emulate the old packet radio system, e.g. for BBS forwarding, DX cluster, telnet chat, etc.
That's basically what we're limited to for various reasons which I won't get too deep into the specifics of but the reality is hams are losing sites because nobody wants us there. We did try to set up 2.5 and 5Ghz systems but our terrain is not favorable - way too many shadows and we can't get the real estate we need to fill the holes. Also there's a negative stigma with most clubs about 44-net in general. If it can be done on 44-net then it can be done more efficiently with a direct IP from the ISP is the attitude most take. I can't say I disagree with such logic. One thing 44-net does help give is some low level sense of security that one sourced with a 44-net IP most likely (although now not true) a ham.
However, most new users who already know the internet want to do other things, like WebSDR, audio and video streaming (e.g. to YouTube), running amateur-oriented web services like a Mattermost server, etc. Internet connectivity is a must for most of these.
That could actually open a can of worms here. A ham using ham frequencies to YouTube for example may constitute a violation of 3rd party communications regulations, or a ham with an asterisk server on ham freqs to phone a non ham may also fall under that same scope. While no rulings have been made or even presented I don't think anyone wishes to chance a black eye on their license in case it is looked at by our governing body. It's easier to keep such things off ham freqs and feel safer that you're not causing any harm to your status.
But you can at least try!
As I've mentioned, via VPN I have. Prior to getting IPIP working I had a VPN link with WA7V in Walla Walla Washington, which route wise about 12 hops further from me then UCSD. While the MTU was 1500 vs 1480 the IPIP tunnel was much faster for me.
I remember seeing the questions here about having an IPIP gateway with more than one external address (e.g. using two different ISP links) to have redundancy at that level. Not possible, Sir! An IPIP tunnel endpoint has no way of seeing that the other side is down.
Correct! There's no multi-home solution using IPIP, but now I'm wondering if BGP or OSPF through IPIP may help fix that?
With the newly proposed system this function would be no problem. BGP sees that a link is down and switches over to the alternate. Even within a second, when you configure BFD with it. But as long as the IPIP advocates get it their way, this will not happen.
Again, with a proper plan (ref: rule of 7 P's) it could happen it just has to be quite simplified for the networking challenged, and IPIP has to be given a cut off date of I would say at least 4-5 years for everyone to get on board with something new. This also gives plenty of time to configure a test-bed and let people at various levels of networking skills (or lack there of) to try it out before full deployment. In the interim however we can't just bump people off because some wish to change the method of connectivity.
I could deploy it to my home, but I have no need to do that. I already have a 5GHz WiFi link to our nearby (5 miles) access point so I get my AMPRnet over radio, thank you very much.
As do I from gw.ct.ampr.org which is a 2.5Ghz hotspot for amprnet. Only my main system connects to it for now.
And I have a VPN as a backup in case it somehow fails. In fact I have backup in 2 directions: when my VDSL connection fails, I can still surf the web via my amateur radio connection. If only to check the ISP website to see if there are any known interruptions.
While I don't have a VPN link anywhere at the moment, I probably could set one up somewhere... and I use Autostatus to constantly check not only my links but links to others I either support, or our RF legacy packet nodes. I modified it especially in it's fping routines to allow the slower speeds but it works and works well.
And there are several other stations here with the same setup. Not only do they have the above advantages, their systems also provide backup to the links between the access points. When the interlink to my accesspoint fails (another radio link), it would be automatically backed up via my own VPN and radio link. BGP does all that. The IPIP system can't.
Over there in Europe you do have a lot more leniency to do what you want to do, with the real estate resources to do it with. Here we unfortunately don't. Some areas of the country are doing Hamwan with some success - here hams are viewed more as a nuisance and our towers/antennas depreciate property value. In the state I live in, a few years back it was even declared that use of our mobile rigs constituted what they call "distracted driving" and is subject to criminal fines. I find this offensive not just for the fact that it's too strict a law, but the ARRL HQ is almost in my back yard and they did nothing to lobby against it.
If you want me to try a VPN/BGP link to you somehow I'd be willing to try it out and perhaps document the process in making it work.
On 22.07.2019 21:25, Brian via 44Net wrote:
That is because the new system is to be using automatic routing (with BGP or maybe OSPF when others can convince my that would work better), while the old system uses manual static routing managed by the portal.
When I helped set up one ISP, we used BGP to our peers and OSPF internally. We found OSPF to be a tad faster in route updating than BGP. Not much but enough where it was noticable.
BGP has one disadvantage, it would relay to private ASNs which is bad idea per se.
*you* are not supposed to be spending that money. It is to be spent by those that deploy the VPN servers. Hopefully ARDC.
I don't think it's the duty or function of ARDC to do this. Sure, this is a personal opinion of mine but I think funding can be better spent elsewhere such as new ham recruitment for example.
Well, the best step would be to make connecting easier, meaning, anything but IPIP.
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.
Until there is simple option to connect using plain, stardard and widespread equipment, there will be no significant expansion.
Because I think it is a waste of money (or a waste of time) to do a lot of research do potentially get a new product or another innovation started, for a community that is not interested in innovation and will make up any motivation to resist it.
I've seen your website and some of the projects you've done - very impressive! I don't think it'd be a waste of time at all! I think once a good draft is made, some sort of script to help those less network-inclinded to help migrate.. and it'd be all good.
I disagree. Inventing new protocol is shooting not in the foot but in the head.
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.
We need the very opposite - to use protocols that are wide spread and available in almost every device.
Ipip isn't the easiest to get connected with though there is enough help and docs available to folks willing to put in the time. But to be honest I would say a bigger deterrent to using 44 net is the nature of some of the discourse on here. I can't claim to be a Saint myself but honestly some people's dialog is frankly appalling. Yes there is some improvement to be made around technology but also some rules around acceptable use of the mailing list should go hand in hand with it.
Marc
Get BlueMail for Android
On 22 Jul 2019, 23:30, at 23:30, Pedja YT9TP via 44Net 44net@mailman.ampr.org wrote:
On 22.07.2019 21:25, Brian via 44Net wrote:
That is because the new system is to be using automatic routing
(with BGP or
maybe OSPF when others can convince my that would work better),
while the old
system uses manual static routing managed by the portal.
When I helped set up one ISP, we used BGP to our peers and OSPF internally. We found OSPF to be a tad faster in route updating than
BGP.
Not much but enough where it was noticable.
BGP has one disadvantage, it would relay to private ASNs which is bad idea per se.
*you* are not supposed to be spending that money. It is to be spent
by those that
deploy the VPN servers. Hopefully ARDC.
I don't think it's the duty or function of ARDC to do this. Sure,
this
is a personal opinion of mine but I think funding can be better spent elsewhere such as new ham recruitment for example.
Well, the best step would be to make connecting easier, meaning, anything but IPIP.
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.
Until there is simple option to connect using plain, stardard and widespread equipment, there will be no significant expansion.
Because I think it is a waste of money (or a waste of time) to do a
lot of research
do potentially get a new product or another innovation started, for
a community
that is not interested in innovation and will make up any motivation
to resist it.
I've seen your website and some of the projects you've done - very impressive! I don't think it'd be a waste of time at all! I think
once a
good draft is made, some sort of script to help those less network-inclinded to help migrate.. and it'd be all good.
I disagree. Inventing new protocol is shooting not in the foot but in the head.
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.
We need the very opposite - to use protocols that are wide spread and available in almost every device.
-- 73, Pedja YT9TP
Checkout: https://pedja.supurovic.net/ https://yu1abh.uzice.net/ https://www.facebook.com/yu1abh/ https://www.facebook.com/groups/yu1abh.konstruktori/ http://www.radio-amater.rs/
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
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.
On 23.07.2019 00:00, Brian 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?
Nope. It is a fact.
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.
RPi is a complication. I learned through years that in 44net community there will never be understanding about that.
And I also learned that we will never see significant expansion of 44net use.
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.
That is not solution. That is just more complication.
As long as 44net is inaccessible using plain, standard factory routers and standard protocols, it will not be expanding.
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.
I understand a principle, and I understand motivation but, c'mon. RPi is not solution. It is part of a problem.
Whole IT world uses standard devices and standard protocols, and it works. Why should anyone spend time, efforts and money to invent new protocol that does the same jsut a bit different and which would bnever become standard outside 44net?
After all, with BGP we have problem only that we cannot easily use public but have to use private ASNs - which is wrong way of doing it.
Al we need is another "instance" of BGP that would allow freely using new set of ASNs. So, why inventing new protocol, just alter existing one so you can run at lest two independent BGP layers on single machine.
But that would be custom protocol, non standard, not available anywhere except on custom set hardware.
And again, that is repellent for people. If we want people to join in, it must be simple and standard way using standard hardware and software. Anything that requires installing linux and setting up custom machine and administer would simply keep people away from 44net as it already does.
Please notice that I do not speak about concrete solutions. I am talking about principles. When we adopt principles we could talk how to implement them. You simply have to see big picture to be able to work on details.
There is nothing wrong with using private ASN's within a network. It's done by many (if not all) telecom and network operators and used for their internal network or connecting an internal customer with redundancy. If we were to use a separate public ASN for each and every customer router that needs redundancy we would quickly run out of ASN's and it'd be a mess.
When connecting to the internet, then indeed you need a public ASN which identifies who you are and what networks you route (using radb and the likes), but within a private network there is no need to use public ASN's. Even Vultr uses a private ASN to connect with your VPS if you want to route some public space via them.
rPi is not a problem btw, it is a solution to many problems. Standard of the shelf routers and modems will never support any kind of real openvpn tunneling or even ipsec tunneling, nor will they run any kind of standard routing protocols like BGP or OSPF, or even IPIP. Name me one brand of standard of the shelf routers that supports IPIP (or even any kind of dynamic routing protocol) out of the box without having to install an additional daemon
So why would a rPi be a complication or problem? Please explain that to me. If you want, you can even explain it of list.
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Pedja YT9TP via 44Net Sent: dinsdag 23 juli 2019 7:53 To: 44net@mailman.ampr.org Cc: Pedja YT9TP yt9tp@uzice.net Subject: Re: [44net] 44 net connectivity
On 23.07.2019 00:00, Brian 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?
Nope. It is a fact.
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.
RPi is a complication. I learned through years that in 44net community there will never be understanding about that.
And I also learned that we will never see significant expansion of 44net use.
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.
That is not solution. That is just more complication.
As long as 44net is inaccessible using plain, standard factory routers and standard protocols, it will not be expanding.
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.
I understand a principle, and I understand motivation but, c'mon. RPi is not solution. It is part of a problem.
Whole IT world uses standard devices and standard protocols, and it works. Why should anyone spend time, efforts and money to invent new protocol that does the same jsut a bit different and which would bnever become standard outside 44net?
After all, with BGP we have problem only that we cannot easily use public but have to use private ASNs - which is wrong way of doing it.
Al we need is another "instance" of BGP that would allow freely using new set of ASNs. So, why inventing new protocol, just alter existing one so you can run at lest two independent BGP layers on single machine.
But that would be custom protocol, non standard, not available anywhere except on custom set hardware.
And again, that is repellent for people. If we want people to join in, it must be simple and standard way using standard hardware and software. Anything that requires installing linux and setting up custom machine and administer would simply keep people away from 44net as it already does.
Please notice that I do not speak about concrete solutions. I am talking about principles. When we adopt principles we could talk how to implement them. You simply have to see big picture to be able to work on details.
-- 73, Pedja YT9TP
Checkout: https://pedja.supurovic.net/ https://yu1abh.uzice.net/ https://www.facebook.com/yu1abh/ https://www.facebook.com/groups/yu1abh.konstruktori/ http://www.radio-amater.rs/
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
"Name me one brand of standard of the shelf routers that supports IPIP"
I know that MikroTik and Ubiquiti Router support IPIP and they are standart of the shelf routers I myself use Mikrotik Router and all our DMR Repeaters that get their Internet with Cellular use MikroTik routers they are very reliable heve good GUI we can use them for that purpuse akso any OPEN WRT based routers support IPIP and OPENWRT support lot of on the shelf routers Ronen - 4Z4ZQ ________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@mailman.ampr.org on behalf of Ruben ON3RVH via 44Net 44net@mailman.ampr.org Sent: Monday, July 22, 2019 11:12 PM To: 'AMPRNet working group' 44net@mailman.ampr.org Cc: Ruben ON3RVH on3rvh@on3rvh.be Subject: Re: [44net] 44 net connectivity
There is nothing wrong with using private ASN's within a network. It's done by many (if not all) telecom and network operators and used for their internal network or connecting an internal customer with redundancy. If we were to use a separate public ASN for each and every customer router that needs redundancy we would quickly run out of ASN's and it'd be a mess.
When connecting to the internet, then indeed you need a public ASN which identifies who you are and what networks you route (using radb and the likes), but within a private network there is no need to use public ASN's. Even Vultr uses a private ASN to connect with your VPS if you want to route some public space via them.
rPi is not a problem btw, it is a solution to many problems. Standard of the shelf routers and modems will never support any kind of real openvpn tunneling or even ipsec tunneling, nor will they run any kind of standard routing protocols like BGP or OSPF, or even IPIP. Name me one brand of standard of the shelf routers that supports IPIP (or even any kind of dynamic routing protocol) out of the box without having to install an additional daemon
So why would a rPi be a complication or problem? Please explain that to me. If you want, you can even explain it of list.
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Pedja YT9TP via 44Net Sent: dinsdag 23 juli 2019 7:53 To: 44net@mailman.ampr.org Cc: Pedja YT9TP yt9tp@uzice.net Subject: Re: [44net] 44 net connectivity
On 23.07.2019 00:00, Brian 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?
Nope. It is a fact.
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.
RPi is a complication. I learned through years that in 44net community there will never be understanding about that.
And I also learned that we will never see significant expansion of 44net use.
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.
That is not solution. That is just more complication.
As long as 44net is inaccessible using plain, standard factory routers and standard protocols, it will not be expanding.
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.
I understand a principle, and I understand motivation but, c'mon. RPi is not solution. It is part of a problem.
Whole IT world uses standard devices and standard protocols, and it works. Why should anyone spend time, efforts and money to invent new protocol that does the same jsut a bit different and which would bnever become standard outside 44net?
After all, with BGP we have problem only that we cannot easily use public but have to use private ASNs - which is wrong way of doing it.
Al we need is another "instance" of BGP that would allow freely using new set of ASNs. So, why inventing new protocol, just alter existing one so you can run at lest two independent BGP layers on single machine.
But that would be custom protocol, non standard, not available anywhere except on custom set hardware.
And again, that is repellent for people. If we want people to join in, it must be simple and standard way using standard hardware and software. Anything that requires installing linux and setting up custom machine and administer would simply keep people away from 44net as it already does.
Please notice that I do not speak about concrete solutions. I am talking about principles. When we adopt principles we could talk how to implement them. You simply have to see big picture to be able to work on details.
-- 73, Pedja YT9TP
Checkout: https://pedja.supurovic.net/ https://yu1abh.uzice.net/ https://www.facebook.com/yu1abh/ https://www.facebook.com/groups/yu1abh.konstruktori/ http://www.radio-amater.rs/
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
"Name me one brand of standard of the shelf routers that supports IPIP"
Cisco Juniper Mikrotik
By the way, http://etutorials.org/Networking/Integrated+cisco+and+unix+network+architectures/Chapter+11.+VPN+Technologies+Tunnel+Interfaces+and+Architectures/IP-IP+Tunnel/ has a tutorial/lab on setting up IPIP tunnels on both Cisco and Linux systems. - Brian
The reality at least in most parts of the US, most residential and even business customers *must* use the ISP provided router to get any support. It's these ISPs and routers:
- Many US ISPs won't forward atypical protocols as they filter IPIP and other protocols - https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#pro... over their ingress, backbone, and egress.
- These ISP routers can have intentionally limited functionality so customers cannot theoretically shoot themselves in the foot
- These routers don't support forwarding of non-TCP / non-UDP traffic to ANY port (no "DMZ" support)
- These don't support bridging or their bridging support is completely messed up (I'm looking at you Comcast Business)
I generally agree that centralizing the traffic distribution to VPN hubs is non-optimal. For those who wish to use AMPR for any voice technologies like DMR, YSF, P25, AllStar, IRLP, EchoLink.. end to end latency matters. Going through every network hop hurts.
To the ease of use AMPR point and to find an acceptable lowest common denominator for traffic forwarding, it should TCP or UDP *only*. No other IP protocols will really cut it due to many of these lame router implementations. Yes, there are higher end solutions out there that do it better (Cisco, Juniper, Mirotik, OpenWRT, DD-WRT, etc) but their usability for the common Internet user can be generally poor. Considering the state of ISP's required routers and their limitation, I have to believe that a *UDP* transport would be the best way to go. Existing examples of this could be NAT-T IPSEC traversal, AXUDP, etc.
--David KI6ZHD
On 07/23/2019 01:42 AM, Brian Kantor via 44Net wrote:
"Name me one brand of standard of the shelf routers that supports IPIP"
Cisco Juniper Mikrotik
By the way, http://etutorials.org/Networking/Integrated+cisco+and+unix+network+architectures/Chapter+11.+VPN+Technologies+Tunnel+Interfaces+and+Architectures/IP-IP+Tunnel/ has a tutorial/lab on setting up IPIP tunnels on both Cisco and Linux systems.
- Brian
billion7800 series
On 23 July 2019 at 09:32 R P via 44Net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org > wrote:
"Name me one brand of standard of the shelf routers that supports IPIP" I know that MikroTik and Ubiquiti Router support IPIP and they are standart of the shelf routers I myself use Mikrotik Router and all our DMR Repeaters that get their Internet with Cellular use MikroTik routers they are very reliable heve good GUI we can use them for that purpuse akso any OPEN WRT based routers support IPIP and OPENWRT support lot of on the shelf routers Ronen - 4Z4ZQ ________________________________ From: 44Net <44net-bounces+ronenp=hotmail.com@mailman.ampr.org mailto:44net-bounces+ronenp=hotmail.com@mailman.ampr.org > on behalf of Ruben ON3RVH via 44Net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org > Sent: Monday, July 22, 2019 11:12 PM To: 'AMPRNet working group' <44net@mailman.ampr.org mailto:44net@mailman.ampr.org > Cc: Ruben ON3RVH <on3rvh@on3rvh.be mailto:on3rvh@on3rvh.be > Subject: Re: [44net] 44 net connectivity There is nothing wrong with using private ASN's within a network. It's done by many (if not all) telecom and network operators and used for their internal network or connecting an internal customer with redundancy. If we were to use a separate public ASN for each and every customer router that needs redundancy we would quickly run out of ASN's and it'd be a mess. When connecting to the internet, then indeed you need a public ASN which identifies who you are and what networks you route (using radb and the likes), but within a private network there is no need to use public ASN's. Even Vultr uses a private ASN to connect with your VPS if you want to route some public space via them. rPi is not a problem btw, it is a solution to many problems. Standard of the shelf routers and modems will never support any kind of real openvpn tunneling or even ipsec tunneling, nor will they run any kind of standard routing protocols like BGP or OSPF, or even IPIP. Name me one brand of standard of the shelf routers that supports IPIP (or even any kind of dynamic routing protocol) out of the box without having to install an additional daemon So why would a rPi be a complication or problem? Please explain that to me. If you want, you can even explain it of list. 73, Ruben - ON3RVH -----Original Message----- From: 44Net <44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org mailto:44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org > On Behalf Of Pedja YT9TP via 44Net Sent: dinsdag 23 juli 2019 7:53 To: 44net@mailman.ampr.org mailto:44net@mailman.ampr.org Cc: Pedja YT9TP <yt9tp@uzice.net mailto:yt9tp@uzice.net > Subject: Re: [44net] 44 net connectivity On 23.07.2019 00:00, Brian 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?> Nope. It is a fact.>> 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 forgreater flexibility. > RPi is a complication. I learned through years that in 44net community there will never be understanding about that.And I also learned that we will never see significant expansion of 44net use. >> 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 routersallow for you to place a daemon in them as well and run it, most of them are linux based. > That is not solution. That is just more complication.As long as 44net is inaccessible using plain, standard factory routers and standard protocols, it will not be expanding. >> 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 usetoday. 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. > I understand a principle, and I understand motivation but, c'mon. RPi is not solution. It is part of a problem.Whole IT world uses standard devices and standard protocols, and it works. Why should anyone spend time, efforts and money to invent new protocol that does the same jsut a bit different and which would bnever become standard outside 44net? After all, with BGP we have problem only that we cannot easily use public but have to use private ASNs - which is wrong way of doing it. Al we need is another "instance" of BGP that would allow freely using new set of ASNs. So, why inventing new protocol, just alter existing one so you can run at lest two independent BGP layers on single machine. But that would be custom protocol, non standard, not available anywhere except on custom set hardware. And again, that is repellent for people. If we want people to join in, it must be simple and standard way using standard hardware and software. Anything that requires installing linux and setting up custom machine and administer would simply keep people away from 44net as it already does. Please notice that I do not speak about concrete solutions. I am talking about principles. When we adopt principles we could talk how to implement them. You simply have to see big picture to be able to work on details. -- 73, Pedja YT9TP Checkout: https://pedja.supurovic.net/ https://yu1abh.uzice.net/ https://www.facebook.com/yu1abh/ https://www.facebook.com/groups/yu1abh.konstruktori/ http://www.radio-amater.rs/ _________________________________________ 44Net mailing list 44Net@mailman.ampr.org mailto:44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org mailto:44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org mailto:44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net ______________________________________________ This email has been scanned by Netintelligence http://www.netintelligence.com/email
More than that, Ubiquiti routers allow even 3rd party SW addons, like ampr-ripd, since they use Debian ase their base distribution.
July 23, 2019 9:32 AM, "R P via 44Net" 44net@mailman.ampr.org wrote:
"Name me one brand of standard of the shelf routers that supports IPIP"
I know that MikroTik and Ubiquiti Router support IPIP and they are standart of the shelf
But, afer almost 20 years playing around witht his topic, I think the lack of specific network services on 44net is the actual element preventing the spread of its usage. The original goal was conectivity, global if possible. But there simply is no incentive for using it anymore. Dx clusters are reachable on the regular internet, repeaters and reflectors too. Specialized sites dedicated to contesting are homebrew stuff, or whatever, use regular internet access. They can not rely on a network where only 10k users are reachable. And BBS systems are outdated and replaced by forums, mailing lists and discussion groups on various platforms. Unless we can find desirable services that really need a "private" globally routeable network for them to work, there will be no real new users influx beyond the occasional network enthusiast.
Marius, YO2LOJ
Marius;
On Tue, 2019-07-23 at 09:06 +0000, marius--- via 44Net wrote:
+1
But, afer almost 20 years playing around witht his topic, I think the lack of specific network services on 44net is the actual element preventing the spread of its usage. The original goal was conectivity, global if possible. But there simply is no incentive for using it anymore. Dx clusters are reachable on the regular internet, repeaters and reflectors too. Specialized sites dedicated to contesting are homebrew stuff, or whatever, use regular internet access. They can not rely on a network where only 10k users are reachable. And BBS systems are outdated and replaced by forums, mailing lists and discussion groups on various platforms. Unless we can find desirable services that really need a "private" globally routeable network for them to work, there will be no real new users influx beyond the occasional network enthusiast.
The one key thing however about using 44-net as a source IP is that when you visit another ham's services no matter what they may be, that ham for the most part (not always due to spoofs) can be rest assured that you're a licensed ham using their facilities whereas this is much more difficult when using a DHCP public IP from an ISP... especially if your services involve the remote usage of amateur radio frequencies.
It also allows you to host services under a static IP schema vs that of a dynamic DNS config. In the case of running a mail server such as sendmail, postfix, exim, etc. you have the availability of RDNS whereas dymamic DNS offerings do not offer this. In many mail server configs, RDNS is required to match forward DNS as a means to help filter spam. Mail server services (at least here) by default are often filtered by the ISPs as well where amprnet allows for usage of one.
In support of your case, I think I'm the only one on this list who uses an MTA on amprnet.
On 23.07.2019. 10:32, R P via 44Net wrote:
"Name me one brand of standard of the shelf routers that supports IPIP"
I know that MikroTik and Ubiquiti Router support IPIP and they are standart of the shelf routers
Mikrotik support for IPIP is limited and it requires quite a hack to make it work. It may be set to work but not as nice and clean solution.
On 23.07.2019. 08:12, Ruben ON3RVH via 44Net wrote:
There is nothing wrong with using private ASN's within a network. It's done by many (if not all) telecom and network operators and used for their internal network or connecting an internal customer with redundancy.
That is true, but only if we are the only ones using private ASNs.
But if happens that some people already uses private ASN for other purpose, they would be in trouble connecting to 44net... because there would be collisions.
I see no point of using public IP addresses and route them using private ASNs. It may be that I do not understand BGP well.
It is not a fact that IPIP is difficult. It is either easy (if your ISP router will forward IPIP or at least allow it through a DMZ) or impossible.
Install BPQ32/LinBPQ, add a few entries to the configuration file and direct IPIP to the virtual IP address that it creates, and the BPQ software suite, including routing IP datagrams over radio links, and anything else running on that host will have access to amprnet. Add another statement to the config and the host any any other host on the lan can have similar access. This works equally well on Windows and Linux machines. It doesn't need any special routers, renumbering you network or any specialist network knowledge.
Of course, if your main interest is playing at being an ISP rather than operating IP over RF links then this isn't for you.
73, John G8BPQ
On 23/07/2019 06:53, Pedja YT9TP via 44Net wrote:
On 23.07.2019 00:00, Brian 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?
Nope. It is a fact.
+1 jerome - VE7ASS
On Jul 23, 2019, at 06:58, John Wiseman via 44Net 44net@mailman.ampr.org wrote:
It is not a fact that IPIP is difficult. It is either easy (if your ISP router will forward IPIP or at least allow it through a DMZ) or impossible.
Install BPQ32/LinBPQ, add a few entries to the configuration file and direct IPIP to the virtual IP address that it creates, and the BPQ software suite, including routing IP datagrams over radio links, and anything else running on that host will have access to amprnet. Add another statement to the config and the host any any other host on the lan can have similar access. This works equally well on Windows and Linux machines. It doesn't need any special routers, renumbering you network or any specialist network knowledge.
Of course, if your main interest is playing at being an ISP rather than operating IP over RF links then this isn't for you.
73, John G8BPQ
My ISP doesn’t support anything they don’t supply either. Doesn’t stop me from using my own router and swapping the supported one in on the very rare occasions (if ever) I need the support...
On Wed, 24 Jul 2019 at 21:20, jerome schatten via 44Net < 44net@mailman.ampr.org> wrote:
+1 jerome - VE7ASS
On Jul 23, 2019, at 06:58, John Wiseman via 44Net <
44net@mailman.ampr.org> wrote:
It is not a fact that IPIP is difficult. It is either easy (if your ISP
router will forward IPIP or at least allow it through a DMZ) or impossible.
Install BPQ32/LinBPQ, add a few entries to the configuration file and
direct IPIP to the virtual IP address that it creates, and the BPQ software suite, including routing IP datagrams over radio links, and anything else running on that host will have access to amprnet. Add another statement to the config and the host any any other host on the lan can have similar access. This works equally well on Windows and Linux machines. It doesn't need any special routers, renumbering you network or any specialist network knowledge.
Of course, if your main interest is playing at being an ISP rather than
operating IP over RF links then this isn't for you.
73, John G8BPQ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
It is not a fact that IPIP is difficult. It is either easy (if your ISP router will forward IPIP or at least allow it through a DMZ) or impossible.
This isn't the fault of ipip, it's the poor service of the provider in this case however for decades, as ISPs have put up hurdles, we as hams and inventors have found ways around what ISPs to do stop our routing.
routing IP datagrams over radio links
This isn't the optimum way to do IP over ax.25 based radio links. Datagram is like UDP - lacks error correction. Case in point would be VoIP/SIP in a weak area. Missed frames stay missed and broken in a stream of data. Things get grunged.
It doesn't need any special routers, renumbering you network or any specialist network knowledge.
... and the ham doesn't gain knowledge but continues to be an application user, then when something happens due to changes by their ISP they don't know how to properly debug it because they haven't gained the skills needed to debug networking.
The system we use has dynamic routing by default since IP on VHF/UHF is encapsulated under ax.25 very similar as if we were able to have BGP based border routers between us. If an ax25 path breaks, and an alternate path exists the IP based socket stays open and connected at both ends. We're also running a higher MTU than a netrom (MTU of 192 bytes) based system does without fragmentation.
This is quite impossible with the software solution previously mentioned.
So that we don't have to have the same conversations twice -- let's move this thread to 44ngn@mailman.ampr.org
On Wed, Jul 24, 2019 at 4:11 PM Brian via 44Net 44net@mailman.ampr.org wrote:
It is not a fact that IPIP is difficult. It is either easy (if your ISP router will forward IPIP or at least allow it through a DMZ) or
impossible.
This isn't the fault of ipip, it's the poor service of the provider in this case however for decades, as ISPs have put up hurdles, we as hams and inventors have found ways around what ISPs to do stop our routing.
routing IP datagrams over radio links
This isn't the optimum way to do IP over ax.25 based radio links. Datagram is like UDP - lacks error correction. Case in point would be VoIP/SIP in a weak area. Missed frames stay missed and broken in a stream of data. Things get grunged.
It doesn't need any special routers, renumbering you network or any
specialist
network knowledge.
... and the ham doesn't gain knowledge but continues to be an application user, then when something happens due to changes by their ISP they don't know how to properly debug it because they haven't gained the skills needed to debug networking.
The system we use has dynamic routing by default since IP on VHF/UHF is encapsulated under ax.25 very similar as if we were able to have BGP based border routers between us. If an ax25 path breaks, and an alternate path exists the IP based socket stays open and connected at both ends. We're also running a higher MTU than a netrom (MTU of 192 bytes) based system does without fragmentation.
This is quite impossible with the software solution previously mentioned. -- If a rabbit is raised indoors, would it be an ingrown hare?
73 de Brian N1URO - President of EastNet IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Rob;
On Mon, 2019-07-22 at 19:42 +0200, Rob Janssen via 44Net wrote:
Taken off list as I think this dead horse is beyond it's glue making stage :)
On 23/07/19 03:42, Rob Janssen via 44Net wrote:
But NONE of those volunteers were from the Netherlands!! (they did not need to be, because I already host such a proxy farm in the Netherlands and the call for volunteers was to get more of them running across the world) The spread of volunteers was not as good as it could have been, but there were several from California, from Canada, from Australia, etc. Probably there are not so affected by backward internet connectivity (or lack of money) as you are. I don't know if they end up spending the $5/month for the benefit of amateur radio or if they got their hosting for free as part of some other deal. But they do offer the service! Voluntarily, without complaining.
I'm one of those volunteers. In my case, I was already paying for the VPS to provide IRLP/Echolink services. Adding a bunch of proxies was a no brainer, and required no additional outlay. I found an additional benefit. Shortly after I got the additional IPs up, my ISP was forced to renumber my commercial subnet. I simply transferred remaining services to 44net IPs, and only took a single commercial IP.
I was left with one last problem - the route between hosts here with 44net IPs (IPIP tunnelled) and the VPS (direct BGP routed) goes via UCSD by default, which is almost unusable. As I've been playing with ZeroTier lately, I used it to create a more direct route between my two subnets, which did the trick.
Maybe you are mostly stuck in the usage scenario where AMPRnet is mostly used to emulate the old packet radio system, e.g. for BBS forwarding, DX cluster, telnet chat, etc. However, most new users who already know the internet want to do other things, like WebSDR, audio and video streaming (e.g. to YouTube), running amateur-oriented web services like a Mattermost server, etc. Internet connectivity is a must for most of these.
Here in Australia, the issue of Internet connectivity is a vexed one. Obviously for use cases like my Echolink proxies, my 44net addresses are simply public IP addresses, and there's no ham radio implications. That all changes once I put IPs to RF. Then direct Internet access becomes problematic, though using the Internet as an intermediate connecting medium is obviously not an issue.
But running amateur related services internal to the network will require good latency and jitter performance for realtime audio applications.
But you can at least try! I remember seeing the questions here about having an IPIP gateway with more than one external address (e.g. using two different ISP links) to have redundancy at that level. Not possible, Sir! An IPIP tunnel endpoint has no way of seeing that the other side is down. With the newly proposed system this function would be no problem. BGP sees that a link is down and switches over to the alternate. Even within a second, when you configure BFD with it. But as long as the IPIP advocates get it their way, this will not happen.
I'm not wedded to IPIP, but I would prefer whatever technology we use uses direct point to point links where possible, and low(ish) latency intermediate links where necessary. Certainly some sort of dynamic routing would be advantageous. However, whatever routing technology we use will need to be capable of running under some fairly complex network environments. For example, I have around 6 different networks on the same wire here. But provided these cases are taken into account, I'm all for a dynamically routed solution. It allows for more fallback options.
-
Brian -
Brian Kantor -
David Ranch -
jerome schatten -
John Wiseman -
K7VE - John -
Marc Williams -
marius＠yo2loj.ro -
Michael Cullen -
paul Lewis -
Pedja YT9TP -
R P -
Rob Janssen -
Ruben ON3RVH -
Tony Langdon -
YT9TP - Pedja