44net

44net@mailman.ampr.org

2 participants
3205 discussions

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

17 Aug '21

Pierre, Coming from twenty years helping various companies connect to the Internet, I find your view of firewalls to not match my own. A firewall can filter at any layer of the network stack (depending on the firewall), but layer 2 and layer 3 firewalls are extremely common... Therefore I look back on you're trying to firewall off a bunch of machines at L3 from the internet at large, while allowing them to speak to the other 44 net machines. I believe we would be better served if that is your goal to write the following rules in whatever ACL / Firewall language your platform allows at the network ingress: Source address 44.0.0.0/9 to any (or more specifically 44.0.0.0/9 & 44.128.0.0/10 if you want those extra rules). Source Address 0.0.0.0/0 drop to any There now your input doesn't allow non 44 net traffic to propagate through your network.... OK, I'm being a little bit simplistic here, but this is what we do in the real world. It is a pure L3 solution. Just like I would do L2 filtering (MAC address level) if I was connected to a ISP on a broadcast medium and only wanted to talk with my upstream provider. In the commercial space groups will publish their addresses mutually with each other to whitelist at the firewalls. I think if there are substantial groups who want to form private networks AMPR being a clearing house of that information is totally appropriate, but it should be up to those groups to control their ingress and egress points, not the network itself. Its job should be to build the backbone and enable connectivity between hams without conflicting address spaces. I have come to view this as a issue a premature optimization. We know where we are now, we know some of the struggles that certain groups are having. But top down solutions tend to have unintended consequences, and become rapidly brittle. Letting groups design their own ingress / egress rules allows them to rapidly iterate. Providing them out of band additional information such as lists of networks that only want to speak to hams, or lists of un-allocated blocks will give them the flexibility to design their rules, and the rest the ability to keep doing what they need to do. Finally, we are still seeing memory and processing power increase with each generation of devices, so we are in no danger of our ham radio network exceeding the basic capacity of most consumer devices, even ones that are on the used market. Best regards, Bill - AF7SJ On 8/16/2021 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: A new era of IPv4 Allocations : Agree (pete M) > 2. Re: A new era of IPv4 Allocations : Agree - No I don't (pete M) > 3. Re: A new era of IPv4 Allocations : Agree - No I don't (pete M) > 4. Network layer easy explaination. A must read. (pete M) > 5. Re: A new era of IPv4 Allocations : Agree (Rob PE1CHL) > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Network layer easy explaination. A must read.
by pete M 16 Aug '21

16 Aug '21

https://insights.profitap.com/osi-7-layers-explained-the-easy-way There are a lot of people comming with solution to the problem that the TAC want to fix. They are comming with solution that are not at the same layer level. This break networking communication. Using a layer 4 software to fix a layer 3 problem wont work. Same as using a layer 3 software wont fix a layer 4 problem. All the layer need to work as intended for a full network to work. TCP and UDP are at level 4 Firewall acts on layer 3 and up. IP is at layer 3 only. routing is a layer 3 task. You can use a firewall to slect what packet pass or not pass up to a point. But at the routing level if you are a link for multiple links. how can you firewall something and not brake routing? how do you make sure that the netwokr you filter with the firewall is really not ok to pass? Judgement call? But at the same time what if the user ask you to do it. One thing is clear, on an open network architecture the local node that pass 3rd party traffic is not to filter any traffic. this woudl break the routing and prevent actual data that to pass on the route that the layer 2 and 3 decided to be the best. But again how to fix a demand of a use that want to have some traffic filtered from the begining? By creating a non open network. And that is the ONLY REAL solution to prevent the breaking of any route at the layer 3 and make sure that the trafic is ligit. All the route are pointing to the non open network and all the node pass all the traffic that need to pass trough them. Client at the end put firewall to prevent some traffic to reach them but they are end of lines not transporting data to 3rd party. I hope this will help removing some of the fog that flow all over the networking talk. Pierre VE2PF

1 0

Unable to ping any nodes
by CJ Kelley 14 Aug '21

14 Aug '21

Hi Everyone, I was running a JNOS BBS a few months ago and I was able to connect to other nodes on the 44net. I had to take JNOS offline for a few months while some changes to the network were made. No changes were made to the JNOS node, though. The gateway IP did change and it was updated on the AMPR gateway. I have brought the JNOS back up, but now I am not able to ping any 44net node. I am able to ping other servers like google.com. I performed a packet capture and I see that the ICMP request is being sent from JNOS, but the ICMP response is not being received. jnos> ping 44.135.92.10 jnos> Resolving 44.135.92.10... jnos> jnos> jnos> ping google.com jnos> Resolving google.com... 172.217.14.110: rtt 21 It is the same story with other nodes as well. Any recommendations? 73, de KG7UJH Christopher Kelley

6 9

Use cases
by Lynn Grant 12 Aug '21

12 Aug '21

Greetings, I have been a ham for over 50 years (though not recently active), and have been involved with networks for about 20, so I am following the recent discussions with great interest. While I can understand in general terms what might be done with hybrid Internat-ham radio links, I would find it very useful to see examples of what other hams are currently doing with them. Would it be possible to have a few hams do short write-ups on what they are doing, and put them on the ARDC home page? Right now, it seems heavily skewed towards how to set up the networking end of things (which, of course, is very important, and something that hams new to networking could use some help with), with not much attention given to "Why would I want to do this?" Thanks, and 73, Lynn Grant N8AF / V31LK

8 20

Portal requests not processed?
by Iain R. Learmonth 11 Aug '21

11 Aug '21

Hi, I made a request for an allocation via the portal on the 8th but I've not even had so much as an automated message yet. I've sent an email to G1FEF anticipating that some extra justification would be needed and also to provide the LoA details, but nothing. Is everyone on holiday? Thanks, Iain. -- https://hambsd.org/

1 0

intranet security illusion
by ei4ku＠ei4ku.ampr.org 10 Aug '21

10 Aug '21

it just takes one bad actor inside an intranet to spoil your weekend. or maybe not even on purpose: a hijacked phone will do the job. great debate, very informative! 73 de stefan ei4ku

2 1

On Allocations, PoPs, and Proposals
by Rosy Wolfe 10 Aug '21

10 Aug '21

Hello everyone, I, along with the board and staff, have been reading these messages. First of all, I want you all to know that YOU ARE HEARD. The point of having the TAC put out a proposal was to get feedback before adoption. It turns out that a significant part of the feedback is negative. I think that this proposal needs more work and adjustment before we can consider implementing it. The board and I want to see consensus on the main points of a proposal among the major schools of thought on this mailing list. That said, it’s important to remember that the people on this list are not the only people using the AMRPnet. We have a complex task on our hands to reach as many of those people as possible as we evolve proposals toward consensus. Several board members have suggested that it's hard to find consensus on solutions until we have a consensus on what problem(s) the solutions are trying to solve. We have a tangle of issues like the complexity of IPIP tunnels, to BGP routing, to address space sparseness, to low performance. With this in mind, what problems with the AMPRnet do you think we should be trying to solve first? One thing we haven't communicated well before, is that we are actively discussing budget and infrastructure for a “backbone” network of PoPs (Points of Presence) of the 44net on various continents, to make it easier for hams to connect to the AMPRnet with minimal effort and higher performance. If you have ideas about how you would like to see this happen, feel free to share here on the mailing list. I know that there’s at least one alternative proposal on the way. There’s obviously more discussion to be had, but for now, please rest assured that no changes are going to be made without more input from you and others using the AMPRnet. I also want to thank the TAC for their work up to this point. They have dedicated hundreds of hours to come up with this proposal. Even if its release has cause some heated discussion, it’s critical that these discussions happen. They will help all of us come up with the best solution for how to most effectively organize our network for the future. 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

18 49

On Allocations, PoPs, Proposals, and something called RF
by Jeff Archambeault 05 Aug '21

05 Aug '21

Wow. I've been watching lots of message traffic that really only applies to what I would consider to be "edge cases"...BGP especially, when I'm here in the Adirondack State Park in upstate New York, Secretary of the local club (W2WCR), hollering "Hey, we should look into rebuilding the packet network north along the Hudson to Montreal and west to Buffalo along the St Laurence like it used to be." for a few years now and getting "Well, we have winlink, so it's ok." I have my allocation, and can't even use it because my local packet nodes are stuck using some archaic BS that can't route netrom needs either a DOS box with real serial ports and UARTS and a real TNC-2 with 6pack eprom (done, invested about $100 in a mfg-1270c and community-supported eprom...only to find out a year after buying it and waiting that it doesn't work) or an old 2.x Linux kernel to even have half a chance. I'm an extra now, but to be honest, I was really looking forward to playing with packet. The local packet folks have been great, tho similarly frustrated, either with having to attempt to upgrade the existing Eastnet/Flexnet history lesson on sites that aren't exactly accessable or even upgradable, or trying to convince clubs and county-maintained systems that it would be in their best interest to upgrade or replace equipment that used to exist but there is actually no real upgrade/migration path. So I have a node running as best as 24/7 as I can, with no real motivation to do so, no mail feed, wondering what the point actually is. And all I see is BGP BGP BGP BGP....BGP, and oh, BGP mentioned in this mailing list, wondering if there is some relation to CRT, as old as the tech is around here. I thought there was some RF involved, but all I see is BGP. If I wasn't an IT person, with a MikroTik Routerboard, I wouldn't have a clue. That, and the fact that I'm practically in a broadband desert, literally makes me sick and tired of any discussion of connecting anything anywhere that doesn't involve RF. Hm. Perhaps I need to say that again. I AM PERSONALLY SICK AND TIRED OF CONVERSATIONS DEALING WITH PACKET RADIO/AX.25 THAT DOESN'T INVOLVE RF. YOU CAN'T GET THERE FROM HERE!!!!!! FSCK GBP. Some of us can only wish we weren't stuck with hoping someone will connect with our PC3+s or hand-configured direwolf linux/uronode systems who are interested in something called "packet radio". When is someone going to start dealing with the fact that there are AMATEUR __RADIO__ OPERATORS, WITH _AMATEUR RADIO LICENSES_ that may actually be interested in sending digital, AX.25 via IP to other anateur radio operators via RF? I can't possibly be the only one. Geez. Sorry. Just frustrated for a little too long, seeing lots of traffic I'd consider "Much todo about nothing" and lots of money behind it. WTF, over. 73 de Jeff AJ2A Jeff Archambeault Proprietor, Bark Eater Studios Technology Frustration Resolution Solutions jeff(a)barkeaterstudios.com (518) 696-5675 (home) (518) 595-9815 (cell)

6 9

Re: [44net] On Allocations, PoPs, and Proposals
by Jim Ancona 03 Aug '21

03 Aug '21

On Mon, 2 Aug 2021 13:29:33 -0700, Rosy Wolfe <rosy(a)ardc.net> wrote: > With this in mind, what problems with the AMPRnet do you think we should > be trying to solve first? I've been subscribed to the list for a while, but I'm not currently an AMPRnet user. (I have been a ham for over 40 years, and I did run TCP/IP over AX.25 back in the nineties.) My background is in software development, not networking, so while I know about building high-volume web services, and I'd guess I know quite a bit more about networking than the average ham, much of the networking discussion here is well over my head. After trying to follow the discussion, I welcome the board and Rosy's attempt to reset things a bit, but I wonder if instead of asking "What problems with the AMPRnet do you think we should be trying to solve first?," we should first ask and try to answer "What is AMPRnet for?" The TAC document discusses reserving address space for non-Internet-connected "amateur radio-based networks," along with other uses. But as I understand it, some people here don't think that AMPRnet addresses should be reserved for things that will never be part of the Internet. I'd like to see a clear definition of what hams are using AMPRnet addresses for now and what they would like to be able to do in the future. In software development we talk about "use cases." According to Wikipedia: "A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal."[1] An actor might be an individual ham, a network administrator, or someone else. I wonder if trying to describe how AMPRnet is being used today, what is easy and what is too difficult and what we would like to enable in the future would help to provide a basis for discussion. If there were consensus on which use cases are most valuable, which are too hard to accomplish today and similar questions, then we would have a better basis to evaluate proposals with respect to how well they solve the important problems, how difficult or disruptive they are to implement and so forth. Jim N1ADJ 1 - https://en.wikipedia.org/wiki/Use_case

1 0

fyi: was unsubscribed
by Thomas Osterried 01 Aug '21

01 Aug '21

Hello, just fyi: I was unsubscribed from the list since 2921-95-26 (where I received a last posting), without notice. Over the past weeks I thought, it's so quiet - nice, everyone enjoys vacation ;) Anyone else had this issue? vy 73, - Thomas dl9sau

6 11

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net