19 Apr
2018
19 Apr
'18
3:50 p.m.
For some time we have been hosting Echolink proxies and relays on the system that is the
gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for
that.
Such proxies and relays facilitate the use if Echolink by users and repeaters that are
behind NAT
or are otherwise firewalled. About 100 repeaters around the world use our proxies, and
over 600
users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static
address on
internet, but often people have no /24 to spare for such things. AMPRnet provides the
required
address space. (unfortunately with an unintended side-effect, but in general it works
well)
For performance of the Echolink system it would be best when there are more places with a
similar
setup, distributed around the globe.
Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the
original Java
software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and
10 relays.
Of course it makes some network traffic, about 3 GB/day for the relays and similar for the
proxies.
When you have your gateway located in a suitable datacenter and are interested in such a
setup
to facilitate Echolink, please send me an e-mail and I can provide more info.
Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would
solve
the problem there now is with partially connected AMPRnet networks.
(when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet
disappears)
Rob
19 Apr
19 Apr
9:12 p.m.
On 19.04.2018 10:50, Rob Janssen wrote:
when the directory server is on AMPRnet, the problem
with NAT between
HAMNET and internet disappears
I'm afraid, it would raise new issues...
For those who are planning to provide echolink proxy services (or any
other useful internet based amateur radio services) within the AMPRNet
by direct BGP, please ask for an /24-allocation within 44.190.0.0/16.
We will promote to all HAMNET users and sysops to route 44.190.0.0/16 to
their ISP rather than to their radio device on the roof.
Best case would be to host such services on non-44 IP-space at all.
73,
Jann
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX / DB0FOX / DB0ZM / DB0DBA / DB0HZS
20 Apr
20 Apr
2:41 p.m.
New subject: Echolink proxy/relay hosting - 44.190 routing ?
Hi Jann,
Le 19/04/2018 à 16:12, Jann Traschewski a écrit :
For those who are planning to provide echolink proxy
services (or any
other useful internet based amateur radio services) within the AMPRNet
by direct BGP, please ask for an /24-allocation within 44.190.0.0/16.
We will promote to all HAMNET users and sysops to route 44.190.0.0/16 to
their ISP rather than to their radio device on the roof.
Is that what you briefly talked about in your email a few weeks ago ?
Could you explain a little bit how this could work ? You'll probably
announce the 44.190.0.0/16 from some location in Germany, but how could
I host some machines (ie 44.190.199.0/24) in my location without direct
BGP announcement ? How would incoming requests to 44.190.199.1 be
forwarded to my public ISP IP ?
We are in the process of getting a subnet for direct BGP announcement
for Corsica, but we would like to try to be compatible with all the
existing (and future) routing methods.
73 de TK1BI
19 Apr
19 Apr
9:25 p.m.
I actually have some server resources where I was considering hosting a large echolink
proxy service for echolink users however I have run into issues getting fiber providers to
bring the ip’s in for me to use.. So I am not sure what my next step should be considering
returning my ip’s if I can’t seem to follow through.
By the way I have to use Java for minecraft servers so my 12 core 24 thread should easily
handle a bunch of proxy servers.. However if you have some thing that is Linux based and
works well I would be all ears to help out the community using the newer code if willing
to share..
Loren Tedford (KC9ZHV)
Phone Main: 1+ (631) 686 – 8878 Option 1
Fax: 1-618-551-2755
Email: loren(a)lorentedford.com
Email: KC9ZHV(a)KC9ZHV.com
http://www.lorentedford.com
http://www.kc9zhv.com
http://forum.kc9zhv.com
http://hub.kc9zhv.com
http://Ltcraft.net
http://voipham.com
From: Rob Janssen
Sent: Thursday, April 19, 2018 3:52 AM
To: 44net(a)mailman.ampr.org
Subject: [44net] Echolink proxy/relay hosting
For some time we have been hosting Echolink proxies and relays on the system that is the
gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for
that.
Such proxies and relays facilitate the use if Echolink by users and repeaters that are
behind NAT
or are otherwise firewalled. About 100 repeaters around the world use our proxies, and
over 600
users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static
address on
internet, but often people have no /24 to spare for such things. AMPRnet provides the
required
address space. (unfortunately with an unintended side-effect, but in general it works
well)
For performance of the Echolink system it would be best when there are more places with a
similar
setup, distributed around the globe.
Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the
original Java
software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and
10 relays.
Of course it makes some network traffic, about 3 GB/day for the relays and similar for the
proxies.
When you have your gateway located in a suitable datacenter and are interested in such a
setup
to facilitate Echolink, please send me an e-mail and I can provide more info.
Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would
solve
the problem there now is with partially connected AMPRnet networks.
(when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet
disappears)
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
10:25 p.m.
Hi Rob,
I'd be willing to host something on my gear in my Vancouver Datacenter.
Only issue is I only have a single /24 at the moment and it's mostly
used up by our radio network. I agree with Jann's comment that it would
be useful to have these services located within a dedicated allocation
to prevent Ampr-Internet routing complexity.
Chris
On 4/19/2018 1:50 AM, Rob Janssen wrote:
For some time we have been hosting Echolink proxies
and relays on the
system that is the
gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We
use a /24 subnet for that.
Such proxies and relays facilitate the use if Echolink by users and
repeaters that are behind NAT
or are otherwise firewalled. About 100 repeaters around the world use
our proxies, and over 600
users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This
can be a static address on
internet, but often people have no /24 to spare for such things.
AMPRnet provides the required
address space. (unfortunately with an unintended side-effect, but in
general it works well)
For performance of the Echolink system it would be best when there are
more places with a similar
setup, distributed around the globe.
Are there other BGP-routed sites outside Europe where such a service
could be run?
I have written a C program for this, that uses considerably less
resources than the original Java
software. On a 2.67GHz XEON server it causes a load around 0.05 for
our 200 proxies and 10 relays.
Of course it makes some network traffic, about 3 GB/day for the relays
and similar for the proxies.
When you have your gateway located in a suitable datacenter and are
interested in such a setup
to facilitate Echolink, please send me an e-mail and I can provide
more info.
Maybe we could even get the whole echolink.org infra hosted on AMPRnet
space, which would solve
the problem there now is with partially connected AMPRnet networks.
(when the directory server is on AMPRnet, the problem with NAT between
HAMNET and internet disappears)
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
10:48 p.m.
That is what the block 44.190.0.0 is set aside for. The intent is
to divide it up into /24s to be BGP-routed directly to the Internet,
and people who otherwise would send 44.x.x.x traffic via radio or
tunnel should insert a special routing rule that directs 44.190.0.0/16
to their ISP instead of the radio or tunnels, if they can.
- Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
I agree with Jann's comment that it would
be useful to have these services located within a dedicated allocation
to prevent Ampr-Internet routing complexity.
Chris
20 Apr
20 Apr
12:08 a.m.
Thanks for posting this. I didn't know.
Michael
N6MEF
-----Original Message-----
From: 44Net <44net-bounces+n6mef=mefox.org(a)mailman.ampr.org> On Behalf Of
Brian Kantor
Sent: Thursday, April 19, 2018 8:48 AM
To: AMPRNet working group <44net(a)mailman.ampr.org>
Subject: Re: [44net] Echolink proxy/relay hosting
That is what the block 44.190.0.0 is set aside for. The intent is
to divide it up into /24s to be BGP-routed directly to the Internet,
and people who otherwise would send 44.x.x.x traffic via radio or
tunnel should insert a special routing rule that directs 44.190.0.0/16
to their ISP instead of the radio or tunnels, if they can.
- Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin
wrote:
I agree with Jann's comment that it would
be useful to have these services located within a dedicated allocation
to prevent Ampr-Internet routing complexity.
Chris
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
12:22 a.m.
Yes, it's just getting started and so we haven't written it up yet.
It's really only applicable to people who DON'T use the tunnel
system at their end user equipment and DO route all of 44.0.0.0/8
via a low-bandwidth/high-delay link, and who DON'T have some other
arrangement in place. Primarily to accomodate HamNet end-users in
Germany, outside of some regions of Europe, it's just a bunch of
non-region-specific BGP-connected subnets.
- Brian
On Thu, Apr 19, 2018 at 10:08:44AM -0700, Michael Fox - N6MEF wrote:
Thanks for posting this. I didn't know.
Michael
N6MEF
12:28 a.m.
On 4/19/18 11:48 AM, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for.
The intent is
to divide it up into /24s to be BGP-routed directly to the Internet,
and people who otherwise would send 44.x.x.x traffic via radio or
tunnel should insert a special routing rule that directs 44.190.0.0/16
to their ISP instead of the radio or tunnels, if they can.
- Brian
Brian,
I'd suggested this and the TAC team voted on this being a good idea 3 years
ago. No action was taken by anyone on the board to do anything with it at
that time. The TAC team largely gave up attempting to work with ARDC at that
time due to the in action.
What changed? It's a bit concerning that policy and operational changes are
handled in such an obscure and closed manner.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
12:59 a.m.
Essentially, it's time had come. There was a demonstrated need,
and an available block of addresses.
- Brian
On Thu, Apr 19, 2018 at 01:28:52PM -0400, Bryan Fields wrote:
Brian,
I'd suggested this and the TAC team voted on this being a good idea 3 years
ago. No action was taken by anyone on the board to do anything with it at
that time. The TAC team largely gave up attempting to work with ARDC at that
time due to the in action.
What changed? It's a bit concerning that policy and operational changes are
handled in such an obscure and closed manner.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
12:47 a.m.
Hey Brian,
Thanks for the clarification, I was unaware of the purpose of that block.
How would I go about requesting a /23 or /24 from 44.190.0.0/16 to
assist with Rob's project?
Chris
On 4/19/2018 8:48 AM, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for.
The intent is
to divide it up into /24s to be BGP-routed directly to the Internet,
and people who otherwise would send 44.x.x.x traffic via radio or
tunnel should insert a special routing rule that directs 44.190.0.0/16
to their ISP instead of the radio or tunnels, if they can.
- Brian
On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
I agree with Jann's comment that it would
be useful to have these services located within a dedicated allocation
to prevent Ampr-Internet routing complexity.
Chris
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
12:54 a.m.
Just apply for it via the normal Portal method. Jann is the coordinator.
- Brian
On Thu, Apr 19, 2018 at 10:47:34AM -0700, Christopher S. Munz-Michielin wrote:
Hey Brian,
Thanks for the clarification, I was unaware of the purpose of that block.
How would I go about requesting a /23 or /24 from 44.190.0.0/16 to
assist with Rob's project?
Chris
On 4/19/2018 8:48 AM, Brian Kantor wrote:
> That is what the block 44.190.0.0 is set aside for. The intent is
> to divide it up into /24s to be BGP-routed directly to the Internet,
> and people who otherwise would send 44.x.x.x traffic via radio or
> tunnel should insert a special routing rule that directs 44.190.0.0/16
> to their ISP instead of the radio or tunnels, if they can.
> - Brian
>
> On Thu, Apr 19, 2018 at 08:25:31AM -0700, Christopher S. Munz-Michielin wrote:
>> I agree with Jann's comment that it would
>> be useful to have these services located within a dedicated allocation
>> to prevent Ampr-Internet routing complexity.
>> Chris
7:31 a.m.
On Apr 19, 2018, at 10:54, Brian Kantor
<Brian(a)BKantor.net> wrote:
Just apply for it via the normal Portal method. Jann is the coordinator.
I just applied for a /24 out of 44.190/16, to help with this endeavor.
I’ll be announcing the prefix out of a commercial datacenter in Fremont, CA under ASN
7247.
73,
-jav k4jh
21 Apr
21 Apr
6:51 p.m.
On 20/04/18 01:48, Brian Kantor wrote:
That is what the block 44.190.0.0 is set aside for.
The intent is
to divide it up into /24s to be BGP-routed directly to the Internet,
and people who otherwise would send 44.x.x.x traffic via radio or
tunnel should insert a special routing rule that directs 44.190.0.0/16
to their ISP instead of the radio or tunnels, if they can.
The problem I have with
this is when traffic is routed via the regular
ISP, the source address is no longer 44.x, it's the public IP of the NAT
router. I'd like to see BGP announced subnets also directly accessible
via a tunnel for those of us running IPIP tunnels. I'll soon be in a
good position to test, as I now have both a direct BGP connected subnet
and a tunnelled one at different sites. Obviously, I have a vested
interest in getting the routing right for my own purposes.
The way I see it, the 44.190 and other directly connected space still
need a tunnel interface and routing to communicate transparently with
the tunnelled parts of AMPRnet (and avoid the delays of the main
gateway). What I'd like to know is what is the best practice for doing
this, that won't result in traffic that gets addresses mangled by NAT at
one end?
I have a general idea, but as you know, the devil is in the detail. :)
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
8:57 p.m.
On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon <vk3jed(a)vkradio.com> wrote:
The problem I have with this is when traffic is routed via the regular
ISP, the source address is no longer 44.x, it's the public IP of the NAT
router.
Why should I as an Echolink relay operator be expected to go through the
additional effort of configuring IPIP just so you can enjoy the novelty of
both ends of the connection having 44/8 addresses? Your IPIP encapsulated
packet will still have your ISP's address and will take the same path
regardless. I understood that one of the motivations of the 44.190/16
prefix was to allow end users to easily configure their routing policy
correctly to avoid tunneling to UCSD first (which isn't the end of the
world since Javier and I are setting up our relays also in California).
--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
22 Apr
22 Apr
3:29 a.m.
If all you're running are Echolink proxies and relays, sure, I get your
argument, the issue of NAT at the source isn't a big deal and simply
routing 44.190.0.0/16 via the NAT router at each end user is a good
solution, but for those of us who WANT to do something more than merely run
proxies on those addresses, I'd like to be able to get my routing right, so
NAT doesn't bite me in the bum when I attempt to set something else up.
On Sat, Apr 21, 2018 at 11:57 PM, Kenneth Finnegan <
kennethfinnegan2007(a)gmail.com> wrote:
> On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon <vk3jed(a)vkradio.com> wrote:
> >
> > The problem I have with this is when traffic is routed via the regular
> > ISP, the source address is no longer 44.x, it's the public IP of the NAT
> > router.
>
>
> Why should I as an Echolink relay operator be expected to go through the
> additional effort of configuring IPIP just so you can enjoy the novelty of
> both ends of the connection having 44/8 addresses? Your IPIP encapsulated
> packet will still have your ISP's address and will take the same path
> regardless. I understood that one of the motivations of the 44.190/16
> prefix was to allow end users to easily configure their routing policy
> correctly to avoid tunneling to UCSD first (which isn't the end of the
> world since Javier and I are setting up our relays also in California).
>
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
>
4:44 a.m.
Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why
would there be NAT?
On Sat, Apr 21, 2018 at 1:29 PM, Tony Langdon <vk3jed(a)vkradio.com> wrote:
> If all you're running are Echolink proxies and relays, sure, I get your
> argument, the issue of NAT at the source isn't a big deal and simply
> routing 44.190.0.0/16 via the NAT router at each end user is a good
> solution, but for those of us who WANT to do something more than merely run
> proxies on those addresses, I'd like to be able to get my routing right, so
> NAT doesn't bite me in the bum when I attempt to set something else up.
>
> On Sat, Apr 21, 2018 at 11:57 PM, Kenneth Finnegan <
> kennethfinnegan2007(a)gmail.com> wrote:
>
> > On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon <vk3jed(a)vkradio.com>
> wrote:
> > >
> > > The problem I have with this is when traffic is routed via the regular
> > > ISP, the source address is no longer 44.x, it's the public IP of the
> NAT
> > > router.
> >
> >
> > Why should I as an Echolink relay operator be expected to go through the
> > additional effort of configuring IPIP just so you can enjoy the novelty
> of
> > both ends of the connection having 44/8 addresses? Your IPIP encapsulated
> > packet will still have your ISP's address and will take the same path
> > regardless. I understood that one of the motivations of the 44.190/16
> > prefix was to allow end users to easily configure their routing policy
> > correctly to avoid tunneling to UCSD first (which isn't the end of the
> > world since Javier and I are setting up our relays also in California).
> >
> > --
> > Kenneth Finnegan
> > http://blog.thelifeofkenneth.com/
> >
5:39 p.m.
On 22/04/18 07:44, K7VE - John wrote:
Wasn't the idea to 44.190.0.0/16 subnets available
via BGP? If so, why
would there be NAT?
Well, I'm not talking about the 44.190 end, but if I host
some service
on my 44.190 for net 44, then if I am routing 44.190.8.x via my ISP,
there will be NAT on my end. As I said to someone else, if all I'm
doing is hosting Echolink proxies and relays, it's a non issue, but if I
want to use the server for something else, it could be an issue.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
20 Apr
20 Apr
3:41 p.m.
Le 19/04/2018 à 17:25, Christopher S. Munz-Michielin a écrit :
I agree with Jann's comment that it would be
useful to have these
services located within a dedicated allocation to prevent
Ampr-Internet routing complexity.
That's already what most people do. Some time ago, I had a look at the
D-Star hosts file : only 1% of the IPs were using 44.0.0.0 space.
My personal opinion is that amateur radio guys should use amateur radio
IP addresses whenever possible. And amateur radio network operators
should make ise of those IP easier for everybody.
Our approach here in Corsica is to consider our AMPR allocation as we
could consider an enterprise network :
- Some machines are "private" (in the "amateur radio" meaning). These
will be on "LAN".
- Some other machines, such as a WEB server (or D-Star repeater), need
public Internet access. These would be put in a "DMZ"
Then, we'll split our allocation into LANs and DMZs. Access rules will
be managed by firewalls. But IP routing will be direct, with no more NAT
or dual-addressing. That's a first step to what we'll have to do when we
decide to migrate to IPv6, HI :-)
73 de TK1BI
19 Apr
19 Apr
11:50 p.m.
It functions OK that 44 NL subnet.
My server IR0AAB-R at 44.134.32.240 receives every
days several call coming from a 44.137.75.xxx subnet
specially by using their Echolink for Android from
any part of the world :)
73 and ciao, gus i0ojj/ir0aab
On 04/19/2018 10:50 AM, Rob Janssen wrote:
For some time we have been hosting Echolink proxies
and relays on the
system that is the
gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use
a /24 subnet for that.
Such proxies and relays facilitate the use if Echolink by users and
repeaters that are behind NAT
or are otherwise firewalled. About 100 repeaters around the world use
our proxies, and over 600
users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This
can be a static address on
internet, but often people have no /24 to spare for such things. AMPRnet
provides the required
address space. (unfortunately with an unintended side-effect, but in
general it works well)
For performance of the Echolink system it would be best when there are
more places with a similar
setup, distributed around the globe.
Are there other BGP-routed sites outside Europe where such a service
could be run?
I have written a C program for this, that uses considerably less
resources than the original Java
software. On a 2.67GHz XEON server it causes a load around 0.05 for our
200 proxies and 10 relays.
Of course it makes some network traffic, about 3 GB/day for the relays
and similar for the proxies.
When you have your gateway located in a suitable datacenter and are
interested in such a setup
to facilitate Echolink, please send me an e-mail and I can provide more
info.
Maybe we could even get the whole echolink.org infra hosted on AMPRnet
space, which would solve
the problem there now is with partially connected AMPRnet networks.
(when the directory server is on AMPRnet, the problem with NAT between
HAMNET and internet disappears)
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
22 Apr
22 Apr
6:07 a.m.
Rob,
I like to help with this as well. Please let me know the details on how to
setup your C program.
I'm going to request for a /24 from the 44.190/16, and I'll announce it
from Seatle via IONSwitch.
-bn
0216331C
On Thu, Apr 19, 2018 at 1:50 AM, Rob Janssen <pe1chl(a)amsat.org> wrote:
For some time we have been hosting Echolink proxies
and relays on the
system that is the
gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use
a /24 subnet for that.
Such proxies and relays facilitate the use if Echolink by users and
repeaters that are behind NAT
or are otherwise firewalled. About 100 repeaters around the world use our
proxies, and over 600
users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can
be a static address on
internet, but often people have no /24 to spare for such things. AMPRnet
provides the required
address space. (unfortunately with an unintended side-effect, but in
general it works well)
For performance of the Echolink system it would be best when there are
more places with a similar
setup, distributed around the globe.
Are there other BGP-routed sites outside Europe where such a service could
be run?
I have written a C program for this, that uses considerably less resources
than the original Java
software. On a 2.67GHz XEON server it causes a load around 0.05 for our
200 proxies and 10 relays.
Of course it makes some network traffic, about 3 GB/day for the relays and
similar for the proxies.
When you have your gateway located in a suitable datacenter and are
interested in such a setup
to facilitate Echolink, please send me an e-mail and I can provide more
info.
Maybe we could even get the whole echolink.org infra hosted on AMPRnet
space, which would solve
the problem there now is with partially connected AMPRnet networks.
(when the directory server is on AMPRnet, the problem with NAT between
HAMNET and internet disappears)
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2437
days inactive
2440
days old
20 comments
14 participants
participants (14)
-
Bao Nguyen -
Brian Kantor -
Bryan Fields -
Christopher S. Munz-Michielin -
Gustavo Ponza -
Jann Traschewski -
Javier Henderson -
K7VE - John -
Kenneth Finnegan -
Loren Tedford -
Michael Fox - N6MEF -
Rob Janssen -
Tony Langdon -
Toussaint OTTAVI