3 Aug
2021
3 Aug
'21
3:29 a.m.
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of
having the TAC put out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I
think that this proposal needs more work and adjustment before we can
consider implementing it. The board and I want to see consensus on the
main points of a proposal among the major schools of thought on this
mailing list. That said, it’s important to remember that the people on
this list are not the only people using the AMRPnet. We have a complex
task on our hands to reach as many of those people as possible as we
evolve proposals toward consensus.
Several board members have suggested that it's hard to find consensus on
solutions until we have a consensus on what problem(s) the solutions are
trying to solve. We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should
be trying to solve first?
One thing we haven't communicated well before, is that we are actively
discussing budget and infrastructure for a “backbone” network of PoPs
(Points of Presence) of the 44net on various continents, to make it
easier for hams to connect to the AMPRnet with minimal effort and higher
performance. If you have ideas about how you would like to see this
happen, feel free to share here on the mailing list. I know that there’s
at least one alternative proposal on the way.
There’s obviously more discussion to be had, but for now, please rest
assured that no changes are going to be made without more input from you
and others using the AMPRnet.
I also want to thank the TAC for their work up to this point. They have
dedicated hundreds of hours to come up with this proposal. Even if its
release has cause some heated discussion, it’s critical that these
discussions happen. They will help all of us come up with the best
solution for how to most effectively organize our network for the future.
73,
Rosy
--
Rosy Wolfe - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
3 Aug
3 Aug
3:50 a.m.
Consider allowing community members to contribute POPs, sort of like APRS2.net. AMPR could
provide a couple route servers to direct them all over BGP, sort of like a distributed
internet exchange, would be "self healing" but of course some vetting of POPs
before had would be needed to approve a certain level of infrastructure. Each pop could
also offer VPN endpoints. Just a thought I had literally just now, so take it with a grain
of salt hah.
-C
-----Original Message-----
From: 44Net <44net-bounces+colin.bodor=imperium.ca(a)mailman.ampr.org> On Behalf Of
Rosy Wolfe via 44Net
Sent: Monday, August 2, 2021 14:30
To: Amprnet 44 Net <44net(a)mailman.ampr.org>
Cc: Rosy Wolfe <rosy(a)ardc.net>
Subject: [44net] On Allocations, PoPs, and Proposals
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of having the TAC put
out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I think that this
proposal needs more work and adjustment before we can consider implementing it. The board
and I want to see consensus on the main points of a proposal among the major schools of
thought on this mailing list. That said, it’s important to remember that the people on
this list are not the only people using the AMRPnet. We have a complex task on our hands
to reach as many of those people as possible as we evolve proposals toward consensus.
Several board members have suggested that it's hard to find consensus on solutions
until we have a consensus on what problem(s) the solutions are trying to solve. We have a
tangle of issues like the complexity of IPIP tunnels, to BGP routing, to address space
sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should be trying to
solve first?
One thing we haven't communicated well before, is that we are actively discussing
budget and infrastructure for a “backbone” network of PoPs (Points of Presence) of the
44net on various continents, to make it easier for hams to connect to the AMPRnet with
minimal effort and higher performance. If you have ideas about how you would like to see
this happen, feel free to share here on the mailing list. I know that there’s at least one
alternative proposal on the way.
There’s obviously more discussion to be had, but for now, please rest assured that no
changes are going to be made without more input from you and others using the AMPRnet.
I also want to thank the TAC for their work up to this point. They have dedicated hundreds
of hours to come up with this proposal. Even if its release has cause some heated
discussion, it’s critical that these discussions happen. They will help all of us come up
with the best solution for how to most effectively organize our network for the future.
73,
Rosy
--
Rosy Wolfe - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
4:02 a.m.
I think much of the thought has been around the POPs being VPN (probably
multiprotocol) servers.
On Mon, Aug 2, 2021 at 1:54 PM Colin Bodor via 44Net <44net(a)mailman.ampr.org>
wrote:
Consider allowing community members to contribute
POPs, sort of like
APRS2.net. AMPR could provide a couple route servers to direct them all
over BGP, sort of like a distributed internet exchange, would be "self
healing" but of course some vetting of POPs before had would be needed to
approve a certain level of infrastructure. Each pop could also offer VPN
endpoints. Just a thought I had literally just now, so take it with a grain
of salt hah.
-C
-----Original Message-----
From: 44Net <44net-bounces+colin.bodor=imperium.ca(a)mailman.ampr.org> On
Behalf Of Rosy Wolfe via 44Net
Sent: Monday, August 2, 2021 14:30
To: Amprnet 44 Net <44net(a)mailman.ampr.org>
Cc: Rosy Wolfe <rosy(a)ardc.net>
Subject: [44net] On Allocations, PoPs, and Proposals
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of
having the TAC put out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I think
that this proposal needs more work and adjustment before we can consider
implementing it. The board and I want to see consensus on the main points
of a proposal among the major schools of thought on this mailing list. That
said, it’s important to remember that the people on this list are not the
only people using the AMRPnet. We have a complex task on our hands to reach
as many of those people as possible as we evolve proposals toward consensus.
Several board members have suggested that it's hard to find consensus on
solutions until we have a consensus on what problem(s) the solutions are
trying to solve. We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should
be trying to solve first?
One thing we haven't communicated well before, is that we are actively
discussing budget and infrastructure for a “backbone” network of PoPs
(Points of Presence) of the 44net on various continents, to make it easier
for hams to connect to the AMPRnet with minimal effort and higher
performance. If you have ideas about how you would like to see this happen,
feel free to share here on the mailing list. I know that there’s at least
one alternative proposal on the way.
There’s obviously more discussion to be had, but for now, please rest
assured that no changes are going to be made without more input from you
and others using the AMPRnet.
I also want to thank the TAC for their work up to this point. They have
dedicated hundreds of hours to come up with this proposal. Even if its
release has cause some heated discussion, it’s critical that these
discussions happen. They will help all of us come up with the best solution
for how to most effectively organize our network for the future.
73,
Rosy
--
Rosy Wolfe - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
_________________________________________
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
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
4:14 a.m.
Rosie firstly thank you for reaching out to the community and acknowledging
the feedback provided to the proposal over the last few days.
I have a few BGP assignments for various radio clubs, at home and remote
repeater sites. One thing I have noticed over the years when requesting
resources is how manual the process is, be that resource approvals, DNS
delegation, LOA generation or RADB/AltDB entries.
I am not at all against re-addressing and moving into a new IP block if
that simplifies routing for other 44net users, but I would not want to go
through the process if the ARDC has not invested effort in automating every
step of the process to ensure end users are not waiting on coordinators.
The RIRs have manual judgement approval steps, but LOAs, public whois DB
entries and PTR/NS delegation is all fully automated - we should make sure
44net has this in place prior to any renumbering process.
Also I read a couple of messages where it was stated IPv6 and RPKI would be
a second project, if the TAC is pushing for a renumber there should at
least be some carrot to entice users to renumber, in my opinion this could
be an IPv6 block and RPKI entries. I support Colin's suggestion on
contributed POP locations.
I look forward to reading a revised TAC proposal in the coming months,
Nat,
On Mon, Aug 2, 2021 at 9:53 PM Colin Bodor via 44Net <44net(a)mailman.ampr.org>
wrote:
Consider allowing community members to contribute
POPs, sort of like
APRS2.net. AMPR could provide a couple route servers to direct them all
over BGP, sort of like a distributed internet exchange, would be "self
healing" but of course some vetting of POPs before had would be needed to
approve a certain level of infrastructure. Each pop could also offer VPN
endpoints. Just a thought I had literally just now, so take it with a grain
of salt hah.
-C
-----Original Message-----
From: 44Net <44net-bounces+colin.bodor=imperium.ca(a)mailman.ampr.org> On
Behalf Of Rosy Wolfe via 44Net
Sent: Monday, August 2, 2021 14:30
To: Amprnet 44 Net <44net(a)mailman.ampr.org>
Cc: Rosy Wolfe <rosy(a)ardc.net>
Subject: [44net] On Allocations, PoPs, and Proposals
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of
having the TAC put out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I think
that this proposal needs more work and adjustment before we can consider
implementing it. The board and I want to see consensus on the main points
of a proposal among the major schools of thought on this mailing list. That
said, it’s important to remember that the people on this list are not the
only people using the AMRPnet. We have a complex task on our hands to reach
as many of those people as possible as we evolve proposals toward consensus.
Several board members have suggested that it's hard to find consensus on
solutions until we have a consensus on what problem(s) the solutions are
trying to solve. We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should
be trying to solve first?
One thing we haven't communicated well before, is that we are actively
discussing budget and infrastructure for a “backbone” network of PoPs
(Points of Presence) of the 44net on various continents, to make it easier
for hams to connect to the AMPRnet with minimal effort and higher
performance. If you have ideas about how you would like to see this happen,
feel free to share here on the mailing list. I know that there’s at least
one alternative proposal on the way.
There’s obviously more discussion to be had, but for now, please rest
assured that no changes are going to be made without more input from you
and others using the AMPRnet.
I also want to thank the TAC for their work up to this point. They have
dedicated hundreds of hours to come up with this proposal. Even if its
release has cause some heated discussion, it’s critical that these
discussions happen. They will help all of us come up with the best solution
for how to most effectively organize our network for the future.
73,
Rosy
--
Rosy Wolfe - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
_________________________________________
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
--
Nat
https://nat.ms
+44 7531 750292
4:10 a.m.
Yes I think the design and deployment of the new backbone network which would replace IPIP
tunnels and would offload
the mandatory task of (complex) routing from the beginning user should be the first
priority.
It would lower the bar of entry and it would also solve the issues that the recent TAC
proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here in
the Netherlands) would be able
to offer the function or the hosting of that function for their region. We currently
have 1Gbit internet connection, soon
to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and
performance is not really
the first concern at the current load. Focus should be on reliability, possibly through
having enough redundancy in
the network.
Rob
On 8/2/21 10:29 PM, Rosy Wolfe via 44Net wrote:
We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should be trying to
solve first?
One thing we haven't communicated well before, is that we are actively discussing
budget and infrastructure for a “backbone” network of PoPs (Points of Presence) of the
44net on various continents, to make it easier for hams to connect to the AMPRnet with
minimal effort and higher performance. If you have ideas about how you would like to see
this happen, feel free to share here on the mailing list. I know that there’s at least one
alternative proposal on the way.
5:48 a.m.
I think that performance IS of prime concerne as much as reliability and redundency (wich
is the 2 face of a same problem)
Reliability with lack of performance will not fix our situation. adding hundreds of
milisecond to a network conection , even if stable is in no way an improvement.
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de Rob
PE1CHL via 44Net <44net(a)mailman.ampr.org>
Envoyé : 2 août 2021 17:10
À : 44net(a)mailman.ampr.org
Cc : Rob PE1CHL
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Yes I think the design and deployment of the new backbone network which would replace IPIP
tunnels and would offload
the mandatory task of (complex) routing from the beginning user should be the first
priority.
It would lower the bar of entry and it would also solve the issues that the recent TAC
proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here in
the Netherlands) would be able
to offer the function or the hosting of that function for their region. We currently
have 1Gbit internet connection, soon
to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and
performance is not really
the first concern at the current load. Focus should be on reliability, possibly through
having enough redundancy in
the network.
Rob
On 8/2/21 10:29 PM, Rosy Wolfe via 44Net wrote:
We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should be trying to
solve first?
One thing we haven't communicated well before, is that we are actively discussing
budget and infrastructure for a “backbone” network of PoPs (Points of Presence) of the
44net on various continents, to make it easier for hams to connect to the AMPRnet with
minimal effort and higher performance. If you have ideas about how you would like to see
this happen, feel free to share here on the mailing list. I know that there’s at least one
alternative proposal on the way.
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2:20 p.m.
Pierre,
You should not read too much into that remark that bandwidth is not the first concern.
I does not mean "we may as well have bad bandwidth and poor performance", but
rather that we are not
using that much bandwidth that we need to have the fastest connections and the fastest
routers.
At the moment our 44.137.0.0/16 gateway has a 1Gbit internet connection but it on average
uses only
about 30 Mbit/s with peaks of up to ~100 Mbit/s (in each direction). At this moment we
are busy moving
the servers to a different datacenter because the old one is going to close down, and
there we will
get 10 Gbit/s but the new datacenter offers us up to 100 Gbit/s. We have chosen not to go
that way for
now because our equipment has only up to 10 Gbit/s interfaces and going higher would mean
more
investment. I think that is not warranted at this time. Maybe if we would host a PoP in
a worldwide
backbone and would get connections from more countries. But at that time it can always be
changed.
This of course has no influence on latency, that is determined by physical location. We
will be next
to the AMS-IX.
Rob
On 8/3/21 12:48 AM, pete M via 44Net wrote:
I think that performance IS of prime concerne as much
as reliability and redundency (wich is the 2 face of a same problem)
Reliability with lack of performance will not fix our situation. adding hundreds of
milisecond to a network conection , even if stable is in no way an improvement.
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de Rob
PE1CHL via 44Net <44net(a)mailman.ampr.org>
Envoyé : 2 août 2021 17:10
À : 44net(a)mailman.ampr.org
Cc : Rob PE1CHL
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Yes I think the design and deployment of the new backbone network which would replace
IPIP tunnels and would offload
the mandatory task of (complex) routing from the beginning user should be the first
priority.
It would lower the bar of entry and it would also solve the issues that the recent TAC
proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here
in the Netherlands) would be able
to offer the function or the hosting of that function for their region. We currently
have 1Gbit internet connection, soon
to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and
performance is not really
the first concern at the current load. Focus should be on reliability, possibly through
having enough redundancy in
the network.
Rob
11:01 p.m.
Next to AMS-IX, or are you actually peering on AMS-IX? A valid consideration for future
POP locations should be internet exchange connectivity. A 100gig connection could be great
(if used) but if you want lower latency an IX will be much better than some large transit
provider, especially if you are connecting to a geographically local POP. The whole POP
proposal reads likes a CDN build but without mentioning the criticality of being peered on
exchange points. IXs serve many purposes but one of them is keeping local traffic local,
and thus latency "low". I only ask to bring it up as part of the discussion and
so I know at least someone else who is dealing with 44net prefixes and an IX 😉
-C
-----Original Message-----
From: 44Net <44net-bounces+colin.bodor=imperium.ca(a)mailman.ampr.org> On Behalf Of
Rob PE1CHL via 44Net
Sent: Tuesday, August 3, 2021 1:21
To: 44net(a)mailman.ampr.org
Cc: Rob PE1CHL <44net(a)pe1chl.nl>
Subject: Re: [44net] On Allocations, PoPs, and Proposals
Pierre,
You should not read too much into that remark that bandwidth is not the first concern.
I does not mean "we may as well have bad bandwidth and poor performance", but
rather that we are not using that much bandwidth that we need to have the fastest
connections and the fastest routers.
At the moment our 44.137.0.0/16 gateway has a 1Gbit internet connection but it on average
uses only about 30 Mbit/s with peaks of up to ~100 Mbit/s (in each direction). At this
moment we are busy moving the servers to a different datacenter because the old one is
going to close down, and there we will get 10 Gbit/s but the new datacenter offers us up
to 100 Gbit/s. We have chosen not to go that way for now because our equipment has only
up to 10 Gbit/s interfaces and going higher would mean more investment. I think that is
not warranted at this time. Maybe if we would host a PoP in a worldwide backbone and
would get connections from more countries. But at that time it can always be changed.
This of course has no influence on latency, that is determined by physical location. We
will be next to the AMS-IX.
Rob
On 8/3/21 12:48 AM, pete M via 44Net wrote:
I think that performance IS of prime concerne as much
as reliability
and redundency (wich is the 2 face of a same problem) Reliability with lack of
performance will not fix our situation. adding hundreds of milisecond to a network
conection , even if stable is in no way an improvement.
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Rob PE1CHL via 44Net <44net(a)mailman.ampr.org> Envoyé : 2 août
2021 17:10 À : 44net(a)mailman.ampr.org Cc : Rob PE1CHL Objet : Re:
[44net] On Allocations, PoPs, and Proposals
Yes I think the design and deployment of the new backbone network
which would replace IPIP tunnels and would offload the mandatory task of (complex)
routing from the beginning user should be the first priority.
It would lower the bar of entry and it would also solve the issues that the recent TAC
proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here
in the Netherlands) would be able
to offer the function or the hosting of that function for their region. We currently
have 1Gbit internet connection, soon
to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and
performance is not really
the first concern at the current load. Focus should be on
reliability, possibly through having enough redundancy in the network.
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
11:50 p.m.
Just as in the current situation, we will not be doing peering ourselves but we leave that
to the company that sponsors our hosting.
They are well connected to local and international peers and it is so much easier to not
have to arrange that.
They will advertise our subnet and statically route the traffic to us.
Rob
On 8/3/21 6:01 PM, Colin Bodor via 44Net wrote:
Next to AMS-IX, or are you actually peering on AMS-IX?
A valid consideration for future POP locations should be internet exchange connectivity. A
100gig connection could be great (if used) but if you want lower latency an IX will be
much better than some large transit provider, especially if you are connecting to a
geographically local POP. The whole POP proposal reads likes a CDN build but without
mentioning the criticality of being peered on exchange points. IXs serve many purposes but
one of them is keeping local traffic local, and thus latency "low". I only ask
to bring it up as part of the discussion and so I know at least someone else who is
dealing with 44net prefixes and an IX 😉
-C
11:52 p.m.
Ah yes, that is easier, I provide the same thing for several clients. You still get the
good routes though!
-----Original Message-----
From: 44Net <44net-bounces+colin.bodor=imperium.ca(a)mailman.ampr.org> On Behalf Of
Rob PE1CHL via 44Net
Sent: Tuesday, August 3, 2021 10:51
To: 44net(a)mailman.ampr.org
Cc: Rob PE1CHL <44net(a)pe1chl.nl>
Subject: Re: [44net] On Allocations, PoPs, and Proposals
Just as in the current situation, we will not be doing peering ourselves but we leave that
to the company that sponsors our hosting.
They are well connected to local and international peers and it is so much easier to not
have to arrange that.
They will advertise our subnet and statically route the traffic to us.
Rob
On 8/3/21 6:01 PM, Colin Bodor via 44Net wrote:
Next to AMS-IX, or are you actually peering on AMS-IX?
A valid consideration for future POP locations should be internet exchange connectivity. A
100gig connection could be great (if used) but if you want lower latency an IX will be
much better than some large transit provider, especially if you are connecting to a
geographically local POP. The whole POP proposal reads likes a CDN build but without
mentioning the criticality of being peered on exchange points. IXs serve many purposes but
one of them is keeping local traffic local, and thus latency "low". I only ask
to bring it up as part of the discussion and so I know at least someone else who is
dealing with 44net prefixes and an IX 😉
-C
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
5:56 a.m.
For the existing AMPRNet, I echo what Rob PE1CHL and others have stated on this list.
Here's my summary though:
1) The barrier to entry for the casual user who wants to connect to the Internet with
44Net space is too high and relies on outdated technology. A technology that is
NAT-friendly for IPv4 is imperative. Not only can many people not port-forward in the IPIP
protocol, they are increasingly finding themselves behind a CGN and thus are a
double-NAT'd. There needs to be a comprehensive, geographically diverse (BY NETWORK
not by country border) set of connection points that use modern, NAT-friendly technologies
such as OpenVPN and Wireguard. Maybe even L2TP. Offer ALL the options, rather than one
option. Options should not require non-standard tooling such as the quasi-RIP routing
daemon.
1A) Offer the OpenVPN, Wireguard, and L2TP endpoints on IPv6 addressing as well as IPv4
addressing. This is imperative in 2021.
2) Manual coordination by country/region should be dropped in favor of an automated portal
allocation solution, DNS delegation, etc. The volunteers do a great job but it seems
unnecessary?
3) Development of a standard "get on 44Net" appliance built on a Pi. Something
that reaches out to the solution developed for #1 and brings in the user's allocation
for experimentation. This should be a community-driven project that aims to have an EASY
setup-and-forget system that provides automatic networking harness for people who want to
experiment. Harness the power of the community who like to tinker with networking to help
those who don't want to.
Jason N8EI
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On
Behalf Of Rosy Wolfe via 44Net
Sent: Monday, August 2, 2021 4:30 PM
To: Amprnet 44 Net <44net(a)mailman.ampr.org>
Cc: Rosy Wolfe <rosy(a)ardc.net>
Subject: [44net] On Allocations, PoPs, and Proposals
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of having
the TAC put out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I think that this
proposal needs more work and adjustment before we can consider
implementing it. The board and I want to see consensus on the main points
of a proposal among the major schools of thought on this mailing list. That
said, it’s important to remember that the people on this list are not the only
people using the AMRPnet. We have a complex task on our hands to reach as
many of those people as possible as we evolve proposals toward consensus.
Several board members have suggested that it's hard to find consensus on
solutions until we have a consensus on what problem(s) the solutions are
trying to solve. We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should
be trying to solve first?
One thing we haven't communicated well before, is that we are actively
discussing budget and infrastructure for a “backbone” network of PoPs
(Points of Presence) of the 44net on various continents, to make it easier for
hams to connect to the AMPRnet with minimal effort and higher
performance. If you have ideas about how you would like to see this happen,
feel free to share here on the mailing list. I know that there’s at least one
alternative proposal on the way.
There’s obviously more discussion to be had, but for now, please rest
assured that no changes are going to be made without more input from you
and others using the AMPRnet.
I also want to thank the TAC for their work up to this point. They have
dedicated hundreds of hours to come up with this proposal. Even if its
release has cause some heated discussion, it’s critical that these discussions
happen. They will help all of us come up with the best solution for how to
most effectively organize our network for the future.
73,
Rosy
--
Rosy Wolfe - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
11:26 p.m.
I agree strongly with N8EI's suggestion 3 to base the "Get on Net44"
appliance on a Raspberry Pi. It's ubiquitous, capable, and
well-understood. Please scale it down as much as possible so that it
runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux
kernels), make the "appliance" available as an ISO image so that it
can be downloaded to an SD card and just stuck into the RPi and
booted. Then have a one pager (or even better, a small script) that
lets you "fill in the blanks" like callsign, VPN that you're trying to
connect to, etc.
Thanks,
Steve N8GNJ
On Mon, Aug 2, 2021 at 3:57 PM Jason McCormick via 44Net
<44net(a)mailman.ampr.org> wrote:
For the existing AMPRNet, I echo what Rob PE1CHL and others have stated on this list.
Here's my summary though:
1) The barrier to entry for the casual user who wants to connect to the Internet with
44Net space is too high and relies on outdated technology. A technology that is
NAT-friendly for IPv4 is imperative. Not only can many people not port-forward in the IPIP
protocol, they are increasingly finding themselves behind a CGN and thus are a
double-NAT'd. There needs to be a comprehensive, geographically diverse (BY NETWORK
not by country border) set of connection points that use modern, NAT-friendly technologies
such as OpenVPN and Wireguard. Maybe even L2TP. Offer ALL the options, rather than one
option. Options should not require non-standard tooling such as the quasi-RIP routing
daemon.
1A) Offer the OpenVPN, Wireguard, and L2TP endpoints on IPv6 addressing as well as IPv4
addressing. This is imperative in 2021.
2) Manual coordination by country/region should be dropped in favor of an automated
portal allocation solution, DNS delegation, etc. The volunteers do a great job but it
seems unnecessary?
3) Development of a standard "get on 44Net" appliance built on a Pi. Something
that reaches out to the solution developed for #1 and brings in the user's allocation
for experimentation. This should be a community-driven project that aims to have an EASY
setup-and-forget system that provides automatic networking harness for people who want to
experiment. Harness the power of the community who like to tinker with networking to help
those who don't want to.
Jason N8EI
--
Steve Stroh stevestroh(a)gmail.com
Editor
Zero Retries Newsletter - https://zeroretries.substack.com
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On
Behalf Of Rosy Wolfe via 44Net
Sent: Monday, August 2, 2021 4:30 PM
To: Amprnet 44 Net <44net(a)mailman.ampr.org>
Cc: Rosy Wolfe <rosy(a)ardc.net>
Subject: [44net] On Allocations, PoPs, and Proposals
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of having
the TAC put out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I think that this
proposal needs more work and adjustment before we can consider
implementing it. The board and I want to see consensus on the main points
of a proposal among the major schools of thought on this mailing list. That
said, it’s important to remember that the people on this list are not the only
people using the AMRPnet. We have a complex task on our hands to reach as
many of those people as possible as we evolve proposals toward consensus.
Several board members have suggested that it's hard to find consensus on
solutions until we have a consensus on what problem(s) the solutions are
trying to solve. We have a tangle of issues like the complexity of IPIP
tunnels, to BGP routing, to address space sparseness, to low performance.
With this in mind, what problems with the AMPRnet do you think we should
be trying to solve first?
One thing we haven't communicated well before, is that we are actively
discussing budget and infrastructure for a “backbone” network of PoPs
(Points of Presence) of the 44net on various continents, to make it easier for
hams to connect to the AMPRnet with minimal effort and higher
performance. If you have ideas about how you would like to see this happen,
feel free to share here on the mailing list. I know that there’s at least one
alternative proposal on the way.
There’s obviously more discussion to be had, but for now, please rest
assured that no changes are going to be made without more input from you
and others using the AMPRnet.
I also want to thank the TAC for their work up to this point. They have
dedicated hundreds of hours to come up with this proposal. Even if its
release has cause some heated discussion, it’s critical that these discussions
happen. They will help all of us come up with the best solution for how to
most effectively organize our network for the future.
73,
Rosy
--
Rosy Wolfe - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
_________________________________________
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
11:54 p.m.
While I agree that it is attractive to use a Raspberry Pi because of its availability
and the capability to also host some applications on the same device aside from
doing the routing, in my experience it is much easier to use a dedicated router
like the MikroTik hEX (RB750Gr3) available for about the same price, but having
5 ethernet ports and all software required for VPN and routing pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
Rob
On 8/3/21 6:26 PM, Steve Stroh via 44Net wrote:
I agree strongly with N8EI's suggestion 3 to base
the "Get on Net44"
appliance on a Raspberry Pi. It's ubiquitous, capable, and
well-understood. Please scale it down as much as possible so that it
runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux
kernels), make the "appliance" available as an ISO image so that it
can be downloaded to an SD card and just stuck into the RPi and
booted. Then have a one pager (or even better, a small script) that
lets you "fill in the blanks" like callsign, VPN that you're trying to
connect to, etc.
Thanks,
Steve N8GNJ
11:56 p.m.
I like the MikroTik Hex line and use them myself but their UI isn't the easiest to
deal with and their OpenVPN client in RouterOS v6 isn't very good. I'm waiting for
OS 7 where it's said to be improved before I start suggesting that platform.
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On
Behalf Of Rob PE1CHL via 44Net
Sent: Tuesday, August 3, 2021 12:54 PM
To: 44net(a)mailman.ampr.org
Cc: Rob PE1CHL <44net(a)pe1chl.nl>
Subject: Re: [44net] On Allocations, PoPs, and Proposals
While I agree that it is attractive to use a Raspberry Pi because of its
availability and the capability to also host some applications on the same
device aside from doing the routing, in my experience it is much easier to use
a dedicated router like the MikroTik hEX (RB750Gr3) available for about the
same price, but having
5 ethernet ports and all software required for VPN and routing pre-installed
and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one
of them.
Rob
On 8/3/21 6:26 PM, Steve Stroh via 44Net wrote:
I agree strongly with N8EI's suggestion 3 to
base the "Get on Net44"
appliance on a Raspberry Pi. It's ubiquitous, capable, and
well-understood. Please scale it down as much as possible so that it
runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux
kernels), make the "appliance" available as an ISO image so that it
can be downloaded to an SD card and just stuck into the RPi and
booted. Then have a one pager (or even better, a small script) that
lets you "fill in the blanks" like callsign, VPN that you're trying to
connect to, etc.
Thanks,
Steve N8GNJ
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
4 Aug
4 Aug
12:24 a.m.
We use L2TP/IPsec, GRE or GRE6 (optionally with IPsec) and it works very well on these
routers.
An advantage is that they provide the same configuration options on CLI or GUI so it is
possible
to provide configuration templates ready for cut/paste and still offer GUI for fine
tuning.
As all config is provided via a single interface it is much easier than plain Linux on
e.g. a Pi
where multiple config files and scripts have to be edited.
Setting up BGP on these routers is very easy, much easier than getting an IPIP gateway
going.
Most important is that the new backbone network should use standard protocols, so that we
can use standard routers like this, while those that want to can still use generic OS-es.
(they can do IPIP mesh but it is a bit of a convoluted solution, L2TP+BGP is much much
easier)
Rob
On 8/3/21 6:56 PM, Jason McCormick via 44Net wrote:
I like the MikroTik Hex line and use them myself but
their UI isn't the easiest to deal with and their OpenVPN client in RouterOS v6
isn't very good. I'm waiting for OS 7 where it's said to be improved before I
start suggesting that platform.
12:29 a.m.
I'll add a comment here, since I've used the RB750G gear and RPi boards
extensively as routers. I *highly* recommend the RPi4B! The difference in
SoC processing power is massive, when crunching crypto for VPNs, enough
RAM for BGP and other system services, etc. There are many OS/distro
sources available and the very latest software version are only a few
clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the
concern for simply having crummy data thru-put due to crypto processing
overhead. I've got several RB750G routers, they're all sitting on the
shelf, these days.
For network port fan-out, since the RPi4B has only a single (but REAL)
1GbE port, I mostly use D-Link DGS-1100-08 switches. They've got good
support for 802.1q VLANs and are very economical ($35 or less).
I've also got a small fleet of Rock64 boards installed, since they were
available with REAL 1GbE ports before the RPi4B was available.
Don't underestimate how capable this solution is! This gear is
rock-solid, super inexpensive and available everywhere. Further, you're
not locked into a single vendor/hardware platform, as the technology
continues to leap forward.
These days, about the only time I gravitate to higher end gear is where I
need faster router port speeds---10GbE or faster.
73, David KB4FXC
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
While I agree that it is attractive to use a Raspberry
Pi because of its availability
and the capability to also host some applications on
the same device aside from
doing the routing, in my experience it is much easier to use a dedicated router
like the MikroTik hEX (RB750Gr3) available for about the same price, but having
5 ethernet ports and all software required for VPN and routing pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
Rob
On 8/3/21 6:26 PM, Steve Stroh via 44Net wrote:
I agree strongly with N8EI's suggestion 3 to base
the "Get on Net44"
appliance on a Raspberry Pi. It's ubiquitous, capable, and
well-understood. Please scale it down as much as possible so that it
runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux
kernels), make the "appliance" available as an ISO image so that it
can be downloaded to an SD card and just stuck into the RPi and
booted. Then have a one pager (or even better, a small script) that
lets you "fill in the blanks" like callsign, VPN that you're trying to
connect to, etc.
Thanks,
Steve N8GNJ
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
1:02 a.m.
As I wrote in another reply, for each problem and each admin there
is a different solution. The RB750Gr3 runs IPsec at >450Mbit/s which
is enough for most users. Do not use OpenVPN on these devices,
use L2TP/IPsec or GRE/IPsec.
I am currently in mail exchange with someone who wants to configure
AMPRnet access on a VPS using standard Linux software. Easy peasy
when you ask me, but it is a nightmare to get someone going who
has no Linux admin skills at all and is only cutting/pasting error messages
all the time, and not really reading the directions or able to debug things
without constant hand-helding. With a MikroTik he would be going,
with the Linux system he is only whining and complaining.
(but others get it working after only a single message with some hints)
Read back in the 44Net mail archives and you can see the same discussion
over and over, so I think this is enough for now.
Rob
On 8/3/21 7:29 PM, David McGough via 44Net wrote:
I'll add a comment here, since I've used the
RB750G gear and RPi boards
extensively as routers. I *highly* recommend the RPi4B! The difference in
SoC processing power is massive, when crunching crypto for VPNs, enough
RAM for BGP and other system services, etc. There are many OS/distro
sources available and the very latest software version are only a few
clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the
concern for simply having crummy data thru-put due to crypto processing
overhead. I've got several RB750G routers, they're all sitting on the
shelf, these days.
1:37 a.m.
Hi Rob,
Not trying to belabor the Linux discussion; agreed, it has been tossed
around many times over the last decade+. I do have one more comment,
thought.
I fully agree that a complete roll-it-for-yourself Linux routing solution
is totally impractical for 99.9% of users and would be a nightmare for
maintainers....I'm the developer and maintainer of HamVoIP (with about
10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or
packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
As I wrote in another reply, for each problem and each
admin there
is a different solution. The RB750Gr3 runs IPsec at >450Mbit/s
which
is enough for most users. Do not use OpenVPN on these devices,
use L2TP/IPsec or GRE/IPsec.
I am currently in mail exchange with someone who wants to configure
AMPRnet access on a VPS using standard Linux software. Easy peasy
when you ask me, but it is a nightmare to get someone going who
has no Linux admin skills at all and is only cutting/pasting error messages
all the time, and not really reading the directions or able to debug things
without constant hand-helding. With a MikroTik he would be going,
with the Linux system he is only whining and complaining.
(but others get it working after only a single message with some hints)
Read back in the 44Net mail archives and you can see the same discussion
over and over, so I think this is enough for now.
Rob
On 8/3/21 7:29 PM, David McGough via 44Net wrote:
I'll add a comment here, since I've used the
RB750G gear and RPi boards
extensively as routers. I *highly* recommend the RPi4B! The difference in
SoC processing power is massive, when crunching crypto for VPNs, enough
RAM for BGP and other system services, etc. There are many OS/distro
sources available and the very latest software version are only a few
clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the
concern for simply having crummy data thru-put due to crypto processing
overhead. I've got several RB750G routers, they're all sitting on the
shelf, these days.
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2:01 a.m.
Well yes, it is probably "easy to do". But you need to be aware that you
get into a commitment that you need to sustain for many years. It is
doable to make a downloadable image for the Raspberry Pi and maybe some
config screen to set it up, and put it on a website, but after some time the
software gets outdated, new models of Pi appear that require or prefer
a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio
oriented services which was published around 6 years ago. I downloaded
that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with
it. Nice. It was based on the first Raspbian (Debian Wheezy I think).
I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it.
He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published
anymore. The user was not really a Linux noob so I explained him how
in principle one can update Debian to the next version, and he did that
and stepped to the next version (Jessie). That went well, although it of
course was quite some work to process all edits of config files, and he had
an issue with a package no longer supported. Fixed all that. Now the
next step, but that failed completely. Too many problems.
(I have done this on PC systems and I know that it requires quite some
attention and skills)
So now such a user is at a dead end: they can go back to the saved card
image and run outdated software forever and no longer be able to do new
things, or they have to re-invent the whole wheel (download recent OS
image for the Pi and then install all the wanted packages and configure them).
At that time the advantage of having a prepared install is lost completely,
works even against you as you have no knowledge of what was exactly
done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router
with current software, you have to be aware that you have the moral
obligation to track the developments of the OS and hardware and keep
releasing new versions about once a year, or you will leave your happy
users behind in frustration.
Then, it may not be that easy after all.
Rob
On 8/3/21 8:37 PM, David McGough via 44Net wrote:
I fully agree that a complete roll-it-for-yourself
Linux routing solution
is totally impractical for 99.9% of users and would be a nightmare for
maintainers....I'm the developer and maintainer of HamVoIP (with about
10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or
packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
2:14 a.m.
Rob, I already do this (https://hamvoip.org)! I fully understand the
concerns.
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
Well yes, it is probably "easy to do". But
you need to be aware that you
get into a commitment that you need to sustain for
many years. It is
doable to make a downloadable image for the Raspberry Pi and maybe some
config screen to set it up, and put it on a website, but after some time the
software gets outdated, new models of Pi appear that require or prefer
a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio
oriented services which was published around 6 years ago. I downloaded
that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with
it. Nice. It was based on the first Raspbian (Debian Wheezy I think).
I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it.
He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published
anymore. The user was not really a Linux noob so I explained him how
in principle one can update Debian to the next version, and he did that
and stepped to the next version (Jessie). That went well, although it of
course was quite some work to process all edits of config files, and he had
an issue with a package no longer supported. Fixed all that. Now the
next step, but that failed completely. Too many problems.
(I have done this on PC systems and I know that it requires quite some
attention and skills)
So now such a user is at a dead end: they can go back to the saved card
image and run outdated software forever and no longer be able to do new
things, or they have to re-invent the whole wheel (download recent OS
image for the Pi and then install all the wanted packages and configure them).
At that time the advantage of having a prepared install is lost completely,
works even against you as you have no knowledge of what was exactly
done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router
with current software, you have to be aware that you have the moral
obligation to track the developments of the OS and hardware and keep
releasing new versions about once a year, or you will leave your happy
users behind in frustration.
Then, it may not be that easy after all.
Rob
On 8/3/21 8:37 PM, David McGough via 44Net wrote:
I fully agree that a complete roll-it-for-yourself
Linux routing solution
is totally impractical for 99.9% of users and would be a nightmare for
maintainers....I'm the developer and maintainer of HamVoIP (with about
10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or
packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
3:17 a.m.
And my point was that is should be an AMPR/ARDC project that's maintained and moved
forward by ARDC. It shouldn't just be a one-person Github repo.
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On
Behalf Of David McGough via 44Net
Sent: Tuesday, August 3, 2021 3:15 PM
To: Rob PE1CHL via 44Net <44net(a)mailman.ampr.org>
Cc: David McGough <kb4fxc(a)inttek.net>
Subject: Re: [44net] On Allocations, PoPs, and Proposals
Rob, I already do this (https://hamvoip.org)! I fully understand the
concerns.
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
Well yes, it is probably "easy to
do". But you need to be aware that you
get into a commitment that you need
to sustain for many years. It is
doable to make a downloadable image for the Raspberry Pi and maybe some
config screen to set it up, and put it on a website, but after some time the
software gets outdated, new models of Pi appear that require or prefer
a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio
oriented services which was published around 6 years ago. I downloaded
that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with
it. Nice. It was based on the first Raspbian (Debian Wheezy I think).
I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it.
He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published
anymore. The user was not really a Linux noob so I explained him how
in principle one can update Debian to the next version, and he did that
and stepped to the next version (Jessie). That went well, although it of
course was quite some work to process all edits of config files, and he had
an issue with a package no longer supported. Fixed all that. Now the
next step, but that failed completely. Too many problems.
(I have done this on PC systems and I know that it requires quite some
attention and skills)
So now such a user is at a dead end: they can go back to the saved card
image and run outdated software forever and no longer be able to do new
things, or they have to re-invent the whole wheel (download recent OS
image for the Pi and then install all the wanted packages and configure
them).
At that time the advantage of having a prepared install is lost completely,
works even against you as you have no knowledge of what was exactly
done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router
with current software, you have to be aware that you have the moral
obligation to track the developments of the OS and hardware and keep
releasing new versions about once a year, or you will leave your happy
users behind in frustration.
Then, it may not be that easy after all.
Rob
On 8/3/21 8:37 PM, David McGough via 44Net wrote:
I fully agree that a complete
roll-it-for-yourself Linux routing solution
is totally impractical for 99.9% of users and would be a nightmare for
maintainers....I'm the developer and maintainer of HamVoIP (with about
10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or
packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
_________________________________________
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
2:15 a.m.
Rob:
Points well made, but what's different from your example, and the
situation with a potential Net44 appliance based on a Raspberry Pi is
that there's now budget available from ARDC to contract for such
"routine, boring maintenance" to keep the Net44 appliance image up to
date. And, potentially, to provide support for it (such as
documentation).
Such that, when RPi OS is updated, so is the Net44 appliance image
because it's someone's job to do so.
That should take a lot of the sting out of the usage of the Raspberry
Pi as a Net44 appliance.
Steve Stroh N8GNJ
On Tue, Aug 3, 2021 at 12:03 PM Rob PE1CHL via 44Net
<44net(a)mailman.ampr.org> wrote:
Well yes, it is probably "easy to do". But you need to be aware that you
get into a commitment that you need to sustain for many years. It is
doable to make a downloadable image for the Raspberry Pi and maybe some
config screen to set it up, and put it on a website, but after some time the
software gets outdated, new models of Pi appear that require or prefer
a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio
oriented services which was published around 6 years ago. I downloaded
that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with
it. Nice. It was based on the first Raspbian (Debian Wheezy I think).
I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it.
He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published
anymore. The user was not really a Linux noob so I explained him how
in principle one can update Debian to the next version, and he did that
and stepped to the next version (Jessie). That went well, although it of
course was quite some work to process all edits of config files, and he had
an issue with a package no longer supported. Fixed all that. Now the
next step, but that failed completely. Too many problems.
(I have done this on PC systems and I know that it requires quite some
attention and skills)
So now such a user is at a dead end: they can go back to the saved card
image and run outdated software forever and no longer be able to do new
things, or they have to re-invent the whole wheel (download recent OS
image for the Pi and then install all the wanted packages and configure them).
At that time the advantage of having a prepared install is lost completely,
works even against you as you have no knowledge of what was exactly
done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router
with current software, you have to be aware that you have the moral
obligation to track the developments of the OS and hardware and keep
releasing new versions about once a year, or you will leave your happy
users behind in frustration.
Then, it may not be that easy after all.
Rob
--
Steve Stroh stevestroh(a)gmail.com
Editor
Zero Retries Newsletter - https://zeroretries.substack.com
9:49 a.m.
That is exactly what I'm doing here. I have existing working configs in one big zip
file what I upload
and configure for their situation. They only thing what they have to do is installation of
the
basic Linux distro and make a ssh port available. Of course, that is much more then IPIP
tunnels.
(IPIP is not difficult at all, most issues are routers/fw's not passing it, less an
issue nowadays
with dd-wrt and otherwise, I provide a VPN from my gateway or another solution.)
The rest is something else, but this provide all kinds of (tcp/ip) services and also old
style packet, if
they want it. A lot are maybe new or have just less experience with this stuff. Some, just
need an
example and after some E-mails and assistance, they figure it out themselves.
Bob
On 2021-08-03 14:37, David McGough via 44Net wrote:
Hi Rob,
Not trying to belabor the Linux discussion; agreed, it has been tossed
around many times over the last decade+. I do have one more comment,
thought.
I fully agree that a complete roll-it-for-yourself Linux routing solution
is totally impractical for 99.9% of users and would be a nightmare for
maintainers....I'm the developer and maintainer of HamVoIP (with about
10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or
packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
--
There is nothing permanent except change
-Heraclitus
As I wrote in another reply, for each problem and
each admin there
is a different solution. The RB750Gr3 runs IPsec at
>450Mbit/s which
is enough for most users. Do not use OpenVPN on these devices,
use L2TP/IPsec or GRE/IPsec.
I am currently in mail exchange with someone who wants to configure
AMPRnet access on a VPS using standard Linux software. Easy peasy
when you ask me, but it is a nightmare to get someone going who
has no Linux admin skills at all and is only cutting/pasting error messages
all the time, and not really reading the directions or able to debug things
without constant hand-helding. With a MikroTik he would be going,
with the Linux system he is only whining and complaining.
(but others get it working after only a single message with some hints)
Read back in the 44Net mail archives and you can see the same discussion
over and over, so I think this is enough for now.
Rob
On 8/3/21 7:29 PM, David McGough via 44Net wrote:
I'll add a comment here, since I've used
the RB750G gear and RPi boards
extensively as routers. I *highly* recommend the RPi4B! The difference in
SoC processing power is massive, when crunching crypto for VPNs, enough
RAM for BGP and other system services, etc. There are many OS/distro
sources available and the very latest software version are only a few
clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the
concern for simply having crummy data thru-put due to crypto processing
overhead. I've got several RB750G routers, they're all sitting on the
shelf, these days.
_________________________________________
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 
9 Aug
9 Aug
4:07 p.m.
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry
Pi because of its availability
and the capability to also host some applications on the same device aside from
doing the routing, in my experience it is much easier to use a dedicated router
like the MikroTik hEX (RB750Gr3) available for about the same price, but having
5 ethernet ports and all software required for VPN and routing pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
11:05 p.m.
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like
that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de
Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry
Pi because of its availability
and the capability to also host some applications on the same device aside from
doing the routing, in my experience it is much easier to use a dedicated router
like the MikroTik hEX (RB750Gr3) available for about the same price, but having
5 ethernet ports and all software required for VPN and routing pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
10 Aug
10 Aug
12:17 a.m.
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <44net(a)mailman.ampr.org>
wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
While I agree that it is attractive to use a
Raspberry Pi because of its
availability
and the capability to also host some applications
on the same device
aside from
doing the routing, in my experience it is much
easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for
about the same price, but
having
5 ethernet ports and all software required for
VPN and routing
pre-installed and
much easier to configure and maintain than a
Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of
them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
3:46 a.m.
USB adapter or the use of VLAN tags and a managed switch.
ex:
https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi…
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net
<44net(a)mailman.ampr.org> wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <44net(a)mailman.ampr.org>
wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net While I agree that it is attractive to use a
Raspberry Pi because of its
availability
and the capability to also host some applications
on the same device
aside from
doing the routing, in my experience it is much
easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for
about the same price, but
having
5 ethernet ports and all software required for
VPN and routing
pre-installed and
much easier to configure and maintain than a
Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of
them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
4:31 a.m.
Thanks for the suggestion Steve.
The use of Vlan and a managed switch seem like a good idea.
But you need to remember 2 thing in the solution that need to be deployed here.
Not every switch is managable, most that are will cost more than the RPI, lambda ham does
not even know what a Vlan is. And using a cheap repurposed 10/100 switch will provide a
maximum 50 Mb/s at max as it will be used twice for each inbound/outbound packets. But it
will be a more stable solution than USB Ethernet NIC.
We need to supply a simple and stable solution for the average ham that start in
networking and easy to support. useage of Vlan wont cut it. USB ethernet nic will be the
same. Yes the RPI 4 will do it. But you have to remember that most ham's that have a
RPI 2 or even a RPI B will want to use his board to experiement. If we do this we will
loose the interest of many by offerring networks that will be slow compared to what they
are use to. And if by bad luck we fall on the geek of the place that the other ham look
upon to use a specific tehnology or not, the 44net wont be used in large chunk of the
globe. This aint our goal.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de Steve
L via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 16:46
À : 44Net general discussion
Cc : Steve L
Objet : Re: [44net] On Allocations, PoPs, and Proposals
USB adapter or the use of VLAN tags and a managed switch.
ex:
https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi…
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net
<44net(a)mailman.ampr.org> wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <44net(a)mailman.ampr.org>
wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net While I agree that it is attractive to use a
Raspberry Pi because of its
availability
and the capability to also host some applications
on the same device
aside from
doing the routing, in my experience it is much
easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for
about the same price, but
having
5 ethernet ports and all software required for
VPN and routing
pre-installed and
much easier to configure and maintain than a
Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of
them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
4:41 a.m.
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a
very competent router that is rock-solid.
73, David KB4FXC
On Mon, 9 Aug 2021, pete M via 44Net wrote:
Thanks for the suggestion Steve.
The use of Vlan and a managed switch seem like a good idea.
But you need to remember 2 thing in the solution that need to be deployed here.
Not every switch is managable, most that are will cost more than the RPI, lambda ham does
not even know what a Vlan is. And using a cheap repurposed 10/100 switch will provide a
maximum 50 Mb/s at max as it will be used twice for each inbound/outbound packets. But it
will be a more stable solution than USB Ethernet NIC.
We need to supply a simple and stable solution for the average ham that start in
networking and easy to support. useage of Vlan wont cut it. USB ethernet nic will be the
same. Yes the RPI 4 will do it. But you have to remember that most ham's that have a
RPI 2 or even a RPI B will want to use his board to experiement. If we do this we will
loose the interest of many by offerring networks that will be slow compared to what they
are use to. And if by bad luck we fall on the geek of the place that the other ham look
upon to use a specific tehnology or not, the 44net wont be used in large chunk of the
globe. This aint our goal.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de
Steve L via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 16:46
À : 44Net general discussion
Cc : Steve L
Objet : Re: [44net] On Allocations, PoPs, and Proposals
USB adapter or the use of VLAN tags and a managed switch.
ex:
https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi…
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net
<44net(a)mailman.ampr.org> wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <44net(a)mailman.ampr.org>
wrote:
_________________________________________
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
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net While I agree that it is attractive to use a
Raspberry Pi because of its
availability
and the capability to also host some applications
on the same device
aside from
doing the routing, in my experience it is much
easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for
about the same price, but
having
5 ethernet ports and all software required for
VPN and routing
pre-installed and
much easier to configure and maintain than a
Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of
them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
4:47 a.m.
Another great option, with a x64 compatible CPU and 3 or 4 real gigabit
ports, M2 SSD and optional mini-PCIe extensions (e.g. WiFi, LoRa or 3G+).
https://pcengines.ch/apu3b4.htm
https://pcengines.ch/apu4c4.htm
73, Marius YO2LOJ
On 10/08/2021 00:41, David McGough via 44Net wrote:
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a
very competent router that is rock-solid.
73, David KB4FXC
4:59 a.m.
"Exotic" hardware and VLANs are not "get easily on 44Net". Seriously,
at the speeds the average non-BGP-advertised ham needs, a Pi4 with an additional
USB-connected Ethernet port will work just fine and meet any necessary performance goals
and be the most approachable format for both connecting wires and online help
availability. Given that, in general, you can't buy the older Pis anymore I would
think most people are getting a Pi4.
Jason N8EI
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On
Behalf Of Marius Petrescu via 44Net
Sent: Monday, August 9, 2021 5:48 PM
To: 44net(a)mailman.ampr.org
Cc: Marius Petrescu <marius(a)yo2loj.ro>
Subject: Re: [44net] On Allocations, PoPs, and Proposals
Another great option, with a x64 compatible CPU and 3 or 4 real gigabit ports,
M2 SSD and optional mini-PCIe extensions (e.g. WiFi, LoRa or 3G+).
https://pcengines.ch/apu3b4.htm
https://pcengines.ch/apu4c4.htm
73, Marius YO2LOJ
On 10/08/2021 00:41, David McGough via 44Net wrote:
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this
makes a very competent router that is rock-solid.
73, David KB4FXC
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2:42 p.m.
True, but remember that you can buy a MikroTik RB750Gr3 for the same amount of money
and you have 5 ethernet ports plus USB without the hassle, and it runs as a router
without
further software installation. When you want to run applications, you can always add a
Pi4
connected to one of its ports.
People sometimes remark "but $59.95 for that router that is more expensive than a
Pi"
but remember it comes with an enclosure, memory, and a powersupply. To a Pi you need to
add an enclosure, SD card, and a powersupply at minimum and then possibly USB ethernet
adapter(s).
Rob
On 8/9/21 11:59 PM, Jason McCormick via 44Net wrote:
"Exotic" hardware and VLANs are not
"get easily on 44Net". Seriously, at the speeds the average non-BGP-advertised
ham needs, a Pi4 with an additional USB-connected Ethernet port will work just fine and
meet any necessary performance goals and be the most approachable format for both
connecting wires and online help availability. Given that, in general, you can't buy
the older Pis anymore I would think most people are getting a Pi4.
Jason N8EI
3:04 p.m.
I know its more expensive than a PI but:-
1. Router models seem to come and go like the sun in a UK summer. Whilst PIs evolve I
can't see them vanishing.
2. Its possible to make the PI pretty much plug-and-play. I have a Pi running PI-Star and
can connect to DMR and YSF. Wouldn't it be great if it could do so over 44net.
Dave
G4UGM
-----Original Message-----
From: 44Net <44net-bounces+dave.g4ugm=gmail.com(a)mailman.ampr.org>
On Behalf Of Rob PE1CHL via 44Net
Sent: 10 August 2021 08:42
To: 44net(a)mailman.ampr.org
Cc: Rob PE1CHL <44net(a)pe1chl.nl>
Subject: Re: [44net] On Allocations, PoPs, and Proposals
True, but remember that you can buy a MikroTik RB750Gr3 for the same
amount of money and you have 5 ethernet ports plus USB without the
hassle, and it runs as a router without further software installation. When
you want to run applications, you can always add a Pi4 connected to one of
its ports.
People sometimes remark "but $59.95 for that router that is more expensive
than a Pi"
but remember it comes with an enclosure, memory, and a powersupply. To
a Pi you need to add an enclosure, SD card, and a powersupply at minimum
and then possibly USB ethernet adapter(s).
Rob
On 8/9/21 11:59 PM, Jason McCormick via 44Net wrote:
"Exotic" hardware and VLANs are not
"get easily on 44Net". Seriously, at
the speeds the average
non-BGP-advertised ham needs, a Pi4 with an
additional USB-connected Ethernet port will work just fine and meet any
necessary performance goals and be the most approachable format for both
connecting wires and online help availability. Given that, in general, you can't
buy the older Pis anymore I would think most people are getting a Pi4.
Jason N8EI
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
3:52 p.m.
Well, actually these routers have existed and evolved for longer than the Raspberry Pi.
Of course they could vanish but as we are (hopefully) no longer using proprietary
protocols
in the routing layer, they can always be replaced by something else.
Actually whn you run your applications on the same system where you do the routing, there
is an extra issue that many admins do not understand: source address selection.
At least with two different systems for applications and routings you don't have that
issue.
Rob
On 8/10/21 10:04 AM, g4ugm via 44Net wrote:
I know its more expensive than a PI but:-
1. Router models seem to come and go like the sun in a UK summer. Whilst PIs evolve I
can't see them vanishing.
2. Its possible to make the PI pretty much plug-and-play. I have a Pi running PI-Star and
can connect to DMR and YSF. Wouldn't it be great if it could do so over 44net.
Dave
G4UGM
4:51 a.m.
ARDC has $, build a custom carrier for a CM4 that has 2 Ethernet ports, a
USB hub, a couple of serial ports et, sell it to Hams below cost, problem
goes away. There are all kids of options, and there is no one size fits
all. the point here is to come up with "easy ways" to get on the net.
Cheap, Easy, Performant pick 2.
On Mon, Aug 9, 2021 at 2:43 PM David McGough via 44Net <
44net(a)mailman.ampr.org> wrote:
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a
very competent router that is rock-solid.
73, David KB4FXC
On Mon, 9 Aug 2021, pete M via 44Net wrote:
_________________________________________
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
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
Thanks for the suggestion Steve.
The use of Vlan and a managed switch seem like a good idea.
But you need to remember 2 thing in the solution that need to be
deployed here.
Not every switch is managable, most that are will
cost more than the
RPI, lambda ham does not even know what a Vlan is. And using a
cheap
repurposed 10/100 switch will provide a maximum 50 Mb/s at max as it will
be used twice for each inbound/outbound packets. But it will be a more
stable solution than USB Ethernet NIC.
We need to supply a simple and stable solution for the average ham that
start in
networking and easy to support. useage of Vlan wont cut it. USB
ethernet nic will be the same. Yes the RPI 4 will do it. But you have to
remember that most ham's that have a RPI 2 or even a RPI B will want to use
his board to experiement. If we do this we will loose the interest of many
by offerring networks that will be slow compared to what they are use to.
And if by bad luck we fall on the geek of the place that the other ham look
upon to use a specific tehnology or not, the 44net wont be used in large
chunk of the globe. This aint our goal.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part
de Steve L via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 16:46
À : 44Net general discussion
Cc : Steve L
Objet : Re: [44net] On Allocations, PoPs, and Proposals
USB adapter or the use of VLAN tags and a managed switch.
ex:
https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi…
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net
<44net(a)mailman.ampr.org> wrote:
>
> Pete,
>
> RPI works just fine with USB to Ethernet adapters. You can add
multiple
> Ethernet connections in this way.
>
> On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <
44net(a)mailman.ampr.org>
> wrote:
>
> > I have a question about using a RPI for net44.
> >
> > Since this device only have one physical Ethernet port (and a Wi-Fi
NIC).
> >
> > By which way are you hoping to use those to route some traffic?
> >
> > Entering by Wi-Fi then out from the Ethernet port? That can work,
but I
> > would not like that.
> >
> >
> >
> > ________________________________________
> > De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de
la
> > part de Toussaint OTTAVI via 44Net
<44net(a)mailman.ampr.org>
> > Envoyé : 9 août 2021 05:07
> > À : 44net(a)mailman.ampr.org
> > Cc : Toussaint OTTAVI
> > Objet : Re: [44net] On Allocations, PoPs, and Proposals
> >
> >
> > Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
> > > While I agree that it is attractive to use a Raspberry Pi because
of its
> > availability
> > > and the capability to also host some applications on the same
device
> > aside from
> > > doing the routing, in my experience it is much easier to use a
dedicated
> > router
> > > like the MikroTik hEX (RB750Gr3) available for about the same
price, but
> > having
> > > 5 ethernet ports and all software required for VPN and routing
> > pre-installed and
> > > much easier to configure and maintain than a Raspberry Pi.
> > >
> > > Of course there always are multiple options. And Raspberry Pi
should be
> > one of them.
> >
> > The network setup must be as standard as possible, so that it can be
> > implemented on a large amount of equipment :
> > - People building networks, remote sites, repeaters, or advanced
users
> > with some network knowledge, may prefer
a dedicated router platform,
> > such as Mikrotik, UBNT, OpenWRT, etc...
> > - Beginners or standalone users may prefer plug-and-play setup on a
> > Raspberry Pi. The most obvious example that comes to my mind is
Pi-Star
> > (a very good Pi appliance for digital
modes hotspot or repeater,
which
embeds many existing software for D-Star, DMR, YSF
etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
3:58 a.m.
My experience with usb to ethernet has never been great.
They do make good sidekick device to debug or for temporary things. But over the long run
they fail more than we can hope it not.
And the USB stack of the RPI is not that fast. So if the CPUis already busy with decrpting
a tunnel packet the flow will drop pretty fast.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de K7VE
- John via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 13:17
À : 44Net general discussion
Cc : K7VE - John
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <44net(a)mailman.ampr.org>
wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
--
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
While I agree that it is attractive to use a
Raspberry Pi because of its
availability
and the capability to also host some applications
on the same device
aside from
doing the routing, in my experience it is much
easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for
about the same price, but
having
5 ethernet ports and all software required for
VPN and routing
pre-installed and
much easier to configure and maintain than a
Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of
them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
4:31 a.m.
Pete:
Understood that the Raspberry Pi isn't the best fit for a "Net44 VPN
router". It's a general purpose computer, kind-of underpowered (until
the RPi 4s) and adding a second Ethernet port via USB isn't ideal.
There are, of course, "Raspberry Pi" systems like this with dual
"real" Ethernet ports -
https://www.seeedstudio.com/Rapberry-Pi-CM4-Dual-GbE-Carrier-Board-p-4874.h…,
but that kind of negates the "training wheels" aspect of the Raspberry
Pi solution. At the point you're considering such a system, there are
real routers.
But there's a lot of us (and I count myself among them) for which the
"training wheels" aspect of a Net44 router on a RPi would be a decent
starting point.
Steve N8GNJ
On Mon, Aug 9, 2021 at 1:59 PM pete M via 44Net <44net(a)mailman.ampr.org> wrote:
My experience with usb to ethernet has never been great.
They do make good sidekick device to debug or for temporary things. But over the long run
they fail more than we can hope it not.
And the USB stack of the RPI is not that fast. So if the CPUis already busy with
decrpting a tunnel packet the flow will drop pretty fast.
--
Steve Stroh stevestroh(a)gmail.com
Editor
Zero Retries Newsletter - https://zeroretries.substack.com
9:04 a.m.
yes, one CAN add a hundred billion USB to Ethernet adapters to the pi.
Yes, Linux WILL even run vlans..... but that doesn't make the PI a GOOD
choice for a routing appliance with only a single ethernet port which if
I remember right is itself connected via usb. A much better thing to
base such an appliance on would be a board that had at least 3 (local
and dual uplinks) separate hardware gigabit ethernet interfaces with
each being attached to a vlan capable switch chip. Then design and
build (or simply buy, aka wifi bridge) an ethernet to bits radio
tranceiver. Could we not say together with TAPR, come up with and build
the next TNC2021 (escentially a 3 port GigE router) and a DR2021 (long
haul, point to point microwave data radio) and keep it at a price point
around say $300 US. (about the cost of a decent mobile radio). This is
where some of that Grant money and funds from ARDC ought be going......
To design and build needs based hardware for amaterur radio networks.
Let's build a starter appliance for those who want to learn networking
via 44net use. We have a grand opportunity yo elmer and teach the next
generation of rf microwave data network, engineers. Given the way it's
going it's going to bits and pieces (packets) (bad pun). lets take the
lead and innovate while teaching the next generation. It gives us just
one more important reason for which to hang on to our precious frequency
allocations. May we lead in these areas and come up with a recommended
appliance and config. That would move us far ahead.
On 2021-08-09 10:17, K7VE - John via 44Net wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add
multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net
<44net(a)mailman.ampr.org>
wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi
NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit : While I agree
that it is attractive to use a Raspberry Pi because of its availability
and the capability to also host some applications on the same device
aside from doing the routing, in my experience it is much easier to use
a dedicated router like the MikroTik hEX (RB750Gr3) available for about
the same price, but having 5 ethernet ports and all software required
for VPN and routing pre-installed and much easier to configure and
maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should
be one of them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
11 Aug
11 Aug
1:45 a.m.
Eric have a VERY valid point.
Just one thing we need to confirm, the board ADRC will choose to promote will need to be a
long term product and make sure that if there is a "new" improved version of it
that the work they did to make the booting image is also compatible or easily portable.
If it would be compatible with openWRT would be a very good thing.
And I think ARDC could even have a large scale rabate. This and a wa to mary a Ubiquity or
Mikrotic dish or omni antenna And the capacity to either be a part of a
"backbone" and/or a mesh and we have a winning solution.
I know that the entry level price of the raspberry pi is very appealing. Yes it would be
nice to have a capacity to have the ethernet port to be able to connect to 44net and
recive a /32. This could be a fun project to do. But it is not a viable one if anyone want
to scale up a bit. the limitation will come back to bite us very fast.
If ARDC want to use raspeberry pi with let say pi-star/net44 interconnect, make it claer
that it is ONLY for local terminaison of the network (client only) not for client and
routing capacity.
In fact the real thing a Raspberry pi should do is to connect to a POP and recive a /32
and maybe relay it by wifi to other machine around the house just for fun. (Acces point
mode) There are also a few distro that are specific to ham radio for the raspberry pi.
Like HamPi https://github.com/dslotter/HamPi
Maybe contact those guys that are already supporting 80+ apps for ham on a rpi and ask if
they would be ok to add a way to connect those RPI to net44 trough one of the POP with a
simple wizard that would ask a few question like ID/password/location and if they are
already connected to one of the networks or mesh on the 44 net to make sure no one will
make bridges with out understanding what they are doing. And the wizard could do the hard
pulling of configuring the network/vpn or wireguard etc. for the ham to actually connect
to net 44 for his ham stuff.
This could be a very short time action ARDC could do to spark the use of net44
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de Af6ep
via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 22:04
À : 44Net general discussion
Cc : eric.fort.listmail(a)fortconsulting.org
Objet : Re: [44net] On Allocations, PoPs, and Proposals
yes, one CAN add a hundred billion USB to Ethernet adapters to the pi.
Yes, Linux WILL even run vlans..... but that doesn't make the PI a GOOD
choice for a routing appliance with only a single ethernet port which if
I remember right is itself connected via usb. A much better thing to
base such an appliance on would be a board that had at least 3 (local
and dual uplinks) separate hardware gigabit ethernet interfaces with
each being attached to a vlan capable switch chip. Then design and
build (or simply buy, aka wifi bridge) an ethernet to bits radio
tranceiver. Could we not say together with TAPR, come up with and build
the next TNC2021 (escentially a 3 port GigE router) and a DR2021 (long
haul, point to point microwave data radio) and keep it at a price point
around say $300 US. (about the cost of a decent mobile radio). This is
where some of that Grant money and funds from ARDC ought be going......
To design and build needs based hardware for amaterur radio networks.
Let's build a starter appliance for those who want to learn networking
via 44net use. We have a grand opportunity yo elmer and teach the next
generation of rf microwave data network, engineers. Given the way it's
going it's going to bits and pieces (packets) (bad pun). lets take the
lead and innovate while teaching the next generation. It gives us just
one more important reason for which to hang on to our precious frequency
allocations. May we lead in these areas and come up with a recommended
appliance and config. That would move us far ahead.
On 2021-08-09 10:17, K7VE - John via 44Net wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add
multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net
<44net(a)mailman.ampr.org>
wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi
NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I
would not like that.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 05:07
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit : While I agree
that it is attractive to use a Raspberry Pi because of its availability
and the capability to also host some applications on the same device
aside from doing the routing, in my experience it is much easier to use
a dedicated router like the MikroTik hEX (RB750Gr3) available for about
the same price, but having 5 ethernet ports and all software required
for VPN and routing pre-installed and much easier to configure and
maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should
be one of them.
The network setup must be as standard as possible, so that it can be
implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform,
such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater, which
embeds many existing software for D-Star, DMR, YSF etc... into a
coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________
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
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
4:31 a.m.
Le 10/08/2021 à 20:45, pete M via 44Net a écrit :
If ARDC want to use raspeberry pi with let say
pi-star/net44 interconnect, make it claer that it is ONLY for local terminaison of the
network (client only) not for client and routing capacity.
That's what I was meaning, too. It's for easy implementation of
plug-and-play appliances. It would be a "first step" into 44net.
Later, if people is interested in 44net and wants to connect more than
one equipment, migrating to a full "Access" router would be the right
choice (Mikrotik, OpenWRT, etc...)
5:31 a.m.
I think that we are on the same page ;-)
Nice to see that I am not the only one.
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de
Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 10 août 2021 17:31
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 10/08/2021 à 20:45, pete M via 44Net a écrit :
If ARDC want to use raspeberry pi with let say
pi-star/net44 interconnect, make it claer that it is ONLY for local terminaison of the
network (client only) not for client and routing capacity.
That's what I was meaning, too. It's for easy implementation of
plug-and-play appliances. It would be a "first step" into 44net.
Later, if people is interested in 44net and wants to connect more than
one equipment, migrating to a full "Access" router would be the right
choice (Mikrotik, OpenWRT, etc...)
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
10 Aug
10 Aug
2:16 p.m.
Le 09/08/2021 à 18:05, pete M via 44Net a écrit :
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
The main purpose of a Raspberry Pi appliance is not to act as a router.
It's to provide easy plug-and-play 44Net connectivity for software
already running on the Pi. F/ex, Pi-Star is a great appliance for
digital modes (D-Star, DMR, C4FM...). The vast majority of digital
repeaters and reflectors all over the world are currently connected
through normal Internet. This would allow those nodes to be connected to
44net instead of Internet. Pi-Star is really "Plug and Play" : you flash
a sd-card, you change a few settings through the web interface
(callsign, etc...) and it works. We need the same thing for 44Net
addressing :-)
Of course, this does not replace routers, which are the preferred way to
connect a local network to 44net. This is an alternative option, to
allow mass adoption of 44net, for people who are not network
specialists, and just want things to work HI :-)
73 de TK1BI
9 Aug
9 Aug
3:48 p.m.
Hi all, and thank you for all the work.
Le 03/08/2021 à 00:56, Jason McCormick via 44Net a écrit :
For the existing AMPRNet, I echo what Rob PE1CHL and
others have stated on this list. Here's my summary though:
1) The barrier to entry for the casual user who wants to connect to the Internet with
44Net space is too high and relies on outdated technology. A technology that is
NAT-friendly for IPv4 is imperative. Not only can many people not port-forward in the IPIP
protocol, they are increasingly finding themselves behind a CGN and thus are a
double-NAT'd. There needs to be a comprehensive, geographically diverse (BY NETWORK
not by country border) set of connection points that use modern, NAT-friendly technologies
such as OpenVPN and Wireguard. Maybe even L2TP. Offer ALL the options, rather than one
option. Options should not require non-standard tooling such as the quasi-RIP routing
daemon.
+1
3) Development of a standard "get on 44Net"
appliance built on a Pi. Something that reaches out to the solution developed for #1 and
brings in the user's allocation for experimentation. This should be a community-driven
project that aims to have an EASY setup-and-forget system that provides automatic
networking harness for people who want to experiment. Harness the power of the community
who like to tinker with networking to help those who don't want to.
+1, with a variant : a ready-to-use Pi image would be perfect for
beginners. But software should be easy to implement in other existing
featured Pi distributions, such as Pi-Star (and many others).
73 de TK1BI
3 Aug
3 Aug
6:49 a.m.
On 3/8/21 6:29 am, Rosy Wolfe via 44Net wrote:
Hello everyone,
I, along with the board and staff, have been reading these messages.
First of all, I want you all to know that YOU ARE HEARD. The point of
having the TAC put out a proposal was to get feedback before adoption.
It turns out that a significant part of the feedback is negative. I
think that this proposal needs more work and adjustment before we can
consider implementing it. The board and I want to see consensus on the
main points of a proposal among the major schools of thought on this
mailing list. That said, it’s important to remember that the people on
this list are not the only people using the AMRPnet. We have a complex
task on our hands to reach as many of those people as possible as we
evolve proposals toward consensus.
I'm in two minds about the proposal, and it
comes down to "more
information needed" (more below). I'm one for whom renumbering will be
a major exercise, with 200+ IP addresses, plus having to liaise with
various network administrators for manual intervention and running some
geolocation sensitive services, which means a protracted changeover.
I'm not opposed to doing this, BUT it has to be worth my while, with
clear benefits for the network (and hopefully myself) at the end of it.
Last thing I want is to spend that time and effort, and be where we are
now, or worse, having to do it again, to fix up something unforeseen.
Several board members have suggested that it's hard to find consensus
on solutions until we have a consensus on what problem(s) the
solutions are trying to solve. We have a tangle of issues like the
complexity of IPIP tunnels, to BGP routing, to address space
sparseness, to low performance.
Yes, I'd like to see the problems fleshed out
first, so we have a clear
definition of the problems, their priority and proposed solutions.
With this in mind, what problems with the AMPRnet do you think we
should be trying to solve first?
One thing we haven't communicated well before, is that we are actively
discussing budget and infrastructure for a “backbone” network of PoPs
(Points of Presence) of the 44net on various continents, to make it
easier for hams to connect to the AMPRnet with minimal effort and
higher performance. If you have ideas about how you would like to see
this happen, feel free to share here on the mailing list. I know that
there’s at least one alternative proposal on the way.
First thing for me is to
replace the IPIP mesh with the proposed
backbone. While I have IPIP working here, I'm not 100% convinced that
it's as reliable as I'd like. Often, my routing table has only had
routes in 44.128/10, on occasions I've checked. While direct point to
point links should offer good performance, I'm not necessarily convinced
I'm seeing that, and there's many possible places things could break
(routers not passing the IPIP protocol, for example). The backbone/POP
idea could offer simpler setup for the cost of slightly less optimal
routing for end users. The VPN software can generally route subnets, if
told to do so by the server (perfect for those of us with subnet
allocations). The question is whether we can make it as easy for ARDC
to manage as the current system.
Other issues I see are:
Manual DNS management seems so 1990s. I haven't made any changes to my
DNS, as manual changes by a third party (network coordinator in this
case) is a major barrier. And a simple means of reverse DNS delegation
would be nice for those of us with /24 or larger allocations. And
having control of firewall separated from DNS would be nice - I may want
ampr.org DNS "internally", but not want my RF sites Internet connected.
There seems to be questions of how to communicate between intranet
(those on the radio/tunneled network) and BGP announced subnets, and
this is where different people may need different solutions, depending
on their network topology, etc. I have a private VPN between my
tunneled and BGP subnets, because some routes would otherwise go via San
Diego otherwise - that's working "long path" (~18000-20000km) for a
server 150km away! :) I'd like relatively right connectivity between my
BGP and intranet subnets, and possibly other BGP routed subnets, but no
connection (generally) to the wider Internet from my part of the intranet.
Anyway, just putting some thoughts out there for discussion.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
9 Aug
9 Aug
3:55 p.m.
Le 03/08/2021 à 01:49, Tony Langdon via 44Net a écrit :
I'd like relatively right connectivity between
my
BGP and intranet subnets, and possibly other BGP routed subnets, but no
connection (generally) to the wider Internet from my part of the intranet.
As I often say, don't confuse "routing" and "firewalling". Those
are two
separated topics, that should IMHO be handled separately :
- Connectivity between BGP, Intranet and maybe other local/extranet
subnets is a matter of routing (which implies a coherent addressing
policy, and probably, some renumbering at some point)
- What kind of traffic is allowed / forbidden is a matter of firewall
rules. Those rules may differ between countries, user groups or specific
situations.
If the lack of a route is a common way to prevent users from reaching
"forbidden" addresses, it's not IMHO the good way of doing things, HI :-)
6:44 p.m.
Dear Toussaint,
Am 09. Aug 2021, um 10:55:50 schrieb Toussaint OTTAVI via 44Net:
In theory, and in normal networks, you would be right. The difference
is however that in normal networks, you generally use firewalls to block
access to ressources. The problem we have at hand is slightly different:
We need to protect access to links.
At least in some jurisdictions, we must not route certain traffic via
an amateur radio link, so we face the dilemma of having a (possibly
preferable) route via the radio that is not available to that certain
traffic. Naturally, you'd block that traffic using a firewall route.
A route announcement generally is a promise to carry traffic to that
destination. Can you still honestly make this promise if your firewall
blocks that traffic? Or should you rather not announce that route ?
In the traditional (internet only) case it doesnt matter because a
a firewall would protect the resource no matter the path.
But in our case, your route announcement and subsequent packet dropping
would be wrong (needlessly preventing communication) if another route were
available that is not subject to the amateur radio link access restriction
(maybe there is no amateur radio link, or maybe its via a different
jurisdiction)
Somewhere deep down in that case lies the problem that the TAC proposal
was trying to solve, although that was not fully documented.
A related question, also burried deep down in that lane:
Your firewall rule would typically be filtering on
source/destination addresses.
It is, I think, not disputed that a part of the reason to get users onto
the 44 Net is that it identifies communiation partners as
duly licensed ham radio operators, hinting your firewall that amateur
radio frequency access may be allowed.
So, does initiation of a 44-to-44 communication also imply some form of
agreement/representation that the content of that communication is
suitable for the amateur radio air waves ?
Suppose I'd want to tell a non-politically-correct joke to another OM.
I can now choose if I wanted to take the VHF TRX to call him on the
local repeater, or I could call him on the landline phone.
How should this be handled ?
73s,
Mario, DL5MLO
--
Mario Lorenz Internet: <ml(a)vdazone.org>
I'd like
relatively right connectivity between my
BGP and intranet subnets, and possibly other BGP routed subnets, but no
connection (generally) to the wider Internet from my part of the intranet.
As I often say, don't confuse "routing" and "firewalling". Those
are two
separated topics, that should IMHO be handled separately :
10 Aug
10 Aug
3:49 p.m.
Le 09/08/2021 à 13:44, Mario Lorenz a écrit :
In theory, and in normal networks, you would be right. The difference
is however that in normal networks, you generally use firewalls to block
access to ressources. The problem we have at hand is slightly different:
We need to protect access to links.
Interesting answer, but the discussion may come al little bit off-topic
here :-)
At least in some jurisdictions, we must not route
certain traffic via
an amateur radio link, so we face the dilemma of having a (possibly
preferable) route via the radio that is not available to that certain
traffic. Naturally, you'd block that traffic using a firewall route.
1/ Most of HAM rules about interconnecting HAM networks with public
networks were written during the last century, when the technology and
Internet were not what they are today. My personal opinion is that most
of those rules may need to be refined or re-defined :-) As licenses HAM
operators, we have the right to experiment new things. Then we (AMPR)
could make proposals for new rules, adapted to the current State of the Art.
2/ IMHO, the validity of the traffic ("Is the operator a licensed ham
radio operator ?") must be checked at the edge. Can we assume every
44net owner is a licensed ham (this implies strict controls by the
people who deliver 44net addresses) ? Can we use certificates ? But most
of all : once some traffic entered 44net network, should we consider it
as "valid" HAM traffic ? Or do we have to make further tests later (the
example you quoted : routing through radio links) ?
3/ As far as we manage the full network from end to end, would it be
possible possible to use QoS everywhere ? An obvious advantage f/ex
would be to prioritize VoIP. But another advantage would be tagging
"valid HAM" packets with a specific DSCP tag. That would allow policy
routing farther in the path (don't route non-ham packets over radio
links, but route them on another link, if available)
A route announcement generally is a promise to carry
traffic to that
destination. Can you still honestly make this promise if your firewall
blocks that traffic?
I would say YES :
- My home network currently has routes to porn sites
- My firewall content filter blocks those sites for everybody (but not
for me, HI)
But in our case, your route announcement and
subsequent packet dropping
would be wrong (needlessly preventing communication) if another route were
available that is not subject to the amateur radio link access restriction
(maybe there is no amateur radio link, or maybe its via a different
jurisdiction)
Nor an easy answer, because there's not one single problem to answer. In
my situation, the problem is simpler, because I'm an island with only
one gateway. Currently, I don't route traffic to other neighbors, so I
don't have to bother with the question : "This traffic is not for me,
should I check if it's valid HAM or not, and should I route it or not ?"
I would say :
- For traffic that is not for me / my network / my region : route in
best effort (without firewalling)
- For traffic that is for me : apply firewall rules according to my
local rules
Somewhere deep down in that case lies the problem that
the TAC proposal
was trying to solve, although that was not fully documented.
I fully agree with the TAC proposal of splitting 44net into two separate
subnets with different policies. We are already experimenting it locally
(with 44.168 and 44.190). This was suggested to me by Jann DG8NGN a
while ago. Each site has two VLANs, dual addressing, and dual routing
policy. Endpoint routers have Ethernet interfaces on both VLANs. We can
choose to connect any equipment to Intranet (44.168) or Internet
(44.190). The central firewall does the main filtering job. It works
fine. It does the job of clearly separating what is "Intranet" and what
is "Internet"
A related question, also burried deep down in that
lane:
Your firewall rule would typically be filtering on
source/destination addresses.
Modern firewalls allow rules based on many parameters (not only
source/dest). Can we imagine a DSCP tag designating "valid" ham radio
traffic ?
It is, I think, not disputed that a part of the reason
to get users onto
the 44 Net is that it identifies communiation partners as
duly licensed ham radio operators, hinting your firewall that amateur
radio frequency access may be allowed.
My personal opinion is that identifying valid amateur radio operators
should be done at the edge, when delivering 44net addresses (Who will do
that and how is yet to be defined, but has been discussed already).
Then, if a packet enters the network with a source IP in the 44net
"Intranet" range, we can consider it as valid amateur data, and route it
accordingly.
So, does initiation of a 44-to-44 communication also
imply some form of
agreement/representation that the content of that communication is
suitable for the amateur radio air waves ?
We should distinguish between "Intranet" and "Internet" ranges :
- If source IP is in the 44net "Intranet" range, then, the sender is a
valid amateur radio operator, operating on a closed radioamateur network
: current amateur traffic rules do apply.
- If source IP is in the 44net "Internet" range, then, the sender is a
valid amateur radio operator :
- If the destination is public Internet : current rules for general
Internet browsing do apply
- If the destination is an amateur radio endpoint (ie, a D-Star or
DMR repeater, linked through Internet because its sysop does not know
how to use 44net, HI) : amateur traffic rules apply.
Suppose I'd want to tell a non-politically-correct
joke to another OM.
I can now choose if I wanted to take the VHF TRX to call him on the
local repeater, or I could call him on the landline phone.
Obviously, you wouldn't use the local VHF repeater, but you would use
phone :-)
How should this be handled ?
You wouldn't connect your terminal to the "Intranet" Ethernet interface
(or WiFi network) of your 44net router, but instead, you would connect
it to the "Internet" interface (or WiFi network)...
73 de TK1BI
9 Aug
9 Aug
10:59 p.m.
Firewaling is the responsibility of the end user and not the routing service.
Routing is what AMPR should keep to and not firewaling. If you don't want to be
directly exposed to the internet there are multiple ways, a firewall on the machine
directly, a "router" that do NAT and won't forward any traffic except
traffic initiated by one machine behind the NAT first. And at the end not having any route
that can connect to the rest of the world and not be connected to any network at all. The
first one is done easily, the second one is a given. And the other are not really useful
at anything.
Now, if you don't want to be accessible from the internet BUT want to be accessible to
HAM ONLY traffic, that is another story. In that case, the only way to go is by route. As
trying to firewall every thing BUT known HAM ONLY traffic is a lost of time, and it will
change almost daily.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de
Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 9 août 2021 04:55
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 01:49, Tony Langdon via 44Net a écrit :
I'd like relatively right connectivity between
my
BGP and intranet subnets, and possibly other BGP routed subnets, but no
connection (generally) to the wider Internet from my part of the intranet.
As I often say, don't confuse "routing" and "firewalling". Those
are two
separated topics, that should IMHO be handled separately :
- Connectivity between BGP, Intranet and maybe other local/extranet
subnets is a matter of routing (which implies a coherent addressing
policy, and probably, some renumbering at some point)
- What kind of traffic is allowed / forbidden is a matter of firewall
rules. Those rules may differ between countries, user groups or specific
situations.
If the lack of a route is a common way to prevent users from reaching
"forbidden" addresses, it's not IMHO the good way of doing things, HI :-)
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
10 Aug
10 Aug
2:58 p.m.
Le 09/08/2021 à 17:59, pete M via 44Net a écrit :
Firewaling is the responsibility of the end user and
not the routing service.
As already noticed several times on this list, there are as many
opinions as members of the list. And I think it's the main difficulty
for the TAC :-)
I don't think firewalling should be the responsibility of end users. We
are sysops and network administrators. We are dealing with complex rules
about connecting 44net networks to Internet. Even on this list, which
includes all major 44net administrators over the world, it's difficult
to agree with a common scheme. Then, it does not seem a clever idea to
let end users do what they want, HI :-)
Here, we are an island. We currently have only one gateway to "the rest
of the world", and in the definite setup, we plan to have two. It seems
obvious to do routing and firewalling at gateway level. At least, it's
what we did :-)
Routing is what AMPR should keep to and not firewaling.
We are saying the same thing :
1/ Routing may be redefined and standardized by AMPR in a way that
allows all possible configurations all over the world (whether local
regulations or policies allow it or not) with modern protocols and tools
2/ Firewalling is where local countries or user groups will define what
is permitted or not in their specific country/region/situation. We are
an island with one gateway, so it's an easy task at gateway level. On a
continent, where rules are different between different neighbor
countries, and where networks are meshed, of course, this is far from easy.
If you don't want to be directly exposed to the
internet there are multiple ways, a firewall on the machine directly, a "router"
that do NAT and won't forward any traffic except traffic initiated by one machine
behind the NAT first. And at the end not having any route that can connect to the rest of
the world and not be connected to any network at all. The first one is done easily, the
second one is a given. And the other are not really useful at anything.
One of the purposes is to allow mass adoption of 44net. Then, we have to
provide plug and play / easy to use setups that can do most of the job
for the user. Here, we are providing "TKBoxes" (OpenWRT routers with
pre-defined configuration made by us). At world-wide scale, we need to
define a common scheme that fits all possible user cases. The split of
44net space in two (one "pure Intranet" and one "Internet-connected")
is
one important step. We are already experimenting it here (44.168 HamNet,
and 44.190 Internet). This involves dual configuration, dual routing,
route exchanges and firewalling at network / gateway level. This can not
be done only at the edge.
Now, if you don't want to be accessible from the
internet BUT want to be accessible to HAM ONLY traffic, that is another story. In that
case, the only way to go is by route. As trying to firewall every thing BUT known HAM ONLY
traffic is a lost of time, and it will change almost daily.
We've been playing that story for a few years now :-) Maybe with a lot
of time lost, I agree :-) For a service that needs to be accessible from
HAMs but not from Internet, you have to put it on the "Intranet" IP
space, and it just works :-) Again, that's not a matter of route, but of
access policy / rule (ie, firewalling).
PS :
As an additional comment, it may be required at some point to mix
routing and firewalling. Nowaday's systems allow to define access rules
and routes based on a lot of parameters (not only source/destination
IP/ports). Some manufacturers call that "policy routing" : there may be
different routes for different kind of traffic based f/ex on a DSCP tag
designating HAM traffic.
What I meant is that the lack of a valid route is not a good way to
block some unwanted traffic. Because what is unwanted by you may be
wanted by me. Routing policy and IP placement must be designed in a WW
strategy, so that it can suit all possible user cases over the world.
Then, what is allowed/forbiden in a specific region may be defined
locally (by firewall rules, not by lack of routes).
73 de TK1BI
11 Aug
11 Aug
2:23 a.m.
We are saying almost the same thing.
ARDC/AMPR need to supply easy way for ham to connect to 44 net and we should not be
defining what they want to receive or send as traffic.
BUT ARDC/AMPR need to also give access to specific use case like an intranet ham only
traffic if asked for it. ( I am sure that a lot of user on the ipip tunnel net dont want
to have russian/chinese hacker to come in their place. And that use case is easy to do if
the routing from the pop to the rest of the world is not open at all to the internet and
you either connect to it by a vpn or any other type of tunnel if connected to the
internet, or if connected by radio, you just dont use a tunel and be free and secure to
use that space without fear. That aint firewalling that is internal routing between the
pop's and the user and the ipip network.
The other use case is to route everything and not firewall anything to another part of 44
net. Yes we could firewall some traffic. Like sanner for port 22/80/443/8080 name the port
you want, from the internet to the user space. (44 net) but again. That is just a service
on top of the real work that ARDC/AMPR need to do. Route the 44 net to the user it target,
the ham community. This can be done by direct BGP ( ARD/AMPR cannot firewall anything
here) or by the POP (an now ARDC/AMPR can firewall things , but again it would be just a
service over the real service they need to provide, ways of connecting ham together.
ARDC/AMPR could make some firewaling rules to adapt to specific country rules and take the
hard work out of the local user. But can it be easily done, We need to see the case before
saying it can be done.
I am sure that you ahve played with routing and programming some route into your setup.
can you tell me, if you want to connect to many /24 that are not on aggregated on a /10 or
even a /16 how many route will you have to keep in your router ? At max the same number of
/24 you have and mayve if lucky you will have a few of those /24 that are aggregated into
a /22 or better a /20 to limit the route number. That is not an easy thing to manage. The
TAC Idea of reserving a /10 for a ham only net would had fix that kind of problem by a
signle magical line that would had route 44.128.0.0/10 to a specific route and without
firewall, without complicated routing and without large difficulty to enter the net a user
would have fallen into the ham only network we all wish we had since the beginning of
AMPR.
But this have been judged by the community as being bad if we read all the answer to the
TAC proposal. I find that very disapointing.
Pierre
VE2PF
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de
Toussaint OTTAVI via 44Net <44net(a)mailman.ampr.org>
Envoyé : 10 août 2021 03:58
À : 44net(a)mailman.ampr.org
Cc : Toussaint OTTAVI
Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 09/08/2021 à 17:59, pete M via 44Net a écrit :
Firewaling is the responsibility of the end user and
not the routing service.
As already noticed several times on this list, there are as many
opinions as members of the list. And I think it's the main difficulty
for the TAC :-)
I don't think firewalling should be the responsibility of end users. We
are sysops and network administrators. We are dealing with complex rules
about connecting 44net networks to Internet. Even on this list, which
includes all major 44net administrators over the world, it's difficult
to agree with a common scheme. Then, it does not seem a clever idea to
let end users do what they want, HI :-)
Here, we are an island. We currently have only one gateway to "the rest
of the world", and in the definite setup, we plan to have two. It seems
obvious to do routing and firewalling at gateway level. At least, it's
what we did :-)
Routing is what AMPR should keep to and not firewaling.
We are saying the same thing :
1/ Routing may be redefined and standardized by AMPR in a way that
allows all possible configurations all over the world (whether local
regulations or policies allow it or not) with modern protocols and tools
2/ Firewalling is where local countries or user groups will define what
is permitted or not in their specific country/region/situation. We are
an island with one gateway, so it's an easy task at gateway level. On a
continent, where rules are different between different neighbor
countries, and where networks are meshed, of course, this is far from easy.
If you don't want to be directly exposed to the
internet there are multiple ways, a firewall on the machine directly, a "router"
that do NAT and won't forward any traffic except traffic initiated by one machine
behind the NAT first. And at the end not having any route that can connect to the rest of
the world and not be connected to any network at all. The first one is done easily, the
second one is a given. And the other are not really useful at anything.
One of the purposes is to allow mass adoption of 44net. Then, we have to
provide plug and play / easy to use setups that can do most of the job
for the user. Here, we are providing "TKBoxes" (OpenWRT routers with
pre-defined configuration made by us). At world-wide scale, we need to
define a common scheme that fits all possible user cases. The split of
44net space in two (one "pure Intranet" and one "Internet-connected")
is
one important step. We are already experimenting it here (44.168 HamNet,
and 44.190 Internet). This involves dual configuration, dual routing,
route exchanges and firewalling at network / gateway level. This can not
be done only at the edge.
Now, if you don't want to be accessible from the
internet BUT want to be accessible to HAM ONLY traffic, that is another story. In that
case, the only way to go is by route. As trying to firewall every thing BUT known HAM ONLY
traffic is a lost of time, and it will change almost daily.
We've been playing that story for a few years now :-) Maybe with a lot
of time lost, I agree :-) For a service that needs to be accessible from
HAMs but not from Internet, you have to put it on the "Intranet" IP
space, and it just works :-) Again, that's not a matter of route, but of
access policy / rule (ie, firewalling).
PS :
As an additional comment, it may be required at some point to mix
routing and firewalling. Nowaday's systems allow to define access rules
and routes based on a lot of parameters (not only source/destination
IP/ports). Some manufacturers call that "policy routing" : there may be
different routes for different kind of traffic based f/ex on a DSCP tag
designating HAM traffic.
What I meant is that the lack of a valid route is not a good way to
block some unwanted traffic. Because what is unwanted by you may be
wanted by me. Routing policy and IP placement must be designed in a WW
strategy, so that it can suit all possible user cases over the world.
Then, what is allowed/forbiden in a specific region may be defined
locally (by firewall rules, not by lack of routes).
73 de TK1BI
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
1234
days inactive
1242
days old
49 comments
18 participants
participants (18)
-
Boudewijn (Bob) Tenty -
Colin Bodor -
Darcy Buskermolen -
dave.g4ugm＠gmail.com -
David McGough -
eric.fort.listmail＠fortconsulting.org -
Jason McCormick -
K7VE - John -
Mario Lorenz -
Marius Petrescu -
Nat Morris -
pete M -
Rob PE1CHL -
Rosy Wolfe -
Steve L -
Steve Stroh -
Tony Langdon -
Toussaint OTTAVI