This caught my attention on the wetnet list:
https://www.enhancedradio.com/products/hamshield-lora-edition-high-power
For those seeking new ways to move data and ones that exceed what you
can do connected to conventional analog rigs, this is worth looking
into.
Circuit Cellar magazine had a pretty decent multi-part LoRA overview last year.
And if you look on github, Travis, KK4VCZ has some code adapted as a
starting place for ham radio:
https://github.com/travisgoodspeed/loraham
Figured I'd point it out there as it's what we do.
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]
If you're a member of TAPR and you have not yet voted for the board of
directors, please take a minute and do so. While you're at it please
consider casting one for yours truly as well so we can have a voice
within TAPR.
--
Do Lipton Tea employees take coffee breaks?
-----
73 de Brian N1URO
IPv6 Certified
n1uro-dawt-ampr-dawt-org
uronode-dawt-n1uro-dawt-com
> Done.
> - Brian
Thanks Brian! I think verifying an item in the data itself is more reliable than checking the
result of the transfer. Which wget doesn't support anyway.
It also covers the case where the .tar.gz file would be incomplete for some reason, e.g.
running out of space.
(I probably added the check for 255.255.255 at some point when that or another undetected
error occurred...)
Rob
It looks like we have the correct routes, but maybe the situation already rectified itself.
44.182.21.0/24 via 89.122.215.236 dev tunl0 proto ampr-ripd metric 4 onlink
44.182.21.1 via 89.33.44.100 dev tunl0 proto ampr-ripd metric 4 onlink
This weekend we had another issue. I use a script to download the ampr.org zone from
ftp://gw.ampr.org/pub/ampr.tar.gz to have it available locally in case there is a DNS problem
on internet or we get isolated (lost connectivity on our gateway). Our local DNS servers
44.137.0.1 and 44.137.0.2 operate from this downloaded zone rather than from internet,
and a regular check of the version number is made and the new file downloaded when it
changes.
As I experienced before that download of this file sometimes is not complete due to DDoS
or other issues that make the download very slow, I added a sanity check: verify that the
PTR entry for 44.255.255.255 is present in the 44.rev file before replacing our copies with
the downloaded one. That entry was the last line in 44.rev, however someone has removed
it so my script permanently rejected the download.
Well... maybe a line can be added at the end of the files like there is at the end of encap.txt
saved by ampr-ripd, so scripts can check for that to see if the file is complete:
# --EOF--
Of course it is always better to have a documented check criterium than to rely on something
like the 44.255.255.255 -> broadcast.ampr.org entry...
Rob
Hello,
I think we have an route update/setup issue in our network that may need
some attention.
First of all, I don't see the root cause so maybe we should investigate
a little.
As you may have noticed, a technical bulldozer issue forced me to move
the yo2tm server to a VPS cloud machine, which is not a bad move by itself.
I put a gw with amprd on it and added a new new portal entry,
44.182.21.1 via 89.33.44.100. The route appeared in the RIP broadcasts a
few minute later and everything seems to be working as expected. Ping
was ok, connecting also.
So at the moment there are 2 overlapping subnets, 44.182.21.1/32 at the
new gw, and 44.182.21.0/24 at the old one.
Since I moved the call home map to the new location, too, I was
expecting that all nodes would show up in the new map, since all
notifications go to 44.182.21.1.
Normally, for routing purposes, the more precise route (/32) should take
precedence over the old one, and everything should be fine.
On the maps, there where some nodes appearing promptly via the new
gateway, like N1URO and some related radio nodes, but that was it. So
after 2 days, only 8 nodes switched to the new route, all others sending
their notification to the old address, WHICH SHOULD NOT HAPPEN.
The gateway was certainly updated as the internet pings hitting it moved
to the new target (some 20 public IPs).
Also, my netrom partners also followed after setting up the end axip
endpoints on the new machine.
I can not find an explanation for this, other than that there is some
route caching involved.
Maybe some of you have ideas/explanation on this behavior, and how to
fix it.
Marius, YO2LOJ
> thanks! I will read and do some tests on a spare MT router prior to
> modifying our primary router
Remember you can use CHR to do testing. Install it on a virtualization platform
and you don't even need a physical system. It can do 1 Mbps for free (usually enough for IP-IP).
When you have an existing ESXi host it is very easy to deploy it (using OVA template).
It can also run on many of the available VPS services so you can have an IP-IP gateway when you
cannot meet the requirements to reasonably run it at home (static IP, incoming protocol 4 without issues).
You can then run an outbound VPN from your home to the CHR instance.
Rob
Hi there - Dan ve4drk here.
I want to setup an IP-IP gateway on one of the Mikrotik devices we have on
our network.
We have a number of subnets defined in the 44 address space that we host
locally via BGP.
We'd like to ensure they are available to the IP-IP tunnels.
I looked at this link:
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers
and there is a reference to the MIkrotik setup by yo2loj - but it's a bad
URL. Is there an update somewhere else I can't seem to find? I was
checking the list and I see his link is down for a bit.
73, Dan ve4drk
Hello,
Due to some bulldozer guy, yo2loj.ro and yo2m.ampr.org are down for the
moment, probably for the whole week (they cut a main cable with some 200
pairs).
I am migrating to a VPS, to get the download section up asap.
Tnx,
73s, Marius, YO2LOJ
Fresh from DerbyCon/Jacob Barnes:
"Hey @derbycon if you didn't wake up early enough to catch my talk, I just dropped a variation on CVE-2018-14847 that allows attackers to remotely root a Mikrotik router: "
https://github.com/tenable/routeros/tree/master/poc/bytheway
