44net March 2019

44net@mailman.ampr.org

41 participants
33 discussions

Re: [44net] BGP routes in RIP transmissions - Using ampr-ripd in parallel with BGP ?
by Rob Janssen 18 Mar '19

18 Mar '19

> And then you'll have issues in at least parts of the German networks. You will have issues with them no matter what. Their network design just isn't suitable for connection to internet. No matter if you do or don't use tunnels, you will always have issues in some way. Rob

3 2

Re: [44net] AX25 support on Linux based (Raspberry PI) node
by Rob Janssen 18 Mar '19

18 Mar '19

> The challenge is that by loosing the protocol stack in the kernel, all the existing Linux packet applications break. Maybe if a new libax25 library was created that could redirect all those calls to something in userland, that would work but that doesn't exist today. By also moving out of the kernel, we loose most of the advanced routing abilities in playing around with AX25/Netrom/Rose, etc. It should be possible to make a usermode program that handles socket calls made by other programs. I.e. you continue to use a socket interface but the protocols are not in the kernel but in that user program. Solutions like this are used for many exotic services that cannot live in the kernel for maintenance reasons. (although for technological reasons they should be in the kernel) > Btw.. I don't understand your "put only device drivers in the kernel". If we did that for say IPv4, IPv6, etc... that would dramatically reduce the functionality of Linux as it stands today. So much would need to change to accomodate a wholesale shift to Userland. Well of course it has been a discussion since (before) linux was first developed. The monolithic vs microkernel discussion. However, you should not compare it to IPv4 or IPv6. The issue is not whether network protocols technologically belong in the kernel, but whether it is sustainable to keep protocols that are used by about 100 users out of a Linux user population of billions can be kept in the kernel and survive every restructuring of the kernel without being damaged beyond usability because people are making changes and don't (because they cannot) test them in real use. Apparently not. So it is better to go for a solution that works. I have been running my version of NET on top of the kernel SCC card driver for quite some time, and there were no issues like this. It had a separate IP address and was connected to the kernel IP stack via tun/tap. Of course that is not a solution for socket applications using AX.25 but something similar could be done. Rob

2 1

Re: [44net] TAP interface routing
by Rob Janssen 17 Mar '19

17 Mar '19

> I'm writing a DVB-GSE receiver block for GNU Radio. It will be used in a > future software defined DVB-S2 receiver. I've pretty much completed the > block, but I'm stuck on how to forward packets written to the TAP > interface into the Linux network stack. That happens automatically. The tap interface has two sides, one exists as a Linux network interface that you configure just as any network interface and the other side is accessed via the socket in your application. Forwarding is done as on any network: you assign IP addresses and subnet masks to either side and send your packets to addresses living on the other side. Rob

2 1

Bouncing Emails
by William Lewis 17 Mar '19

17 Mar '19

Brian Kantor: I tried sending you two emails (off list). Both got bounced: ----------------------------------------------------------------------------------------------------------------------------- Remote-MTA: dns; bkantor.net Diagnostic-Code: smtp; 550 5.7.1 Disposition Notification Denied:NOYGDB -------------------------------------------------------------------------- Can you contact me off list to verify any change in your email address? Thank you. ------------------------------------------------------------------------ Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) ------------------------------------------------------------------------ This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

1 0

TAP interface routing
by Ron Economos 16 Mar '19

16 Mar '19

I'm writing a DVB-GSE receiver block for GNU Radio. It will be used in a future software defined DVB-S2 receiver. I've pretty much completed the block, but I'm stuck on how to forward packets written to the TAP interface into the Linux network stack. I'm guessing some sort of bridge or virtual Ethernet interface is required, but I just can't find a coherent example. I'm hoping the brain trust here on 44net can help. The source code is here: https://github.com/drmpeg/gr-dvbgse/blob/master/lib/bbheader_sink_impl.cc The block parses a baseband header frame from the DVB-S2 receiver, builds an Ethernet frame, and writes it to the tap1 interface. https://github.com/drmpeg/gr-dvbgse/blob/master/lib/bbheader_sink_impl.cc#L… But I want that packet to be injected into the network stack. How can that be done? Ron W6RZ

1 0

Re: [44net] AX25 support on Linux based (Raspberry PI) node
by Rob Janssen 16 Mar '19

16 Mar '19

> Is there a place where we can get the latest unofficial patches? Has anyone considered a fork to keep it relevant to modern kernels? I would say it is best to remove all AX.25 code from the kernel and use one or more userspace programs to provide the functionality instead. It is just too difficult to keep some seldomly used feature working in the kernel working without testing (as outlined by David). And once there is a problem, it is almost impossible to get it fixed and very difficult to propagate fixes to end-user systems. Put only device drivers in the kernel, not the actual protocol code. Rob

2 1

Re: [44net] BGP routes in RIP transmissions - Using ampr-ripd in parallel with BGP ?
by Rob Janssen 14 Mar '19

14 Mar '19

> - May I encounter routing issues with some clients ? > - Is it recommended to deploy ampr-ripd in parallel with BGP ? You won't encounter problems with traffic to other systems on internet and also not with other AMPRnet systems routed via BGP, but some of the traditional AMPRnet networks that are only routed via IPIP will be unreachable when you do not run IPIP tunnels in parallel to your BGP announcement, or at best they will be routed via San Diego, USA which of course affects delay and packet loss values. I cannot judge if this will affect your system. However, when your router system is capable of running ampr-ripd or another solution for IPIP tunnels (e.g. the scripts for RouterOS or the recent solution for Juniper) I think it is always a good idea to install one of them. Rob

3 2

Re: [44net] BGP routes in RIP transmissions -- CANCELLED
by Rob Janssen 13 Mar '19

13 Mar '19

> What's this "snow" thing? And can it be routed over the 44 net? ;P It can sometimes affect the routing over UHF/SHF radio links. But is anyone using those, or is only internet routing used? Here we have had lots of rain and strong winds over the past week. The antennas are shaking and I cannot work on my OSCAR 100 uplink. My WiFi AMPRnet link to the radio tower nearby is affected due to a tree in the path. Rob

2 1

gateway on 0.0.0.0 entry in the portal
by R P 13 Mar '19

13 Mar '19

0.0.0.0 2019-02-16 11:36:03 F4BWT View<https://portal.ampr.org/gateways_list.php?a=view&id=1787> What is that ? Regards Ronen - 4Z4ZQ

2 1

Re: [44net] BGP routes in RIP transmissions -- CANCELLED
by Rob Janssen 13 Mar '19

13 Mar '19

> If you have a 44net subnet behind your router, machines that do not have DNS entries at ampr.org will not be able to reach BGPed networks, because amprgw requires any host passing traffic through it must have such a DNS entry. > At the moment, simply removing the default route in your ampr table solves this and routes those hosts vis ISP NAT. > By automatically creating individual routes for BGP subnets make this a little more diffcult, and breaks existing working setups. Even if this is not a big issue for people with good networking knowledge, it breaks things for those that should have expected a simpler setup and are not profficient in networking, contrary to the initial goal of the proposal. I think it is a little broader than this. When you have a BGP routed subnet yourself, and you run ampr-ripd in parallel to improve connectivity to IPIP-only subnets, you force the traffic to other BGP routed subnets via amprgw where they would much more efficiently be routed directly. (without NAT) Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given. You could release such a version and advertise its existence here, give everyone involved the opportunity to install it, and only then make the change. Rob

8 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2019