Hello Everyone,
It was very sad news hear to about Brian Kantor passing as he was my
AMPR Coordinator mentor and I imagine *the* mentor for many of us. As
we need to push on with out him, it's unclear on what is the chain of
succession for everything that Brian did. I ask this as I have a new
interested member looking for a BGP allocation and this process was
always processed through Brian to deal with the vetting process,
processing the AMPR Letter of Authority, etc. Can someone from the ARDC,
etc. tell me who to contact if I have questions, next steps once I get
all the required details, etc?
--David
KI6ZHD
Silicon Valley 44.4.x.x/16 AMPR Coordinator
Hello everyone. I've had a two address allocation for a while and I'm
just now getting things setup.
Just wondering if anyone has some info on (our point me to a wiki page)
on getting one of my IP's setup on my home network using TELUS internet
(Canada)? I would like to say I'm not new to networking but for some
reason I'm not at my best.
My plan is to try and setup some rudimentary networking using a simplex
frequency between my remote location and my home base. For now I'm
going to use 9600 baud UHF just to get things working. I know this will
be incredibly slow but I want to try anyway. I may move up to the GHz
range later. Biggest thing is I would like to get internet access using
the 44 net for field day. This will be in hopes of setting up for
emergency situations.
Currently I'm just working on this by myself and would like to get a
proof of concept going before I demonstrate this to anyone else.
Thanks for your help
Stephen Atkins
VE6CIC
On Wed, Nov 27, 2019 at 11:26 AM kd6oat <kd6oat(a)gmail.com> wrote:
> I was saddened by the news of Brian's passing.
> While I did not have the pleasure of ever meeting him in person, I was -
> as with so many on this list - periodically in contact with him by email.
> My first exchanges were during my days in Los Angeles in the early 1990's
> with a 44.16 ip assignment and where he and other provided valuable
> mentoring and helped make the learning curve exciting and enjoyable.
> Over the years - and until very recently - the one-to-one contact has
> remained primarily because of his easy access and willingness to provide
> helpful information at a moments notice.
> He was an anchor for me in this particular area of the amateur radio hobby
> and he will be missed.
> Ken Adlam - KD6OAT
> Utah ampr.org coordinator
>
>>
>>
I have very sad news. My good friend, Brian Kantor, WB6CYT
<https://photos.smugmug.com/photos/i-qRxpLrc/1/X4/i-qRxpLrc-X4.jpg>,
suddenly passed away this week at his home in San Diego, California.
Brian retired only two years ago after 47 years of service on the staff
at the University of California San Diego (UCSD). Way back in the mid
1980s, Brian and I founded AMPRnet, the TCP/IP over amateur radio
network. He continued to manage it until his passing.
Brian recently created and served as chair and CEO of Amateur Radio
Digital Communications (ARDC), a charitable foundation funded by the
sale of unused AMPRnet IPv4 addresses. ARDC promotes STEM education and
amateur radio digital development through scholarships and by funding
the development of open source hardware and software.
Brian will be sorely missed and impossible to replace. Memorial
arrangements will be announced when known.
Phil Karn, KA9Q
Really Sad News
Rest in peace my friend and thank you for all
the help and assistance in supporting amprnet
over the past three decades.
I send my condolences to his family.
Paul g4apl
It is with great sorrow that we learn of Brian's passing. For dozens
of years he has worked in support of Amateur Radio and gone far
beyond what could be expected of an individual to make Amateur Radio
digital operations a success. In the early years he almost
single-handedly insured that the interface with the educational and
commercial worlds were properly managed.
As Phil stated, it will be impossible for us to replace the talent
and knowledge he has provided. This event presents another
opportunity for us to learn how to work together for success in the
future. It is critical that those of us still around, including
those of us from the Southern California Digital Coordination Council
days, endeavor to pass on all that has been learned. There are less
and less of those Don listed still with us.
I for one think that ARDC can play an important role in ensuring our
continued success.
Thank You Brian,
- JimF K6IYK
At 11/22/2019 05:19 PM, Donald Jacob via 44Net wrote:
>Phil, et al,
>Very sad news. I first met Brian (and you) at the SCDCC (Southern
>California Digital Coordinating Council)
>in the early 80's. Had great get togethers at NK6K, Harold's house after
>TRW swapmeets, along with Wally, WA6JPR
>Mike Brock, Skip WB6YMH and many others back in the beginning days of
>digital in amateur radio. As AMPR coordinator for
>Los Angeles I did email Brian periodically, but not nearly enough. We have
>lost a true friend of amateur radio and
>AMPR.
>Please pass along any information if there will be any service.
>
>RIP Brian, thanks for your guidance, knowledge and talent. You will be
>missed.
>
>73
>Don Jacob
>WB5EKU
>
>On Fri, Nov 22, 2019 at 3:37 PM vk2tv via 44Net <44net(a)mailman.ampr.org>
>wrote:
>
> > Thanks Phil,
> >
> > I offer my condolences to all who new Brian.
> >
> > Ray vk2tv
> >
> > On 23/11/19 10:27 am, Phil Karn via 44Net wrote:
> > > I have very sad news. My good friend, Brian Kantor, WB6CYT
> > > <https://photos.smugmug.com/photos/i-qRxpLrc/1/X4/i-qRxpLrc-X4.jpg>,
> > > suddenly passed away this week at his home in San Diego, California.
> > > Brian retired only two years ago after 47 years of service on the staff
> > > at the University of California San Diego (UCSD). Way back in the mid
> > > 1980s, Brian and I founded AMPRnet, the TCP/IP over amateur radio
> > > network. He continued to manage it until his passing.
> > >
> > > Brian recently created and served as chair and CEO of Amateur Radio
> > > Digital Communications (ARDC), a charitable foundation funded by the
> > > sale of unused AMPRnet IPv4 addresses. ARDC promotes STEM education and
> > > amateur radio digital development through scholarships and by funding
> > > the development of open source hardware and software.
> > >
> > > Brian will be sorely missed and impossible to replace. Memorial
> > > arrangements will be announced when known.
> > >
> > > Phil Karn, KA9Q
> > >
> > >
--------------------------------------------------------------------------
James T. Fortney, K6IYK / AAA9R6
E-mail: K6IYK(a)K6IYK.net
or K6IYK(a)K6IYK.radio
or K6IYK(a)220sma.org
or AAA9R6(a)usamars.us
or Jim(a)Fortney.org
Voice: 805.491.3916
Cell: 805.208.3108
Snail: P.O. Box 12589
Prescott,, AZ 86304-2589
Assistant Director, ARRL Southwestern Division
<http://ARRLSWD.org>
IT Services Officer, US Army MARS - Region 9
<<http://usamars.us/>http://USAMARS.us>
President, Valley Emergency Radio Association
<http://VERA.k6iyk.net>
Treasurer & Information Services Officer, 220SMA
<http://220SMA.org>
Member: AMSAT, ARES, Army MARS, ARRL, CACTUS, DCS,
NCS-SHARES, OMARS, SARBA, RACES, TAPR,
YARC, 220SMA
"It is not the class of license the Amateur holds, but the class
of the Amateur that holds the license."
--------------------------------------------------------------------------
Hi OM
I'm hoping to pick someone's brain with regards to the IPIP and RIP config
for AMPRnet on my Mikrotik at home.
I'm using the guide http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt,
which indicates after step seven and a few minutes of waiting I should see
my routing table populated with routes with a 44rip routing mark. Nope.
I've monitored for port 520 on the IPIP as well as Internet facing
interface and see no activity. I also haven't seen a single packet on the
ucsd-gw interface (not sure if I should at this time). So I'm obviously
missing something important and perhaps fundamental in this configuration.
Please send some of your wisdom my way.
Regards
Paul (ZS6IO)
--
Paul Greeff
email(a)paulgreeff.com
Office: +27 86 100 3117
Cell: +27 83 954 3453
Fax:
086 659 0511
Winlink:
zs6io(a)winlink.org
That guide worked for establishing the tunnel, but I don't seem to get
working RIP packets.
The IP address for my local port is 44.x.y.1/32 with a network of 44.x.y.0
(/24). But the IP address on the tunnel interface is 44.x.y.2/32 with a
network of 44.0.0.0 (/8). Somehow this works and the tunnel connects.
Every five minutes I see some packets come in and a packet capture shows
the clear text password in them. But the RIP listener isn't seeing them. I
even set the RIP to listen for any advertisement (not just 44.0.0.0) on any
interface.
tg.
AJ4UQ.
On Fri, Nov 15, 2019 at 2:28 PM Paul Greeff via 44Net <
44net(a)mailman.ampr.org> wrote:
> Hi OM
>
> I'm hoping to pick someone's brain with regards to the IPIP and RIP config
> for AMPRnet on my Mikrotik at home.
>
> I'm using the guide http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt,
> which indicates after step seven and a few minutes of waiting I should see
> my routing table populated with routes with a 44rip routing mark. Nope.
>
> I've monitored for port 520 on the IPIP as well as Internet facing
> interface and see no activity. I also haven't seen a single packet on the
> ucsd-gw interface (not sure if I should at this time). So I'm obviously
> missing something important and perhaps fundamental in this configuration.
>
> Please send some of your wisdom my way.
>
> Regards
> Paul (ZS6IO)
> --
> Paul Greeff
> email(a)paulgreeff.com
> Office: +27 86 100 3117
> Cell: +27 83 954 3453
> Fax:
> 086 659 0511
> Winlink:
> zs6io(a)winlink.org
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
Good day OM
I am trying to locate the new coordinator for South Africa. With the
unfortunate passing of Dick ZS6RO no one is dishing out network allocations
for South Africans.
Regards
Paul (ZS6IO)
--
Paul Greeff
email(a)paulgreeff.com
Office: +27 86 100 3117
Cell: +27 83 954 3453
Fax:
086 659 0511
Winlink:
zs6io(a)winlink.org
Greetings OM's.
I operate a URONode and FBB BBS in Toronto, Canada (FN03GQ).
Recently, my connection partner (VE2PKT) has gone offline due to
technical problems.
Is there anyone on this continent (Canada or USA) that would be willing
to become a partner with me?
I need access using any of: UDP port 92, 93, 10092, 10093 or 10094.
I am not on the 44 net currently.
Thanks and 73,
Matt / VE3OY
--
/My mind is like a web browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?/
Greetings,
I received a "Contact Coordinator" message from the portal. How
exactly are we supposed to reply to these? There is no "Messages" menu
item in the coordinators menu. Am I supposed to reply directly to the
other party or what?
--
Geoff Joy - ke6qh -
AmprNet IP Address Coordinator for San Bernardino & Riverside Counties.
(44.18/16)
Hello,
There are lots of news about my project "New Packet Radio".
Reminder, all info is here: https://hackaday.io/project/164092
A Chinese partner is now selling modems, assembled or kits, world-wide.
Price is low : 80$ fully assembled, with aluminum enclosure.
https://www.elekitsorparts.com/product/npr-70
I have improved the firmware, it's more stable, and it now allows the
optional "FDD mode" (Frequency Division Duplex).
With this optional feature, you can use the Master (=repeater) in duplex
mode, with 2 modems (TX/RX) and a RF duplexer. The frequencies are
different between uplink (from Clients to Master) and downlink (from
Master to Clients). Clients are half duplex, with one single modem,
switching very fast (300us) between uplink and downlink frequencies. The
main goal is to put NPR master on tower where there is already a duplex
repeater (FM or DMR or D-Star...), without interference between the 2
repeaters.
Check all the documentation on hackaday for more details: mainly
"Introduction", and "Advanced user guide".
The new firmware is also on hackaday of course.
Finally, I have written an article for "IEEE spectrum"; It's currently
on the web, and it will be on the paper version in a few days. I hope it
will bring some advertisement to my project, and to the modern amateur
radio movement.
https://spectrum.ieee.org/geek-life/hands-on/build-a-longdistance-data-netw…
If you have any question, just ask me.
73,
Guillaume F4HDK
Hello,
My knowledge and experience is lower than the participants on this mailling list.
I don't understand most of the topics discussed .
Examples :
- What's the connection between Amprgw, Caida and USCD/NT?
- Where can I find information about the structure of Amprgw ?
Do you know a "Hamnet ML for newbies" ? :-)
Frédéric
F1sxo
I am the Utah coordinator and appreciate Brian's comment that this matter
should not be dealt with in this forum.
Thank you.
Ken - KD6OAT
On Mon, Oct 21, 2019 at 1:00 PM <44net-request(a)mailman.ampr.org> wrote:
> Send 44Net mailing list submissions to
> 44net(a)mailman.ampr.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.ampr.org/mailman/listinfo/44net
> or, via email, send a message with subject or body 'help' to
> 44net-request(a)mailman.ampr.org
>
> You can reach the person managing the list at
> 44net-owner(a)mailman.ampr.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 44Net digest..."
>
>
> Today's Topics:
>
> 1. Re: Mikrotik hAP ac lite gateway configuration (Keith Kasin)
> 2. Registration request from Alekzandr Evans (KI7HOC) (Ruben ON3RVH)
> 3. Re: Registration request from Alekzandr Evans (KI7HOC)
> (Paul Sladen)
> 4. Re: Registration request from Alekzandr Evans (KI7HOC)
> (Brian Kantor)
> 5. Re: Registration request from Alekzandr Evans (KI7HOC)
> (Bryan Fields)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 20 Oct 2019 15:11:56 -0700
> From: Keith Kasin <ai6bx.keith(a)verizon.net>
> To: "ai6bx.keith" <ai6bx.keith(a)verizon.net>, <44net(a)mailman.ampr.org>
> Subject: Re: [44net] Mikrotik hAP ac lite gateway configuration
> Message-ID: <35EECA40-B9B8-4563-8D8A-FD7786A9A292(a)verizon.net>
> Content-Type: text/plain; charset="UTF-8"
>
>
>
> Greetings all. I am trying to set up a gateway on the MikroTik hAP lite
> following the posted instructions at
> http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers. A few
> questions as I do not seem to be having success. At the end, prior to
> installing scripts, I do have access to the broader Internet however still
> have a 192.168.88.x address issued to my PC.
>
>
>
> Question on step 1: At first assign 44 Net address to your router
> Interface You do it by the web : IP --> Addresses --> Add New , a new
> screen will open , fill your 44 Net IP 44.xxx.YYY.ZZZ/your sub net (usually
> it will be /24) feel the network it should usually be same as the IP but
> with 0 in the end
>
> In the first I am using my 44 IP of 44.18.50.1/28 and then using the
> 44.18.50.0 in the network slot. Is that correct? I then assigned this to
> one of the LAN ports on the MikroTik which looks correct for the LAN IP
> info as it does change this from the 192.168.88.x sequence. The checkbox
> below that still shows as NAT, should this change to DHCP?
>
>
>
> Now some routes commands needed to be done
>
> 1) Route all the traffic to the tunnel interface
>
> You do it by : IP --> Routes and clicking on the 0.0.0.0 line and changing
> the gateway to the tunnel interface name and clicking apply
>
> The command line in text is as follow
>
> If I use the /ip route
> add distance=1 gateway=UCSD
>
> It creates a new entry showing UCSD however it does not connect. Am I
> doing something wrong in this whole process?
>
>
>
> After creating the tunnel the following instruction does not yield an
> editable gateway box as it would lead me to think it would so I cannot
> select the UCSD gateway. I did also load the scripts linked at the bottom
> of the page with edited IP addresses relevant to my networks and so not see
> the routes table updating.
>
>
>
> Any assistance would be appreciated.
>
>
>
> Thank you,
>
>
>
> Keith ? AI6BX
>
>
>
>
>
>
>
>
>
> Sent from my iPad
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Oct 2019 11:18:07 +0000
> From: Ruben ON3RVH <on3rvh(a)on3rvh.be>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: [44net] Registration request from Alekzandr Evans (KI7HOC)
> Message-ID:
> <
> AM6PR01MB41829D7D296205CCC15C2F76D3690(a)AM6PR01MB4182.eurprd01.prod.exchangelabs.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> Just wanted to get some background info on this one. We got a subnet
> request from, who appeared to be KI7HOC located in Utah.
> He requested a /24 and wanted to route that through BGP by AS208173
> (--
> organisation: ORG-TYRA2-RIPE
> org-name: Jori Vanneste
> descr: Tyrasuki
> --)
>
> The ASN owner is located in Belgium and seems a bit shady to me looking
> through the subnets he's announcing (one IPv4 /24 from Africa and a few
> IPv6 subnets from APNIC, RIPE) and maintainers on the ASN (Singapore,
> Sweden, Switserland, ..)
> The email domain used, uses a whois hiding service and does not match
> Alekzandr's email address on QRZ. Emailing Alekzandr on his QRZ email
> address does not yield a respons, however returning the allocation request
> to the requestor almost immediatly prompts a return through the AMPR portal
> form.
>
> The details in the request:
> --
> Name: Alekzandr Evans
> Email: ampr(a)alekeagle.com<mailto:ampr@alekeagle.com>
> Callsign: KI7HOC
> --
> Note in the original request: "AE: The operator of the AS number posted
> above lives in Belgium. Though I'm not sure if this would justify a Belgian
> allocation, he recommended me to request a Belgian one."
> --
>
> My question would be if anybody on the list knows Alekzandr and can speak
> to him if this request is legit or not.
> >From his QRZ page, Alekzandr is 12, nothing wrong with that, but the way
> that the email domain is using a whois hiding service makes me ponder if
> this might be a scam from someone posing as Alekzandr trying to get a BGP
> routed /24 for free.
>
> Has anyone else received a request from this callsign?
>
> Any input would be appreciated. We ended up denying the request as neither
> Alekzandr, nor that Jori are a holder of a valid ON ham license and
> Alekzandr did not respond to the question which ham services he would be
> hosting on this subnet (I asked that question because of my suspicions) and
> I haven't received any answer to my direct email to Alekzandr's qrz email
> address neither.
>
> 73,
>
> Ruben - ON3RVH
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 21 Oct 2019 13:01:11 +0100 (BST)
> From: Paul Sladen <44net(a)paul.sladen.org>
> To: Ruben ON3RVH via 44Net <44net(a)mailman.ampr.org>
> Subject: Re: [44net] Registration request from Alekzandr Evans
> (KI7HOC)
> Message-ID:
> <Pine.LNX.4.21.1910211237390.28516-100000(a)starsky.19inch.net>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Mon, 21 Oct 2019, Ruben ON3RVH via 44Net wrote:
> > subnet request from, ... KI7HOC located in Utah. ...
> > a /24 ... BGP by AS208173 ... located in Belgium
>
> https://as208173.net/
> https://as139347.net/ "Educational ASN for learning BGP."
>
> https://apps.db.ripe.net/db-web-ui/#/lookup?source=RIPE&type=as-set&key=as-…
>
> The descriptions appear to be an experimental/educational network for
> *learning BGP*. Very much in-tune with the AMPRNet stated goals.
>
> The request appears to be coming from a licensed HAM, with details all
> technically correct and present.
>
> > domain used, uses a whois hiding service
>
> Most domain registrations now use some (automatic) hiding/obfuscation
> of contact email addresses. Including (for example) for 'on3rvh.be'.
>
> > does not match Alekzandr's email address on QRZ. ...
> > Email: ampr(a)alekeagle.com
>
> The 'ampr@' prefix shows a customisation for AMPRnet purposes. (cf.
> '44net@' prefix in this email address, but 'qrz(a)p.s.o' on QRZ).
> Such prefixes allow easy tracking of when email addresses have leaked.
>
> > in the original request: "AE: The operator of the AS number posted
> > above lives in Belgium. Though I'm not sure if this would justify
> > a Belgian allocation, he recommended me to request a Belgian one."
> > ...
> > We ended up denying the request as neither Alekzandr,
>
> Alekzandr has clearly stated the rationale for applying for a Belgium
> assignment.
>
> Ideally the maintainers responsible for ONxxx and Kxxxx would,
> firstly, work together to discuss the jurisdiction where the
> assignment/application might most appropriately made.
>
> Would this be a good next-stop to take, in conjuction with Alekzandr?
>
> (Perhaps along with a humble apology to Alekzandr).
>
> 73,
> -Paul
> --
> Encourage those with an active interest!
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 21 Oct 2019 05:33:27 -0700
> From: Brian Kantor <Brian(a)bkantor.net>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: Re: [44net] Registration request from Alekzandr Evans
> (KI7HOC)
> Message-ID: <20191021123327.GB14358(a)meow.BKantor.net>
> Content-Type: text/plain; charset=us-ascii
>
> I am dealing with this off-list. I don't think the 44net technical
> discussion list is the appropriate forum for this matter.
>
> Let's not discuss it further here.
> - Brian
>
>
> On Mon, Oct 21, 2019 at 01:01:11PM +0100, Paul Sladen via 44Net wrote:
> > On Mon, 21 Oct 2019, Ruben ON3RVH via 44Net wrote:
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 21 Oct 2019 08:35:58 -0400
> From: Bryan Fields <Bryan(a)bryanfields.net>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: Re: [44net] Registration request from Alekzandr Evans
> (KI7HOC)
> Message-ID: <4223801d-d49c-808f-b7a5-33bc1f78a03a(a)bryanfields.net>
> Content-Type: text/plain; charset=utf-8
>
> On 10/21/19 8:01 AM, Paul Sladen via 44Net wrote:
> > https://as208173.net/
> > https://as139347.net/ "Educational ASN for learning BGP."
> >
> https://apps.db.ripe.net/db-web-ui/#/lookup?source=RIPE&type=as-set&key=as-…
> >
> > The descriptions appear to be an experimental/educational network for
> > *learning BGP*. Very much in-tune with the AMPRNet stated goals.
> >
> > The request appears to be coming from a licensed HAM, with details all
> > technically correct and present.
>
> I've borrowed an ASN from others before, we're doing that for much of IP
> space
> we have live here in Florida. It's valid so long as you have an LOA for
> it.
>
> I've found many people who request IPs may not be ready to announce them,
> and
> have no idea of the typical requirements. Much like "paper repeaters",
> they
> want to reserve "their" space, but are not ready to use it.
>
> I'd have asked who the upstream would be, and get an LOA from the AS
> holder.
> The whole regional administrator thing breaks a bit with sharing ASN's like
> this, IMO it should be an application to Utah. That way he's got a local
> person in his time zone to talk to. It could be 100% legit, best thing to
> do
> is get the docs and grant it. Get on the phone and verifying helps too.
>
> If it's not legit, we'll know in a week when the spam reports roll in :)
>
> A 12 year old running BGP is cool. I thought I was hot shit when I
> migrated
> to qmail at his age.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
>
> ------------------------------
>
> End of 44Net Digest, Vol 8, Issue 168
> *************************************
>
Hi all,
Just wanted to get some background info on this one. We got a subnet request from, who appeared to be KI7HOC located in Utah.
He requested a /24 and wanted to route that through BGP by AS208173
(--
organisation: ORG-TYRA2-RIPE
org-name: Jori Vanneste
descr: Tyrasuki
--)
The ASN owner is located in Belgium and seems a bit shady to me looking through the subnets he's announcing (one IPv4 /24 from Africa and a few IPv6 subnets from APNIC, RIPE) and maintainers on the ASN (Singapore, Sweden, Switserland, ..)
The email domain used, uses a whois hiding service and does not match Alekzandr's email address on QRZ. Emailing Alekzandr on his QRZ email address does not yield a respons, however returning the allocation request to the requestor almost immediatly prompts a return through the AMPR portal form.
The details in the request:
--
Name: Alekzandr Evans
Email: ampr(a)alekeagle.com<mailto:ampr@alekeagle.com>
Callsign: KI7HOC
--
Note in the original request: "AE: The operator of the AS number posted above lives in Belgium. Though I'm not sure if this would justify a Belgian allocation, he recommended me to request a Belgian one."
--
My question would be if anybody on the list knows Alekzandr and can speak to him if this request is legit or not.
>From his QRZ page, Alekzandr is 12, nothing wrong with that, but the way that the email domain is using a whois hiding service makes me ponder if this might be a scam from someone posing as Alekzandr trying to get a BGP routed /24 for free.
Has anyone else received a request from this callsign?
Any input would be appreciated. We ended up denying the request as neither Alekzandr, nor that Jori are a holder of a valid ON ham license and Alekzandr did not respond to the question which ham services he would be hosting on this subnet (I asked that question because of my suspicions) and I haven't received any answer to my direct email to Alekzandr's qrz email address neither.
73,
Ruben - ON3RVH
Greetings all. I am trying to set up a gateway on the MikroTik hAP lite following the posted instructions at http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers. A few questions as I do not seem to be having success. At the end, prior to installing scripts, I do have access to the broader Internet however still have a 192.168.88.x address issued to my PC.
Question on step 1: At first assign 44 Net address to your router Interface You do it by the web : IP --> Addresses --> Add New , a new screen will open , fill your 44 Net IP 44.xxx.YYY.ZZZ/your sub net (usually it will be /24) feel the network it should usually be same as the IP but with 0 in the end
In the first I am using my 44 IP of 44.18.50.1/28 and then using the 44.18.50.0 in the network slot. Is that correct? I then assigned this to one of the LAN ports on the MikroTik which looks correct for the LAN IP info as it does change this from the 192.168.88.x sequence. The checkbox below that still shows as NAT, should this change to DHCP?
Now some routes commands needed to be done
1) Route all the traffic to the tunnel interface
You do it by : IP --> Routes and clicking on the 0.0.0.0 line and changing the gateway to the tunnel interface name and clicking apply
The command line in text is as follow
If I use the /ip route
add distance=1 gateway=UCSD
It creates a new entry showing UCSD however it does not connect. Am I doing something wrong in this whole process?
After creating the tunnel the following instruction does not yield an editable gateway box as it would lead me to think it would so I cannot select the UCSD gateway. I did also load the scripts linked at the bottom of the page with edited IP addresses relevant to my networks and so not see the routes table updating.
Any assistance would be appreciated.
Thank you,
Keith – AI6BX
Sent from my iPad
This morning, during routine maintenance, AMPRGW failed to
reboot. We're looking into the failure now. No estimate
on when it'll be back just yet.
- Brian
Network Working Group V. Cerf
Request for Comments: 2468 MCI
Category: Informational October 1998
I REMEMBER IANA
October 17, 1998
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Remembrance
A long time ago, in a network, far far away, a great adventure took
place!
Out of the chaos of new ideas for communication, the experiments, the
tentative designs, and crucible of testing, there emerged a
cornucopia of networks. Beginning with the ARPANET, an endless
stream of networks evolved, and ultimately were interlinked to become
the Internet. Someone had to keep track of all the protocols, the
identifiers, networks and addresses and ultimately the names of all
the things in the networked universe. And someone had to keep track
of all the information that erupted with volcanic force from the
intensity of the debates and discussions and endless invention that
has continued unabated for 30 years. That someone was Jonathan B.
Postel, our Internet Assigned Numbers Authority, friend, engineer,
confidant, leader, icon, and now, first of the giants to depart from
our midst.
Jon, our beloved IANA, is gone. Even as I write these words I cannot
quite grasp this stark fact. We had almost lost him once before in
1991. Surely we knew he was at risk as are we all. But he had been
our rock, the foundation on which our every web search and email was
built, always there to mediate the random dispute, to remind us when
our documentation did not do justice to its subject, to make
difficult decisions with apparent ease, and to consult when careful
consideration was needed. We will survive our loss and we will
remember. He has left a monumental legacy for all Internauts to
Cerf Informational [Page 1]
RFC 2468 I REMEMBER IANA October 1998
contemplate. Steadfast service for decades, moving when others
seemed paralyzed, always finding the right course in a complex
minefield of technical and sometimes political obstacles.
Jon and I went to the same high school, Van Nuys High, in the San
Fernando Valley north of Los Angeles. But we were in different
classes and I really didn't know him then. Our real meeting came at
UCLA when we became a part of a group of graduate students working
for Professor Leonard Kleinrock on the ARPANET project. Steve
Crocker was another of the Van Nuys crowd who was part of the team
and led the development of the first host-host protocols for the
ARPANET. When Steve invented the idea of the Request for Comments
series, Jon became the instant editor. When we needed to keep track
of all the hosts and protocol identifiers, Jon volunteered to be the
Numbers Czar and later the IANA once the Internet was in place.
Jon was a founding member of the Internet Architecture Board and
served continuously from its founding to the present. He was the
FIRST individual member of the Internet Society I know, because he
and Steve Wolff raced to see who could fill out the application forms
and make payment first and Jon won. He served as a trustee of the
Internet Society. He was the custodian of the .US domain, a founder
of the Los Nettos Internet service, and, by the way, managed the
networking research division of USC Information Sciences Institute.
Jon loved the outdoors. I know he used to enjoy backpacking in the
high Sierras around Yosemite. Bearded and sandaled, Jon was our
resident hippie-patriarch at UCLA. He was a private person but fully
capable of engaging photon torpedoes and going to battle stations in
a good engineering argument. And he could be stubborn beyond all
expectation. He could have outwaited the Sphinx in a staring
contest, I think.
Jon inspired loyalty and steadfast devotion among his friends and his
colleagues. For me, he personified the words "selfless service".
For nearly 30 years, Jon has served us all, taken little in return,
indeed sometimes receiving abuse when he should have received our
deepest appreciation. It was particularly gratifying at the last
Internet Society meeting in Geneva to see Jon receive the Silver
Medal of the International Telecommunications Union. It is an award
generally reserved for Heads of State, but I can think of no one more
deserving of global recognition for his contributions.
While it seems almost impossible to avoid feeling an enormous sense
of loss, as if a yawning gap in our networked universe had opened up
and swallowed our friend, I must tell you that I am comforted as I
contemplate what Jon has wrought. He leaves a legacy of edited
documents that tell our collective Internet story, including not only
Cerf Informational [Page 2]
RFC 2468 I REMEMBER IANA October 1998
the technical but also the poetic and whimsical as well. He
completed the incorporation of a successor to his service as IANA and
leaves a lasting legacy of service to the community in that role.
His memory is rich and vibrant and will not fade from our collective
consciousness. "What would Jon have done?", we will think, as we
wrestle in the days ahead with the problems Jon kept so well tamed
for so many years.
There will almost surely be many memorials to Jon's monumental
service to the Internet Community. As current chairman of the
Internet Society, I pledge to establish an award in Jon's name to
recognize long-standing service to the community, the Jonathan B.
Postel Service Award, which will be awarded to Jon posthumously as
its first recipient.
If Jon were here, I am sure he would urge us not to mourn his passing
but to celebrate his life and his contributions. He would remind us
that there is still much work to be done and that we now have the
responsibility and the opportunity to do our part. I doubt that
anyone could possibly duplicate his record, but it stands as a
measure of one man's astonishing contribution to a community he knew
and loved.
Security Considerations
Security issues are not relevant to this Remembrance.
Author's Address
Vinton G. Cerf
MCI
EMail: vcerf(a)mci.net
Cerf Informational [Page 3]
RFC 2468 I REMEMBER IANA October 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cerf Informational [Page 4]
Hi everyone
Is there anyone here that know or did DYNDNS client for Cisco routers ?
I know that a command can be set at the rouuter to do it
I need to take the IP address that the router get from my ISP (the Commercial IP which is a dynamic IP ) and send it to the ddns system (in my case it is no-ip.com)
the router have to connect via HTTP to the no-ip web (there is a web address that reply the ip that it see that cobnnect to it ) and then update the no-ip (again via http protocol)
I know it can be done
i didnt succeded
have anyone did it or willing to help me to accomplish it?
Thanks Forward
Ronen - 4Z4ZQ
http://www.ronen.org
All,
Checking the portal, there are no call sign details for this endpoint/subnet pair. I ask that the Canadian operator at the route below - properly configure their clients to use 44net IPs to query the DNS server at 44.60.44.3.
Thanks and 73,
- Lynwood
KB3VWG
--------------------
44.135.179.16/29 via 184.65.186.101 dev tunl0 proto 44 onlink window 840 44.135.179.24/29 via 184.65.186.101 dev tunl0 proto 44 onlink window 840
2019-09-27 11:14:36.019 0.004 UDP 184.65.186.101:50202 -> 44.60.44.3:53 6 438 1
2019-09-27 11:14:36.169 0.012 UDP 184.65.186.101:15513 -> 44.60.44.3:53 27 1971... 1
Hi all,
We are migrating our TKNet network to AMPRNet addressing. For machines
directly connected to Internet (ie : XLX, DMR), we are using
44.190.11.0/24 range. Those addresses are geo-located in Chicago. This
has funny consequences. F/ex, when doing speed tests with online
services such as nperf.com, the automatically-selected "nearest" server
is very far from here :-)
I have absolutely no idea about how geolocation works. Just for
curiosity, where is this information taken from ? The Whois database ?
But Brian's address is in San Diego, not in Chicago...
Is there an easy way to change geo-location information for a specific
AMPR subnet ?
Thank you in advance. 73 de TK1BI
Hi Brian,
Thanks for answer. It's strange because of this host has IP registered in AMPR DNS. I suppose it is a routing trouble: ICMP packet cannot find a way back to tunnel (because of I can ping Raspberry PI connected to this interface).
It's not a big problem but I would like to know why id doesn't work.
Regards,
Tomek
--- 2019-09-25 15:31:00 +0200 CEST 44net-bounces+hf8n=winlink.org(a)mailman.ampr.org wrote: ---
>On Wed, Sep 25, 2019 at 02:23:06PM +0100, Alistair Mackenzie via 44Net wrote:
>> Are you running rip to tell the amprgw of your prefix?
>
>Amprgw doesn't listen for RIP. All its routing information comes
>from the encap file published by the portal, which contains the route
>44.165.1.48/28 via 91.199.89.253
>
>However, only the addresses 44.165.1.49 and 44.165.1.50 are entered
>in the DNS, so only they will be pingable from outside 44net. Any
>other address on that subnet will not due to /32-level filtering on
>amprgw. If it is desired to be able to ping 44.165.1.48, for example,
>there must be an entry in the DNS for it to enable the ingress filter.
> - Brian
>
>_________________________________________
>44Net mailing list
>44Net(a)mailman.ampr.org
>https://mailman.ampr.org/mailman/listinfo/44net
Hi,
I joined to ampr network recently, set up IPIP tunnel on Cisco router and directly connected Raspberry Pi 3 (44.165.1.50/28) to one of its interfaces (44.165.1.49). It works great, I can ping and connect to and from this Pi device from outside.
The problem is that I cannot ping this Cisco's 44.165.1.49/28 interface from outside. It should work as 44 packet leaves a tunnel, finds this internal interface and should get back to tunnel. I have PBR route who directs all packets from this interface directly to tunell.
Each host has a valid 44 DNS address.
Interfaces:
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 91.199.89.253 YES NVRAM up up
FastEthernet2/0 44.165.1.49 YES manual up up
Tunnel0 unassigned YES unset up up
Routing table:
44.0.0.0/8 is variably subnetted, 244 subnets, 12 masks
C 44.165.1.48/28 is directly connected, FastEthernet2/0
L 44.165.1.49/32 is directly connected, FastEthernet2/0
Config:
interface Tunnel0
no ip address
tunnel source GigabitEthernet0/0
tunnel mode ipip
tunnel destination 169.228.34.84
route-map AMPR-ROUTE permit 10
match ip address 11
set default interface Tunnel0
access-list 11 permit 44.165.1.48 0.0.0.15
ARP:
Protocol Address Age (min) Hardware Addr Type Interface
Internet 44.165.1.49 - 001e.f7af.4cd9 ARPA FastEthernet2/0
Internet 44.165.1.50 27 b827.eb7e.840a ARPA FastEthernet2/0
Any ideas?
Regards,
Tomek
Hello,
I’ve some errors with startampr script. Any idea to help me for resolve these mistakes?
73
F1SXO Frédéric
------------------------------
fred@f1sxo:/ampr-ripd $ sudo ./startampr
cannot determine tunnel mode (ipip, gre, vti or sit)
Error: Nexthop has invalid gateway.
---------------------------------
Ifconfig :
tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480
inet 44.151.31.6 netmask 255.255.255.255
tunnel txqueuelen 1000 (IPIP Tunnel)
---------------------------------
Extract from startampr script :
### ENABLE IP FORWARDING ###
sysctl -w net.ipv4.ip_forward=1
## Allows traceroute to respond using 44net IP of tunl0 or br-amprlan ##
echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
################### AMPRNet IPENCAP UBUNTU SYNTAX
modprobe ipip
ip tunnel add tunl0 mode ipip
###NUMBER tunl0 with a /32 from your allocation
###(you may reuse this IP on an Ethernet interface
ip addr add 44.151.31.6/32 dev tunl0
ip link set tunl0 mtu 1480 up
ip tunnel change tunl0 ttl 64 tos inherit pmtudisc
################### OPTIONAL - DEFAULT ROUTE FOR INTERNET ACCESS
ip route add default dev tunl0 via 44.151.31.6 onlink proto 44 table 44
################### POLICY-BADED ROUTING #######################
###OPTIONAL LOCAL RULES
ip rule add from 44.151.31.6 to 192.168.1.0/24 table main priority 22
#REQUIRED RULES
ip rule add to 44.151.31.6 table main priority 44
ip rule add dev tunl0 table 44 priority 45
ip rule add dev 44.151.31.6 table 44 priority 46
ip rule add from 44.151.31.6 table 44 priority 47
###SOME OF THIS MAY BE NEEDED TO RUN ampr-ripd from another folder than the compile option
73
F1sxo
Frédéric ZULIAN
https://www.ampr.org/grants/
ARDC has now given 110k to ARISS. I've asked ARISS if they condone ARDC by
accepting this fraudulently obtained funding.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
Is anyone experiencing a flood of pings from 44.4.92.50 (ke6i.ampr.org).
I'm seeing pings every second. The pings are flowing from the amprnet
server via encap.
root@linux:/jnos3/# tcpdump -n -i sl0 src 44.4.28.50
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sl0, link-type RAW (Raw IP), capture size 262144 bytes
03:01:43.969910 IP 44.4.28.50 > 44.17.0.128: ICMP echo request, id 27171, seq 25514, length 64
03:01:44.972033 IP 44.4.28.50 > 44.17.0.128: ICMP echo request, id 27171, seq 25515, length 64
03:01:45.975101 IP 44.4.28.50 > 44.17.0.128: ICMP echo request, id 27171, seq 25516, length 64
03:01:46.975808 IP 44.4.28.50 > 44.17.0.128: ICMP echo request, id 27171, seq 25517, length 64
03:01:47.976128 IP 44.4.28.50 > 44.17.0.128: ICMP echo request, id 27171, seq 25518, length 64
73 Jack AA6HF (44.17.0.128)
Hi,
Anyone out there familiar with adding the 44net to a Ubiquiti USG via the UniFi controller....??? I had it working by forwarding IPIP to a Linux box on my inside network, but it quit working after a few days. At first, I thought Comcast was blocking Protocol 4, but running tcpdump on the WAN interface shows the packets are there, but not being forwarded to the inside network.
Because the USG has the same OS as the EdgeRouter, I followed the AmprNet setup steps for the EdgeRouter. The rub there is the config does'nt get saved in the USG because it's over-written by the UniFi controller. In order to store the config, you have to add a config file (config-gateway-json). It works...but it's not pretty (one example is my internal network is not nat'ing outgoing packets to the 44 network).
So long story short...has anyone else done this or had experience with it....???
Feel free to reply here...or reply via my email listed on QRZ...
73's
-Albert
I am trying to configure the tunnel on Ubuntu 18 on a cloud VM just to figure out how the configuration works.
I am looking at http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example and have trouble configure the interface.
I have configure
auto ens4
iface ens3 inet static
address {my allocated IP}
netmask 255.255.255.252
However, the ifup ens4 command will failed to bring up ens4 interface. And of course when running ampr-run.sh and find_pass.sh will resulted in Setting SO_BINDTODEVICE: No such device.
Any advices on how to set it up on Ubuntu 18?
Thanks
Kun
To: Marius
I tried to compile that ax25-patch and it is terminating with the error:
make[2]: *** [scripts/Makefile.build:279:
/opt/ax25_patch/ax25/ax25_route.o] Error 1
make[1]: *** [Makefile:1601: _module_/opt/ax25_patch/ax25] Error 2
make[1]: Leaving directory '/usr/src/kernels/5.2.13-200.fc30.x86_64'
make: *** [Makefile:26: ax25.ko] Error 2
The compiler is in fedora 30 (gcc-9.2.1-1)
73
Libor OK2PEN (PY2ZEN)
Hello,
Here are some news about NPR - New Packet Radio.
I have made a big update of the firmware. Check it here:
https://hackaday.io/project/164092-npr-new-packet-radio
The main evolution is a great improvement of the radio sensitivity. If
you have noticed lack of sensitivity, it will help, for sure!
In fact, I have switched to GFSK instead of GMSK, with double frequency
deviation compared to GMSK.
After studying it in details, we have concluded that the radio chip that
I use (SI4463) is quite bad at GMSK demodulation.
This evolution makes it (of course) not compatible with previous
version! You have to update all your modems at the same time.
The bit per hertz ratio decreases, and I managed it like this:
* for low symbol rates with bandwidth constraints, I remain in
existing constraints (100kHz for modulation 20, 200kHz for modulations
11 dans 21)
* for higher symbol rates, the SR is the same than before, and the
radio bandwidth is increased.
Check all new version of documentation, release notes, etc...
Other improvements:
* I now publish a firmware for the 144-148MHz band (you need adequate
radio modules of course).
* Frequency setting resolution is improved to 1kHz (instead of
previously 40kHz).
* RSSI is now displayed in "dBm"
The next step of development will be frequency shift and FDD (Frequency
Division Duplex) feature. The uplink and downlink frequency could be
different, and you will be able to install 2 modems at Master side (one
for RX the other for TX) plus a duplexer. The main goal is to be able to
locate a NPR Master (repeater) in places (towers) where shift repeaters
are already present.
Finaly, about the kits sale, a new world-wide sale will probably start
before end of october. I will keep you informed.
73,
Guillaume F4HDK
I have been watching and using the 44 address group since the great days of
packet in the 90s.
With work and other obligations,
somehow I missed the selling of portions of the 44 block.
IT WAS NOT ANYONE'S TO SELL.
It was setup for the Ham Community at large.
If I try and get a group together and sell a portion of 2 meters is that
right? To me it seems to be about what happened here.
Thanks Bryan for trying to let the group know what is being done with these
proceeds.
Yes ARRL had a notice. I also do not think the ARRL is the sole news
agency for all thing ham radio either.
Just my 2cents
Thomas KC5KCT
Cathryn,
I see your ping requests arriving at 169.228.34.84 no problem,
and they are being encapsulated at sent to 50.79.209.150, again,
no problem. Nothing is coming back from 50.79.209.150.
This suggests that something is filtering out protocol 4 (IPIP)
between 169.228.34.84 and 50.79.209.150.
A traceroute from 169.228.34.84 to 50.79.209.150 using ordinary
UDP works, completing after 18 hops. The last few hops in that
path look like this:
14 162.151.87.226 12.097 ms 12.315 ms 12.088 ms
15 162.151.79.134 12.735 ms 12.744 ms 12.773 ms
16 68.87.227.122 13.080 ms 12.983 ms 12.920 ms
17 * * *
18 50.79.209.150 37.676 ms 42.664 ms 33.084 ms
A traceroute from 169.228.34.84 to 50.79.209.150 using protocol 4
(IPIP) does not complete, and there are no responses beyond hop
15. The last few hops are:
12 68.86.84.150 11.117 ms 12.601 ms 12.734 ms
13 68.86.94.154 11.761 ms 11.743 ms 11.340 ms
14 162.151.87.226 12.469 ms 12.162 ms 12.392 ms
15 162.151.79.134 12.757 ms 12.800 ms 12.797 ms
16 * * *
17 * * *
18 * * *
This suggests that hop 16, 68.87.227.122, is not accepting/passing
protocol 4 packets. The hostname for that host is
lag-2-240-acr07.pinole.ca.sfba.comcast.net.
I hate to throw you to the wolves of comcast's customer service line,
but you may need to find out from them if they suddenly started filtering
out inbound IPIP packets at that router.
- Brian
On Sat, Jun 29, 2019 at 09:50:40AM -0700, Cathryn Mataga via 44Net wrote:
> Date: Sat, 29 Jun 2019 09:50:40 -0700
> From: Cathryn Mataga <cathryn(a)junglevision.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: Connecting to 44net
>
> I'm not connected to 44net anymore, when I ping, to me at least, my
> outgoing packets look correct, but I get no response ever.
>
> I'm trying to put together as much as I can. My gateway ips 44.4.28.50
> at 50.79.209.150, I have a static IP.
>
> I'm current on the portal, far as I can tell with no error messages.
>
>
> ping 44.0.0.1
> PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data.
> *no response ever
>
> I see the outgoing, but never the ping back.
>
> tcpdump -vv -i enp4s0 host 169.228.34.84
> tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 09:39:25.982188 IP (tos 0x0, ttl 64, id 54479, offset 0, flags [DF],
> proto IPIP (4), length 104)
> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> id 14161, offset 0, flags [DF], proto ICMP (1), length 84)
> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 105,
> length 64
> 09:39:27.006173 IP (tos 0x0, ttl 64, id 54594, offset 0, flags [DF],
> proto IPIP (4), length 104)
> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> id 15137, offset 0, flags [DF], proto ICMP (1), length 84)
> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 106,
> length 64
>
> I occasionally see one of these, which hints to me that ipip is making
> it to my gateway.
>
> 09:39:15.386222 IP (tos 0x20, ttl 48, id 32657, offset 0, flags [none],
> proto IPIP (4), length 60)
> amprgw.ucsd.edu > hamradio.junglevision.com: IP (tos 0x0, ttl 237,
> id 33644, offset 0, flags [none], proto TCP (6), length 40)
> no-reverse-dns-configured.com.46324 > ke6i.ampr.org.finger: Flags
> [S], cksum 0x039d (correct), seq 2046795537, win 1024, length 0
>
>
> ip tunnel list tunl0
> tunl0: any/ip remote any local any ttl 64
>
> ifconfig tunl0
>
> tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480
> inet 44.4.28.50 netmask 255.255.255.255
> tunnel txqueuelen 1000 (IPIP Tunnel)
> RX packets 2259 bytes 305270 (298.1 KiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 2874 bytes 233904 (228.4 KiB)
> TX errors 232 dropped 0 overruns 0 carrier 0 collisions 232
>
> ifconfig enp4s0
> enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 50.79.209.150 netmask 255.255.255.240 broadcast
> 50.79.209.159
> ether 8c:89:a5:64:04:4c txqueuelen 1000 (Ethernet)
> RX packets 140452 bytes 25244334 (24.0 MiB)
> RX errors 0 dropped 473 overruns 0 frame 0
> TX packets 53461 bytes 5807456 (5.5 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> ampr-ripd -d -t 44 -a 44.4.28.50/32 -s -L ke6i@cm87uu
> Using gateway 50.79.209.158 for direct 44net endpoints via interface enp4s0.
> Calling home
> Waiting for RIPv2 broadcasts...
> Simple password: ***********
>
>
> ip rule list
>
> 0: from all lookup local
> 44: from all to 44.0.0.0/8 lookup hamradio
> 45: from all iif tunl0 lookup hamradio
> 45: from 44.4.28.50 lookup hamradio
> 32766: from all lookup main
> 32767: from all lookup default
>
>
> ip route list table hamradio
> 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840
> 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840
> 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840
> ...
>
> I don't think it's a firewall issue, I've turned off firewall and it
> doesn't fix anything.
>
> My route table looks healthy, so I think ampr-ripd is worrking correctly?
>
> Tried to include as much information as I can, thanks for any help!
>
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
Hi everyone, new 44Net list member here. I'm trying to setup the OpenVPN connection to the OH7LZB VPN server. I'm primarily using this link (http://wiki.ampr.org/wiki/AMPRNet_VPN), but I am planning to update it once I get my connection working. Looking thru the archives, it seems a number of us have had challenges with the setup.
If someone has successfully configured it recently, maybe you can help me out with my setup? The encryption and auth seems to not negotiate, the connection never sets up. Per Hessu's response to my email (below), perhaps it has to do with the newer version / algorithms trying to get along with the server version.
Thanks in advance for any assist.
- Matt / KM4EXS
-------- Forwarded message -------
From: "Heikki Hannikainen" <hessu(a)hes.iki.fi (mailto:hessu@hes.iki.fi)>
To: matthew(a)alberti.us (mailto:matthew@alberti.us)
Sent: August 18, 2019 12:13 PM
Subject: Re: 44Net VPN Setup
Hi,
I generally prefer to have these discussions on a mailing list so that the answers are archived
publicly, and others can look for existing answers from the archive instead of asking the same
question again. I run aprs.fi so I get a lot of questions and emails.
The log, at this verbosity level, doesn't actually say what went wrong in the negotiation. I think
there was a thread on the 44list before where someone resolved this issue, something to do with new
versions of openvpn openssl refusing to use the older algorithms currently configured on the VPN
server.
https://mailman.ampr.org/mailman/private/44net (https://mailman.ampr.org/mailman/private/44net)
On Sat, 17 Aug 2019, matthew(a)alberti.us (mailto:matthew@alberti.us) wrote:
Hi Hessu,
I pulled your e-mail address off the 44net mailman list. Didn't want to spam
it, as I think I am missing something easy.
I'm trying to setup an OpenVPN connection to your server, so that I can get
an AMPRNet IP. I have followed the instructions at
http://wiki.ampr.org/wiki/AMPRNet_VPN (http://wiki.ampr.org/wiki/AMPRNet_VPN). It looks like I'm stuck after the CA
is verified, but before the data channel encryption/auth is negotiated.
Below are my logs. I was hoping you could take a look at the server side, my
public IP is 184.82.197.68. I think I'm probably using the wrong client
settings. I'm trying to set this up on a pfSense router.... so I have to
enter all the settings manually. I am trying to use BF-CBC and SHA1... but
also tried a few other combos. No luck.
Thanks in advance!
- Matt Alberti / KM4EXS
Aug 17 16:47:52
openvpn
18908
SIGUSR1[soft,tls-error] received, process restarting
Aug 17 16:47:52
openvpn
18908
Restart pause, 5 second(s)
Aug 17 16:47:57
openvpn
18908
WARNING: No server certificate verification method has been enabled. See
http://openvpn.net/howto.html#mitm (http://openvpn.net/howto.html#mitm) for more info.
Aug 17 16:47:57
openvpn
18908
NOTE: the current --script-security setting may allow this configuration to
call user-defined scripts
Aug 17 16:47:57
openvpn
18908
TCP/UDP: Preserving recently used remote address: [AF_INET]85.188.1.118:1773
Aug 17 16:47:57
openvpn
18908
Socket Buffers: R=[42080->42080] S=[57344->57344]
Aug 17 16:47:57
openvpn
18908
UDP link local (bound): [AF_INET][undef]:0
Aug 17 16:47:57
openvpn
18908
UDP link remote: [AF_INET]85.188.1.118:1773
Aug 17 16:47:57
openvpn
18908
TLS: Initial packet from [AF_INET]85.188.1.118:1773 (via
[AF_INET]184.82.197.68%), sid=368827b7 79c57373
Aug 17 16:47:59
openvpn
18908
VERIFY OK: depth=1, O=AMPRnet, CN=OH7LZB VPN service CA
Aug 17 16:47:59
openvpn
18908
VERIFY OK: depth=0, CN=ampr-gw.he.fi
Aug 17 16:48:57
openvpn
18908
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your
network connectivity)
Aug 17 16:48:57
openvpn
18908
TLS Error: TLS handshake failed
- Hessu
Greatings...!!!
I'm setting up an AMPR Gateway on an Ubuntu 16.04 box. This box is behind a Ubiquiti Unifi USG. I'm forwarding IP Protocol 4 to the internal IP of the box.
The layout of the box is two NIC cards...one that sits on my home network, the other card will handle my 44 net allocations with connection to the rest of the AMPR Net via the AMPR Net tunnel.
When I first bring the box up, and before I bring up the tunnel, I'm able to ping the 44 net hosts inside of my network. Using TCPDUMP I can follow the flow of packets pretty easily. The problem starts when I bring up the tunnel. As soon the tunnel comes up, when I try to ping one of my 44 hosts, I can see the packets are now going out on the tunnel interface and not on the NIC card on my 44 network. I've gone through this line by line on my scripts, and the problem starts when the actual default route to the AMPR Gateway is added. From that point on, all the packets are sent thru the tunnel. I've tried three different versions of scripts that I've found on the Internet and the result is the same.
Here's one script that I got off the AMPR Wiki:
#!/bin/sh
###
## Create AMPRNet Tunnel and routing
##
## Configure Tunnel (put your ISP you received from your ISP Here).
ip tunnel add ampr0 mode ipip local 192.168.12.158 ttl 255
## Bring it up
ip link set dev ampr0 up
## Enable Multicast in order to receive routes
ifconfig ampr0 multicast
## Configure Policy Based routing
# Packets to 44/8 network use routing table 44
ip rule add to 44.0.0.0/8 table 44 priority 44
# Packets from our 44 subnet use table 44 (put your AMPRNet Subnet here)
ip rule add from 44.26.2.32/27 table 44 priority 45
## Configure static routes
# Default route for table 44 is to send traffic to amprnet gateway at UCSD
ip route add default dev ampr0 via 169.228.34.84 onlink table 44
# Route packets for our net to local interface (put your AMPRNet Subnet here)
ip route add 44.26.2.32/27 dev ens192 table 44
## Start ampr-ripd to learn rest of mesh routes
# Be sure to substitute the password you found earlier for <SecretPassword>
# Put your static IP you received from your ISP here.
ampr-ripd -s -i ampr0 -a 192.168.12.158 -t 44
I've tried the obvious stuff...removing the route, re-adding the route....but I can't seem to figure this out. Any input, ideas, suggestions would be appreciated.
73's
Albert
WB7AWL
I thought some of you might be interested in this upcoming event. It
sounds relevant to our membership... Maybe a way to encourage other people
to get their licences? Too far from San Francisco for me to participate...
but I will be tracking the event from afar...
As to the ongoing maiing list discussion: I would like to propose we form
a subcommittee of interested members to review the organizational bylaws
and make recommendations to the Board of Directors for improvements.
I also think we need to communicate better and more efficently.. Perhaps
we can add some newer open source software tools to ensure smoother
communication?
Lori Guidos
KE6INO
OCTOBER 23, 2019
Mobile World Congress Americas
Los Angeles Convention Center :
https://www.spectrumcollaborationchallenge.com/
- The Challenge
-
The DARPA Spectrum Collaboration Challenge (SC2) aims to ensure that the
exponentially growing number of military and civilian wireless devices will
have full access to the increasingly crowded electromagnetic spectrum.
In this first-of-its-kind collaborative machine-learning competition,
competitors will reimagine new spectrum access strategies in which radio
networks autonomously collaborate to dynamically determine how the radio
frequency (RF) spectrum should be used moment to moment, avoiding
interference and jointly exploiting opportunities. SC2 teams will develop
these breakthrough capabilities by taking advantage of recent advances in
artificial intelligence (AI) and machine learning, and the expanding
capacities of software-defined radios.
The team whose radio design most reliably achieves successful communication
in the presence of other competing radios could win as much as $3,500,000.
I'm starting a new thread regarding this topic.
On 8/24/2019 2:10 AM, Lori Guidos wrote:
> I also think we need to communicate better and more efficently.. Perhaps
> we can add some newer open source software tools to ensure smoother
> communication?
I am reluctant to endorse adoption of new methods or tools: they tend to
become the problem they are supposed to prevent, drawing resources and
time away from more pressing issues.
This mailing list is stable, well-known, and easy to use. A new paradigm
would require that each subscriber climb what might be a steep
learning-curve, and once they do that, some will feel compelled to
demonstrate their command of the new methods and/or software by adding
to the amount of smoke surrounding our electronic campfire, without also
adding enough light to make the changes worthwhile.
Could communication be improved? Of course. Will having a new way to
communicate automagically cause that to happen? I don't feel that it will.
YMMV. HTH.
73,
W4EWH
Bill Horne
Hello,
I'm working on setting up a 44net gateway. I need to get some DNS names into the 44net DNS server. How is that being done nowadays...???
Thanks
Albert
WB7AWL
One approach that may generate some visibility of the issue - and possibly some action, or an investigation - would be to file a complaint with ARIN, the responsible entity fir all North American IP address allocations. See arin.net
Bill Semich, K1CSL
________________________________
From: 44Net <44net-bounces+bsemich=msn.com(a)mailman.ampr.org> on behalf of 44net-request(a)mailman.ampr.org <44net-request(a)mailman.ampr.org>
Sent: Friday, August 16, 2019 3:00:00 PM
To: 44net(a)mailman.ampr.org <44net(a)mailman.ampr.org>
Subject: 44Net Digest, Vol 8, Issue 133
Send 44Net mailing list submissions to
44net(a)mailman.ampr.org
To subscribe or unsubscribe via the World Wide Web, visit
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.a…
or, via email, send a message with subject or body 'help' to
44net-request(a)mailman.ampr.org
You can reach the person managing the list at
44net-owner(a)mailman.ampr.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 44Net digest..."
Hello,
I'm configuring a Raspberry with raspbian on 44.0.0.0 network.
I don’t understand some syntax options.
Man "route" options are "add" with "-net" or "-host" but
I don't find how to use the "addprivate" options.Example in Encap file : route addprivate 44.154.64/24 encap 62.169.206.224
But Man "route" says : route add [-net|-host]
"addprivate" seems not to be a option for "route add" command.
73
F1SXO
Frédéric ZULIAN
Hello,
I’m setting up my Raspberry 3 for HAMNET.
To configure my DNS server, I need the address of a root DNS server.
Is there one or more root DNS servers dedicated to HAMNET?
73
F1SXO
Frédéric ZULIAN
How suspicious, another new board member has been added to ARDC to help out in
the ongoing fraud, Bdale Garbee, KB0G.
https://www.ampr.org/about/who-we-are/
I'd hope we all keep an eye on this page, as we can't trust ARDC to police
themselves.
The plot thickens..
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
Those of us who have been involved in this arena for over 30 years
know that Bdale Garbee, KB0G, is not only one of the most technically
astute leaders we have had in the hobby, but is an honorable and very
respected individual.
I fully support his selection.
- JimF K6IYK
In the past ampr gateway would only forward packets to the general internet from 44-net address space and not from 44 net to other 44 net addresses. Will the ampr gateway now forward packets for addresses from 44-net to 44.192.0.0/10?
Philip KC3IPF
Hello,
After some time away, I try to get back into the Hmanet network with a
server (Raspberry) under Yunohost.
I begin the configuration :)
Does the Hamnet network have a root DNS server?
73
F1SXO
Frédéric ZULIAN
--
Frédéric ZULIAN
Hello,
Please note that the update to Mikrotik ROS 6.45.3 breaks reception of
the RIP multicasts used by the gateway scripts.
Please do not update unless you need to solve issues described in the
change list.
Changes in this release:
*) certificate - renew certificates via SCEP when 3/4 of lifetime reached;
*) crs317 - fixed multicast packet receiving (introduced in v6.45);
*) hotspot - fixed default profile values not being used (introduced in
v6.45);
*) rb4011 - fixed SFP+ interface linking (introduced in v6.45.2);
*) smips - reduced RouterOS main package size (disabled LTE modem, dot1x
and SwOS support);
*) supout - fixed SIM slot printing (introduced in v6.45);
*) wireless - improved U-APSD (WMM Power Save) support for 802.11e;
Marius, YO2LOJ
I'm trying to monitor RIP broadcasts from ucsd using 'tcpdump'. Does
anyone know what 44-ip address(s), port, or protocol I should source
to monitor incoming broadcasts. Is it 44.0.0.1 ?
Thanks,
Jack AA6HF
Host mailman.ampr.org (where this and other mailing lists are hosted)
has moved from address 199.249.230.93 to 44.76.7.7. This change was
made because the 199.249.230.93 address was being blocked by too
many blacklists due to other activity on the subnet.
Unfortunately, whenever a mail handler such as 'mailman' gets a new
address, it loses all the good will and reputation it has previously
earned in various spam filters, so some recipients may miss out on a
few messages because of over-enthusiastic spam filtering.
There is nothing I know of to enhance its reputation except time.
Your patience is appreciated.
- Brian
Hello all,
I am looking for some recommendations on network routers for harsh environments. By harsh, I mean hot but not particularly dirty. I know there's a number of people on this list who use Mikrotik and Ubiquit EdgeRouters for your deployments and I am looking for thoughts on those product lines, as well as any other similar products. I am looking for a reasonably low-cost device. The key items I am looking for are:
- Wide operating temperatures. Some of the sites are tower buildings that don't have A/C and during last week's heatwave the in-room temperature in one of the buildings was 105F-110F (killed an SRX power supply). None of the rooms will freeze in the winter but the temp will get quite low.
- RELIABLE -- some of our sites have limited access and frequent power cycles, port failures, etc. are show stoppers
- IPv6 support for basic routing and switching functions
- Support for BGP and OSPFv3 (routing tables < 100 items)
- VLAN tagging
- IPSec or OpenVPN tunnels as clients
- No firewalling or the ability to pass traffic without firewalls - note I don't mean a "permit any/any", I mean literally the device operates as a router or traffic can bypass a firewall-like function.
- The device is a pre-packaged commercial system; I don't want to have to mess around with custom Linux/BSD installs, etc.
- A device that can operate as both a router and switch would be nice, but not required
As background, our club has a wide-area network around southwest Akron, Ohio-area stretching out to Rittman, Ohio and southeast to Alliance, Ohio with legs planned in other directions. This network supports a number of ham repeaters as well as other related services for the repeaters plus some of the site operations for the tower locations. Most of the gear is showing its age and we're going to start a wholesale replacement of most of it later this summer/autumn.
All of the sites are connected with narrow-beam WiFi using point-to-point dishes, currently N but upgrading to AC AirMAX when we do the hardware refresh. Each site has a router or switch or both (depending on size and needs). The gear is a mix of Juniper SSG5s, Juniper SRXs, HP ProCurve switches, and some other random items. As part of the work, we're going to do a complete renumbering of the networks (which have grown up ad-hoc over the years), incorporate better use of 44Net space, and overlay IPv6 across the whole network. The reason for not wanting firewalling between the sites is we've run into problems with link reliability over UDP (losing a few packets) and also certain network device behaviors that don't survive multiple hops through stateful firewalls for a variety of reasons.
Any thoughts in this community? I've been looking at the Mikrotik hEX S and the Ubiquiti EdgeRouter X as example devices. I don't have experience with Mikrotik gear although I hear it mentioned here a lot.
Thanks
Jason N8EI
> < IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 106 >
> They say a little knowledge is dangerous !
> At the moment at my tunl0 ( remote location ) I am getting groups of
five of the above line every minute in my recently installed gateway.
> I have tried without success to stop it appearing using iptables with
< -A INPUT -p udp -i tunl0 --sport 5678 -j DROP >.
Well, there is no need to do that really. Those packets are not
dangerous, they sometimes may be even useful.
This is a router discovery protocol that will inform you about
manufacturer, version number of software, router name etc of the device
sending it.
When you have a device that supports it (sends it), you will also have
some overview table in the user interface there which shows the decoded
info received in the last 2 minutes or so.
At first I also disabled this everywhere I saw it, and I am still not
sending it on IPIP tunnels (where it actually is a bit troublesome for
some cases because every minute such a packets would go out on all 500
tunnels at the same time and would result in a traffic burst that may
overflow some queues somewhere and would result in packet loss of other
usage).
But on the VPN links that we use with our new style connections, I now
keep it enabled. It provides a nice overview about who is connected
and what software they are running, and I occasionally mail people that
never upgrade their software to urge them to do so.
As the mechanism for enabling/disabling these broadcasts has changed a
little in the recent past in MikroTik firmware, and people not always
update their software, some people that run an older YO2LOJ (Marius)
script version may unknowingly be sending these things.
But they are not dangerous and should not cause any noticable traffic
volume.
Rob
> But, afer almost 20 years playing around witht his topic, I think the lack of specific network services on 44net is the actual element preventing the spread of its usage.
> The original goal was conectivity, global if possible.
> But there simply is no incentive for using it anymore. Dx clusters are reachable on the regular internet, repeaters and reflectors too. Specialized sites dedicated to contesting are homebrew stuff, or whatever, use regular internet access. They can not rely on a network where only 10k users are reachable. And BBS systems are outdated and replaced by forums, mailing lists and discussion groups on various platforms.
> Unless we can find desirable services that really need a "private" globally routeable network for them to work, there will be no real new users influx beyond the occasional network enthusiast.
I agree with that, it does not make much sense to run it as an isolated network.
However, the 44net address space has enabled us to build a radio linked network and have infrastucture like repeaters, WebSDR, VoIP exchanges etc
attached to it and also connect interested users to the same network. Without NAT issues.
For that network to be useful though, it needs to be connected to internet in a reasonably efficient way.
That is why we announced our country network on internet, and now we can use the services both on the radio network and from internet.
(of course as far as firewall rules permit, you really don't want to route all traffic from internet to your radio network...)
Still it is difficult to interest new users.
However, when we get an interested user and he wants to setup some new service or experiment with what is there,
shouldn't we make access to the network easy for new users, instead of making them fight with their router settings?
The 44net also often makes things easier by having transparent routing.
E.g. to setup a system with echolink usually is a nightmare because of the port forwarding requirements.
By connecting to 44net and putting the echolink system on a 44net address, the filtering in the ISP router is eliminated
and it is much easier to make it working.
Rob
> So that we don't have to have the same conversations twice -- let's move
> this thread to 44ngn at mailman.ampr.org <https://mailman.ampr.org/mailman/listinfo/44net>
I was against the creation of that second list, but I was too late to respond: it already was created.
This inevitably creates such problems. I vote for deleting it.
Now I have to find some way to use that new list, while using this one already is so difficult.
With two lists it is becoming even more problematic...
Rob
> >/Because we are trying to draft a new solution that would not work only for /> >/you, but also for others. You do not seem to be interested in that. /
> Please quote me showing me saying I'm not interested in something new.
> If there's something I *could* do where I don't have to increase my cost
> not even $0.01/yr that's well documented I'd be quite happy to try
> something out. Not once did I say I'm not interested, I have however
> said don't scrap what's there that's working for me.
The problem is that the new proposal will not work as smoothly and will be much
more difficult to implement when the old system is to be left in place.
That is because the new system is to be using automatic routing (with BGP or
maybe OSPF when others can convince my that would work better), while the old
system uses manual static routing managed by the portal.
> >/Come on, it costs like $5-$10 per month per location to host such a
service. /
> Even this is still $5-10 per month more than I'm willing to spend.
*you* are not supposed to be spending that money. It is to be spent by those that
deploy the VPN servers. Hopefully ARDC.
> >/And that is only when it is paid for. Last time I asked here for
volunteers /> >/to host an echolink proxy farm, there were like 10 volunteers that would /> >/do (and did) it for free. It is likely that they would add such a VPN /> >/server feature to their already existing hosted system, if we would kindly /> >/ask it to them. /
> Again, you're in the Netherlands, I am not. You most likely use 220v a/c
> @50hz where we use 120v a/c at 60hz. Things are not the same here as
> they are where you are and doubtful in other parts of the world as well.
But NONE of those volunteers were from the Netherlands!! (they did not need to
be, because I already host such a proxy farm in the Netherlands and the call for
volunteers was to get more of them running across the world)
The spread of volunteers was not as good as it could have been, but there were
several from California, from Canada, from Australia, etc.
Probably there are not so affected by backward internet connectivity (or lack
of money) as you are. I don't know if they end up spending the $5/month for
the benefit of amateur radio or if they got their hosting for free as part of
some other deal. But they do offer the service! Voluntarily, without complaining.
> Why would it be a waste of money?
> I've wanted to see actual drafts and test environments where something new works.
Because I think it is a waste of money (or a waste of time) to do a lot of research
do potentially get a new product or another innovation started, for a community
that is not interested in innovation and will make up any motivation to resist it.
(including age, expense, "lack of reliability of the new system", and so on)
You very well know that a system like the proposed one is operating in many other
places, and the only proposed change is to interconnect those systems and make
more of them, to replace the old and static system with something more flexible
and more usable.
> Why do I need internet connectivity from 44-net systems? It's a bonus
> sure but I don't *need* it.
Maybe you are mostly stuck in the usage scenario where AMPRnet is mostly used to
emulate the old packet radio system, e.g. for BBS forwarding, DX cluster, telnet
chat, etc. However, most new users who already know the internet want to do
other things, like WebSDR, audio and video streaming (e.g. to YouTube), running
amateur-oriented web services like a Mattermost server, etc.
Internet connectivity is a must for most of these.
> Often we forget many factors, some which we don't necessarily physically
> see. No matter the solution, there will always be a very large amount of
> points of failure. There's nothing you can do about that.
But you can at least try! I remember seeing the questions here about having an
IPIP gateway with more than one external address (e.g. using two different ISP
links) to have redundancy at that level. Not possible, Sir! An IPIP tunnel
endpoint has no way of seeing that the other side is down.
With the newly proposed system this function would be no problem. BGP sees
that a link is down and switches over to the alternate. Even within a second,
when you configure BFD with it.
But as long as the IPIP advocates get it their way, this will not happen.
> One argument against IPIP however is it's deployment in the home.
> Has anyone tried to simplify this? I have, and I've updated my system to
> reflect the 2 subnets. All you do is set your device as the DMZ of your
> router and run the install script which will ask for your 44-net info.
I could deploy it to my home, but I have no need to do that. I already have a
5GHz WiFi link to our nearby (5 miles) access point so I get my AMPRnet over
radio, thank you very much. And I have a VPN as a backup in case it somehow
fails. In fact I have backup in 2 directions: when my VDSL connection fails,
I can still surf the web via my amateur radio connection. If only to check the
ISP website to see if there are any known interruptions.
And there are several other stations here with the same setup. Not only do they
have the above advantages, their systems also provide backup to the links between
the access points. When the interlink to my accesspoint fails (another radio link),
it would be automatically backed up via my own VPN and radio link. BGP does
all that. The IPIP system can't.
Rob
Indeed, rdns for HamWAN is still broken (44.25.0.0/16). It appears to be
because second level delegations were made on ARIN's DNS servers for every
"44.x" label. Since that's at the same level as our delegation, DNS
servers see it as an invalid "horizontal" delegation.
Can you please see that the "25.44.in-addr.arpa." record is updated in
ARIN's DNS servers to point to:
a.ns.hamwan.net.
b.ns.hamwan.net.
Thank you,
-Cory, NQ1E
HamWAN
$ dig +trace 25.44.in-addr.arpa.
<snip>
44.in-addr.arpa. 86400 IN NS z.arin.net.
44.in-addr.arpa. 86400 IN NS x.arin.net.
44.in-addr.arpa. 86400 IN NS r.arin.net.
;; Received 92 bytes from 200.10.60.53#53(200.10.60.53) in 232 ms
25.44.in-addr.arpa. 86400 IN NS ns2.threshinc.com.
25.44.in-addr.arpa. 86400 IN NS ampr-dns.in-berlin.de.
25.44.in-addr.arpa. 86400 IN NS a.coreservers.uk.
25.44.in-addr.arpa. 86400 IN NS ampr.org.
25.44.in-addr.arpa. 86400 IN NS munnari.oz.au.
;; Received 181 bytes from 199.180.180.63#53(199.180.180.63) in 498 ms
25.44.in-addr.arpa. 3600 IN NS a.ns.hamwan.net.
25.44.in-addr.arpa. 3600 IN NS c.ns.hamwan.net.
25.44.in-addr.arpa. 3600 IN NS b.ns.hamwan.net.
;; BAD (HORIZONTAL) REFERRAL
;; Received 97 bytes from 192.109.42.4#53(192.109.42.4) in 269 ms
25.44.in-addr.arpa. 3600 IN SOA a.ns.hamwan.net.
hostmaster.hamwan.net. 2019071706 900 180 604800 900
;; Received 98 bytes from 44.24.245.2#53(44.24.245.2) in 11 ms
On Fri, Jul 19, 2019 at 7:40 AM Tom Hayward via 44Net <
44net(a)mailman.ampr.org> wrote:
>
>
>
> ---------- Forwarded message ----------
> From: Tom Hayward <esarfl(a)gmail.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc:
> Bcc:
> Date: Fri, 19 Jul 2019 07:38:57 -0700
> Subject: Re: [44net] Reverse DNS broken
> Seems 44.25.0.0/16 is still broken. It was previously delegated to [abc].
> ns.hamwan.net.
>
> Tom KD7LXL
>
> On Fri, Jul 19, 2019, 05:07 Job Snijders <job(a)ntt.net> wrote:
>
> > I think this is resolved now.
> >
> > On Fri, Jul 19, 2019 at 02:37 Job Snijders <job(a)ntt.net> wrote:
> >
> > > Some good debugging information was provided to me offlist , I've now
> > > been in touch with ARIN staff and some changes were made. It may take a
> > > few hours for the changes to be visible on the Internet, new zone file
> > > needs to be generated & pushed out.
> > >
> > > My initial assessment is that the delegations for the remaining /10 and
> > > /9 towards AMPRnet DNS servers didnt exist. I don't know whose
> > > responsiblity it would've been to ensure that existed. I can't guess
> why
> > > they were missing, perhaps a coordination issue in the transfer process
> > > from the previous state to the current state.
> > >
> > > The AMPRnet reverse DNS administators may want to verify that the
> > > authoritative dns servers are configured not for for 44.in-addr.arpa,
> > > but for the individual /16s within 44/8 that still are AMPRnet. I don't
> > > know who manages that so I hope this message finds them.
> > >
> > > I'm running on fumes and only have 4 hours of sleep opportunity ahead
> of
> > > me - so signing off, I think things will probably restore in the next
> > > few hours.
> > >
> > > Good luck!
> > >
> > > Job
> > >
> > > On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote:
> > > > To help speed up the resolution process, it would be beneficial if
> > > > someone provides me with data what exactly is broken, and what the
> > > > values / parameters previously were.
> > > >
> > > > was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net,
> > and
> > > > r.arin.net? If not, where was it delegated? Where should it be
> > > > delegated?
> > > >
> > > > Any tangible data about what the state currently is, and what it
> should
> > > > be; will help speed up recovery.
> > > >
> > > > Kind regards,
> > > >
> > > > Job
> > >
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)mailman.ampr.org
> > https://mailman.ampr.org/mailman/listinfo/44net
> >
>
>
>
> ---------- Forwarded message ----------
> From: Tom Hayward via 44Net <44net(a)mailman.ampr.org>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc: Tom Hayward <esarfl(a)gmail.com>
> Bcc:
> Date: Fri, 19 Jul 2019 07:38:57 -0700
> Subject: Re: [44net] Reverse DNS broken
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
< IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 106 >
Hello,
They say a little knowledge is dangerous !
At the moment at my tunl0 ( remote location ) I am getting groups of
five of the above line every minute in my recently installed gateway.
I have tried without success to stop it appearing using iptables with
< -A INPUT -p udp -i tunl0 --sport 5678 -j DROP >.
It shows as dropped when I monitor iptables but still appears when
using tcpdump at the same time.
It can be stopped by removing my ipencap entry but that stops my
ampr-ripd reception was well.
Is this just something I have to accept or is there a solution ?
Regards,
Ian..
As a few people have requested, I've created a new mailing list for
discussions of the architecture of the Next Generation Network for
AMPRNet, such as have been recently discussed here under the subject
line of '44 net connectivity'. Feel free to join, and to invite your
colleagues to join at
<https://mailman.ampr.org/mailman/listinfo/44ngn>
Welcome!
- Brian
> >/And these addresses are normally included with your internet service
for free. /
> One thing to note however is that in many cases, any ports or protocols
> blocked by the ISP on IPv4 are also blocked on IPv6. This is what makes
> getting a block from a tunnel broker beneficial.
Of course you will not need to have some unusual protocol like IPIP operational over
that IPv6 connection, and usually the plain TCP and UDP ports can be opened without
problem so it should be possible to run the usual services.
A tunnel broker introduces an additional dependency and additional weird routing, so
when people complain that using some VPN servers across the world instead of a tunnel
mesh is objectionable, they certainly should not use an IPv6 tunnel broker!
Rob
> That is true, but only if we are the only ones using private ASNs.
> But if happens that some people already uses private ASN for other
> purpose, they would be in trouble connecting to 44net... because there
> would be collisions.
> I see no point of using public IP addresses and route them using private
> ASNs. It may be that I do not understand BGP well.
It is important to note that the routing in this overlay network,
let's call it BGP44 from now, is running as a separate BGP instance
that is not combined with BGP announcement to internet or private use
of BGP. The BGP44 instance will only distribuite the routing info
for AMPRnet subnets, similar to what is now in the IPIP routing table.
Also, even though there could theoretically be collisions, in practice
there is not much risk because there are 94,967,295 available AS numbers
in the space that we use. That is 8 times more than the number of IP
addresses we have left.
Rob
> If anyone in Europe fancies announcing their own 44 /24 from a VPS /
> ISP and doesn't have their own ASN, I can help out with that element.
> Happy to apply for ASNs via my RIPE LIR account for folk from the HAM
> community for free. Takes 2 or 3 days for RIPE to approve the
> paperwork and issue the ASN, under current RIPE billing policy these
> do not cost anything.
While this is of course always welcome, please do understand that this is not
related to the current discussion! What I am proposing here is to deploy
an overlay network (VPN tunnels) to route the AMPRnet around the world and
to connect users to it. The autorouting within that overlay network could be
done using BGP. It could also be done using OSPF.
This use of BGP is NOT related to announcing someone's subnet on internet
using BGP! For that, you could require an AS number, amongst other things.
(it is also possible that it can be announced using the AS number of your ISP)
However, to operate our own overlay network, a group of routers that interconnect
using BGP over VPN tunnels, we do not require AS numbers from a LIR!
We just use private AS numbers. In the 32-bit AS number space there is a large
range of private AS numbers that we can (and already DO) use for that.
We already have an allocation scheme to split this range across countries, so
we do not need a central registry for them either.
Maybe we should refer to this usage of BGP as BGP44, to make clear that it is
not related to the use of BGP on internet? Of course, BGP and BGP44 are the
same protocol running on standard hardware, but the usage is different. Much
like an intranet and the internet use the same protocols, but their usage is
different.
So while this contribution is of course always welcome, please (those who do not
completely understand the discussion) note that it is not related to what we
are discussing.
That being said, once there is a deployment of VPN routers like I propose, it
will be much easier to have parts of AMPRnet announced from the datacenters
where these are located. That could be considered part 2 of the project.
Rob
On Tue, Jul 23, 2019 at 09:52:29AM +0200, Marc Williams via 44Net wrote:
> I suppose recent examples would be personal attacks on named individuals.
While those are never welcome, as mailing list manager, I don't
like the idea of banning those persons from participating in the
list because, however unlikely, they may be able to contribute
usefully to discussions here.
I feel that correct mailing list etiquette would be, when someone
is out of line, or indeed, out of control, for list members to send
him a private email reminding him that civility and rational
discussion achieve more than frenzied, often hastily composed
diatribes do.
That said, it is possible for repeat or particularly vile offenders
to be subject to moderation or struck off or banned from the list.
So please, folks, no matter how angry or upset a posting here gets
you, at all times remember to be civil to your fellow list members.
Thank you.
- Brian
PS: to discourage trolls and bots, it's my policy that when a
newcomer is first subscribed to the list, his 'mod' flag is turned
on, so that his initial posting is reviewed before being forwarded
to the list. I recognize that this causes a delay, but I believe
its in the best interests of our subscribers. As soon as a valid
posting is received, the 'mod' flag will be turned off. Many other
mailing lists have this same policy.
> But to be honest I would say a bigger deterrent to using 44 net is the nature of some of the discourse on here. I can't claim to be a Saint myself but honestly some people's dialog is frankly appalling.
> Yes there is some improvement to be made around technology but also some rules around acceptable use of the mailing list should go hand in hand with it.
It is unclear to me what you are referring to.
Maybe you should be reminded that part of the people here do not have English as their first language.
Their language vocabulary is limited and it is difficult for us to express the subtleties that you may want to see.
Rob
Hi there
Now that we have a lot of money in the pocket may we consider installing a VPN server at UCSD to allow user connecting AMPRNET with VPN in addition to the IPIP tunnel ?
I myself will be more then happy to move our networks from IPIP connectivity to VPN (or any other more sophisticated technology) .
Thanks Forward
Ronen - 4Z4ZQ
> Personally, I love the idea of allowing the network to be more
inclusive by allowing connections other than the current IPIP one.
Rather than replace IPIP, I would suggest that we keep it and just allow
people to act as hubs for those that are behind NAT/Limiting firewalls, etc.
This is what we already have working, and others have that too. A local
VPN server that is connected to IPIP (and in our case BGP too).
However, such a setup is a bit complicated because the IPIP mesh is not
well supported on many router types, and having the two
different network types integrated in the same router also is kind of
tricky.
Not everyone gets that right: all routes have to be in the same routing
table and evaluated from more-specific to less-specific.
But you still need to handle cases where multiple routes to the same
subnet (using different protocols) can exist.
In some cases, people have resorted to having multiple routing tables
and searching them in a specific sequence, but that does not work
correctly in some cases.
Also there is the issue of determining the correct source address.
Sometimes such gateways send traffic with a non-44net source address
through an IPIP tunnel, which of course is unwanted.
So my proposal is to drop the IPIP mesh to remove this additional
complexity, and make the system easier to rollout and maintain.
> While I think BGP would be great, it adds questions like: can people
announce their own non-44 space, can people use their own ASNs, how will
we allocate ASNs, how do we confirm people are announcing space actually
allocated to them. One thing we can do, is look at DN42 and how they
work. Their network is similar to some of these suggestion with the
exception that they use private space.
Some of those topics have already been addressed and resolved before.
For example w.r.t. the AS numbers, we have agreed to use an allocation
scheme for private AS numbers so this can be delegated to individual
regions without chance of collisions.
The scheme is to use "42"+iso country designator+5 digits, where these 5
digits can be subdivided in a region specific way.
Large countries have several iso country designators so there should be
ample space using this scheme.
Here we use 42204+3digits+2digits where a router in our
44.137.aaa.bbb/16 subnet gets AS 44204aaann where nn=bbb/16.
Of course this network is only meant to distribute net44 addresses, our
routefilters filter announcements outside that. But you can announce
space for your friend inside net44. Actually the same as the current
IPIP situation.
Indeed very similar to what DN42 does.
Rob
> >/I don't suggest that you would use only our VPN server, you could /> >/connect it in addition to some other to have additional redundancy /> >/and maybe a more efficient path to western europe. /
> Why would I want or need to go across the Atlantic when it's not
> necessary since IPIP is working fine for me.
Because we are trying to draft a new solution that would not work only for
you, but also for others. You do not seem to be interested in that.
> >/You (or ARDC, using their money) should eastablish one or more VPN /> >/servers on the eastcoast and/or Canada, then you connect there and /> >/those servers connect back to UCSD or maybe even advertise some of /> >/the locally assigned subnets on internet BGP. /
> I don't see where this would be a reasonable allocation of funds by
> ARDC.
Come on, it costs like $5-$10 per month per location to host such a service.
And that is only when it is paid for. Last time I asked here for volunteers
to host an echolink proxy farm, there were like 10 volunteers that would
do (and did) it for free. It is likely that they would add such a VPN
server feature to their already existing hosted system, if we would kindly
ask it to them.
> If ARDC were to allocate funding I would rather see it go into research
> of new techologies. We as hams are not leaders anymore, we're lemmings.
That would be a complete waste of money! As is clearly shown by this entire
discussion, there is nothing that hams hate more than to change something
that they think is working well for them, even without considering how it
works for others.
Again, it is much like the discussion about CW. Large groups of hams
still believe that CW is the most efficient mode and can be received when
all other modes fail. Utter bullshit, of course, but it was like that
50 years ago so it still must be true today.
> >/Then it will improve your connectivity to internet, and connectivity /> >/to other AMPRnet systems is the same or similar. /
> How will that improve my connectivity to the internet? I can and do get
> around blocks by my ISP just fine - once I know what they are and I take
> full advantage of the 200Mbs link I have for a residential circuit.
The connectivity to internet from your 44net systems, of course!
That would now go via UCSD and when you could get a local VPN server which
also announces the state's network allocation on BGP, it would be faster
than the trip via UCSD in many cases.
> I could get another circuit with 4G backup and shell out almost
> $2,000/yr additional as a business circuit but why? For people on this
> list to try and tell me what to do with my circuit that I spend my money
> on? I think not thank you. That's when a ham community turns into a ham
> dictatorship.
It is always amazing to see people on this list toggle between "but there
are single points of failure in this solution, I do not like that!" and
"don't tell me to do things the way you like" after explaining them how to
work around those single points of failure. Apparently they bring that up
only to put a spanner in the works of any discussion about change, not
because they really care about it.
Also I think your solution is way too expensive. My home internet connection
(with fixed IPv4, native IPv6 /48, 100 Mbps, unlimited data, no silly filtering)
costs me less than $600/year and it includes 4G backup up to 1GB/month.
Rob
> No need to use UCSD. Cloud based server(s) work just fine. Places like
> AWS drip with bandwidth.
Is AWS able to run an IPIP gateway? I am currently trying to migrate an IPIP gateway
from the "Hosted Raspberry Pi" that it is now to a VM that is being offered as a replacement,
but it turns out that the "Apache Cloudstack" that this (and apparently many other) hoster
uses to deploy VMs is unable to pass other network traffic than TCP and UDP.
(and replies to outgoing traffic)
Good enough for OpenVPN and will probably work with IPsec and other VPN protocols, but not
suitable for an IPIP gateway that also accepts incoming traffic.
I am now looking for a solution. Of course I can make a VPN to our gateway, but this
system was a test environment for an IPIP gateway. When IPIP goes away, I no longer need it.
However, I could also use it to draft an example of how to setup a VPN service on a Linux machine.
Rob
> You can also host it in vultr. I would have to check, but IPIP should
not be a problem there and it costs indeed about 5$ per month
Toussaint TK1BI is also using that, isn't it? It seems one can even
advertise BGP space there.
I see they also host in Amsterdam. In fact, when we would deploy a VPN
server in all 16 datacenters
they offer we already would have covered most of the world. But that is
another topic, this query
is mainly intended for my personal colocation server.
(it serves my mail, my website, an IPIP gateway for testing, and an
echolink proxy server for testing)
Rob
> No it is not possible with my ISP. To run any local services is a
> violation of the ToS agreement. The ports and services they close they
> will not open. I've tried. They also incorporate a watchdog on all
> sockets that destroys them after so many minutes of "birth". This kills
> client services such as VPN, SSH, etc. Web services often aren't
> affected since most web elements are downloaded within 300 seconds +/-.
I would go away. How do you get IPIP working over that? Probably not
working correctly either.
> IMHO the dependency is a moot issue. If I used your VPN I'd be dependent
> on you... but you're suggesting that you can still reach me if my ISP's
> edge router dies and this is not true. Also if I were on your VPN, I
> would have to travel all the way to the netherlands and back half way
> across the US to reach say Indiana. So very inefficient.
I don't suggest that you would use only our VPN server, you could
connect it in addition to some other to have additional redundancy
and maybe a more efficient path to western europe.
You (or ARDC, using their money) should eastablish one or more VPN
servers on the eastcoast and/or Canada, then you connect there and
those servers connect back to UCSD or maybe even advertise some of
the locally assigned subnets on internet BGP.
Then it will improve your connectivity to internet, and connectivity
to other AMPRnet systems is the same or similar.
Furthermore, you can buy a 4G router and use that as a backup for when
your ISP link or -router dies, and you can switchover all your routing
to that path automatically within seconds. Even when its address is
dynamic and probably even when they have such idiotic policies as your
ISP appears to have (because the VPN will just re-establish when it fails).
Rob
Now that the space isn't legacy we can begin to use ARIN services.
Delegated RPKI definitely needs to happen. What about SWIP?
Looking forward to helping anyway I can. I believe most of the lift for
RPKI would be for the portal programmer.
Regards,
Scott. ki4cuw
> I don't think BGP has a problem working over IPIP tunnels. In the end it is just a TCP connection to one or mre endpoints.
In principle yes, but unfortunately the current IPIP tunnel implementation
handles both the tunnel establishment and the routing. The routing is
static. You cannot setup BGP sessions because you do not know the other
side's address and AS.
Possibly one could work around that by adding the 44net endpoint address
and the BGP AS number of each tunnel gateway, so the endpoints could
connect eachother for the BGP routing.
However that would be another major change and I'm not sure everyone
would want to BGP peer with everyone else. That could also introduce
new scaling problems.
Rob
> Oh, I misunderstood maybe. I considered that the Israelian BGP subnet will be announced from the VPN Server’s ASN. It will not go to UCSD and traffic to it will not come via UCSD.
> Having UCSD in the middle for non-North America is 200+ ms bonus per packet, so most people want to avoid it.
He repeatedly indicates that it his beyond his capabilities to arrange
such things. However, once we have a flexible overlay network in place,
he could connect to some more nearby gateway and try to get it arranged
that this gateway also announces the Israelian subnet. Then he has a
shorter roundtrip to internet without having to set it up himself.
> What I would do is the following:
>
> Ask the IP space owner (person allocated to) to send an e-mail to
Brian, requesting the block to be advertised over BGP (needs to be /24+,
or collection of networks /24+) and Cc me in this e-mail. I reply with
the ASN, route objects that need to be created, etc. Brian hopefully
approves the request.
>
> Afterwards, I advertise the /24 via BGP to the Internet.
>
> Then, I arrange with the IP space owner how the space will be router
to them. I can support OpenVPN, PPTP, L2TP, GRE, IPSec, etc.
I think he means "after I connect to a VPN server in the USA or e.g. in
Greece, how do I make it send the traffic for my Israelian subnet to me
over that connection".
That is by far not that complicated.
He only needs to connect to that VPN server, he will get an IP from the
address space of that server, and setup BGP over that connection (using
an agreed-upon private AS number) and announce his own Israelian subnet.
The BGP protocol will then exchange this information with all other
interconnected VPN servers and they will all route his subnet to the VPN
server he is connected to, and that will route it to him.
Traffic from internet will still be routed to UCSD as part of the
default network announcement, and the router there will first route it
to the VPN server he is connected to, then to him. No need to announce
his /24 on internet explicitly!
Of course this gets more difficult when the IPIP mesh is kept in place
and is used as backbone.
Then the VPN gateway he connects to needs to add his subnet to its list
of handled subnets, via the portal.
This means he can connect only to a single VPN server and have working
routing.
When that server goes down, he would have to arrange that the portal
information is changed, the subnet being removed from that gateway and
added to another.
Without IPIP, he could simply connect to two or more VPN servers at the
same time, and as long as one of them is working he has connectivity to
everywhere.
Rob
> How do i manage to get my allocated addresses from someone else VPN ?
> what about transferring a whole network block via a VPN server ? specially to a home which uses a dynamic IP ?
That is why the proposal is not so simply use a VPN, but to use a VPN and run BGP on top of that.
The transfer of your network block to the VPN is handled by BGP.
The internet address of the home VPN does not matter, you connect to a VPN server and present some ID (e.g. callsign and password)
and the VPN server knows who you are.
Those topics precisely are the improvements in the proposed system, over the existing IPIP system.
Rob
> For example, I am able and willing to provide such service, however there hasn’t been any place I can really publish that information.
I think this is a generic topic that could be one of the first things to solve within the AMPRnet.
When we get new users, we immediately get the question "now that I am connected, what can I do?".
Such a VPN server comes before that, but it is another case of information lookup.
We could construct some website within AMPRnet where you can look for such information.
What interesting websites are there to visit, who is offering SIP telephony, etc.
Of course it can be done in a Wiki (it already exists), but such information quickly gets outdated.
People post their new services, then they lose interest and the services stop working, but never
update the information anymore.
Also, access to the Wiki is often problematic: when open to everyone it will have to be monitored
and corrected when things go wrong, when access control is used it adds the burden of creating and
maintaining trusted user accounts and it is a hurdle for registering services.
So we could come up with some way to keep such a services database with some form of automated
maintenance. E.g. a user who wants to have his services in the database somehow creates a
description in a standard format on some standard URL and submit this once to the central
system, which then regularly queries this file and adds info to the listings, plus it automatically
drops it when it cannot retrieve the data for some time.
It should be easy to add information, but still it should be in a standard format so it can
easily be shown in tables.
Of course there already is HamnetDB but it is focused mainly on the network layer.
Something similar could be made for services, plus it should guard against outdated information
as mentioned before (HamnetDB also suffers from that problem)
The wellknown WebSDR site "websdr.org" has an example of what I mean. The list of SDRs shown
there is always actual. The sysop of the SDR puts its information in the configuration, and
the running SDR sends it to the central system automatically (unless you turn that off).
Rob
> >Again, while there are over 500 gateways in the current network with
tunnels
> >between all of them, there is no way they are all going to be in use.
>
> It doesn't matter how many are in use. If my ampr routing table has
50 or 500 or 5000 routes, who cares?
That is true for the Linux or JNOS situation. However, people want to
use the equipment they have available,
and on many other systems there has to be a separate virtual interface
for every tunnel. Scripts exist for
e.g. MikroTik and Cisco routers that manage this, but they have to
create a large number of tunnel interfaces
and they hit limits of NVRAM size and others.
With 5000 endpoints there will certainly be issues!
> >Wiring them up for everyone really makes no sense, and introduces a
scalability
> >problem that would become real when it were easier to use the system
and we had like
> >50000 participants instead of 500.
>
> Do you have evidence for your statements?
Yes. See above. I also once tried to use a left-over Cisco router and
its NVRAM already was too small for this.
> https://qrznow.com/us-amateur-radio-population-grows-slightly-in-2018/
> It looks like from 2014 to 2018, the US ham population only grew 4%.
> And I haven't monitored it closely. But it seems to me that the size
of amprnet has remained about the same (+/- 100 or so) for the last 10
years.
> So who/where are these 49,500 other gateways?
They probably are either not interested, or they are unable to overcome
the problems setting up an IPIP gateway.
When we introduced the easier OpenVPN connection method here, there was
a flurry of requests for certificates
and there now are 200 certificates active. And that is only for one
small country.
Rob
The sale of 44.192.0.0/10 took most of us by surprise and for some it
somehow feels like a coup. Here are a few thoughts I have had, since the
announcement:
1) ARDC (Amateur Radio Digital Communications), is a California
Nonprofit Public Benefit Corporation and has existed since the 11th of
October 2011. ARDC has had control/ownership of 44.0.0.0/8 that whole
time. This corporation allows for continuity of control vs. a single
person being the designated "owner" of the address space. This is a good
thing. (E.g. there is no probate should the “owner” die intestate.)
a) Brian Kantor did the work and paid the expenses to move control from
himself as an individual to the non-profit organization. To my
understanding, he is the President and CEO, who under the direction of the
Board of Directors manages the day-to-day operations of the ARDC
i) Of note: Brian did ask for donations to offset these expenses which
were largely ignored.
2) There are no “voting members” in the corporation, nor according to
the by-laws <https://www.ampr.org/wp-content/uploads/Bylaws-2019-03-03.pdf>
are there any procedures for voting beyond those afforded the Board of
Directors. As such, there was no requirement to get approval from anyone
outside of the Board of Directors.
3) There are no “shareholders” to be consulted in the transaction.
4) Since no individual or individuals can claim to have property rights
to the address space beyond the ARDC, nothing was stolen.
5) Negotiations for the purchase and sale of tangible assets often
require a certain degree of privacy. Public disclosure is a two-edged
sword, it can help or hurt the interests of the seller and/or buyer.
6) As reported in communications from the Board, some non-disclosures
were required for the transaction, among them the price and buyer identity.
a) The controlling entity can be discovered easily using *whois
44.192.0.0/10 <http://44.192.0.0/10>*
b) Based on known market values, this transaction likely produced the
mid to high tens of millions of dollars for the ARDC.
i) Splitting the address space further actually would provide less
value to the buyer and less money to the seller. Based on estimates given
me by a buyer, the collection of 65 thousand /24 in a /8 would only return
65% of the price of the entire /8.
7) The proceeds are going to be used to further Amateur Radio,
specifically through grants, scholarships, and funded studies. Which would
not exist without this action. If administered properly, this will be a
monumental boon to Amateur Radio.
a) I know some of the board members, and of those whom I know I am
confident they will manage this process well and honorably.
i) That doesn’t mean their decisions will be universally accepted.
ii) I have served on the technical advisory committee for ARDC for years
and if asked will help with review of applications.
b) To this point I am not aware of any officer, board member, or
committee member receiving compensation for their work. They are
volunteers.
8) 75% of the /8 address space was retained and only one block out of
the 44.192.0.0/10 had been allocated. See
https://portal.ampr.org/networks.php
a) Of the remaining 12 million addresses, less than half have been
allocated, and a tiny fraction are actually in use.
b) Even though I and others have advocated for more utilization of the
address space and provided tools, tutorials, etc. this address space has
been sorely underutilized.
9) As others have mentioned, this is an excellent time to reexamine the
structure of the network and modernize it.
a) Deprecate the IPIP tunnel mesh
b) Update firewall rules, replacing 44.0.0.0/8 with similar rules for
44.0.0.0/9 and 44.128.0.0/10
c) Adopt BGP and VPNs (or similar strategies) for interconnection and
routing.
d) Develop better management tools (e.g. money allows hiring out
improvements to things like http://portal.ampr.org) including DNS/rDNS
delegation.
10) There were some operational issues overnight such as reverse DNS.
Major ones have already been resolved and the others can be worked
through. No matter how well planned, these things can happen.
11) This will not be reversed. One can involve oneself in second guessing
and fighting it or one can step up and help ARDC come up with appropriate
processes to provide a perpetual fund for Amateur Radio research,
education, and outreach.
tl;dr – It’s a done deal, work with it. Become active and take the
initiative to improve the network.
--
John D. Hays
Kingston, WA
K7VE
/> From my point of view, any interconnection technology that requires /> going through a third point (e.g. external OpenVPN server) likely won't
> fly with me. Odds are that any such interconneciton is going to be a
> long way from here and add unacceptable latency. Ideally, where direct
> connections are possible, a mesh topology, like the current IPIP mesh is
> what I'd like to see, regardless of underlying technology.
There is no reason why you cannot have some VPN servers in datacenters in Australia,
and connect them to the system and interconnect them in a mesh fashion.
Then everyone can connect to their closest server and you have fast local
connectivity, combined with ease of access. When, in addition, you arrange
for the subnets involved to be BGP announced on internet, you will have fast
internet connectivity as well, without a roundtrip via UCSD.
While this is already possible with the current system, it is much more complicated
to implement it and it can only be done on a select number of router types.
> Obviously,
> there will be corner cases, such as endpoints stuck behind CGNAT, which
> may require a relay point external to them. For me, I'd rather beat my
> router into submission and get that direct connection (like I have with
> IPIP). ;)
As several people have written, may users are not network architects and have
limited knowledge about networking. And there may be many more who are interested
in joining the network but have been unable to do so, because of lack of knowledge
and/or lack of a suitable internet connection.
Making the system easier to access may get us many more participants and after
that we may ask ourselves "why did we live with that complicated IPIP system
for so long"?
Here in the Netherlands, there are 16 registered IPIP gateways (some of them are
not actually operational), and 36 active VPN connections with BGP. Plus at this
time there are 14 active OpenVPN connections (endpoints not using BGP) out of
220 registered accounts for that. So 50 "new technology" connections vs at most
16 old IPIP connections. That should be clear.
There used to be more active connections, it is on a decrease again. Probably
after some time the users start asking "what is the benefit of being on this
network, what service is it offering that I don't have on plain internet".
That is something we should be working on as well.
Rob
> But you also say "There is no need for a portal that registers the
subnets,
> they only need to be configured
> in the gateway routers."
>
> I haven't seen a technical write-up of what you propose. But the
statement
> above tells me that those who aren't interested in the putting up
with the
> new problems the overlay hubs would create have lost the simplicity
we have
> now.
The routing of the subnets is not something the user would have to
manage, that
is what BGP does automatically. There is no need to register them.
Every gateway tells its neighbors what subnets it has locally, and this
information
is passed around the entire overlay network.
> It's easy enough to say things like "you can set up crosslinks to
wherever
> you like". But without the central registry, we lose the simplicity
we have
> today. Today, we download a file and run a script. Done. Direct
> connections to everyone else. No middle men. No added latency. No
added
> complexity. No added troubleshooting difficulty. No added dependence on
> some volunteer at the hub who may or may not be available when needed.
As I wrote, to have that it would require an additional protocol like
Cisco DMVPN
which unfortunately is proprietary and not available in most (if not
all) of the
inexpensive routers that radio operators want to use.
> Now if your proposal included the following, it would truly be solving a
> problem for some people with causing a problem for others:
>
> 1) For folks who can't support direct connections, let them use a VPN
> connection to a hub of their choosing (as you appear to be proposing)
>
> 2) *** BUT *** leave the central registry in place, and augment it so
that
> when you sign up for a hub, your subnets are still published to all other
> gateways as reachable through the hub.
>
> 3) Therefore, those who can support direct connects but are not a hub can
> still see a full registry and automatically create direct
links/tunnels to
> all other gateways (whether they are individual gateways or hub gateways)
> and routes to all subnets behind all other gateways.
I think the minor problem of "now some paths are two hops while they would
have been direct in the current system" is very minor compared to the many
issues there are with the current system. When we want a system that anyone
can easily connect to without being a network export, the system I propose
provides that. When you do not want that, because it takes away the
artificial
hurdles "that everyone has to overcome", of course you could object to such
changes. It is similar to the situation of no-code licenses. People who
already
had passed the CW exam were objected to removing the requirement for new
licensees, with similar reasoning.
Again, while there are over 500 gateways in the current network with tunnels
between all of them, there is no way they are all going to be in use.
Wiring
them up for everyone really makes no sense, and introduces a scalability
problem
that would become real when it were easier to use the system and we had like
50000 participants instead of 500.
A system with regional hubs, while still offering the capability to
cross-connect,
is much more extensible.
Cross-connects require manual intervention because the situation has to be
examined. As the new system does not require the IP address of the
participants
to be static, allows them to be behind NAT, behind a firewall, etc, it
has to be
decided what type of connection is made, which direction the connection
is made,
etc. E.g. when one of the two has a static address and the other one
dynamic,
it is best to connect from the dynamic to the static address (and
re-make the
connection when the dynamic address changes). When they are behind NAT,
it is possible to use a VPN that can cross NAT.
Right now, such stations simply cannot participate, and with a new
system they can.
Rob
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
In light of the recent theft from amateur radio, I cannot continue to be part
of ARDC. I was a technical committee member for several years, at least since
2014 or so, and while the TAC members wished to accomplish much, not much
happened.
I will give credit for reverse DNS as we worked to get that delegated to BGP
operators properly, and my allocation at 44.98.254.0/24 was the first subnet
to have it working. I've recently asked about RPKI, DNSSEC, and even made
some noise regarding SWIP.
In every talk I've given I've mentioned the resource amateur radio has in 44/8
and how very special it is. Protect the IP space and use it, just as get on
and use the bands to protect them.
Understand this is likely 50M+ USD for this space paid to ARDC, and has
exposed 44net to ARIN control. RDNS seems to have been broken as well.
I call for a full public accounting of these monies, and outside public audit
of ARDC. Brian Kantor must resign and we must demand a clear ethics policy
with self-inurement and cross dealing between organizations prohibited.
Best 73s and it was a pleasure helping the community where I could.
- --
Bryan Fields, W9CR
Former ARDC TAC member
727-409-1194 - Voice
http://bryanfields.net
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xQu4ACgkQYTmgYVLG
kUDRkhAAqpST8VkCAyipaj496C0bO3wjArJKvIookeQYOAqGqYl2wtHxC6zWBEeG
zYfolJ4zVOku91RRIP2x/PtTdWLJ8PSpWNVxLWDcb8ofVZ7p8aRTsqCx0nWko18c
HKE6FJ1Qfp+NmTeOWrBc7/CWd/7FPJseTVA5oOq9L4VOTrdXUF0DuvzNpcGTihST
XO2Mnv0A5a5+5ih+5yeus/mgmmbwSSB9jBQQbZ/wBWLq+wPLnd6rBjBVsZrsOY1G
Kr88enrMbrK78h7+9OCM+o19Dz5rItNxXz87o8UfeqNHMldYqMMhXWiMjFjWvvNJ
phILyuvjElkh+fgoqJ+tdXyavnteuVJm0lpOKEsNpgpKkw+QQw4QwsJxoAIY9j85
gSa9v1BIwhx+H7r8K2vl/GMdbd81G8fBgVi5c55czIa52LqlX6uAyIm9/iQWiEdA
Ob06JxCvszc+DEuRE5xdonN4NpUqIMOPmrz7FB6gigN2u43J8eIt0NdwjaRfIY0c
MLd0g4F/9LaGSCo+cDvDhfghYyVJL8yj74RMggiIkJXUDcrLZxlp7o61nXEmPOhS
2zY3yDe485fDvcdr40uDINDt05oBwK1PjEf6ZO02LuO4c6DPVifBGO1gPc3Fovzr
+C95bM5SPoeyPC8WWZEHJIG/75n1R5yUYFfHWo49KLGngqioGYo=
=0LLk
-----END PGP SIGNATURE-----
> Then, the question becomes :
> - Is it better to keep full mesh / standalone endpoints (such as current
> IP-IP) ? But if so, how to handle Plug and Play and NAT traversal ?
> - Or is it better to have small local gateways managed by skilled teams,
> and end-users connecting to those gateways with simpler PnP VPN systems ?
>
> We choosed the second option, with fully home-made design (OpenWRT,
> OpenVPN, OSPF), because it best suited our needs, and because we are an
> island, with few inter-connects with the rest of the world.
Same thing here. We are not an island but still we feel that we need to
use a
local gateway where everyone is connected using modern technologies
compatible
with today's internet connections and equipment. Our gateway is still
connected to
the IPIP mesh but the individual stations are connected using another
VPN type.
> It seems lots of people in the world are using similar designs, with a
> central gateway and enpoints connecting to it via VPNs. Maybe we just
> have to share our experiences, and adopt some kind of "standardized"
> rules for our gateways ?
That is what I am trying to do... and reduce their compexity by
dropping the
old IPIP mesh and use some newer technologies that are available in standard
routers, so it will become easier to setup a gateway.
Rob
Hello all,
I've not been active here, but some of you may remember me as the guy
who first got TCP/IP going on amateur packet radio way back in 1986. At
one time, my name was registered as the owner of the block. This makes
me one of a VERY small group of people with any arguable personal
property interest in network 44. And yes, 25% of this space, which is
VERY unlikely to ever be used by hams, has been sold to Amazon.
Rather than try to personally profit from this, we all readily agreed to
place the *entire* proceeds of this sale into a 501(c)(3) charity
chartered to support amateur digital radio and related developments. No
one is buying a yacht or a mansion. As a tax-exempt charity, our tax
returns and related documents will be publicly available so you can see
what is being done. Like the rest of the amateur community, all of you
will have the opportunity to apply for grants and do good things for
amateur radio with them.
73, Phil
> Please consider using part of the money for reserving us (buying ?) IPV6 address for future use ..
I think there is quite universal agreement that we should not buy/reserve special IPv6 addresses as
a group but rather everyone should obtain addresses from their own local internet provider and we
should arrange some way to distribute the list of IP addresses in use amongst the participants.
This makes it unnecessary to use a tunneling system which simplifies the network and makes the
routing much faster (no need to go via UCSD anymore!).
And these addresses are normally included with your internet service for free.
Rob
> I'll +1 your comments and raise you with this:
>
> As President and engineer of EastNet, let me go over some bullet points
> for those especially NOT in our country or region.
>
> o The average age of those sysops on EastNet is 70+
> o They grew up without technology and are most happy to remain ignorant
> about it
> o BGP, IPIP, GRE are initial groupings they could care less about.
> o Many of these guys can't even type in a URL without their hands held.
> o Virtual Private Network to them sounds like the evil doings of the
> dark web and they want nothing to do with it.
> o If it's not standard equipment from my ISP it must be against my
> contract with them.
> o If HRO doesn't sell a pre-made appliance to plug in and use for
> this amprnet thing then it can't be any good or work.
Do you really think that the abundancy of elderly users in the amateur radio
community is to be used as a reason not to change anything anymore until
they all are dead?
Should there be no development anymore just because these people cannot
learn?
Should we all stand still just because of that?
Don't you think that the scarce newcomers we have (and need) will be
running away
in laughter when they see such statements being made??
> I could go on but I'll stop right there. As Charles tried to mention,
> just because a very small percentage of hams are familiar with amateur
> IP or amateur wired internet that doesn't mean the bulk of hams are or
> that they even wish to learn. Most still immediately think IP = wired
> only period and that's not what they took a license test for... and they
> find it to actually be offensive in regards to amateur RADIO. If it's
> not HF Contesting, it's not "ham radio" it's wire and they don't need
> nor want to learn about this... but they do wish to offer the services.
I am in no way proposing that any radio amateur is to be joining the
AMPRnet!
When they are happy working in CW on HF, or to be contesting, just let
them do
it! The AMPRnet is for those interested in networking and when they ar not
interested in amateur IP there is no need for them to become familiar
with it.
> The current IPIP mesh network does indeed work... I suppose if it works
> don't fix it no longer applies? I'm on it and the fact you see this
> mail is a PoC it works.
That is a very narrowminded view. The fact that you could make it work
does not
mean that it works for everyone. We sometimes see the struggles here when
people try to join, and I can tell you that joining the system I propose
(and that
we have had running here for several years, and is running in some other
regions as well) is much easier to join.
There is NO NEED anymore to fiddle with ISP routers to make forwardings or
DMZ settings, NO NEED to install specialized software on routers or systems,
just buy a suitable router (e.g. the MikroTik hEX, list price $59,95, or
even smaller
and cheaper models), apply some simple configuration steps that can be
written
up in a document, and you are online.
And you can make a wireless connection to a friend or to some local
access point
and the routing will be fully automatic. Traffic to your friend will be
over your
link and other traffic will be via the internet.
As an example of what you need to connect this way, this is an example
of all
configuration required in such a router to connect (an actual export of
a router):
/interface l2tp-client
add allow=mschap2 connect-to=213.222.29.196 disabled=no ipsec-secret=\
HAMNET-L2TP max-mru=1400 max-mtu=1400 name=l2tp-241 password=12345678 \
profile=default use-ipsec=yes user=l2tp-pd2ebh
/routing bgp instance
set default as=4220401109 router-id=44.137.11.158
/routing bgp network
add network=44.137.11.144/28
/routing bgp peer
add in-filter=hamnet-in name=gw-44-137 nexthop-choice=force-self
out-filter=\
hamnet-out remote-address=44.137.61.254 remote-as=4220406100 ttl=1 \
update-source=l2tp-241
/routing filter
add bgp-communities=44137:10050 chain=hamnet-in set-bgp-local-pref=50
add bgp-communities=44137:10200 chain=hamnet-in set-bgp-weight=200
add action=accept chain=hamnet-in prefix=44.0.0.0/8 prefix-length=8-32
add action=accept bgp-as-path=4220406100 chain=hamnet-in prefix=0.0.0.0/0
add action=discard chain=hamnet-in
add action=accept chain=hamnet-out prefix=44.0.0.0/8 prefix-length=8-32
add action=accept bgp-as-path=4220406100 chain=hamnet-out prefix=0.0.0.0/0
add action=discard chain=hamnet-out
That is all! With this configuration, that user connects to our VPN
server with L2TP/IPsec
which passes NAT and can be on a dynamic address, advertises the local
network and
receives the routes. This can be copied to another user and just be
modified for the
different user,password,AS number, router ID and local network.
This is the text version of the configuration, it can be modified in a
GUI when desired.
Sure you can keep saying "but my 70+ years old users don't understand it
and they have
their JNOS box running IPIP so they don't want to change that" but do
you really think this
can be used as a reason to keep everything the same and not to allow
others to join much
more easily?
That is like saying the new hams should learn CW because the old ones
also did, and
the new digital modes (e.g. FT-8) are evil because the CW operators
don't understand them.
Rob
> As far as we are thinking about possible evolutions, we can also add new
> criteria. Ability to change link "weight" according to link quality (or
> other parameters) may be an intesring thing.
Well, as soon as something is changed in the protocol you lose the big advantage of
running standard protocols available in standard firmware, see the AMPR RIP thing.
> I don't know if BGP has some "weight" parameter. OSPF has. It can not
> change the weight dynamically, but it's possible to change that weight
> by an external script. That's nice, and that's the reason why we choose
> OSPF for our "internal" network.
I have considered doing similar things in BGP (adjusting prepend or local-pref
dynamically based on SNMP monitoring of the link).
We have not experimented with OSPF yet, I read in many places that it has problems
with scaling when the CPU power on routers is limited (like on old RB750s)
Rob
Now that we are all going to have to dive into our router
configurations, wouldn't it be a
good time to make some changes that are long overdue?
Like getting rid of the IPIP mesh and replace it with something more
modern and supported
by off-the-shelf routers, works behind NAT, etc?
I would say setup some routers with VPN of different types around the
world, have everyone
connect to there using a suitable VPN protocol, run BGP on it to
announce the gateway subnets.
A $50 MikroTik can do those jobs, for those that still want to run a
JNOS system on MS-DOS
they can put one in front of their box and still use it. People are
already using it for IPIP mesh,
a change in topology would be only a config change for them. And other
routers mentioned
here can do it too, without having to get external programs installed on
them.
Those that want direct connection without a centralized system in the
path can simply setup
a VPN connection between them and configure the BGP peers, it will
automatically work.
There is no need to use only a single protocol in such a network, only
the peers have to agree,
so you can select from anything like L2TP/IPsec, OpenVPN, Wireguard,
just plain GRE or even IPIP,
etc etc. Just at this time I am trying to move my colocated machine
that runs as an IPIP mesh
member and I face that stupid "protocol 4 is not passed by the firewall"
problem again. Arghh!!
Also we could get that IPv6 idea going. Remember it has been discussed
many times and the
only things we still need is some agreement on how to register and
distribute the "list of AMPRnet
prefixes in IPv6 space". Again that could be done using BGP, no need to
setup yet another
registration portal with downloadable files.
Note that Daniel EA4GPZ put some ideas around IPv6 on his site:
https://destevez.net/ipv6-for-amateur-radio/
Rob
> I saw that. Messages are readable on Android, but appears blank in Thunderbird. When we answer, the answer remains blank (but the text is readable in the message source)
> Will check...
Mail isn't what it used to be. Programs like Thunderbird auto-decide whether to send the mail in text
or HTML, and somewhere along there are linebreaks inserted in the messages that I do not insert myself
and that do not appear in my Sent folder, which fouls up the layout. I see that with some other
people's messages as well, so the fault may be in the mailing list software.
The funny thing is that sometimes when my messages, that appear broken when posted, get quoted by
other people they suddenly are OK.
It is now completely unclear to me whether I am supposed to breakup paragraphs by line or to type
everything on a single line. Both ways things are getting fouled up.
Rob
W.r.t. the issue of /64 or smaller addresses, my plan is as follows:
- we have a /16 network within AMPRnet (44.137.0.0/16)
- it is very easy to get a /48 network in IPv6 (every home customer at
my ISP gets one of them, I have one as well. it would be easy to get
a /48 assigned to our gateway where 44.137.0.0/16 is BGP routed now
- I want to make a 1:1 mapping of every assigned address in our IPv4
subnet to a /16 network within that /48 space.
E.g. when we get 1234:5678:abcd::/48 from our ISP, I would map
44.137.0.1 to 1234:5678:abcd:0001::/64, up to 44.137.255.255 mapped
to 1234:5678:abcd:ffff::/64
- This means every single address allocated in IPv4 gets a /64 subnet
in IPv6, any /28 in IPv4 (common subnet size for hams) gets a /60
subnet, etc.
This way, standard practices for using IPv6 addresss can be used, and
the proposal of Daniel EA4GPZ can be followed to encode the callsign and
service in the lower 64 address bits as desired (for convenience only).
We would "just" have to add IPv6 addresses to all routers in our network,
but it can be done in an almost automated way because the IPv6 addresses
and subnets can be calculated from the IPv4 addresses already configured
using a simple tool.
Of course it still requires quite some work, and causes double maintenance
on things like firewalls and routing filters, so I have not done it yet.
But it sure would be possible.
Rob
> > - I want to make a 1:1 mapping of every assigned address in our IPv4
> > subnet to a /16 network within that /48 space.
> > E.g. when we get 1234:5678:abcd::/48 from our ISP, I would map
> > 44.137.0.1 to 1234:5678:abcd:0001::/64, up to 44.137.255.255 mapped
> > to 1234:5678:abcd:ffff::/64
> I'm a bit lost at what you're suggesting, and the practical way it would
> be implemented. At first glance, this looks like a recipe for
> suboptimal routing to the outside world.
The above is an idea how to add IPv6 addresses to the 44.137.0.0/16
network that
is BGP connected in a datacenter and where users are connected via VPN
and radio
paths. The added IPv6 addresses would be from the datacenter space and
would be
routed along the same paths as the 44.137 traffic. Of course that is
suboptimal, but
it works for users that do not have IPv6 themselves.
> I have 2 AMPRnet IPv4 allocations - one BGP connected, one IPIP
> connected. Both sites have IPv6 available. Here, where the IPIP mesh
> terminates has a /56. I currently have a /64 on the VPS, but as there's
> only one host, it wouldn't be difficult to carve that into AMPRnet and
> non AMPRnet parts, because IPs are assigned by hand and are all on the
> same interface.
In my opinion it is not a good idea to deploy a system based on
splitting a /64 net
in smaller subnets. You could do that locally, but you would not want
to give other
local users an IPv6 network that is smaller than a /64. This is going
to cause all kinds
of difficulties. That is why my intention is to give every user at
least a /64.
Rob
> > Setting up BGP on a MikroTik is much much much easier than getting
> > IPIP mesh to run on anything!
> I see an opportunity here to learn BGP. I'm for this idea.
I posted an example configuration above. Of course this is not the same
as "learn BGP", but
I think many users of the current IPIP mesh also did not "learn IPIP"
and "learn RIP" but only
copied an example configuration and fiddled with it until it worked.
Of course when you want to setup a regional VPN server you need some
configuration for that
as well, but when such a system would be deployed of course examples for
that can be
given as well.
BGP for such a small closed network is not that complicated. Basically
every system maintains
a TCP connection (port 179) with all its peers, and it sends the
networks that it can route.
It receives the same information from the other side, and fills the
route table. The active
route is selected on a couple of criteria, where the least number of
hops is usually preferred.
It is possible to send tags along each route (called bgp-communities)
that can be used to
prefer certain routes over others, e.g. to prefer routes over radio when
both a radio and a
VPN path exist.
There are some issues with BGP, e.g. the total lack of security in the
protocol. Anyone can claim
that they have a subnet and all the others will happily route all
traffic for that subnet to them.
The routing filters are an attempt to work around the most severe
problems, but as can be seen
on the internet (which also uses BGP) it is difficult to make it
completely failsafe.
Also, in our world it is a bit of a nuisance that there is no way to
incorporate some form of
dynamically determined link quality in the routing decision. Links are
either up or down. But for
this proposed use (replacement of the IPIP mesh) that is not a problem,
it mainly affects the
use of BGP on the radio links in our network.
Rob
> First thought would be that BGP is too difficult for 90% of the HAM operators.
Setting up BGP on a MikroTik is much much much easier than getting IPIP mesh to run on anything!
Rob
Amateur Radio Digital Communications [ARDC] is a United States
charitable 501(c)(3) nonprofit public benefit corporation that has
long owned and managed the Internet address space known as the
AMPRNet.
Nearly 40 years ago, early in the evolution of the Internet, this
address allocation was acquired to be used for the mutual benefit
of Amateur Radio and digital communications technology.
Amateur Radio operators ("hams") use the global radio spectrum set
aside for them by international treaty in non-commercial ways to
improve engineering, research, experimentation, training, education,
and emergency communications. Having the AMPRNet available over
the past four decades has facilitated integration of the Internet
with radio-based technologies long used by hams. This long term
interaction has been key to development of now ubiquitous wireless
technology such as WiFi and the ability to browse the Internet or
to stream various media to your mobile phone.
Over those past decades, a portion of the AMPRNet IPv4 address space
has rarely been used, and recent utilization surveys show that it
is not likely to ever be needed by hams.
Initially free, IPv4 Internet addresses are now highly valuable,
and there is an international marketplace in which to sell them.
ARDC has sold some of its unused and unneeded address space, but
retains a more than ample supply of IPv4 addresses for current and
future use by the many Amateur Radio operators worldwide. The sale
amounts to some millions of dollars, which will be used in the
furtherance of ARDC's continuing public benefit purpose.
Before the sale, the AMPRNet consisted of the addresses 44.0.0.0
through 44.255.255.255 (in Internet notation, 44.0.0.0/8). Post-sale,
it consists of addresses 44.0.0.0 through 44.191.255.255 (44.0.0.0/9
plus 44.128.0.0/10). The uppermost 1/4 of the former AMPRNet address
space (44.192.0.0/10) has been withdrawn from ham radio use and
sold to another owner, however over 12 million IPv4 addresses remain
for amateur radio use.
ARDC will use the proceeds of this address sale to further its
mission to support, promote, and enhance Amateur Radio, digital
communications, and broader communication science and technology
by funding grants and scholarships for scientific research,
experimentation, education, open access, and innovation in information
and communications technology, with an emphasis on benefiting the
international Amateur Radio service.
For further information, please see <https://www.ampr.org/amprnet/>.
Best wishes and 73,
The ARDC Board of Directors
> The IPIP mesh may be non-standard, but it is distributed, without any single point of failure. To get between two points, the two gateways have to have IP connectivity to each other. That's it. The two end-points can troubleshoot directly.
> But every proposal I've seen on this list involves adding at least two other ham points of failure. For example, I would presumably connect to some other ham's BGP node and the other end of the connection would do the same. Why?
Mainly because it makes it an "outgoing" connection for most people.
That means it is not affected by NAT, CGNAT, dynamic addresses, inflexible router firewalls, etc.
Getting IPIP to work bidirectionally often requires to setup the internal system as "DMZ" (which in home router speak means that it will receive all incoming traffic not matched by the NAT engine).
This can only be done for a single system, and even then it often does not work correctly (e.g. it receives only TCP/UDP and not other protocols).
You should not under-estimate the difficulty that IPIP is causing for more and more people.
As an example, I am currently trying to migrate my physical colocation server to a VM. The service offered by the hosting company uses Apache Cloudstack.
While the VM itself works fine and can load the ipip module, it turns out that Cloudstack cannot allow IPIP ingress in its firewall settings.
So I will have to look for another hosting option...
By putting VPN servers in datacenters and having the users connect to them, you avoid those problems.
Also, using the topology I propose, there is no requirement that the entire network runs a single tunneling protocol or a single topology.
Only the peers need to support the same protocol. And it can be a symmetric protocol like IPIP or GRE when you like that better.
Also, there is no requirement that there only be a single connection! You can setup crosslinks to wherever you like.
There will rarely be traffic to all IPIP mesh peers. There are more than 500 gateways in the list, and when I look in our stats I see we have had traffic to only 23 of them in the past day.
Most active gateways can probably point out at most 5 peers to which they have regular traffic. You can setup crosslinks to those.
And this system is not dependent on a central RIP sender! Every node is active in distributing its own subnets and receiving the others.
There is no need for a portal that registers the subnets, they only need to be configured in the gateway routers.
A portal could still be useful as a management system for VPN accounts. Especially at the major hubs, the users need to have a VPN account that assigns them a point-to-point address, and the BGP on that router needs to be configured with the AS number on that address. This could be done using some form of portal and a program that configures the router using its API.
That is not mandatory. On our gateway the addition of new users still is done manually. I once have added a large number of skeleton BGP peers and VPN accounts, and when a new user requests a connection I find an available one, enter the username (callsign), a random password, and enable it. In the BGP peer I enter the AS number and enbale it. Done.
There always will be some dependencies, but they do not need to be single-point and with some money available they do not need to be only relying on volunteers and unclear situations where some company hosts a service only because a worker there has arranged it.
I think it has big advantages over the system we have now.
Rob
Well, I think there are enough examples of how to do it (also already
doing it within AMPRnet),
lots of people who can contribute knowledge and will volunteer to help,
the only thing we lack
here in this group is someone (with the appropriate authority) who says
"Lets' do that!" and
gets everyone moving.
That is why these discussions usually go on for a couple of days here,
then die out, and
nothing ever changes. We are still running the same system as 25 years
ago, with only
the addition of RIP auto route distribution.
This gets worse over time, as those who would like to change things see
this and leave, and
in the end we only have a number of old hats left who don't change anything.
That does not improve our reputation... sometimes newcomers ask "why do
we use that
method when it is so difficult to implement and it can all be done so
much easier", and the
only response can be "don't ask...".
Rob
Because of the current changes, people want to change firewall entries
that check an address to be "within AMPRnet".
This of course used to be simple, like "-s 44.0.0.0/8" as a matcher in
Linux iptables.
I already read remarks like "well I just need to split those rules in
two, one for 44.0.0.0/9 and another for 44.128.0.0/10".
This is not really required. And it is not so easy when the match was
in a "not" context, like: ! -s 44.0.0.0/8.
Also it makes the firewall rule list longer and maybe less intuitive.
Maybe not everyone knows how ipset can be used to match more than one
address in the same rule.
The ipset program creates "address sets" that can be lists of addresses,
networks, portnumbers etc that can then be referenced in a match.
For example, create an address set that contains the new AMPRnet ranges:
ipset create AMPRnet hash:net
ipset add AMPRnet 44.0.0.0/8
ipset add AMPRnet 44.128.0.0/10
ipset add AMPRnet 44.224.0.0/15
(the last one of course has to go, but I kept it there to give our
German friends some time to renumber)
Now instead of "-s 44.0.0.0/8" you can use: -m set --match-set AMPRnet src
Instead of "-d 44.0.0.0/8" it would be: -m set --match-set AMPRnet dst
And instead of "! -s 44.0.0.0/8" you still can use the form: -m set !
--match-set AMPRnet (src or dst), so
there is no need to change the structure of the rules to work around the
problem of not having a "not" operator.
Of course you need to arrange for the above commands to be run before
the iptables rules are loaded.
No problem for me as I have always done that in an own shellscript not
using distributor's solutions that use iptables-save or similar.
(I prefer to have the possibility to have comments, use variables
holding certain addresses and networks, etc)
In MikroTik RouterOS the same feature is available as "Address list" in
the firewall.
You can create an address list and load those subnet values:
/ip firewall address-list
add address=44.0.0.0/9 list=amprnet
add address=44.128.0.0/10 list=amprnet
and then use that in filter rules by using Src.Address List instead of
Src.Address for the match.
Rob
Hey everyone, if you are like me and you’re working to update your firewall rules to carve out the recent subnetwork sale, I’d like to remind you that the proper way to refer to the portion of the network that has been sold is this:
44.192.0.0/10
The converse, “44.192/10” actually expands to "44.0.0.192/10” in some software, and this is probably not what you want!
-Jeremy
> But hey, if you'd really like to go back to only one ACL entry, we could
> also sell 44.128/10. Then you'd only need 44/9. <-- (note smiley)
Actually there would be plenty of space with just the /9 when it had not been
all allocated to the US in the beginning. OTOH, had that been the case, we probably
had been tempted (or forced) to sell it off (or just release it) much earlier.
Rob
