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
Consider allowing community members to contribute POPs, sort of like APRS2.net. AMPR could provide a couple route servers to direct them all over BGP, sort of like a distributed internet exchange, would be "self healing" but of course some vetting of POPs before had would be needed to approve a certain level of infrastructure. Each pop could also offer VPN endpoints. Just a thought I had literally just now, so take it with a grain of salt hah. -C
-----Original Message----- From: 44Net 44net-bounces+colin.bodor=imperium.ca@mailman.ampr.org On Behalf Of Rosy Wolfe via 44Net Sent: Monday, August 2, 2021 14:30 To: Amprnet 44 Net 44net@mailman.ampr.org Cc: Rosy Wolfe rosy@ardc.net Subject: [44net] On Allocations, PoPs, and Proposals
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
I think much of the thought has been around the POPs being VPN (probably multiprotocol) servers.
On Mon, Aug 2, 2021 at 1:54 PM Colin Bodor via 44Net 44net@mailman.ampr.org wrote:
Consider allowing community members to contribute POPs, sort of like APRS2.net. AMPR could provide a couple route servers to direct them all over BGP, sort of like a distributed internet exchange, would be "self healing" but of course some vetting of POPs before had would be needed to approve a certain level of infrastructure. Each pop could also offer VPN endpoints. Just a thought I had literally just now, so take it with a grain of salt hah. -C
-----Original Message----- From: 44Net 44net-bounces+colin.bodor=imperium.ca@mailman.ampr.org On Behalf Of Rosy Wolfe via 44Net Sent: Monday, August 2, 2021 14:30 To: Amprnet 44 Net 44net@mailman.ampr.org Cc: Rosy Wolfe rosy@ardc.net Subject: [44net] On Allocations, PoPs, and Proposals
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 _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Rosie firstly thank you for reaching out to the community and acknowledging the feedback provided to the proposal over the last few days.
I have a few BGP assignments for various radio clubs, at home and remote repeater sites. One thing I have noticed over the years when requesting resources is how manual the process is, be that resource approvals, DNS delegation, LOA generation or RADB/AltDB entries.
I am not at all against re-addressing and moving into a new IP block if that simplifies routing for other 44net users, but I would not want to go through the process if the ARDC has not invested effort in automating every step of the process to ensure end users are not waiting on coordinators. The RIRs have manual judgement approval steps, but LOAs, public whois DB entries and PTR/NS delegation is all fully automated - we should make sure 44net has this in place prior to any renumbering process.
Also I read a couple of messages where it was stated IPv6 and RPKI would be a second project, if the TAC is pushing for a renumber there should at least be some carrot to entice users to renumber, in my opinion this could be an IPv6 block and RPKI entries. I support Colin's suggestion on contributed POP locations.
I look forward to reading a revised TAC proposal in the coming months,
Nat,
On Mon, Aug 2, 2021 at 9:53 PM Colin Bodor via 44Net 44net@mailman.ampr.org wrote:
Consider allowing community members to contribute POPs, sort of like APRS2.net. AMPR could provide a couple route servers to direct them all over BGP, sort of like a distributed internet exchange, would be "self healing" but of course some vetting of POPs before had would be needed to approve a certain level of infrastructure. Each pop could also offer VPN endpoints. Just a thought I had literally just now, so take it with a grain of salt hah. -C
-----Original Message----- From: 44Net 44net-bounces+colin.bodor=imperium.ca@mailman.ampr.org On Behalf Of Rosy Wolfe via 44Net Sent: Monday, August 2, 2021 14:30 To: Amprnet 44 Net 44net@mailman.ampr.org Cc: Rosy Wolfe rosy@ardc.net Subject: [44net] On Allocations, PoPs, and Proposals
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 _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yes I think the design and deployment of the new backbone network which would replace IPIP tunnels and would offload the mandatory task of (complex) routing from the beginning user should be the first priority. It would lower the bar of entry and it would also solve the issues that the recent TAC proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here in the Netherlands) would be able to offer the function or the hosting of that function for their region. We currently have 1Gbit internet connection, soon to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and performance is not really the first concern at the current load. Focus should be on reliability, possibly through having enough redundancy in the network.
Rob
On 8/2/21 10:29 PM, Rosy Wolfe via 44Net wrote:
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.
I think that performance IS of prime concerne as much as reliability and redundency (wich is the 2 face of a same problem) Reliability with lack of performance will not fix our situation. adding hundreds of milisecond to a network conection , even if stable is in no way an improvement.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 2 août 2021 17:10 À : 44net@mailman.ampr.org Cc : Rob PE1CHL Objet : Re: [44net] On Allocations, PoPs, and Proposals
Yes I think the design and deployment of the new backbone network which would replace IPIP tunnels and would offload the mandatory task of (complex) routing from the beginning user should be the first priority. It would lower the bar of entry and it would also solve the issues that the recent TAC proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here in the Netherlands) would be able to offer the function or the hosting of that function for their region. We currently have 1Gbit internet connection, soon to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and performance is not really the first concern at the current load. Focus should be on reliability, possibly through having enough redundancy in the network.
Rob
On 8/2/21 10:29 PM, Rosy Wolfe via 44Net wrote:
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.
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Pierre,
You should not read too much into that remark that bandwidth is not the first concern. I does not mean "we may as well have bad bandwidth and poor performance", but rather that we are not using that much bandwidth that we need to have the fastest connections and the fastest routers. At the moment our 44.137.0.0/16 gateway has a 1Gbit internet connection but it on average uses only about 30 Mbit/s with peaks of up to ~100 Mbit/s (in each direction). At this moment we are busy moving the servers to a different datacenter because the old one is going to close down, and there we will get 10 Gbit/s but the new datacenter offers us up to 100 Gbit/s. We have chosen not to go that way for now because our equipment has only up to 10 Gbit/s interfaces and going higher would mean more investment. I think that is not warranted at this time. Maybe if we would host a PoP in a worldwide backbone and would get connections from more countries. But at that time it can always be changed. This of course has no influence on latency, that is determined by physical location. We will be next to the AMS-IX.
Rob
On 8/3/21 12:48 AM, pete M via 44Net wrote:
I think that performance IS of prime concerne as much as reliability and redundency (wich is the 2 face of a same problem) Reliability with lack of performance will not fix our situation. adding hundreds of milisecond to a network conection , even if stable is in no way an improvement.
Pierre VE2PF
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 2 août 2021 17:10 À : 44net@mailman.ampr.org Cc : Rob PE1CHL Objet : Re: [44net] On Allocations, PoPs, and Proposals
Yes I think the design and deployment of the new backbone network which would replace IPIP tunnels and would offload the mandatory task of (complex) routing from the beginning user should be the first priority. It would lower the bar of entry and it would also solve the issues that the recent TAC proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here in the Netherlands) would be able to offer the function or the hosting of that function for their region. We currently have 1Gbit internet connection, soon to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and performance is not really the first concern at the current load. Focus should be on reliability, possibly through having enough redundancy in the network.
Rob
Next to AMS-IX, or are you actually peering on AMS-IX? A valid consideration for future POP locations should be internet exchange connectivity. A 100gig connection could be great (if used) but if you want lower latency an IX will be much better than some large transit provider, especially if you are connecting to a geographically local POP. The whole POP proposal reads likes a CDN build but without mentioning the criticality of being peered on exchange points. IXs serve many purposes but one of them is keeping local traffic local, and thus latency "low". I only ask to bring it up as part of the discussion and so I know at least someone else who is dealing with 44net prefixes and an IX 😉 -C
-----Original Message----- From: 44Net 44net-bounces+colin.bodor=imperium.ca@mailman.ampr.org On Behalf Of Rob PE1CHL via 44Net Sent: Tuesday, August 3, 2021 1:21 To: 44net@mailman.ampr.org Cc: Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] On Allocations, PoPs, and Proposals
Pierre,
You should not read too much into that remark that bandwidth is not the first concern. I does not mean "we may as well have bad bandwidth and poor performance", but rather that we are not using that much bandwidth that we need to have the fastest connections and the fastest routers. At the moment our 44.137.0.0/16 gateway has a 1Gbit internet connection but it on average uses only about 30 Mbit/s with peaks of up to ~100 Mbit/s (in each direction). At this moment we are busy moving the servers to a different datacenter because the old one is going to close down, and there we will get 10 Gbit/s but the new datacenter offers us up to 100 Gbit/s. We have chosen not to go that way for now because our equipment has only up to 10 Gbit/s interfaces and going higher would mean more investment. I think that is not warranted at this time. Maybe if we would host a PoP in a worldwide backbone and would get connections from more countries. But at that time it can always be changed. This of course has no influence on latency, that is determined by physical location. We will be next to the AMS-IX.
Rob
On 8/3/21 12:48 AM, pete M via 44Net wrote:
I think that performance IS of prime concerne as much as reliability and redundency (wich is the 2 face of a same problem) Reliability with lack of performance will not fix our situation. adding hundreds of milisecond to a network conection , even if stable is in no way an improvement.
Pierre VE2PF
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 2 août 2021 17:10 À : 44net@mailman.ampr.org Cc : Rob PE1CHL Objet : Re: [44net] On Allocations, PoPs, and Proposals
Yes I think the design and deployment of the new backbone network which would replace IPIP tunnels and would offload the mandatory task of (complex) routing from the beginning user should be the first priority. It would lower the bar of entry and it would also solve the issues that the recent TAC proposal appears to target.
When budget is a problem, I think some of the existing gateways (certainly the one here in the Netherlands) would be able to offer the function or the hosting of that function for their region. We currently have 1Gbit internet connection, soon to be upgraded to 10Gbit, and a powerful system. Furthermore I think that bandwidth and performance is not really the first concern at the current load. Focus should be on reliability, possibly through having enough redundancy in the network.
Rob
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Just as in the current situation, we will not be doing peering ourselves but we leave that to the company that sponsors our hosting. They are well connected to local and international peers and it is so much easier to not have to arrange that. They will advertise our subnet and statically route the traffic to us.
Rob
On 8/3/21 6:01 PM, Colin Bodor via 44Net wrote:
Next to AMS-IX, or are you actually peering on AMS-IX? A valid consideration for future POP locations should be internet exchange connectivity. A 100gig connection could be great (if used) but if you want lower latency an IX will be much better than some large transit provider, especially if you are connecting to a geographically local POP. The whole POP proposal reads likes a CDN build but without mentioning the criticality of being peered on exchange points. IXs serve many purposes but one of them is keeping local traffic local, and thus latency "low". I only ask to bring it up as part of the discussion and so I know at least someone else who is dealing with 44net prefixes and an IX 😉 -C
Ah yes, that is easier, I provide the same thing for several clients. You still get the good routes though!
-----Original Message----- From: 44Net 44net-bounces+colin.bodor=imperium.ca@mailman.ampr.org On Behalf Of Rob PE1CHL via 44Net Sent: Tuesday, August 3, 2021 10:51 To: 44net@mailman.ampr.org Cc: Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] On Allocations, PoPs, and Proposals
Just as in the current situation, we will not be doing peering ourselves but we leave that to the company that sponsors our hosting. They are well connected to local and international peers and it is so much easier to not have to arrange that. They will advertise our subnet and statically route the traffic to us.
Rob
On 8/3/21 6:01 PM, Colin Bodor via 44Net wrote:
Next to AMS-IX, or are you actually peering on AMS-IX? A valid consideration for future POP locations should be internet exchange connectivity. A 100gig connection could be great (if used) but if you want lower latency an IX will be much better than some large transit provider, especially if you are connecting to a geographically local POP. The whole POP proposal reads likes a CDN build but without mentioning the criticality of being peered on exchange points. IXs serve many purposes but one of them is keeping local traffic local, and thus latency "low". I only ask to bring it up as part of the discussion and so I know at least someone else who is dealing with 44net prefixes and an IX 😉 -C
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
For the existing AMPRNet, I echo what Rob PE1CHL and others have stated on this list. Here's my summary though:
1) The barrier to entry for the casual user who wants to connect to the Internet with 44Net space is too high and relies on outdated technology. A technology that is NAT-friendly for IPv4 is imperative. Not only can many people not port-forward in the IPIP protocol, they are increasingly finding themselves behind a CGN and thus are a double-NAT'd. There needs to be a comprehensive, geographically diverse (BY NETWORK not by country border) set of connection points that use modern, NAT-friendly technologies such as OpenVPN and Wireguard. Maybe even L2TP. Offer ALL the options, rather than one option. Options should not require non-standard tooling such as the quasi-RIP routing daemon.
1A) Offer the OpenVPN, Wireguard, and L2TP endpoints on IPv6 addressing as well as IPv4 addressing. This is imperative in 2021.
2) Manual coordination by country/region should be dropped in favor of an automated portal allocation solution, DNS delegation, etc. The volunteers do a great job but it seems unnecessary?
3) Development of a standard "get on 44Net" appliance built on a Pi. Something that reaches out to the solution developed for #1 and brings in the user's allocation for experimentation. This should be a community-driven project that aims to have an EASY setup-and-forget system that provides automatic networking harness for people who want to experiment. Harness the power of the community who like to tinker with networking to help those who don't want to.
Jason N8EI
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Rosy Wolfe via 44Net Sent: Monday, August 2, 2021 4:30 PM To: Amprnet 44 Net 44net@mailman.ampr.org Cc: Rosy Wolfe rosy@ardc.net Subject: [44net] On Allocations, PoPs, and Proposals
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 _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I agree strongly with N8EI's suggestion 3 to base the "Get on Net44" appliance on a Raspberry Pi. It's ubiquitous, capable, and well-understood. Please scale it down as much as possible so that it runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux kernels), make the "appliance" available as an ISO image so that it can be downloaded to an SD card and just stuck into the RPi and booted. Then have a one pager (or even better, a small script) that lets you "fill in the blanks" like callsign, VPN that you're trying to connect to, etc.
Thanks,
Steve N8GNJ
On Mon, Aug 2, 2021 at 3:57 PM Jason McCormick via 44Net 44net@mailman.ampr.org wrote:
For the existing AMPRNet, I echo what Rob PE1CHL and others have stated on this list. Here's my summary though:
- The barrier to entry for the casual user who wants to connect to the Internet with 44Net space is too high and relies on outdated technology. A technology that is NAT-friendly for IPv4 is imperative. Not only can many people not port-forward in the IPIP protocol, they are increasingly finding themselves behind a CGN and thus are a double-NAT'd. There needs to be a comprehensive, geographically diverse (BY NETWORK not by country border) set of connection points that use modern, NAT-friendly technologies such as OpenVPN and Wireguard. Maybe even L2TP. Offer ALL the options, rather than one option. Options should not require non-standard tooling such as the quasi-RIP routing daemon.
1A) Offer the OpenVPN, Wireguard, and L2TP endpoints on IPv6 addressing as well as IPv4 addressing. This is imperative in 2021.
Manual coordination by country/region should be dropped in favor of an automated portal allocation solution, DNS delegation, etc. The volunteers do a great job but it seems unnecessary?
Development of a standard "get on 44Net" appliance built on a Pi. Something that reaches out to the solution developed for #1 and brings in the user's allocation for experimentation. This should be a community-driven project that aims to have an EASY setup-and-forget system that provides automatic networking harness for people who want to experiment. Harness the power of the community who like to tinker with networking to help those who don't want to.
Jason N8EI
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Rosy Wolfe via 44Net Sent: Monday, August 2, 2021 4:30 PM To: Amprnet 44 Net 44net@mailman.ampr.org Cc: Rosy Wolfe rosy@ardc.net Subject: [44net] On Allocations, PoPs, and Proposals
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 _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-- Steve Stroh stevestroh@gmail.com Editor Zero Retries Newsletter - https://zeroretries.substack.com
While I agree that it is attractive to use a Raspberry Pi because of its availability and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
Rob
On 8/3/21 6:26 PM, Steve Stroh via 44Net wrote:
I agree strongly with N8EI's suggestion 3 to base the "Get on Net44" appliance on a Raspberry Pi. It's ubiquitous, capable, and well-understood. Please scale it down as much as possible so that it runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux kernels), make the "appliance" available as an ISO image so that it can be downloaded to an SD card and just stuck into the RPi and booted. Then have a one pager (or even better, a small script) that lets you "fill in the blanks" like callsign, VPN that you're trying to connect to, etc.
Thanks,
Steve N8GNJ
I like the MikroTik Hex line and use them myself but their UI isn't the easiest to deal with and their OpenVPN client in RouterOS v6 isn't very good. I'm waiting for OS 7 where it's said to be improved before I start suggesting that platform.
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Rob PE1CHL via 44Net Sent: Tuesday, August 3, 2021 12:54 PM To: 44net@mailman.ampr.org Cc: Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] On Allocations, PoPs, and Proposals
While I agree that it is attractive to use a Raspberry Pi because of its availability and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
Rob
On 8/3/21 6:26 PM, Steve Stroh via 44Net wrote:
I agree strongly with N8EI's suggestion 3 to base the "Get on Net44" appliance on a Raspberry Pi. It's ubiquitous, capable, and well-understood. Please scale it down as much as possible so that it runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux kernels), make the "appliance" available as an ISO image so that it can be downloaded to an SD card and just stuck into the RPi and booted. Then have a one pager (or even better, a small script) that lets you "fill in the blanks" like callsign, VPN that you're trying to connect to, etc.
Thanks,
Steve N8GNJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
We use L2TP/IPsec, GRE or GRE6 (optionally with IPsec) and it works very well on these routers. An advantage is that they provide the same configuration options on CLI or GUI so it is possible to provide configuration templates ready for cut/paste and still offer GUI for fine tuning. As all config is provided via a single interface it is much easier than plain Linux on e.g. a Pi where multiple config files and scripts have to be edited.
Setting up BGP on these routers is very easy, much easier than getting an IPIP gateway going.
Most important is that the new backbone network should use standard protocols, so that we can use standard routers like this, while those that want to can still use generic OS-es. (they can do IPIP mesh but it is a bit of a convoluted solution, L2TP+BGP is much much easier)
Rob
On 8/3/21 6:56 PM, Jason McCormick via 44Net wrote:
I like the MikroTik Hex line and use them myself but their UI isn't the easiest to deal with and their OpenVPN client in RouterOS v6 isn't very good. I'm waiting for OS 7 where it's said to be improved before I start suggesting that platform.
I'll add a comment here, since I've used the RB750G gear and RPi boards extensively as routers. I *highly* recommend the RPi4B! The difference in SoC processing power is massive, when crunching crypto for VPNs, enough RAM for BGP and other system services, etc. There are many OS/distro sources available and the very latest software version are only a few clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the concern for simply having crummy data thru-put due to crypto processing overhead. I've got several RB750G routers, they're all sitting on the shelf, these days.
For network port fan-out, since the RPi4B has only a single (but REAL) 1GbE port, I mostly use D-Link DGS-1100-08 switches. They've got good support for 802.1q VLANs and are very economical ($35 or less).
I've also got a small fleet of Rock64 boards installed, since they were available with REAL 1GbE ports before the RPi4B was available.
Don't underestimate how capable this solution is! This gear is rock-solid, super inexpensive and available everywhere. Further, you're not locked into a single vendor/hardware platform, as the technology continues to leap forward.
These days, about the only time I gravitate to higher end gear is where I need faster router port speeds---10GbE or faster.
73, David KB4FXC
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
While I agree that it is attractive to use a Raspberry Pi because of its availability
and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
Rob
On 8/3/21 6:26 PM, Steve Stroh via 44Net wrote:
I agree strongly with N8EI's suggestion 3 to base the "Get on Net44" appliance on a Raspberry Pi. It's ubiquitous, capable, and well-understood. Please scale it down as much as possible so that it runs on a RPi 3 (so that there's at least one Ethernet port).
Please (for those of us mortals who don't routinely compile Linux kernels), make the "appliance" available as an ISO image so that it can be downloaded to an SD card and just stuck into the RPi and booted. Then have a one pager (or even better, a small script) that lets you "fill in the blanks" like callsign, VPN that you're trying to connect to, etc.
Thanks,
Steve N8GNJ
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
As I wrote in another reply, for each problem and each admin there is a different solution. The RB750Gr3 runs IPsec at >450Mbit/s which is enough for most users. Do not use OpenVPN on these devices, use L2TP/IPsec or GRE/IPsec.
I am currently in mail exchange with someone who wants to configure AMPRnet access on a VPS using standard Linux software. Easy peasy when you ask me, but it is a nightmare to get someone going who has no Linux admin skills at all and is only cutting/pasting error messages all the time, and not really reading the directions or able to debug things without constant hand-helding. With a MikroTik he would be going, with the Linux system he is only whining and complaining. (but others get it working after only a single message with some hints)
Read back in the 44Net mail archives and you can see the same discussion over and over, so I think this is enough for now.
Rob
On 8/3/21 7:29 PM, David McGough via 44Net wrote:
I'll add a comment here, since I've used the RB750G gear and RPi boards extensively as routers. I *highly* recommend the RPi4B! The difference in SoC processing power is massive, when crunching crypto for VPNs, enough RAM for BGP and other system services, etc. There are many OS/distro sources available and the very latest software version are only a few clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the concern for simply having crummy data thru-put due to crypto processing overhead. I've got several RB750G routers, they're all sitting on the shelf, these days.
Hi Rob,
Not trying to belabor the Linux discussion; agreed, it has been tossed around many times over the last decade+. I do have one more comment, thought.
I fully agree that a complete roll-it-for-yourself Linux routing solution is totally impractical for 99.9% of users and would be a nightmare for maintainers....I'm the developer and maintainer of HamVoIP (with about 10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
As I wrote in another reply, for each problem and each admin there
is a different solution. The RB750Gr3 runs IPsec at >450Mbit/s which is enough for most users. Do not use OpenVPN on these devices, use L2TP/IPsec or GRE/IPsec.
I am currently in mail exchange with someone who wants to configure AMPRnet access on a VPS using standard Linux software. Easy peasy when you ask me, but it is a nightmare to get someone going who has no Linux admin skills at all and is only cutting/pasting error messages all the time, and not really reading the directions or able to debug things without constant hand-helding. With a MikroTik he would be going, with the Linux system he is only whining and complaining. (but others get it working after only a single message with some hints)
Read back in the 44Net mail archives and you can see the same discussion over and over, so I think this is enough for now.
Rob
On 8/3/21 7:29 PM, David McGough via 44Net wrote:
I'll add a comment here, since I've used the RB750G gear and RPi boards extensively as routers. I *highly* recommend the RPi4B! The difference in SoC processing power is massive, when crunching crypto for VPNs, enough RAM for BGP and other system services, etc. There are many OS/distro sources available and the very latest software version are only a few clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the concern for simply having crummy data thru-put due to crypto processing overhead. I've got several RB750G routers, they're all sitting on the shelf, these days.
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Well yes, it is probably "easy to do". But you need to be aware that you get into a commitment that you need to sustain for many years. It is doable to make a downloadable image for the Raspberry Pi and maybe some config screen to set it up, and put it on a website, but after some time the software gets outdated, new models of Pi appear that require or prefer a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio oriented services which was published around 6 years ago. I downloaded that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with it. Nice. It was based on the first Raspbian (Debian Wheezy I think). I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it. He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published anymore. The user was not really a Linux noob so I explained him how in principle one can update Debian to the next version, and he did that and stepped to the next version (Jessie). That went well, although it of course was quite some work to process all edits of config files, and he had an issue with a package no longer supported. Fixed all that. Now the next step, but that failed completely. Too many problems. (I have done this on PC systems and I know that it requires quite some attention and skills)
So now such a user is at a dead end: they can go back to the saved card image and run outdated software forever and no longer be able to do new things, or they have to re-invent the whole wheel (download recent OS image for the Pi and then install all the wanted packages and configure them). At that time the advantage of having a prepared install is lost completely, works even against you as you have no knowledge of what was exactly done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router with current software, you have to be aware that you have the moral obligation to track the developments of the OS and hardware and keep releasing new versions about once a year, or you will leave your happy users behind in frustration.
Then, it may not be that easy after all.
Rob
On 8/3/21 8:37 PM, David McGough via 44Net wrote:
I fully agree that a complete roll-it-for-yourself Linux routing solution is totally impractical for 99.9% of users and would be a nightmare for maintainers....I'm the developer and maintainer of HamVoIP (with about 10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
Rob, I already do this (https://hamvoip.org)! I fully understand the concerns.
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
Well yes, it is probably "easy to do". But you need to be aware that you
get into a commitment that you need to sustain for many years. It is doable to make a downloadable image for the Raspberry Pi and maybe some config screen to set it up, and put it on a website, but after some time the software gets outdated, new models of Pi appear that require or prefer a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio oriented services which was published around 6 years ago. I downloaded that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with it. Nice. It was based on the first Raspbian (Debian Wheezy I think). I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it. He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published anymore. The user was not really a Linux noob so I explained him how in principle one can update Debian to the next version, and he did that and stepped to the next version (Jessie). That went well, although it of course was quite some work to process all edits of config files, and he had an issue with a package no longer supported. Fixed all that. Now the next step, but that failed completely. Too many problems. (I have done this on PC systems and I know that it requires quite some attention and skills)
So now such a user is at a dead end: they can go back to the saved card image and run outdated software forever and no longer be able to do new things, or they have to re-invent the whole wheel (download recent OS image for the Pi and then install all the wanted packages and configure them). At that time the advantage of having a prepared install is lost completely, works even against you as you have no knowledge of what was exactly done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router with current software, you have to be aware that you have the moral obligation to track the developments of the OS and hardware and keep releasing new versions about once a year, or you will leave your happy users behind in frustration.
Then, it may not be that easy after all.
Rob
On 8/3/21 8:37 PM, David McGough via 44Net wrote:
I fully agree that a complete roll-it-for-yourself Linux routing solution is totally impractical for 99.9% of users and would be a nightmare for maintainers....I'm the developer and maintainer of HamVoIP (with about 10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
And my point was that is should be an AMPR/ARDC project that's maintained and moved forward by ARDC. It shouldn't just be a one-person Github repo.
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of David McGough via 44Net Sent: Tuesday, August 3, 2021 3:15 PM To: Rob PE1CHL via 44Net 44net@mailman.ampr.org Cc: David McGough kb4fxc@inttek.net Subject: Re: [44net] On Allocations, PoPs, and Proposals
Rob, I already do this (https://hamvoip.org)! I fully understand the concerns.
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
Well yes, it is probably "easy to do". But you need to be aware that you
get into a commitment that you need to sustain for many years. It is doable to make a downloadable image for the Raspberry Pi and maybe some config screen to set it up, and put it on a website, but after some time the software gets outdated, new models of Pi appear that require or prefer a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio oriented services which was published around 6 years ago. I downloaded that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with it. Nice. It was based on the first Raspbian (Debian Wheezy I think). I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it. He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published anymore. The user was not really a Linux noob so I explained him how in principle one can update Debian to the next version, and he did that and stepped to the next version (Jessie). That went well, although it of course was quite some work to process all edits of config files, and he had an issue with a package no longer supported. Fixed all that. Now the next step, but that failed completely. Too many problems. (I have done this on PC systems and I know that it requires quite some attention and skills)
So now such a user is at a dead end: they can go back to the saved card image and run outdated software forever and no longer be able to do new things, or they have to re-invent the whole wheel (download recent OS image for the Pi and then install all the wanted packages and configure them). At that time the advantage of having a prepared install is lost completely, works even against you as you have no knowledge of what was exactly done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router with current software, you have to be aware that you have the moral obligation to track the developments of the OS and hardware and keep releasing new versions about once a year, or you will leave your happy users behind in frustration.
Then, it may not be that easy after all.
Rob
On 8/3/21 8:37 PM, David McGough via 44Net wrote:
I fully agree that a complete roll-it-for-yourself Linux routing solution is totally impractical for 99.9% of users and would be a nightmare for maintainers....I'm the developer and maintainer of HamVoIP (with about 10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Rob:
Points well made, but what's different from your example, and the situation with a potential Net44 appliance based on a Raspberry Pi is that there's now budget available from ARDC to contract for such "routine, boring maintenance" to keep the Net44 appliance image up to date. And, potentially, to provide support for it (such as documentation).
Such that, when RPi OS is updated, so is the Net44 appliance image because it's someone's job to do so.
That should take a lot of the sting out of the usage of the Raspberry Pi as a Net44 appliance.
Steve Stroh N8GNJ
On Tue, Aug 3, 2021 at 12:03 PM Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:
Well yes, it is probably "easy to do". But you need to be aware that you get into a commitment that you need to sustain for many years. It is doable to make a downloadable image for the Raspberry Pi and maybe some config screen to set it up, and put it on a website, but after some time the software gets outdated, new models of Pi appear that require or prefer a new kernel, the Raspbian gets updated, etc.
A good example is HamServerPi, a ready-made image with some hamradio oriented services which was published around 6 years ago. I downloaded that, put it on SD card, installed it in a Raspberry Pi 1 and played a bit with it. Nice. It was based on the first Raspbian (Debian Wheezy I think). I am not really using it as I have a PC running Linux all the time.
Recently I had mail contact with someone who was still running it. He wanted to do some new things but there were missing dependencies.
Now, this project has been abandoned. No new images were published anymore. The user was not really a Linux noob so I explained him how in principle one can update Debian to the next version, and he did that and stepped to the next version (Jessie). That went well, although it of course was quite some work to process all edits of config files, and he had an issue with a package no longer supported. Fixed all that. Now the next step, but that failed completely. Too many problems. (I have done this on PC systems and I know that it requires quite some attention and skills)
So now such a user is at a dead end: they can go back to the saved card image and run outdated software forever and no longer be able to do new things, or they have to re-invent the whole wheel (download recent OS image for the Pi and then install all the wanted packages and configure them). At that time the advantage of having a prepared install is lost completely, works even against you as you have no knowledge of what was exactly done to make that and what you should do to re-create it.
So when you make that shiny SD card image today which creates the router with current software, you have to be aware that you have the moral obligation to track the developments of the OS and hardware and keep releasing new versions about once a year, or you will leave your happy users behind in frustration.
Then, it may not be that easy after all.
Rob
That is exactly what I'm doing here. I have existing working configs in one big zip file what I upload and configure for their situation. They only thing what they have to do is installation of the basic Linux distro and make a ssh port available. Of course, that is much more then IPIP tunnels. (IPIP is not difficult at all, most issues are routers/fw's not passing it, less an issue nowadays with dd-wrt and otherwise, I provide a VPN from my gateway or another solution.) The rest is something else, but this provide all kinds of (tcp/ip) services and also old style packet, if they want it. A lot are maybe new or have just less experience with this stuff. Some, just need an example and after some E-mails and assistance, they figure it out themselves.
Bob
On 2021-08-03 14:37, David McGough via 44Net wrote:
Hi Rob,
Not trying to belabor the Linux discussion; agreed, it has been tossed around many times over the last decade+. I do have one more comment, thought.
I fully agree that a complete roll-it-for-yourself Linux routing solution is totally impractical for 99.9% of users and would be a nightmare for maintainers....I'm the developer and maintainer of HamVoIP (with about 10,000 users), so I know this well!!
My suggestion would be to roll an (almost) plug-and-play distro (or packages), to make the Linux setup process trivial.
This is doable, if fact, probably even easy to do.
73, David KB4FXC
On Tue, 3 Aug 2021, Rob PE1CHL via 44Net wrote:
As I wrote in another reply, for each problem and each admin there
is a different solution. The RB750Gr3 runs IPsec at >450Mbit/s which is enough for most users. Do not use OpenVPN on these devices, use L2TP/IPsec or GRE/IPsec.
I am currently in mail exchange with someone who wants to configure AMPRnet access on a VPS using standard Linux software. Easy peasy when you ask me, but it is a nightmare to get someone going who has no Linux admin skills at all and is only cutting/pasting error messages all the time, and not really reading the directions or able to debug things without constant hand-helding. With a MikroTik he would be going, with the Linux system he is only whining and complaining. (but others get it working after only a single message with some hints)
Read back in the 44Net mail archives and you can see the same discussion over and over, so I think this is enough for now.
Rob
On 8/3/21 7:29 PM, David McGough via 44Net wrote:
I'll add a comment here, since I've used the RB750G gear and RPi boards extensively as routers. I *highly* recommend the RPi4B! The difference in SoC processing power is massive, when crunching crypto for VPNs, enough RAM for BGP and other system services, etc. There are many OS/distro sources available and the very latest software version are only a few clicks away.
Also, MikroTik support for OpenVPN is seriously lacking--beyond the concern for simply having crummy data thru-put due to crypto processing overhead. I've got several RB750G routers, they're all sitting on the shelf, these days.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its availability and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment : - People building networks, remote sites, repeaters, or advanced users with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc... - Beginners or standalone users may prefer plug-and-play setup on a Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its availability and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment : - People building networks, remote sites, repeaters, or advanced users with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc... - Beginners or standalone users may prefer plug-and-play setup on a Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its
availability
and the capability to also host some applications on the same device
aside from
doing the routing, in my experience it is much easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for about the same price, but
having
5 ethernet ports and all software required for VPN and routing
pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
USB adapter or the use of VLAN tags and a managed switch.
ex: https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi-...
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net 44net@mailman.ampr.org wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its
availability
and the capability to also host some applications on the same device
aside from
doing the routing, in my experience it is much easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for about the same price, but
having
5 ethernet ports and all software required for VPN and routing
pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Thanks for the suggestion Steve.
The use of Vlan and a managed switch seem like a good idea. But you need to remember 2 thing in the solution that need to be deployed here. Not every switch is managable, most that are will cost more than the RPI, lambda ham does not even know what a Vlan is. And using a cheap repurposed 10/100 switch will provide a maximum 50 Mb/s at max as it will be used twice for each inbound/outbound packets. But it will be a more stable solution than USB Ethernet NIC.
We need to supply a simple and stable solution for the average ham that start in networking and easy to support. useage of Vlan wont cut it. USB ethernet nic will be the same. Yes the RPI 4 will do it. But you have to remember that most ham's that have a RPI 2 or even a RPI B will want to use his board to experiement. If we do this we will loose the interest of many by offerring networks that will be slow compared to what they are use to. And if by bad luck we fall on the geek of the place that the other ham look upon to use a specific tehnology or not, the 44net wont be used in large chunk of the globe. This aint our goal.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Steve L via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 16:46 À : 44Net general discussion Cc : Steve L Objet : Re: [44net] On Allocations, PoPs, and Proposals
USB adapter or the use of VLAN tags and a managed switch.
ex: https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi-...
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net 44net@mailman.ampr.org wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its
availability
and the capability to also host some applications on the same device
aside from
doing the routing, in my experience it is much easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for about the same price, but
having
5 ethernet ports and all software required for VPN and routing
pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a very competent router that is rock-solid.
73, David KB4FXC
On Mon, 9 Aug 2021, pete M via 44Net wrote:
Thanks for the suggestion Steve.
The use of Vlan and a managed switch seem like a good idea. But you need to remember 2 thing in the solution that need to be deployed here. Not every switch is managable, most that are will cost more than the RPI, lambda ham does not even know what a Vlan is. And using a cheap repurposed 10/100 switch will provide a maximum 50 Mb/s at max as it will be used twice for each inbound/outbound packets. But it will be a more stable solution than USB Ethernet NIC.
We need to supply a simple and stable solution for the average ham that start in networking and easy to support. useage of Vlan wont cut it. USB ethernet nic will be the same. Yes the RPI 4 will do it. But you have to remember that most ham's that have a RPI 2 or even a RPI B will want to use his board to experiement. If we do this we will loose the interest of many by offerring networks that will be slow compared to what they are use to. And if by bad luck we fall on the geek of the place that the other ham look upon to use a specific tehnology or not, the 44net wont be used in large chunk of the globe. This aint our goal.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Steve L via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 16:46 À : 44Net general discussion Cc : Steve L Objet : Re: [44net] On Allocations, PoPs, and Proposals
USB adapter or the use of VLAN tags and a managed switch.
ex: https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi-...
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net 44net@mailman.ampr.org wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its
availability
and the capability to also host some applications on the same device
aside from
doing the routing, in my experience it is much easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for about the same price, but
having
5 ethernet ports and all software required for VPN and routing
pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Another great option, with a x64 compatible CPU and 3 or 4 real gigabit ports, M2 SSD and optional mini-PCIe extensions (e.g. WiFi, LoRa or 3G+).
https://pcengines.ch/apu3b4.htm
https://pcengines.ch/apu4c4.htm
73, Marius YO2LOJ
On 10/08/2021 00:41, David McGough via 44Net wrote:
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a very competent router that is rock-solid.
73, David KB4FXC
"Exotic" hardware and VLANs are not "get easily on 44Net". Seriously, at the speeds the average non-BGP-advertised ham needs, a Pi4 with an additional USB-connected Ethernet port will work just fine and meet any necessary performance goals and be the most approachable format for both connecting wires and online help availability. Given that, in general, you can't buy the older Pis anymore I would think most people are getting a Pi4.
Jason N8EI
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Marius Petrescu via 44Net Sent: Monday, August 9, 2021 5:48 PM To: 44net@mailman.ampr.org Cc: Marius Petrescu marius@yo2loj.ro Subject: Re: [44net] On Allocations, PoPs, and Proposals
Another great option, with a x64 compatible CPU and 3 or 4 real gigabit ports, M2 SSD and optional mini-PCIe extensions (e.g. WiFi, LoRa or 3G+).
https://pcengines.ch/apu3b4.htm
https://pcengines.ch/apu4c4.htm
73, Marius YO2LOJ
On 10/08/2021 00:41, David McGough via 44Net wrote:
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a very competent router that is rock-solid.
73, David KB4FXC
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
True, but remember that you can buy a MikroTik RB750Gr3 for the same amount of money and you have 5 ethernet ports plus USB without the hassle, and it runs as a router without further software installation. When you want to run applications, you can always add a Pi4 connected to one of its ports.
People sometimes remark "but $59.95 for that router that is more expensive than a Pi" but remember it comes with an enclosure, memory, and a powersupply. To a Pi you need to add an enclosure, SD card, and a powersupply at minimum and then possibly USB ethernet adapter(s).
Rob
On 8/9/21 11:59 PM, Jason McCormick via 44Net wrote:
"Exotic" hardware and VLANs are not "get easily on 44Net". Seriously, at the speeds the average non-BGP-advertised ham needs, a Pi4 with an additional USB-connected Ethernet port will work just fine and meet any necessary performance goals and be the most approachable format for both connecting wires and online help availability. Given that, in general, you can't buy the older Pis anymore I would think most people are getting a Pi4.
Jason N8EI
I know its more expensive than a PI but:-
1. Router models seem to come and go like the sun in a UK summer. Whilst PIs evolve I can't see them vanishing. 2. Its possible to make the PI pretty much plug-and-play. I have a Pi running PI-Star and can connect to DMR and YSF. Wouldn't it be great if it could do so over 44net.
Dave G4UGM
-----Original Message----- From: 44Net 44net-bounces+dave.g4ugm=gmail.com@mailman.ampr.org On Behalf Of Rob PE1CHL via 44Net Sent: 10 August 2021 08:42 To: 44net@mailman.ampr.org Cc: Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] On Allocations, PoPs, and Proposals
True, but remember that you can buy a MikroTik RB750Gr3 for the same amount of money and you have 5 ethernet ports plus USB without the hassle, and it runs as a router without further software installation. When you want to run applications, you can always add a Pi4 connected to one of its ports.
People sometimes remark "but $59.95 for that router that is more expensive than a Pi" but remember it comes with an enclosure, memory, and a powersupply. To a Pi you need to add an enclosure, SD card, and a powersupply at minimum and then possibly USB ethernet adapter(s).
Rob
On 8/9/21 11:59 PM, Jason McCormick via 44Net wrote:
"Exotic" hardware and VLANs are not "get easily on 44Net". Seriously, at
the speeds the average non-BGP-advertised ham needs, a Pi4 with an additional USB-connected Ethernet port will work just fine and meet any necessary performance goals and be the most approachable format for both connecting wires and online help availability. Given that, in general, you can't buy the older Pis anymore I would think most people are getting a Pi4.
Jason N8EI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Well, actually these routers have existed and evolved for longer than the Raspberry Pi. Of course they could vanish but as we are (hopefully) no longer using proprietary protocols in the routing layer, they can always be replaced by something else.
Actually whn you run your applications on the same system where you do the routing, there is an extra issue that many admins do not understand: source address selection. At least with two different systems for applications and routings you don't have that issue.
Rob
On 8/10/21 10:04 AM, g4ugm via 44Net wrote:
I know its more expensive than a PI but:-
- Router models seem to come and go like the sun in a UK summer. Whilst PIs evolve I can't see them vanishing.
- Its possible to make the PI pretty much plug-and-play. I have a Pi running PI-Star and can connect to DMR and YSF. Wouldn't it be great if it could do so over 44net.
Dave G4UGM
ARDC has $, build a custom carrier for a CM4 that has 2 Ethernet ports, a USB hub, a couple of serial ports et, sell it to Hams below cost, problem goes away. There are all kids of options, and there is no one size fits all. the point here is to come up with "easy ways" to get on the net. Cheap, Easy, Performant pick 2.
On Mon, Aug 9, 2021 at 2:43 PM David McGough via 44Net < 44net@mailman.ampr.org> wrote:
These work GREAT!
https://www.amazon.com/gp/product/B08P2C2GXF/
Use the native 1GbE port on an RPi4B or Rock64 with VLANs and this makes a very competent router that is rock-solid.
73, David KB4FXC
On Mon, 9 Aug 2021, pete M via 44Net wrote:
Thanks for the suggestion Steve.
The use of Vlan and a managed switch seem like a good idea. But you need to remember 2 thing in the solution that need to be
deployed here.
Not every switch is managable, most that are will cost more than the
RPI, lambda ham does not even know what a Vlan is. And using a cheap repurposed 10/100 switch will provide a maximum 50 Mb/s at max as it will be used twice for each inbound/outbound packets. But it will be a more stable solution than USB Ethernet NIC.
We need to supply a simple and stable solution for the average ham that
start in networking and easy to support. useage of Vlan wont cut it. USB ethernet nic will be the same. Yes the RPI 4 will do it. But you have to remember that most ham's that have a RPI 2 or even a RPI B will want to use his board to experiement. If we do this we will loose the interest of many by offerring networks that will be slow compared to what they are use to. And if by bad luck we fall on the geek of the place that the other ham look upon to use a specific tehnology or not, the 44net wont be used in large chunk of the globe. This aint our goal.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la
part de Steve L via 44Net 44net@mailman.ampr.org
Envoyé : 9 août 2021 16:46 À : 44Net general discussion Cc : Steve L Objet : Re: [44net] On Allocations, PoPs, and Proposals
USB adapter or the use of VLAN tags and a managed switch.
ex:
https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi-...
On Mon, Aug 9, 2021 at 12:20 PM K7VE - John via 44Net 44net@mailman.ampr.org wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add
multiple
Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net <
44net@mailman.ampr.org>
wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi
NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work,
but I
would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de
la
part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because
of its
availability
and the capability to also host some applications on the same
device
aside from
doing the routing, in my experience it is much easier to use a
dedicated
router
like the MikroTik hEX (RB750Gr3) available for about the same
price, but
having
5 ethernet ports and all software required for VPN and routing
pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi
should be
one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced
users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is
Pi-Star
(a very good Pi appliance for digital modes hotspot or repeater,
which
embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
My experience with usb to ethernet has never been great. They do make good sidekick device to debug or for temporary things. But over the long run they fail more than we can hope it not.
And the USB stack of the RPI is not that fast. So if the CPUis already busy with decrpting a tunnel packet the flow will drop pretty fast.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de K7VE - John via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 13:17 À : 44Net general discussion Cc : K7VE - John Objet : Re: [44net] On Allocations, PoPs, and Proposals
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit :
While I agree that it is attractive to use a Raspberry Pi because of its
availability
and the capability to also host some applications on the same device
aside from
doing the routing, in my experience it is much easier to use a dedicated
router
like the MikroTik hEX (RB750Gr3) available for about the same price, but
having
5 ethernet ports and all software required for VPN and routing
pre-installed and
much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be
one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
------------------------------ John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Pete:
Understood that the Raspberry Pi isn't the best fit for a "Net44 VPN router". It's a general purpose computer, kind-of underpowered (until the RPi 4s) and adding a second Ethernet port via USB isn't ideal.
There are, of course, "Raspberry Pi" systems like this with dual "real" Ethernet ports - https://www.seeedstudio.com/Rapberry-Pi-CM4-Dual-GbE-Carrier-Board-p-4874.ht..., but that kind of negates the "training wheels" aspect of the Raspberry Pi solution. At the point you're considering such a system, there are real routers.
But there's a lot of us (and I count myself among them) for which the "training wheels" aspect of a Net44 router on a RPi would be a decent starting point.
Steve N8GNJ
On Mon, Aug 9, 2021 at 1:59 PM pete M via 44Net 44net@mailman.ampr.org wrote:
My experience with usb to ethernet has never been great. They do make good sidekick device to debug or for temporary things. But over the long run they fail more than we can hope it not.
And the USB stack of the RPI is not that fast. So if the CPUis already busy with decrpting a tunnel packet the flow will drop pretty fast.
yes, one CAN add a hundred billion USB to Ethernet adapters to the pi. Yes, Linux WILL even run vlans..... but that doesn't make the PI a GOOD choice for a routing appliance with only a single ethernet port which if I remember right is itself connected via usb. A much better thing to base such an appliance on would be a board that had at least 3 (local and dual uplinks) separate hardware gigabit ethernet interfaces with each being attached to a vlan capable switch chip. Then design and build (or simply buy, aka wifi bridge) an ethernet to bits radio tranceiver. Could we not say together with TAPR, come up with and build the next TNC2021 (escentially a 3 port GigE router) and a DR2021 (long haul, point to point microwave data radio) and keep it at a price point around say $300 US. (about the cost of a decent mobile radio). This is where some of that Grant money and funds from ARDC ought be going...... To design and build needs based hardware for amaterur radio networks. Let's build a starter appliance for those who want to learn networking via 44net use. We have a grand opportunity yo elmer and teach the next generation of rf microwave data network, engineers. Given the way it's going it's going to bits and pieces (packets) (bad pun). lets take the lead and innovate while teaching the next generation. It gives us just one more important reason for which to hang on to our precious frequency allocations. May we lead in these areas and come up with a recommended appliance and config. That would move us far ahead.
On 2021-08-09 10:17, K7VE - John via 44Net wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit : While I agree that it is attractive to use a Raspberry Pi because of its availability and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Eric have a VERY valid point.
Just one thing we need to confirm, the board ADRC will choose to promote will need to be a long term product and make sure that if there is a "new" improved version of it that the work they did to make the booting image is also compatible or easily portable.
If it would be compatible with openWRT would be a very good thing. And I think ARDC could even have a large scale rabate. This and a wa to mary a Ubiquity or Mikrotic dish or omni antenna And the capacity to either be a part of a "backbone" and/or a mesh and we have a winning solution.
I know that the entry level price of the raspberry pi is very appealing. Yes it would be nice to have a capacity to have the ethernet port to be able to connect to 44net and recive a /32. This could be a fun project to do. But it is not a viable one if anyone want to scale up a bit. the limitation will come back to bite us very fast.
If ARDC want to use raspeberry pi with let say pi-star/net44 interconnect, make it claer that it is ONLY for local terminaison of the network (client only) not for client and routing capacity.
In fact the real thing a Raspberry pi should do is to connect to a POP and recive a /32 and maybe relay it by wifi to other machine around the house just for fun. (Acces point mode) There are also a few distro that are specific to ham radio for the raspberry pi. Like HamPi https://github.com/dslotter/HamPi
Maybe contact those guys that are already supporting 80+ apps for ham on a rpi and ask if they would be ok to add a way to connect those RPI to net44 trough one of the POP with a simple wizard that would ask a few question like ID/password/location and if they are already connected to one of the networks or mesh on the 44 net to make sure no one will make bridges with out understanding what they are doing. And the wizard could do the hard pulling of configuring the network/vpn or wireguard etc. for the ham to actually connect to net 44 for his ham stuff.
This could be a very short time action ARDC could do to spark the use of net44
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Af6ep via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 22:04 À : 44Net general discussion Cc : eric.fort.listmail@fortconsulting.org Objet : Re: [44net] On Allocations, PoPs, and Proposals
yes, one CAN add a hundred billion USB to Ethernet adapters to the pi. Yes, Linux WILL even run vlans..... but that doesn't make the PI a GOOD choice for a routing appliance with only a single ethernet port which if I remember right is itself connected via usb. A much better thing to base such an appliance on would be a board that had at least 3 (local and dual uplinks) separate hardware gigabit ethernet interfaces with each being attached to a vlan capable switch chip. Then design and build (or simply buy, aka wifi bridge) an ethernet to bits radio tranceiver. Could we not say together with TAPR, come up with and build the next TNC2021 (escentially a 3 port GigE router) and a DR2021 (long haul, point to point microwave data radio) and keep it at a price point around say $300 US. (about the cost of a decent mobile radio). This is where some of that Grant money and funds from ARDC ought be going...... To design and build needs based hardware for amaterur radio networks. Let's build a starter appliance for those who want to learn networking via 44net use. We have a grand opportunity yo elmer and teach the next generation of rf microwave data network, engineers. Given the way it's going it's going to bits and pieces (packets) (bad pun). lets take the lead and innovate while teaching the next generation. It gives us just one more important reason for which to hang on to our precious frequency allocations. May we lead in these areas and come up with a recommended appliance and config. That would move us far ahead.
On 2021-08-09 10:17, K7VE - John via 44Net wrote:
Pete,
RPI works just fine with USB to Ethernet adapters. You can add multiple Ethernet connections in this way.
On Mon, Aug 9, 2021 at 9:06 AM pete M via 44Net 44net@mailman.ampr.org wrote:
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
Entering by Wi-Fi then out from the Ethernet port? That can work, but I would not like that.
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 05:07 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 18:54, Rob PE1CHL via 44Net a écrit : While I agree that it is attractive to use a Raspberry Pi because of its availability and the capability to also host some applications on the same device aside from doing the routing, in my experience it is much easier to use a dedicated router like the MikroTik hEX (RB750Gr3) available for about the same price, but having 5 ethernet ports and all software required for VPN and routing pre-installed and much easier to configure and maintain than a Raspberry Pi.
Of course there always are multiple options. And Raspberry Pi should be one of them.
The network setup must be as standard as possible, so that it can be implemented on a large amount of equipment :
- People building networks, remote sites, repeaters, or advanced users
with some network knowledge, may prefer a dedicated router platform, such as Mikrotik, UBNT, OpenWRT, etc...
- Beginners or standalone users may prefer plug-and-play setup on a
Raspberry Pi. The most obvious example that comes to my mind is Pi-Star (a very good Pi appliance for digital modes hotspot or repeater, which embeds many existing software for D-Star, DMR, YSF etc... into a coherent and easy to use WEB UI).
73 de TK1BI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Le 10/08/2021 à 20:45, pete M via 44Net a écrit :
If ARDC want to use raspeberry pi with let say pi-star/net44 interconnect, make it claer that it is ONLY for local terminaison of the network (client only) not for client and routing capacity.
That's what I was meaning, too. It's for easy implementation of plug-and-play appliances. It would be a "first step" into 44net.
Later, if people is interested in 44net and wants to connect more than one equipment, migrating to a full "Access" router would be the right choice (Mikrotik, OpenWRT, etc...)
I think that we are on the same page ;-)
Nice to see that I am not the only one.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 10 août 2021 17:31 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 10/08/2021 à 20:45, pete M via 44Net a écrit :
If ARDC want to use raspeberry pi with let say pi-star/net44 interconnect, make it claer that it is ONLY for local terminaison of the network (client only) not for client and routing capacity.
That's what I was meaning, too. It's for easy implementation of plug-and-play appliances. It would be a "first step" into 44net.
Later, if people is interested in 44net and wants to connect more than one equipment, migrating to a full "Access" router would be the right choice (Mikrotik, OpenWRT, etc...)
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Le 09/08/2021 à 18:05, pete M via 44Net a écrit :
I have a question about using a RPI for net44.
Since this device only have one physical Ethernet port (and a Wi-Fi NIC).
By which way are you hoping to use those to route some traffic?
The main purpose of a Raspberry Pi appliance is not to act as a router. It's to provide easy plug-and-play 44Net connectivity for software already running on the Pi. F/ex, Pi-Star is a great appliance for digital modes (D-Star, DMR, C4FM...). The vast majority of digital repeaters and reflectors all over the world are currently connected through normal Internet. This would allow those nodes to be connected to 44net instead of Internet. Pi-Star is really "Plug and Play" : you flash a sd-card, you change a few settings through the web interface (callsign, etc...) and it works. We need the same thing for 44Net addressing :-)
Of course, this does not replace routers, which are the preferred way to connect a local network to 44net. This is an alternative option, to allow mass adoption of 44net, for people who are not network specialists, and just want things to work HI :-)
73 de TK1BI
Hi all, and thank you for all the work.
Le 03/08/2021 à 00:56, Jason McCormick via 44Net a écrit :
For the existing AMPRNet, I echo what Rob PE1CHL and others have stated on this list. Here's my summary though:
- The barrier to entry for the casual user who wants to connect to the Internet with 44Net space is too high and relies on outdated technology. A technology that is NAT-friendly for IPv4 is imperative. Not only can many people not port-forward in the IPIP protocol, they are increasingly finding themselves behind a CGN and thus are a double-NAT'd. There needs to be a comprehensive, geographically diverse (BY NETWORK not by country border) set of connection points that use modern, NAT-friendly technologies such as OpenVPN and Wireguard. Maybe even L2TP. Offer ALL the options, rather than one option. Options should not require non-standard tooling such as the quasi-RIP routing daemon.
+1
- Development of a standard "get on 44Net" appliance built on a Pi. Something that reaches out to the solution developed for #1 and brings in the user's allocation for experimentation. This should be a community-driven project that aims to have an EASY setup-and-forget system that provides automatic networking harness for people who want to experiment. Harness the power of the community who like to tinker with networking to help those who don't want to.
+1, with a variant : a ready-to-use Pi image would be perfect for beginners. But software should be easy to implement in other existing featured Pi distributions, such as Pi-Star (and many others).
73 de TK1BI
On 3/8/21 6:29 am, Rosy Wolfe via 44Net wrote:
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.
I'm in two minds about the proposal, and it comes down to "more information needed" (more below). I'm one for whom renumbering will be a major exercise, with 200+ IP addresses, plus having to liaise with various network administrators for manual intervention and running some geolocation sensitive services, which means a protracted changeover. I'm not opposed to doing this, BUT it has to be worth my while, with clear benefits for the network (and hopefully myself) at the end of it. Last thing I want is to spend that time and effort, and be where we are now, or worse, having to do it again, to fix up something unforeseen.
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.
Yes, I'd like to see the problems fleshed out first, so we have a clear definition of the problems, their priority and proposed solutions.
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.
First thing for me is to replace the IPIP mesh with the proposed backbone. While I have IPIP working here, I'm not 100% convinced that it's as reliable as I'd like. Often, my routing table has only had routes in 44.128/10, on occasions I've checked. While direct point to point links should offer good performance, I'm not necessarily convinced I'm seeing that, and there's many possible places things could break (routers not passing the IPIP protocol, for example). The backbone/POP idea could offer simpler setup for the cost of slightly less optimal routing for end users. The VPN software can generally route subnets, if told to do so by the server (perfect for those of us with subnet allocations). The question is whether we can make it as easy for ARDC to manage as the current system.
Other issues I see are:
Manual DNS management seems so 1990s. I haven't made any changes to my DNS, as manual changes by a third party (network coordinator in this case) is a major barrier. And a simple means of reverse DNS delegation would be nice for those of us with /24 or larger allocations. And having control of firewall separated from DNS would be nice - I may want ampr.org DNS "internally", but not want my RF sites Internet connected.
There seems to be questions of how to communicate between intranet (those on the radio/tunneled network) and BGP announced subnets, and this is where different people may need different solutions, depending on their network topology, etc. I have a private VPN between my tunneled and BGP subnets, because some routes would otherwise go via San Diego otherwise - that's working "long path" (~18000-20000km) for a server 150km away! :) I'd like relatively right connectivity between my BGP and intranet subnets, and possibly other BGP routed subnets, but no connection (generally) to the wider Internet from my part of the intranet.
Anyway, just putting some thoughts out there for discussion.
Le 03/08/2021 à 01:49, Tony Langdon via 44Net a écrit :
I'd like relatively right connectivity between my BGP and intranet subnets, and possibly other BGP routed subnets, but no connection (generally) to the wider Internet from my part of the intranet.
As I often say, don't confuse "routing" and "firewalling". Those are two separated topics, that should IMHO be handled separately : - Connectivity between BGP, Intranet and maybe other local/extranet subnets is a matter of routing (which implies a coherent addressing policy, and probably, some renumbering at some point) - What kind of traffic is allowed / forbidden is a matter of firewall rules. Those rules may differ between countries, user groups or specific situations.
If the lack of a route is a common way to prevent users from reaching "forbidden" addresses, it's not IMHO the good way of doing things, HI :-)
Dear Toussaint,
Am 09. Aug 2021, um 10:55:50 schrieb Toussaint OTTAVI via 44Net:
I'd like relatively right connectivity between my BGP and intranet subnets, and possibly other BGP routed subnets, but no connection (generally) to the wider Internet from my part of the intranet.
As I often say, don't confuse "routing" and "firewalling". Those are two separated topics, that should IMHO be handled separately :
In theory, and in normal networks, you would be right. The difference is however that in normal networks, you generally use firewalls to block access to ressources. The problem we have at hand is slightly different: We need to protect access to links.
At least in some jurisdictions, we must not route certain traffic via an amateur radio link, so we face the dilemma of having a (possibly preferable) route via the radio that is not available to that certain traffic. Naturally, you'd block that traffic using a firewall route.
A route announcement generally is a promise to carry traffic to that destination. Can you still honestly make this promise if your firewall blocks that traffic? Or should you rather not announce that route ? In the traditional (internet only) case it doesnt matter because a a firewall would protect the resource no matter the path.
But in our case, your route announcement and subsequent packet dropping would be wrong (needlessly preventing communication) if another route were available that is not subject to the amateur radio link access restriction (maybe there is no amateur radio link, or maybe its via a different jurisdiction)
Somewhere deep down in that case lies the problem that the TAC proposal was trying to solve, although that was not fully documented.
A related question, also burried deep down in that lane: Your firewall rule would typically be filtering on source/destination addresses.
It is, I think, not disputed that a part of the reason to get users onto the 44 Net is that it identifies communiation partners as duly licensed ham radio operators, hinting your firewall that amateur radio frequency access may be allowed.
So, does initiation of a 44-to-44 communication also imply some form of agreement/representation that the content of that communication is suitable for the amateur radio air waves ?
Suppose I'd want to tell a non-politically-correct joke to another OM. I can now choose if I wanted to take the VHF TRX to call him on the local repeater, or I could call him on the landline phone.
How should this be handled ?
73s,
Mario, DL5MLO
Le 09/08/2021 à 13:44, Mario Lorenz a écrit :
In theory, and in normal networks, you would be right. The difference is however that in normal networks, you generally use firewalls to block access to ressources. The problem we have at hand is slightly different: We need to protect access to links.
Interesting answer, but the discussion may come al little bit off-topic here :-)
At least in some jurisdictions, we must not route certain traffic via an amateur radio link, so we face the dilemma of having a (possibly preferable) route via the radio that is not available to that certain traffic. Naturally, you'd block that traffic using a firewall route.
1/ Most of HAM rules about interconnecting HAM networks with public networks were written during the last century, when the technology and Internet were not what they are today. My personal opinion is that most of those rules may need to be refined or re-defined :-) As licenses HAM operators, we have the right to experiment new things. Then we (AMPR) could make proposals for new rules, adapted to the current State of the Art.
2/ IMHO, the validity of the traffic ("Is the operator a licensed ham radio operator ?") must be checked at the edge. Can we assume every 44net owner is a licensed ham (this implies strict controls by the people who deliver 44net addresses) ? Can we use certificates ? But most of all : once some traffic entered 44net network, should we consider it as "valid" HAM traffic ? Or do we have to make further tests later (the example you quoted : routing through radio links) ?
3/ As far as we manage the full network from end to end, would it be possible possible to use QoS everywhere ? An obvious advantage f/ex would be to prioritize VoIP. But another advantage would be tagging "valid HAM" packets with a specific DSCP tag. That would allow policy routing farther in the path (don't route non-ham packets over radio links, but route them on another link, if available)
A route announcement generally is a promise to carry traffic to that destination. Can you still honestly make this promise if your firewall blocks that traffic?
I would say YES : - My home network currently has routes to porn sites - My firewall content filter blocks those sites for everybody (but not for me, HI)
But in our case, your route announcement and subsequent packet dropping would be wrong (needlessly preventing communication) if another route were available that is not subject to the amateur radio link access restriction (maybe there is no amateur radio link, or maybe its via a different jurisdiction)
Nor an easy answer, because there's not one single problem to answer. In my situation, the problem is simpler, because I'm an island with only one gateway. Currently, I don't route traffic to other neighbors, so I don't have to bother with the question : "This traffic is not for me, should I check if it's valid HAM or not, and should I route it or not ?"
I would say : - For traffic that is not for me / my network / my region : route in best effort (without firewalling) - For traffic that is for me : apply firewall rules according to my local rules
Somewhere deep down in that case lies the problem that the TAC proposal was trying to solve, although that was not fully documented.
I fully agree with the TAC proposal of splitting 44net into two separate subnets with different policies. We are already experimenting it locally (with 44.168 and 44.190). This was suggested to me by Jann DG8NGN a while ago. Each site has two VLANs, dual addressing, and dual routing policy. Endpoint routers have Ethernet interfaces on both VLANs. We can choose to connect any equipment to Intranet (44.168) or Internet (44.190). The central firewall does the main filtering job. It works fine. It does the job of clearly separating what is "Intranet" and what is "Internet"
A related question, also burried deep down in that lane: Your firewall rule would typically be filtering on source/destination addresses.
Modern firewalls allow rules based on many parameters (not only source/dest). Can we imagine a DSCP tag designating "valid" ham radio traffic ?
It is, I think, not disputed that a part of the reason to get users onto the 44 Net is that it identifies communiation partners as duly licensed ham radio operators, hinting your firewall that amateur radio frequency access may be allowed.
My personal opinion is that identifying valid amateur radio operators should be done at the edge, when delivering 44net addresses (Who will do that and how is yet to be defined, but has been discussed already). Then, if a packet enters the network with a source IP in the 44net "Intranet" range, we can consider it as valid amateur data, and route it accordingly.
So, does initiation of a 44-to-44 communication also imply some form of agreement/representation that the content of that communication is suitable for the amateur radio air waves ?
We should distinguish between "Intranet" and "Internet" ranges : - If source IP is in the 44net "Intranet" range, then, the sender is a valid amateur radio operator, operating on a closed radioamateur network : current amateur traffic rules do apply. - If source IP is in the 44net "Internet" range, then, the sender is a valid amateur radio operator : - If the destination is public Internet : current rules for general Internet browsing do apply - If the destination is an amateur radio endpoint (ie, a D-Star or DMR repeater, linked through Internet because its sysop does not know how to use 44net, HI) : amateur traffic rules apply.
Suppose I'd want to tell a non-politically-correct joke to another OM. I can now choose if I wanted to take the VHF TRX to call him on the local repeater, or I could call him on the landline phone.
Obviously, you wouldn't use the local VHF repeater, but you would use phone :-)
How should this be handled ?
You wouldn't connect your terminal to the "Intranet" Ethernet interface (or WiFi network) of your 44net router, but instead, you would connect it to the "Internet" interface (or WiFi network)...
73 de TK1BI
Firewaling is the responsibility of the end user and not the routing service.
Routing is what AMPR should keep to and not firewaling. If you don't want to be directly exposed to the internet there are multiple ways, a firewall on the machine directly, a "router" that do NAT and won't forward any traffic except traffic initiated by one machine behind the NAT first. And at the end not having any route that can connect to the rest of the world and not be connected to any network at all. The first one is done easily, the second one is a given. And the other are not really useful at anything.
Now, if you don't want to be accessible from the internet BUT want to be accessible to HAM ONLY traffic, that is another story. In that case, the only way to go is by route. As trying to firewall every thing BUT known HAM ONLY traffic is a lost of time, and it will change almost daily.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 9 août 2021 04:55 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 03/08/2021 à 01:49, Tony Langdon via 44Net a écrit :
I'd like relatively right connectivity between my BGP and intranet subnets, and possibly other BGP routed subnets, but no connection (generally) to the wider Internet from my part of the intranet.
As I often say, don't confuse "routing" and "firewalling". Those are two separated topics, that should IMHO be handled separately : - Connectivity between BGP, Intranet and maybe other local/extranet subnets is a matter of routing (which implies a coherent addressing policy, and probably, some renumbering at some point) - What kind of traffic is allowed / forbidden is a matter of firewall rules. Those rules may differ between countries, user groups or specific situations.
If the lack of a route is a common way to prevent users from reaching "forbidden" addresses, it's not IMHO the good way of doing things, HI :-)
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Le 09/08/2021 à 17:59, pete M via 44Net a écrit :
Firewaling is the responsibility of the end user and not the routing service.
As already noticed several times on this list, there are as many opinions as members of the list. And I think it's the main difficulty for the TAC :-)
I don't think firewalling should be the responsibility of end users. We are sysops and network administrators. We are dealing with complex rules about connecting 44net networks to Internet. Even on this list, which includes all major 44net administrators over the world, it's difficult to agree with a common scheme. Then, it does not seem a clever idea to let end users do what they want, HI :-)
Here, we are an island. We currently have only one gateway to "the rest of the world", and in the definite setup, we plan to have two. It seems obvious to do routing and firewalling at gateway level. At least, it's what we did :-)
Routing is what AMPR should keep to and not firewaling.
We are saying the same thing : 1/ Routing may be redefined and standardized by AMPR in a way that allows all possible configurations all over the world (whether local regulations or policies allow it or not) with modern protocols and tools 2/ Firewalling is where local countries or user groups will define what is permitted or not in their specific country/region/situation. We are an island with one gateway, so it's an easy task at gateway level. On a continent, where rules are different between different neighbor countries, and where networks are meshed, of course, this is far from easy.
If you don't want to be directly exposed to the internet there are multiple ways, a firewall on the machine directly, a "router" that do NAT and won't forward any traffic except traffic initiated by one machine behind the NAT first. And at the end not having any route that can connect to the rest of the world and not be connected to any network at all. The first one is done easily, the second one is a given. And the other are not really useful at anything.
One of the purposes is to allow mass adoption of 44net. Then, we have to provide plug and play / easy to use setups that can do most of the job for the user. Here, we are providing "TKBoxes" (OpenWRT routers with pre-defined configuration made by us). At world-wide scale, we need to define a common scheme that fits all possible user cases. The split of 44net space in two (one "pure Intranet" and one "Internet-connected") is one important step. We are already experimenting it here (44.168 HamNet, and 44.190 Internet). This involves dual configuration, dual routing, route exchanges and firewalling at network / gateway level. This can not be done only at the edge.
Now, if you don't want to be accessible from the internet BUT want to be accessible to HAM ONLY traffic, that is another story. In that case, the only way to go is by route. As trying to firewall every thing BUT known HAM ONLY traffic is a lost of time, and it will change almost daily.
We've been playing that story for a few years now :-) Maybe with a lot of time lost, I agree :-) For a service that needs to be accessible from HAMs but not from Internet, you have to put it on the "Intranet" IP space, and it just works :-) Again, that's not a matter of route, but of access policy / rule (ie, firewalling).
PS : As an additional comment, it may be required at some point to mix routing and firewalling. Nowaday's systems allow to define access rules and routes based on a lot of parameters (not only source/destination IP/ports). Some manufacturers call that "policy routing" : there may be different routes for different kind of traffic based f/ex on a DSCP tag designating HAM traffic.
What I meant is that the lack of a valid route is not a good way to block some unwanted traffic. Because what is unwanted by you may be wanted by me. Routing policy and IP placement must be designed in a WW strategy, so that it can suit all possible user cases over the world. Then, what is allowed/forbiden in a specific region may be defined locally (by firewall rules, not by lack of routes).
73 de TK1BI
We are saying almost the same thing. ARDC/AMPR need to supply easy way for ham to connect to 44 net and we should not be defining what they want to receive or send as traffic. BUT ARDC/AMPR need to also give access to specific use case like an intranet ham only traffic if asked for it. ( I am sure that a lot of user on the ipip tunnel net dont want to have russian/chinese hacker to come in their place. And that use case is easy to do if the routing from the pop to the rest of the world is not open at all to the internet and you either connect to it by a vpn or any other type of tunnel if connected to the internet, or if connected by radio, you just dont use a tunel and be free and secure to use that space without fear. That aint firewalling that is internal routing between the pop's and the user and the ipip network.
The other use case is to route everything and not firewall anything to another part of 44 net. Yes we could firewall some traffic. Like sanner for port 22/80/443/8080 name the port you want, from the internet to the user space. (44 net) but again. That is just a service on top of the real work that ARDC/AMPR need to do. Route the 44 net to the user it target, the ham community. This can be done by direct BGP ( ARD/AMPR cannot firewall anything here) or by the POP (an now ARDC/AMPR can firewall things , but again it would be just a service over the real service they need to provide, ways of connecting ham together. ARDC/AMPR could make some firewaling rules to adapt to specific country rules and take the hard work out of the local user. But can it be easily done, We need to see the case before saying it can be done.
I am sure that you ahve played with routing and programming some route into your setup. can you tell me, if you want to connect to many /24 that are not on aggregated on a /10 or even a /16 how many route will you have to keep in your router ? At max the same number of /24 you have and mayve if lucky you will have a few of those /24 that are aggregated into a /22 or better a /20 to limit the route number. That is not an easy thing to manage. The TAC Idea of reserving a /10 for a ham only net would had fix that kind of problem by a signle magical line that would had route 44.128.0.0/10 to a specific route and without firewall, without complicated routing and without large difficulty to enter the net a user would have fallen into the ham only network we all wish we had since the beginning of AMPR.
But this have been judged by the community as being bad if we read all the answer to the TAC proposal. I find that very disapointing.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 10 août 2021 03:58 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
Le 09/08/2021 à 17:59, pete M via 44Net a écrit :
Firewaling is the responsibility of the end user and not the routing service.
As already noticed several times on this list, there are as many opinions as members of the list. And I think it's the main difficulty for the TAC :-)
I don't think firewalling should be the responsibility of end users. We are sysops and network administrators. We are dealing with complex rules about connecting 44net networks to Internet. Even on this list, which includes all major 44net administrators over the world, it's difficult to agree with a common scheme. Then, it does not seem a clever idea to let end users do what they want, HI :-)
Here, we are an island. We currently have only one gateway to "the rest of the world", and in the definite setup, we plan to have two. It seems obvious to do routing and firewalling at gateway level. At least, it's what we did :-)
Routing is what AMPR should keep to and not firewaling.
We are saying the same thing : 1/ Routing may be redefined and standardized by AMPR in a way that allows all possible configurations all over the world (whether local regulations or policies allow it or not) with modern protocols and tools 2/ Firewalling is where local countries or user groups will define what is permitted or not in their specific country/region/situation. We are an island with one gateway, so it's an easy task at gateway level. On a continent, where rules are different between different neighbor countries, and where networks are meshed, of course, this is far from easy.
If you don't want to be directly exposed to the internet there are multiple ways, a firewall on the machine directly, a "router" that do NAT and won't forward any traffic except traffic initiated by one machine behind the NAT first. And at the end not having any route that can connect to the rest of the world and not be connected to any network at all. The first one is done easily, the second one is a given. And the other are not really useful at anything.
One of the purposes is to allow mass adoption of 44net. Then, we have to provide plug and play / easy to use setups that can do most of the job for the user. Here, we are providing "TKBoxes" (OpenWRT routers with pre-defined configuration made by us). At world-wide scale, we need to define a common scheme that fits all possible user cases. The split of 44net space in two (one "pure Intranet" and one "Internet-connected") is one important step. We are already experimenting it here (44.168 HamNet, and 44.190 Internet). This involves dual configuration, dual routing, route exchanges and firewalling at network / gateway level. This can not be done only at the edge.
Now, if you don't want to be accessible from the internet BUT want to be accessible to HAM ONLY traffic, that is another story. In that case, the only way to go is by route. As trying to firewall every thing BUT known HAM ONLY traffic is a lost of time, and it will change almost daily.
We've been playing that story for a few years now :-) Maybe with a lot of time lost, I agree :-) For a service that needs to be accessible from HAMs but not from Internet, you have to put it on the "Intranet" IP space, and it just works :-) Again, that's not a matter of route, but of access policy / rule (ie, firewalling).
PS : As an additional comment, it may be required at some point to mix routing and firewalling. Nowaday's systems allow to define access rules and routes based on a lot of parameters (not only source/destination IP/ports). Some manufacturers call that "policy routing" : there may be different routes for different kind of traffic based f/ex on a DSCP tag designating HAM traffic.
What I meant is that the lack of a valid route is not a good way to block some unwanted traffic. Because what is unwanted by you may be wanted by me. Routing policy and IP placement must be designed in a WW strategy, so that it can suit all possible user cases over the world. Then, what is allowed/forbiden in a specific region may be defined locally (by firewall rules, not by lack of routes).
73 de TK1BI
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Boudewijn (Bob) Tenty -
Colin Bodor -
Darcy Buskermolen -
dave.g4ugm＠gmail.com -
David McGough -
eric.fort.listmail＠fortconsulting.org -
Jason McCormick -
K7VE - John -
Mario Lorenz -
Marius Petrescu -
Nat Morris -
pete M -
Rob PE1CHL -
Rosy Wolfe -
Steve L -
Steve Stroh -
Tony Langdon -
Toussaint OTTAVI