- 44net - mailman.ardc.net

Re: [44net] Need TraceRoute from UCSD router (R P)
by lleachii＠aol.com 24 Jan '20

24 Jan '20

David, https://gw.ampr.org/private/ Username: gatewaysPassxword: MTashram2007Ron It's in the archive. Also, my trace tool is available: http://kb3vwg-010.ampr.org/tools/trace/php-trace44.php 73, - Lynwood KB3VWG

4 3

Ubiquiti Networks ER-10X set up
by Angelo Glorioso 24 Jan '20

24 Jan '20

I have not played with NOS and JNOS in years. I would like to use some of my 44 network address again. I see that a lot of the IRIP, Allstar Dstar etc are using 44 for stations, reflectors and so on. I purchased an Ubiquiti Networks ER-10X as a tunnel to the 44 network. Is there anyone that has done this already?? Anyone would like to be an Elmer to me in helping get this setup up and running?? Angelo Glorioso / N5UXT gw.n5uxt.ampr.org ( still there )

2 1

EC2 Router Reference Implementation
by Stephen Thomas 24 Jan '20

24 Jan '20

To learn the routing protocol, I created an Amazon EC2 instance of a Linux Ubuntu router inside a virtual private cloud (VPC) where I have full control over IP and can open 0.0.0.0/0 in both directions over all protocols (EC2 without a VPC only permits TCP/UDP/ICMP access control). When I run the daemon in verbose mode it is stuck calling home: ubuntu@ip-192-168-44-12:~$ sudo ampr-ripd -d -v -L KZ0FOX@EM89mx Using metric 0 for routes. Using TCP window 840 for routes. Using gateway 192.168.44.1 for direct 44net endpoints via interface eth0. Calling home Waiting for RIPv2 broadcasts... Calling home Calling home Calling home This system is online in the portal as 3.135.62.22 ( ec2-3-135-62-22.us-east-2.compute.amazonaws.com) and subnet 44.76.0.12/32. Setting up a reference implementation like this one may be good for learning the basic premise and ability to test out a configuration with less variables than one may have at home with an ISP. I welcome any constructive comments or suggestions. Best regards, Stephen Thomas

3 2

Re: [44net] 44Net Digest, Vol 8, Issue 178
by Roger 23 Jan '20

23 Jan '20

Very sad news. I was talking to him just the other day. What a shock. My condolences to his family and those close to him. As busy as I imagine he must have been, he always had time to help. Roger VA7LBB > On Nov 23, 2019, at 12:00, 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. Brian Kantor, WB6CYT, SK (Phil Karn) > 2. Re: Brian Kantor, WB6CYT, SK (vk2tv) > 3. Re: Brian Kantor, WB6CYT, SK (Donald Jacob) > 4. Re: Brian Kantor, WB6CYT, SK (Doug) > 5. Re: Brian Kantor, WB6CYT, SK (John Ricketts) > 6. Re: Brian Kantor, WB6CYT, SK (Fortney, Jim - K6IYK) > 7. Brian Kantor, WB6CYT, SK (Brian) > 8. Re: Brian Kantor, WB6CYT, SK (vk4aa(a)vk4aa.com.au) > 9. Re: Brian Kantor, WB6CYT, SK (Albert Lawson) > 10. Re: Brian Kantor, WB6CYT, SK (pete M) > 11. Re: [44ngn] Brian Kantor, WB6CYT, SK (Marius Petrescu) > 12. Brian Kantor, WB6CYT, SK (Paul) > 13. Re: Brian Kantor, WB6CYT, SK (Tony Langdon) > 14. Re: Brian Kantor, WB6CYT, SK (Tommy Chen) > 15. Re: Brian Kantor, WB6CYT, SK (Tim Po??r) > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

3 2

Re: [44net] 44Net Digest, Vol 9, Issue 2
by Michael Herring 16 Jan '20

16 Jan '20

I just read the Terms of Service & Acceptable Use Agreement. It could be updated to reflect the changes in the allocated ip blocks 44.0.0.0/9 and 44.128.0.0/10 On Sun, Jan 12, 2020 at 3: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: BGP portal management after WB6CYT's passing (Scott Nicholas) > > > > ---------- Forwarded message ---------- > From: Scott Nicholas <scott.nicholas(a)scottn.us> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Sun, 12 Jan 2020 14:29:27 -0500 > Subject: Re: [44net] BGP portal management after WB6CYT's passing > Will Chris be named as a POC in ARIN to be able to provide LOA to > upstreams for BGP announcement? > > On Mon, Dec 30, 2019 at 12:39 PM Phil Karn via 44Net > <44net(a)mailman.ampr.org> wrote: > > > > Hi. As you all know, Brian Kantor WB6CYT passed away suddenly last > > month. Brian did so much for AMPRNet from the very beginning that he'll > > be impossible to fully replace. We're trying but it's hard, especially > > since he was a close personal friend. > > > > Chris Smith, G1FEF (chris(a)g1fef.co.uk) has kindly volunteered to take > > over Brian's portal work and to handle portal and BGP allocation > > requests. Please direct queries to him. > > > > 73, Phil Karn, KA9Q > > > > President, ARDC > > > > > > > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

1 0

44 compatible Routers
by Angelo Glorioso 14 Jan '20

14 Jan '20

Hi All, I remember seeing a list of hardware router that would work with the 44 network. Anyone know where this list is located?? If I remember there was a list of Ubiquiti Edgerouters . Thanks.

1 0

Memorial service for Brian Kantor, WB6CYT
by Phil Karn 13 Jan '20

13 Jan '20

As you know, Brian Kantor, WB6CYT passed away suddenly on November 21, 2019. We will hold a memorial service for Brian on Saturday, Feb 1 2020 at 1:30 PM in La Jolla, CA (part of San Diego). Please see this link for details: https://www.evite.com/event/0135NF64ATPRMYGRMEPKGPM2G3LMLQ/rsvp?utm_campaig… Please bring any photos, mementos and (above all) stories and anecdotes about Brian to share. Brian wasn't exactly a highly formal person who stood on ceremony, so we'll keep this informal. If you have a story to tell, it's up to you whether you stand up and relate it to the whole group or just a few others at a time. There will be plenty of time for both. Everyone who knew Brian is welcome. His friendships spanned at least three distinct social circles, and I know he'd be very happy to see everyone meet and enjoy everyone else's company. Even if he'd be a little embarrassed that we were doing it in his honor. Free snacks and refreshments will be provided, so please RSVP through the evite link so we can tell the hotel how much to make available. If you have special dietary needs, please say so; the hotel has a menu we can choose from. Please forward this email to anyone you think might be interested. Hope to see you on the 1st. Phil Karn, KA9Q

1 0

test Sat, 04 Jan 2020 21:21:45 -0500
by n2nov＠n2nov.net 05 Jan '20

05 Jan '20

This is a test mailing

2 1

Re: [44net] Bad name in DNS
by Thomas Osterried 05 Jan '20

05 Jan '20

Hello, Am 05.01.2020 um 11:25 schrieb Rob Janssen via 44Net <44net(a)mailman.ampr.org>: [..] > After investigating it appeared that an invalid name has been added to DNS by someone: > > dhcp-44-149-72-.db0eif IN A 44.149.72.89 thank you for your open eyes. It must have been a bug while doing cut+paste. The archive of the source of changes shows the correct entry. I wish a bugfree new year ;) vy 73, - Thomas dl9sau

1 0

Bad name in DNS
by Rob Janssen 05 Jan '20

05 Jan '20

I noted that since a couple of days the updates to DNS have been stuck and it caused a problem with out local DNS server as well. After investigating it appeared that an invalid name has been added to DNS by someone: dhcp-44-149-72-.db0eif IN A 44.149.72.89 Note the trailing minus sign in the name, which is not allowed. Bind with (default) strict name checking will issue an error on this, and (I think that is bad) it will refuse to load or transfer the entire zone. So the previous version of the zone will remain active. This was version 2001012115, while the current version is 2001050245 so it has been stuck for a couple of days (the format used for the version is YYMMDDHHMM). For now I have deleted the bad name, but it would probably be prudent to add: check-names warn; to the zone configurations of the bind daemons running the ampr.org zone so that they have the more reasonable behavior of just ignoring that single name instead of the entire zone. Rob

1 0

BGP Request Process
by VK4AA 30 Dec '19

30 Dec '19

Hi Guys Has the process for BGP approvals been finalised yet? Samantha VK4AA Australian Co-Ordinator AMPRnet

4 3

Re: [44net] 44Net Digest, Vol 8, Issue 185
by kd6oat 22 Dec '19

22 Dec '19

Brett: Thank you for your decades of service to one of the digital sides of amateur radio.. My jnos convers server has been linked to wa7v for many years 24/7 and I am most grateful that you have been able to provide a gateway and for all the work you have done. Merry Christmas and Happy New Year to you and yours. Ken - KD6OAT > > > Date: Sat, 21 Dec 2019 12:43:00 -0800 > From: Brett Mueller <wa7v(a)wa7v.com> > To: 44net(a)mailman.ampr.org > Subject: [44net] WA7V Services to End > Message-ID: <7a53f433-ed44-508b-83fd-5bce59361592(a)wa7v.com> > Content-Type: text/plain; charset=utf-8 > > Hello, 44net ops, > > An assortment of circumstances have gradually led me to the decision to > terminate the WA7V gateway/BBS and related services at College > Place/Walla Walla, Washington, USA. > > Services are scheduled to go offline on Monday, December 30, at > > >

1 0

SMTP Gateway
by Jean Létourneau 21 Dec '19

21 Dec '19

Good day, I am looking for a smtp gateway where I will be able to send mail from my jnos (va2om.ampr.org) to the internet. Any taker? Happy Holiday!. 73 de Jean, VA2OM / VE2PKT -- -- Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode) : VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net) : VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway) RF: 147.435 Mhz (1200 Bps), Internet: Telnet://nodes-ve2pkt.dyndns.org port 23 (Network Node) Telnet://fbb-ve2pkt.dyndns.org port 6300 (FBB BBS) Telnet://ve2pkt.dyndns.org port 9000 (DXCluster) E-Mail: packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam ampr net: ve2pkt(a)ve2pkt.ampr.org Inet: ve2pkt(a)gmail.com

1 0

WA7V Services to End
by Brett Mueller 21 Dec '19

21 Dec '19

Hello, 44net ops, An assortment of circumstances have gradually led me to the decision to terminate the WA7V gateway/BBS and related services at College Place/Walla Walla, Washington, USA. Services are scheduled to go offline on Monday, December 30, at approximately 00:00 UTC (Sunday afternoon/evening in the Americas). These services include: * Hub_NA saupp convers hub * ALWGW:WA7V-8 NOS Gateway/BBS * ALWBBS:WA7V FBB BBS * ALWHUB:WA7V-4 UROnode * PNW:WA7V-2 (X)Net Router I believe we have a replacement lined out for Hub_NA. I should have a confirmation shortly, and another announcement will be following. It's been an interesting 2+ decades for me, and I'm very grateful to a number of extremely bright and motivated hams around the world who have contributed so much in advancing the all-encompassing art of amateur radio. I've been the undeserving recipient of their creativity, expertise, time and energy. For most it is a labor of love, and certainly not something that has put any bread on their tables. To those amateurs, I heartily say, "thank you!" Thanks for your links, chats, assistance and friendship! We'll see what the future holds. :) Merry Christmas, and happy holidays! 73, Brett Mueller Pendleton, Oregon, USA

1 0

Linux GRE Tunnels
by Jason McCormick 08 Dec '19

08 Dec '19

I'm running into an interesting problem I thought maybe someone in this community would have run into before. We're working on a project to redesign and re-IP our entire radio network. Part of the goal is to stop using OpenVPN and IPSec tunnels (long story) and move exclusively to GRE-based tunnels. The plan is to have two Linux VPS hosts running at a provider with our 44Net allocation and an IPv6 allocation advertised and then routed into the radio network over GRE tunnels to 3 different locations that are all backhauled together. One of the primary goals is to do dual-stack throughout the network. I have one site setup working perfectly - "gre0". It's passing IPv4 and IPv6 traffic over the GRE tunnel. One *key* point to this is that the GRE connection endpoints are iPv6. IPv4 isn't doable for this connection (again, long story but not an option). When setting up the second GRE tunnel "gre2", nothing would work even though the configuration was the same EXCEPT for the fact that the second GRE tunnel was using IPv4 addresses for the GRE tunnel endpoints. Linux keeps spitting out a very odd error when I try to ping across the tunnel I cannot find reasonably documented anywhere: ip6_tunnel: gre2 xmit: Local address not yet configured! The key was the "ip6_tunnel" part that took me awhile to figure out. After experimenting, I've found that if I have one GRE tunnel using IPv6 endpoints (ip -6 tunnel add gre0 mod ip6gre) and one using IPv4 endpoints (ip tunnel add gre2 mode gre), only the gre0 tunnel will work and the gre2 tunnel seems to believe it's missing an IPv6 address. If I delete the gre0 tunnel, the gre2 tunnel immediately beings working with both IPv4 and IPv6 traversing the GRE. I cannot find any documentation that describes this behavior or why it would be the case. I can't switch to IPIP tunnels because I haven't found a way to do a dual-stack tunnel between the endpoints - seems like you can only do one IPIP tunnel between two endpoint IPs regardless of type (ipip, ipip6, ip6ip6, sit) Anyone have any deep wisdom on GRE tunnels? Jason

2 3

AMPR BGP coordination next steps without WB6CYT
by David Ranch 03 Dec '19

03 Dec '19

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

4 3

Telus and ampr
by Stephen Atkins 02 Dec '19

02 Dec '19

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

1 0

Re: [44net] 44Net Digest, Vol 8, Issue 178
by kd6oat 28 Nov '19

28 Nov '19

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 > >> >>

1 0

Brian Kantor, WB6CYT, SK
by Phil Karn 23 Nov '19

23 Nov '19

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

17 16

Brian Kantor, WB6CYT, SK
by Paul 23 Nov '19

23 Nov '19

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

1 0

Re: [44net] Brian Kantor, WB6CYT, SK
by Fortney, Jim - K6IYK 23 Nov '19

23 Nov '19

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." --------------------------------------------------------------------------

1 0

IPIP and RIP configuration on a Mikrotik
by Paul Greeff 16 Nov '19

16 Nov '19

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

3 5

IPIP and RIP configuration on a Mikrotik
by Thomas Glaab 15 Nov '19

15 Nov '19

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 >

2 2

44Net coordinator for South Africa
by Paul Greeff 15 Nov '19

15 Nov '19

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

2 1

Need connection partner
by VE3OY Matt 15 Nov '19

15 Nov '19

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?/

5 4

Re: [44net] Portal Messaging
by Brian Kantor 03 Nov '19

03 Nov '19

Use regular email. There is no return message function. null

1 0

Portal Messaging
by Geoff Joy -KE6QH- 03 Nov '19

03 Nov '19

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)

1 0

NPR (New Packet Radio): Modems for sale (world-wide)
by f4hdk 28 Oct '19

28 Oct '19

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

1 0

Mailing list for Hamnet newbies
by f1sxo＠zulian.be 23 Oct '19

23 Oct '19

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

1 0

Re: [44net] 44Net Digest, Vol 8, Issue 168
by kd6oat 21 Oct '19

21 Oct '19

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 > ************************************* >

1 0

Registration request from Alekzandr Evans (KI7HOC)
by Ruben ON3RVH 21 Oct '19

21 Oct '19

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

4 3

Re: [44net] Mikrotik hAP ac lite gateway configuration
by Keith Kasin 20 Oct '19

20 Oct '19

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

1 0

AMPRGW down
by Brian Kantor 20 Oct '19

20 Oct '19

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

6 7

I remember IANA [RFC2468]
by Brian Kantor 17 Oct '19

17 Oct '19

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]

1 0

Search for a French mailling list
by f1sxo＠zulian.be 09 Oct '19

09 Oct '19

Hello, Do you know an active french mailling list about Hamnet? 73, F1sxo Frédéric ZULIAN

3 2

How long does it take to get allocated?
by Harley Ge 08 Oct '19

08 Oct '19

4 3

DYNDNS Script for Cisco Routers
by R P 03 Oct '19

03 Oct '19

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

3 2

DNS Queries
by lleachii＠aol.com 27 Sep '19

27 Sep '19

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

1 0

44.190 addresses and geolocation ?
by Toussaint OTTAVI 27 Sep '19

27 Sep '19

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

6 10

Re: [44net] Cannot ping a host
by HF8N＠winlink.org 27 Sep '19

27 Sep '19

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

1 0

Cannot ping a host
by HF8N＠winlink.org 25 Sep '19

25 Sep '19

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

4 3

Some errors with startampr script
by f1sxo＠zulian.be 23 Sep '19

23 Sep '19

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

1 0

Fraud update: 110k to ARISS
by Bryan Fields 23 Sep '19

23 Sep '19

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

13 18

DOS ?
by Jack Eifer 20 Sep '19

20 Sep '19

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)

3 2

44net on Ubiquiti Unifi Controller and USG
by Albert Lawson 18 Sep '19

18 Sep '19

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

1 0

need help configure gateway on ubuntu
by KUN LIN 17 Sep '19

17 Sep '19

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

2 9

Re: [44net] ax25-patch
by Libor Berka 17 Sep '19

17 Sep '19

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)

1 0

NPR (New Packet Radio)
by f4hdk 15 Sep '19

15 Sep '19

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

2 1

Re: [44net] Fraud update: 110k to ARISS
by Thomas Moss 15 Sep '19

15 Sep '19

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

4 3

Re: [44net] Connecting to 44net
by Brian Kantor 06 Sep '19

06 Sep '19

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

4 5

44Net OpenNet VPN Setup
by matthew＠alberti.us 03 Sep '19

03 Sep '19

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

6 8

Routing Help Please
by Albert Lawson 30 Aug '19

30 Aug '19

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

2 3

DARPA Spectrum Collaboration Challenge (SC2) - OCTOBER 23, 2019
by Lori Guidos 26 Aug '19

26 Aug '19

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.

5 4

Improved Communications (Thread split)
by Bill Horne 25 Aug '19

25 Aug '19

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

2 1

DNS Entries
by Albert Lawson 24 Aug '19

24 Aug '19

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

2 1

Another approach Re: Fraud
by J. William Semich 21 Aug '19

21 Aug '19

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..."

12 16

[Linux] Encap files and route options
by f1sxo＠zulian.be 21 Aug '19

21 Aug '19

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

3 2

Certificate for openVPN
by f1sxo＠zulian.be 18 Aug '19

18 Aug '19

Hello, I’m trying to configure openvpn (linux client). I go to the address:: http://wiki.ampr.org/wiki/AMPRNet_VPN#Getting_a_certificate_from_LoTW then I go to: "Getting a certificate from LoTW, Go through these simple step " Then the server answer is http://www.arrl.org/pages/display/error404 :-( An idea for a certificate for openVPN? 73 F1SXO Frédéric ZULIAN

2 1

Root DNS HAMNET server
by f1sxo＠zulian.be 16 Aug '19

16 Aug '19

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

5 7

Another new board member...
by Bryan Fields 15 Aug '19

15 Aug '19

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

7 7

Re: [44net] Another new board member...
by Fortney, Jim - K6IYK 15 Aug '19

15 Aug '19

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

3 2

amprnet gateway forwarding
by Martinez, Philip 11 Aug '19

11 Aug '19

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

4 3

Hamnet server DNS root
by Frederic Zulian 09 Aug '19

09 Aug '19

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

1 0

And the fraud begins.
by Bryan Fields 08 Aug '19

08 Aug '19

13 15

RouterOS update breaks RIP reception
by Marius Petrescu 06 Aug '19

06 Aug '19

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

1 0

RIP broadcasts
by Jack Eifer 01 Aug '19

01 Aug '19

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

3 2

Re: [44net] mailman.ampr.org new IP address (Jay Nugent)
by Rob Janssen 30 Jul '19

30 Jul '19

> It *should* be a multi-step process: Why so difficult? The TTL in the ampr.org zone is one hour, and it has been for a long time. Rob

4 3

mailman.ampr.org new IP address
by Brian Kantor 30 Jul '19

30 Jul '19

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

5 9

Network Routers for Harsh Environments
by Jason McCormick 28 Jul '19

28 Jul '19

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

4 3

Re: [44net] Is this a worry ?
by Rob Janssen 25 Jul '19

25 Jul '19

> < 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

2 1

Re: [44net] 44 net connectivity
by Rob Janssen 25 Jul '19

25 Jul '19

> 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

7 8

Re: [44net] 44 net connectivity
by Rob Janssen 25 Jul '19

25 Jul '19

> 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

1 0

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 25 Jul '19

25 Jul '19

> >/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

16 21

Re: [44net] Reverse DNS broken
by Cory (NQ1E) 24 Jul '19

24 Jul '19

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 >

3 4

Is this a worry ?
by gm4upx＠gb7jd.co.uk 24 Jul '19

24 Jul '19

< 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..

2 3

New mailing list '44NGN' - was '44 net connectivity'
by Brian Kantor 23 Jul '19

23 Jul '19

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

1 0

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 23 Jul '19

23 Jul '19

> >/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

4 3

Re: [44net] 44 net connectivity
by Rob Janssen 23 Jul '19

23 Jul '19

> 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

3 2

Re: [44net] Time to restructure the network?
by Rob Janssen 23 Jul '19

23 Jul '19

> 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

2 1

Civility on this mailing list
by Brian Kantor 23 Jul '19

23 Jul '19

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.

1 0

Re: [44net] 44 net connectivity
by Rob Janssen 23 Jul '19

23 Jul '19

> 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

2 1

Adding VPN server at UCSD ?
by R P 23 Jul '19

23 Jul '19

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

6 10

Re: [44net] Time to restructure the network?
by Rob Janssen 23 Jul '19

23 Jul '19

> 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

6 5

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 22 Jul '19

22 Jul '19

> >/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

3 3

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

3 2

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

1 0

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

2 1

ARIN services now possible
by Scott Nicholas 22 Jul '19

22 Jul '19

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

2 2

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

2 1

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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.

1 0

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

4 3

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

1 0

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

1 0

Re: [44net] Time to restructure the network?
by Rob Janssen 22 Jul '19

22 Jul '19

> >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

1 0

A few thoughts on recent developments
by John D. Hays 22 Jul '19

22 Jul '19

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

8 7

Re: [44net] Time to restructure the network?
by Rob Janssen 22 Jul '19

22 Jul '19

/> 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

1 0

Re: [44net] Time to restructure the network?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

3 2

Formal notice of my resignation from ARDC Technical Advisory Committee
by Bryan Fields 22 Jul '19

22 Jul '19

-----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-----

5 4

Re: [44net] Time to restructure the network?
by Rob Janssen 22 Jul '19

22 Jul '19

> 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

4 3

44.192.0.0/10 sale
by Phil Karn 22 Jul '19

22 Jul '19

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

12 17

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net