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