44net

44net@mailman.ampr.org

2 participants
3205 discussions

Creating / hosting a new sub-mailing-list 44net-fr ?
by Toussaint OTTAVI 10 Sep '21

10 Sep '21

Hi, I often talked with French 44net guys, and it appears there's no current forum or mailing-list for communications between us, without polluting the world-wide 44net list. A long time ago, I planned to create a dedicated mailing-list 44net-fr on our mail server, but I never finished it, HI :-) The current project of a link between Corsica and France shows the need of such a tool, because private mails are becoming too bulky. My primary idea was to create a group on groups.io. As AMPR has now fundings and technical team, would it be possible to host such a 44net-fr mailing-list directly at ampr.org ? 73 de TK1BI

4 9

Addl Portal Services
by Kris Kirby 10 Sep '21

10 Sep '21

If we've got a TAC working new possible opportunities for 44net, I strongly recommend developing and deploying a Dynamic DNS (DDNS) service, and extending the portal so that end users may edit thier own DNS records. -- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager

3 2

Known (US) providers to route/announce a 44
by Nick Hammler 05 Sep '21

05 Sep '21

(Sorry for repost. Chris kindly informed me that my messages are empty. I think it could be because GPG sig. Another attempt without it) Hi, I am aware there will be a slim chance for this to happen but having a 44net subnet directly routed would be super amazing. I am aware that "normal" providers likely won't do this except for business customers (at many $$$/months) and likely the subnet needs to be large (>=/24?) I could imagine though that small providers may be up for it (as an example, in a place I lived many years ago, I had a small provider; I contacted the CEO directly and he immideately agreed to assign+route me a /29 at no cost!). Are there any known providers (US, California) who could route a 44net subnet? To everyone who has their 44 routed directly: How does it work for you? Finally: The whole 44net is announed only by the UCSD gateway (as far as I understand). Wouldn't it be great to improve the connectivity, reliability, redundancy by having 44 announced by multiple people who route their subnet directly and then forwarding them to the mesh network via ipip? Is there a reason this is not done, other than nobody besides UCSD volunteered ? Thanks, KM6RDV

7 10

Questions on (reverse) DNS
by Nick Hammler 26 Aug '21

26 Aug '21

(Sorry for repost. Chris kindly informed me that my messages are empty. I think it could be because GPG sig. Another attempt without it) Hi all, I am new to 44net and I haven't found much about DNS. I have the following questions: 1. In order to get traffic routed through the 44 gateway, does a forward or reverse DNS entry need to exist? Does it need to satisfy certain format/conditions? (from a technical standpoint, existance of reverse would make sense as it's done in SMTP servers, but I don't know how this information is queried by the gateway). 2. I run my own bind (also accessible over 44net). I'd love to handle my DNS entries on my own (not least because every request on the portal can take well over a year to be answered, at least for me). Is it possible to request classless in-add.arpa delegation (RFC2317) for my subnet? 3. If the ampr.org domain is used, are there any requirements on the format/hierarchy? Can it be a subdomain <myname>.ampr.org? Or does it need to be <callsign>.ampr.org? Can all entries and hierarchy under this subdomain be freely chosen? 4. Is there any way in the portal to keep track of DNS related requests/messages as it is for subnets? I am not sure any more if, when, what and who I have asked about DNS and I want to avoid sending the request again if it's still "pending". Thanks, Nick

4 6

Known (US) providers to route/announce a 44
by Nick Hammler 26 Aug '21

26 Aug '21

1 0

Questions on (reverse) DNS
by Nick Hammler 26 Aug '21

26 Aug '21

1 0

Pacific Packet Radio Society history site: www.pprs.org
by John Gilmore 24 Aug '21

24 Aug '21

Curtis Spangler, N6ECT, has kindly created an archive of documents and photos from amateur radio packet networking history. The Pacific Packet Radio Society was a small group of hams in the San Francisco Bay Area, led by Hank Magnuski, KA6M, in the 1980s. Hank's KA8M-1 repeater talked half duplex at 1200 bits/sec with VADCG Terminal Node Controllers throughout the Bay Area. A good chunk of the history is here, including how Hank originally requested and received the 44net IP address allocation: http://www.pprs.org/ In particular, in this page, Hank wrote on 1981-06-10 to Paul Rinaldo, W4RI, thanking him for information about the INTERNET protocols, and reported: http://www.pprs.org/bulletin/pages/page003.html "In looking over this document the application of the standard is fairly straightforward except for one area, and that concerns addressing. A four byte source or destination address is specified, and that does not meet our needs. The first byte of this four byte field represents a network, and about 40 of the possible 256 combinations are already assigned. I attempted to contact the author of the document to see if a number could be assigned to an amateur radio experimental network, or to see if there already was a number for personal computing networks, but John [sic] Postel was out of town, and I didn't get an answer to my question. It seems clear that 256 networks is somewhat limiting, and that some future revision of the standard will have to expand this field." (As we now know, figuring out how to allocate network addresses, and route packets among them, is not as simple as it seemed back then!) Page 13 reports, in a 1981-12-06 page of notes about how to build packet repeaters and networks: http://www.pprs.org/bulletin/pages/page013.jpg "Direct connect stations using IP protocol can use "NET 00 00 00" as the network node address. NET is decimal 44." John Gilmore, W0GNU

1 0

no route due to no host resolution
by R P 22 Aug '21

22 Aug '21

Hi there My gateway (44.138.1.1) tunnel get the commercial IP host name from no-ip.com and the UCSD router use this name to resolve the IP and make tunnel to it since it use dynamic IP every time that this hos is in some reason not resolvable the UCSD takes it out from the routing table and i get no route to it anymore Even when the host is resolvable again the only solution is to write Chris and ask him to fix it for me Has anyone seen this thing at his system ? Is there any thing i can do to make the route back ? Or (prefered) can any mechanism be add to ucsd that when a certain host get resolved again the route will come back without any intervention by human ? Any help welcome .. Regards Ronen - 4Z4ZQ http://www.ronen.org

2 1

Re: [44net] 44Net Digest, Vol 10, Issue 112
by Bill Buhler 19 Aug '21

19 Aug '21

Sorry, I just realized that I broke threading when I replied to you Pierre, Now we really are getting to where there should be layer4 and Layer5 firewalls. Looking at this your proposal actually gives a false sense of security by segregating. Why do I say that? Modern web browsers will attempt to use https first if not explicitly told to. This was determined by their coders to be a good thing because it encourages privacy on the Internet, and few places of the world limit encryption. Of course most if not all amateur radio operators are prohibited from "obscuring the meaning" and therefore using encryption. We could walk down that rabbit hole, but lets not. Instead lets walk down the handshaking rabbit hole. If I want to do SSL with a website I access it at port 443. If I don't I access it at port 80. Therefore if I do a L4 firewall rule at the gateway that feeds rf link that rejects any traffic to or from port 443 I've prevented the handshake and no encryption will follow. SMTP can be a little trickier if I have enabled the libraries on my device for SSL, it's possible that it could issue a start tls command and negotiate a encrypted feed over what would normally be a unencrypted port. There are two solutions to this. One is to install a application aware next generation firewall (Palo Alto makes the one I use), which looks inside the packets at the actual data flows and classifies what the actual protocol being used is rather than just the port (socket address) that is being passed. With a Palo Alto I can drop or reject all traffic that uses encrypted protocols. Once dropped I'm safe. But many don't have these firewalls, and that's understandable. Instead, as the licensed radio operator, who knows the rules, they should learn how to disable the encrypted protocols running on their devices that will be problematic for these reasons. There is no universal solution, because if I just say "oh this network is unencrypted" doesn't mean that if I have setup a web server with a ssl port that someone else on the network won't access it over chrome and accidentally end up with a encrypted feed. Being on the network is only the first step, administrating our devices to comply with the rules is a ongoing and important thing. Fortunately, most devices either have limited packet filtering built in, or can have features like SSL/TLS disabled in their settings. Which makes this a moot point. For my RF devices I make sure that their backhaul link blocks known points of encryption. Because that is the purpose of a firewall, and proper network stewardship. Just like I filter Bogons and known bad actors at the edge of my network connections. Sorry for the novel, but I believe in trying for a universal solution, many are missing why the solution won't cure the problems. Best regards, Bill Buhler - AF7SJ On 8/17/2021 12:30 PM, pete M wrote: > Bill, yes making rules like you just told will get rid of all the > traffic that is not 44. > > But it does not fix some issue that ham will have with the normal ham > to the world exchange of data. > > There are 2 use case that we seen. One being ham talking to ham and > the world and earing from ham and the world. > > The second use case is ham talking to ham, end ham earing from ham only. > > In the explanation you gave this would fit only the first use case and > the local guys would firewall what he want or not. > > But when we come to the ham to ham only use case we fall short. On > many network we cannot allow to have encryption on RF. Now let's say > someone put a web site on a 44 address and enable https. The ham on RF > want to connect to it. He open his browser and he is now actively > passing encrypted data over the air. > > What will the 44.128/10 segment will provide is to make sure that > everyone on that segment won't encrypt anything and won't put someone > else into a bad situation > > Pierre > VE2PF >

2 1

A new era of IPv4 Allocations
by Antonios Chariton (daknob) 17 Aug '21

17 Aug '21

Fellow radio amateurs, I am writing to you on behalf of the ARDC TAC, which I represent. Those of you that were on our Community Call last Saturday may remember that I promised you we would share our first proposal with the community. A few days after that, I am happy to send that to you for your review, feedback, comments, questions, and information! You can find our 5-page PDF here: https://pdf.daknob.net/ardc/tac128.pdf <https://pdf.daknob.net/ardc/tac128.pdf> The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning, and actual research[1] performed on the IP network and the Portal allocations. Since the TAC does not have any authority on the IP (or any other) resources of ARDC, and we only have an advisory role, we end this document with a proposed resolution we intend to submit soon to the ARDC Board of Directors, where we urge them to vote and approve some key things required for us to be able to achieve what is described. We believe that the TAC represents the community and the 44 Net users, so we created this document and post it here in advance, with the purpose of being able to answer your questions, collect your feedback, and hear from you. This is why we briefly explain the situation in about 4 pages, and then we end with the resolution we want the ARDC Board of Directors to approve. I hope you like it, and I remain at your disposal for anything you may need. Antonis Links: [1] - https://blog.daknob.net/mapping-44net/ <https://blog.daknob.net/mapping-44net/>

41 195

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net