22 Jul
2019
22 Jul
'19
6:42 p.m.
/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. >/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
22 Jul
22 Jul
8:25 p.m.
New subject: 44 net connectivity
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.
--
Rain is caused by big, high-pressure areas; cold fronts; warm, moist air;
And the first day of your vacation.
-----
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org
10:27 p.m.
New subject: 44 net connectivity
On 22.07.2019 21:25, Brian via 44Net wrote:
BGP has one disadvantage, it would relay to private ASNs which is bad
idea per se.
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.
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/
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. *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. 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. 
10:44 p.m.
New subject: 44 net connectivity
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(a)mailman.ampr.org>
wrote:
On 22.07.2019 21:25, Brian via 44Net wrote:
BGP.
this
> 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 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, 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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
11 p.m.
New subject: 44 net connectivity
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.
--
Rain is caused by big, high-pressure areas; cold fronts; warm, moist air;
And the first day of your vacation.
-----
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org
23 Jul
23 Jul
6:53 a.m.
New subject: 44 net connectivity
On 23.07.2019 00:00, Brian via 44Net wrote:
Nope. It is a fact.
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.
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.
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/
Well, the best
step would be to make connecting easier, meaning,
anything but IPIP.
That seems to be the vocal preference no? 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. 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. 
7:12 a.m.
New subject: 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(a)mailman.ampr.org> On Behalf Of Pedja
YT9TP via 44Net
Sent: dinsdag 23 juli 2019 7:53
To: 44net(a)mailman.ampr.org
Cc: Pedja YT9TP <yt9tp(a)uzice.net>
Subject: Re: [44net] 44 net connectivity
On 23.07.2019 00:00, Brian via 44Net wrote:
Nope. It is a fact.
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.
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.
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
Well, the best
step would be to make connecting easier, meaning,
anything but IPIP.
That seems to be the vocal preference no? 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. 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. 
9:32 a.m.
New subject: 44 net connectivity
"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(a)mailman.ampr.org> on behalf of Ruben
ON3RVH via 44Net <44net(a)mailman.ampr.org>
Sent: Monday, July 22, 2019 11:12 PM
To: 'AMPRNet working group' <44net(a)mailman.ampr.org>
Cc: Ruben ON3RVH <on3rvh(a)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(a)mailman.ampr.org> On Behalf Of Pedja
YT9TP via 44Net
Sent: dinsdag 23 juli 2019 7:53
To: 44net(a)mailman.ampr.org
Cc: Pedja YT9TP <yt9tp(a)uzice.net>
Subject: Re: [44net] 44 net connectivity
On 23.07.2019 00:00, Brian via 44Net wrote:
Nope. It is a fact.
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.
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.
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
Well, the best
step would be to make connecting easier, meaning,
anything but IPIP.
That seems to be the vocal preference no? 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. 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. 
9:42 a.m.
New subject: 44 net connectivity
"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
24 Jul
24 Jul
8:37 p.m.
New subject: 44 net connectivity
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#pr…
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 
23 Jul
23 Jul
10 a.m.
New subject: 44 net connectivity
billion7800 series
On 23 July 2019 at 09:32 R P via 44Net
<44net(a)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(a)mailman.ampr.org
mailto:44net-bounces+ronenp=hotmail.com@mailman.ampr.org > on behalf of Ruben ON3RVH
via 44Net <44net(a)mailman.ampr.org mailto:44net@mailman.ampr.org >
Sent: Monday, July 22, 2019 11:12 PM
To: 'AMPRNet working group' <44net(a)mailman.ampr.org
mailto:44net@mailman.ampr.org >
Cc: Ruben ON3RVH <on3rvh(a)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(a)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(a)mailman.ampr.org mailto:44net@mailman.ampr.org
Cc: Pedja YT9TP <yt9tp(a)uzice.net mailto:yt9tp@uzice.net >
Subject: Re: [44net] 44 net connectivity
On 23.07.2019 00:00, Brian via 44Net wrote:
And I also learned that we will never see significant expansion of 44net use.
As long as 44net is inaccessible using plain, standard factory routers and standard
protocols, it will not be expanding.
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(a)mailman.ampr.org mailto:44Net@mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org mailto:44Net@mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)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
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. 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. 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. 
10:06 a.m.
New subject: 44 net connectivity
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(a)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
10:41 a.m.
New subject: 44 net connectivity
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.
--
Rain is caused by big, high-pressure areas; cold fronts; warm, moist air;
And the first day of your vacation.
-----
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org
10:58 a.m.
New subject: 44 net connectivity
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.
--
73,
YT9TP, Pedja
http://www.yt9tp.iz.rs
10:50 a.m.
New subject: 44 net connectivity
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.
--
73,
YT9TP, Pedja
http://www.yt9tp.iz.rs
2:58 p.m.
New subject: 44 net connectivity
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:
Nope. It is a fact.
Well, the
best step would be to make connecting easier, meaning,
anything but IPIP.
That seems to be the vocal preference no? 
24 Jul
24 Jul
9:18 p.m.
New subject: 44 net connectivity
+1
jerome - VE7ASS
On Jul 23, 2019, at 06:58, John Wiseman via 44Net
<44net(a)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
11:05 p.m.
New subject: 44 net connectivity
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(a)mailman.ampr.org> wrote:
+1
jerome - VE7ASS
On Jul 23, 2019, at 06:58, John Wiseman via 44Net
<
44net(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
25 Jul
25 Jul
12:09 a.m.
New subject: 44 net connectivity
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
12:30 a.m.
New subject: 44 net connectivity
So that we don't have to have the same conversations twice -- let's move
this thread to 44ngn(a)mailman.ampr.org
On Wed, Jul 24, 2019 at 4:11 PM Brian via 44Net <44net(a)mailman.ampr.org>
wrote:
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
22 Jul
22 Jul
8:26 p.m.
New subject: 44.192.0.0/10 sale
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 :)
--
Rain is caused by big, high-pressure areas; cold fronts; warm, moist air;
And the first day of your vacation.
-----
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org
24 Jul
24 Jul
10:39 a.m.
New subject: 44.192.0.0/10 sale
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.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
1749
days inactive
1751
days old
21 comments
16 participants
participants (16)
-
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