Marius,
Sorry, what works as designed? You have an daemon running on a tunnel, with a 44net address, creating routes to other 44net entities.
The application ampr-ripd works as designed. I asked:
/Exactly how do I tell this one system application to use 44.60.44.1, />/br-amprlan, tunl0, and table 44 - instead of the defaults (Public IP, />/WAN and table main)? //>/I see no way to tell ampr-ripd to use 44.60.44.1 as its source address />/for these sent packets. I even assigned an IP to tunl0, still nothing. /
/
You responded:
Actually when sending the notification, you*can not* tell it where to send the info.
The solution is to code an argument that tells the system to use an interface/IP as source, you told me that doesn't exist in code.
You don't send traffic destined to those partners from a 44net address with a 44net source.
That is correct, You must be plugged into a physical AMPRNet interface to connect to AMPRNet at my QTH.
Instead you use a public address to reach those nodes.
Correct.
Ok. Now could you please explain why do you think the mesh network was designed to work like that?
It isn't AMPRNet, as I noted, this is a non-44 network, and no system application running on a non-44 network should use AMPRNet unless I use an argument. Without an argument to assign SRC IP, ampr-ripd works as designed. Ping, traceroute, ip(8), and many other system applications allow your to tell it what interface/IP to use as its SRC.
Because it wasn't. It was designed to forward traffic from 44 to 44 addresses via a tunnel mesh, not the way you use it.
Maybe it works as you want it, but not as designed.
Marius, YO2LOJ.
True, they are two separate networks, other anomalies occur when mixing them (e.g. I could not sit on a non-44 IP at my house and test connectivity to 44/8 thru Brian, these anomalies are also how PE1CHL discovered policy-based routing was needed).
73,
- Lynwood KB3VWG