Hello,
For those using amprd (like myself), here a small update:
- added map notification every 5 min. There is a new config file parameter for it, check the example config
- modified the default ampr gw address to the new IP. This has actually no effect until the RIP broadcasts for 44.0.0.1 will change to the new IP (44.0.0.1 still uses the old GW address).
Older versions, like 1.5 and 1.6 will switch gateways automatically if presented with a new gw for 44.0.0.1 in the RIP data, so unless you want to be on the map with a blue dot, there is no urge to update (live map is at http://yo2tm.ampr.org/ampr-map/)
As always:
http://www.yo2loj.ro/hamprojects/
http://yo2tm.ampr.org/hamprojects/
Marius, YO2LOJ
On Fri, Jun 02, 2017 at 04:37:34PM +0300, Marius Petrescu wrote:
- modified the default ampr gw address to the new IP. This has actually no
effect until the RIP broadcasts for 44.0.0.1 will change to the new IP (44.0.0.1 still uses the old GW address).
Marius, I'm sending RIP transmissions from BOTH the old and new gateways, each with its own appropriate address. The old gateway is scheduled to shut down Monday and its RIP transmissions will cease at that time. Do you think there will be any problems with ampr-ripd?
I'm a little concerned: there is still a notable amount of traffic from gateways to old amprgw. On Monday those gateways will stop working until they update to the new address. - Brian
I don't think there will be any issues with ampr-ripd, amprd or the mikrotik script:
- ampr-ripd works with both gateways at the same time and doesn't care about the default route. It is the surrounding scripts that must be updated.
- amprd (my favorite) will adapt automatically to the gateway that is broadcasted as the gateway for 44.0.0.1 (since the first release actually).
- the mikrotik needs only a manual tunnel endpoint update if not already done.
I am more concerned about jnos gateways and some handcrafted router setups....
About that old gateway traffic: remember that all replies from the internet still return via the old gw, since that is the official 44.0.0.0/8 route, and commercial ISPs and core routers don't use connection tracking of any kind.
If the AS BGP announcement of the new 44.0.0.0/8 will propagate, this will cease.
On Fri, Jun 02, 2017 at 05:14:57PM +0300, Marius Petrescu wrote:
About that old gateway traffic: remember that all replies from the internet still return via the old gw, since that is the official 44.0.0.0/8 route, and commercial ISPs and core routers don't use connection tracking of any kind.
It's not the traffic from 44.0.0.0/8 to the gateways that concerns me (that traffic is expected for now), it's the traffic in the other direction, outbound from the various gateways to old amprgw to be routed to 44.0.0.0/8 that is the concern. That path will stop working on Monday.
If the AS BGP announcement of the new 44.0.0.0/8 will propagate, this will cease.
Both old and new amprgw are behind the same border router. I believe the BGP announcement will not change at all, what's scheduled is merely an on-campus internal routing change to switch the 'next-hop' route destination in the border router from old to new. We'll still be publicly announcing the same path to 44.0.0.0/8 via our border router as before. - Brian
- amprd (my favorite) will adapt automatically to the gateway that is
broadcasted as the gateway for 44.0.0.1 (since the first release actually).
Is it now suitable to run over dynamic IP system? I was unable to run it... perhaps my fault.
I am more concerned about jnos gateways and some handcrafted router setups....
The goal could be to effectively use the multipoint to multipoint feature... then, as per Brian K. proposal, the JNOS2 is able to run IP-in-IP and then IP-in-UDP encapsulation (using this last the UDP port 94 for both the source and destination ports).
As usual, I'm open for any tests also for this new experimentation branch :)
It was always suitable (my amprd system it is also on a dynamic IP). You just can not place a hostname in the ignore list, that's all.
But this should not bother you. If you use the daemon as recommended (/8 netmask on its interface), all other routes, including your own you need to ignore would be defined in your routing table, and would take precedence over the 44/8 rule via the tunnel interface (you don't need all individual routes for amprd). So there is nothing to block using it on a dynamic interface. Your routing table should look something like this:
default via <def gw ip> dev <some interface> <--- the system's default route
44.0.0.0/8 dev ampr0 <--- default 44 gateway
44.a.b.c/32 via <def gw ip> dev <some interface> <--- host routes for 44 IPIP endpoint
44.b.c.d/32 via <def gw ip> dev <some interface> <--- host routes for 44 IPIP endpoint
44.x.y.x dev <some other interface> <--- your network
44.x.y.z dev <some other interface> <--- your network
Marius, YO2LOJ
On 02.06.2017 18:09, Gustavo Ponza wrote:
- amprd (my favorite) will adapt automatically to the gateway that is
broadcasted as the gateway for 44.0.0.1 (since the first release actually).
Is it now suitable to run over dynamic IP system? I was unable to run it... perhaps my fault.
Let's hold our horses with amprd until the switch is complete.
The split routing between the old and new gateway doesn't seem to go with it. Let's wait until Monday, when the 44.0.0.1 broadcast with the old GW on the old interface disappears. I really have no solution for this at the moment.
On 02.06.2017 18:09, Gustavo Ponza wrote:
- amprd (my favorite) will adapt automatically to the gateway that is
broadcasted as the gateway for 44.0.0.1 (since the first release actually).
Is it now suitable to run over dynamic IP system? I was unable to run it... perhaps my fault.
I am more concerned about jnos gateways and some handcrafted router setups....
I can easily turn off the rip transmissions from old amprgw if you think that will help and not harm anything. - Brian
On Fri, Jun 02, 2017 at 10:21:33PM +0300, Marius Petrescu wrote:
Let's hold our horses with amprd until the switch is complete.
The split routing between the old and new gateway doesn't seem to go with it. Let's wait until Monday, when the 44.0.0.1 broadcast with the old GW on the old interface disappears. I really have no solution for this at the moment.
Marius, TNX for the detailed explanation.
Just sent off list a detailed procedure adopted with all references and particularly the amprd.conf file used on my setup. Hope you can find the solution as you do every day :)
73, gus
On 06/02/2017 09:21 PM, Marius Petrescu wrote:
Let's hold our horses with amprd until the switch is complete.
The split routing between the old and new gateway doesn't seem to go with it. Let's wait until Monday, when the 44.0.0.1 broadcast with the old GW on the old interface disappears. I really have no solution for this at the moment.
On 02.06.2017 18:09, Gustavo Ponza wrote:
- amprd (my favorite) will adapt automatically to the gateway that
is broadcasted as the gateway for 44.0.0.1 (since the first release actually).
Is it now suitable to run over dynamic IP system? I was unable to run it... perhaps my fault.
I am more concerned about jnos gateways and some handcrafted router setups....
Marius,
I noticed an odd anomaly. It doesn't matter since most GWs show the 44 IPs.
At this time, my gateway has not updated from 7x.xxx.xxx.xxx; but your map shows my new IP, and I should be reachable from AMPRNet!
Nice!
- Lynwood KB3VWG
Lynwood,
I see the new IP, but those notifications should come via tunnel from their 44 addresses. Your GW is the only exception that doesn't (that's why your dot is red).
This could be an indicator that something isn't 100% right, e.g. some policy routing on your system.
On 03.06.2017 03:38, lleachii--- via 44Net wrote:
Marius,
I noticed an odd anomaly. It doesn't matter since most GWs show the 44 IPs.
At this time, my gateway has not updated from 7x.xxx.xxx.xxx; but your map shows my new IP, and I should be reachable from AMPRNet!
Nice!
- Lynwood
KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Lynwood.
On my smartphone, at this very moment: kb3vwg-010.ampr.org - bare Internet - _IS NOT_ accessible. - with AMPNet VPN - is accessible.
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
W 3 czerwca 2017 7:19:22 AM Marius Petrescu marius@yo2loj.ro napisał:
Lynwood,
I see the new IP, but those notifications should come via tunnel from their 44 addresses. Your GW is the only exception that doesn't (that's why your dot is red).
This could be an indicator that something isn't 100% right, e.g. some policy routing on your system.
On 03.06.2017 03:38, lleachii--- via 44Net wrote:
Marius,
I noticed an odd anomaly. It doesn't matter since most GWs show the 44 IPs.
At this time, my gateway has not updated from 7x.xxx.xxx.xxx; but your map shows my new IP, and I should be reachable from AMPRNet!
Nice!
- Lynwood
KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian, Lynwood et al.
Recently some important changes were performed pertaining whole [44net] community.
Today I made few test in order to check accessibility of [44net] hosts. Below I present results of them in very simple "table".
Date, time: June 3rd 2017 09:00UTC Location: Gdynia, Poland Appliance used: Sony Xperia Z1 System Android 5.1.1 Dynamic IP address: 37.248.160.253 OpenVPN application
Accessibility of [44net] hosts.
Target host Internet assigned OpenVPN IP 44.137.40.185 44.139.11.30 44.165.15.128
44.0.0.1:443 O.K OK NO NO 44.60.44.10:80 NO OK OK OK 45.135.172.128:23 NO OK OK OK 44.147.210.26:6303 NO OK OK OK 44.165.25.250:23 NO OK OK OK 44.168.19.19:6300 NO OK OK OK
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
Brian, Lynwood et al.
Due to brainless mobile text editors I repeat my post.
Recently some important changes were performed pertaining whole [44net] community.
Today I made few test in order to check accessibility of [44net] hosts. Below I present results of them in very simple "table".
Date, time: June 3rd 2017 09:00UTC Location: Gdynia, Poland Appliance used: Sony Xperia Z1 System Android 5.1.1 Dynamic IP address: 37.248.160.253 OpenVPN application
Accessibility of [44net] hosts.
Target host ======== internet ========= assigned OpenVPN IP ========================== 44.137.40.185 = 44.139.11.30 = 44.165.15.128
44.0.0.1:443 ======== OK ====== OK ========== NO ========== NO 44.60.44.10:80 ====== NO ====== OK ========== OK ========== OK 45.135.172.128:23 === NO ====== OK ========== OK ========== OK 44.147.210.26:6303 == NO ====== OK ========== OK ========== OK 44.165.25.250:23 ==== NO ====== OK ========== OK ========== OK 44.168.19.19:6300====NO ====== OK ========== OK ========== OK
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
Tom, I think Lynwood and I have determined the cause of his outage and fixed it. It may have affected others.
You might want to try your tests again and see if anything is now working that wasn't before. - Brian
On Sat, Jun 03, 2017 at 12:33:51PM +0200, SP2L Tom wrote:
Brian, Lynwood et al.
Due to brainless mobile text editors I repeat my post.
Recently some important changes were performed pertaining whole [44net] community.
Today I made few test in order to check accessibility of [44net] hosts. Below I present results of them in very simple "table".
Date, time: June 3rd 2017 09:00UTC Location: Gdynia, Poland Appliance used: Sony Xperia Z1 System Android 5.1.1 Dynamic IP address: 37.248.160.253 OpenVPN application
Accessibility of [44net] hosts.
Target host ======== internet ========= assigned OpenVPN IP ========================== 44.137.40.185 = 44.139.11.30 = 44.165.15.128
44.0.0.1:443 ======== OK ====== OK ========== NO ========== NO 44.60.44.10:80 ====== NO ====== OK ========== OK ========== OK 45.135.172.128:23 === NO ====== OK ========== OK ========== OK 44.147.210.26:6303 == NO ====== OK ========== OK ========== OK 44.165.25.250:23 ==== NO ====== OK ========== OK ========== OK 44.168.19.19:6300====NO ====== OK ========== OK ========== OK
Best regards.
Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian.
I appreciate your info, indeed. Will re-check bit later as I work till 17:00UTC.
Best regards. Have a nice weekend. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
W 3 czerwca 2017 5:44:09 PM Brian Kantor Brian@UCSD.Edu napisał:
Tom, I think Lynwood and I have determined the cause of his outage and fixed it. It may have affected others.
You might want to try your tests again and see if anything is now working that wasn't before.
- Brian
On Sat, Jun 03, 2017 at 12:33:51PM +0200, SP2L Tom wrote:
Brian, Lynwood et al.
Due to brainless mobile text editors I repeat my post.
Recently some important changes were performed pertaining whole [44net] community.
Today I made few test in order to check accessibility of [44net] hosts. Below I present results of them in very simple "table".
Date, time: June 3rd 2017 09:00UTC Location: Gdynia, Poland Appliance used: Sony Xperia Z1 System Android 5.1.1 Dynamic IP address: 37.248.160.253 OpenVPN application
Accessibility of [44net] hosts.
Target host ======== internet ========= assigned OpenVPN IP ========================== 44.137.40.185 = 44.139.11.30 = 44.165.15.128
44.0.0.1:443 ======== OK ====== OK ========== NO ========== NO 44.60.44.10:80 ====== NO ====== OK ========== OK ========== OK 45.135.172.128:23 === NO ====== OK ========== OK ========== OK 44.147.210.26:6303 == NO ====== OK ========== OK ========== OK 44.165.25.250:23 ==== NO ====== OK ========== OK ========== OK 44.168.19.19:6300====NO ====== OK ========== OK ========== OK
Best regards.
Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Is the Vpn access on the android phone open for everyone (ham radios of course)
? if yes where can i get the Application ?
It is interesting way to gain access the amprnet from SmartPhone
If such service can be done on Mikrotik and someone know how to do it im willing to supply it on my mikrotik
Thanks Forward
Ronen
________________________________
Date, time: June 3rd 2017 09:00UTC Location: Gdynia, Poland Appliance used: Sony Xperia Z1 System Android 5.1.1 Dynamic IP address: 37.248.160.253 OpenVPN application
Accessibility of [44net] hosts.
Target host Internet assigned OpenVPN IP 44.137.40.185 44.139.11.30 44.165.15.128
44.0.0.1:443 O.K OK NO NO 44.60.44.10:80 NO OK OK OK 45.135.172.128:23 NO OK OK OK 44.147.210.26:6303 NO OK OK OK 44.165.25.250:23 NO OK OK OK 44.168.19.19:6300 NO OK OK OK
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Ronen,
The VPN listed on the Wiki is OpenVPN-PKI-based, it requires taking a text editor and bundling your CRT issued from ARRL Logbook of the world with their Certificate Authority (CA) CRT. You should be able to download OpenVPN connect from an app store on your device.
The instructions should be on a VPN Wiki page.
- Lynwood KB3VWG
Marius,
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)?
In Linux, this isn't routing issue. Unless you've placed it in code, ampr-ripd would use my Public IP because my Kernel does, otherwise I wouldn't have an Internet connection. I actually noticed 1-2 other systems that appeared with the Public IP, I was trying to screen shot them so I could contact them, but it moved very fast.
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. As always, my script is reflected in Startampr. If there's another way to configure the policies to make this work, (without causing my other systems applications to use 44.60.44.1), it's open source, just let me know...
- Lynwood KB3VWG
This could be an indicator that something isn't 100% right, e.g. some policy routing on your system.
Actually when sending the notification, you can not tell it where to send the info.
It will use your system's routing policies. So if your routing from that system is OK, if will go via tunnel. If not, it will choose whatever route your system uses.
This is actually a good check for a working gateway. And if this happens, the dot is red - to see it and take action.
On 03.06.2017 14:39, lleachii--- via 44Net wrote:
Marius,
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)?
In Linux, this isn't routing issue. Unless you've placed it in code, ampr-ripd would use my Public IP because my Kernel does, otherwise I wouldn't have an Internet connection. I actually noticed 1-2 other systems that appeared with the Public IP, I was trying to screen shot them so I could contact them, but it moved very fast.
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. As always, my script is reflected in Startampr. If there's another way to configure the policies to make this work, (without causing my other systems applications to use 44.60.44.1), it's open source, just let me know...
- Lynwood
KB3VWG
This could be an indicator that something isn't 100% right, e.g. some policy routing on your system.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
Cool...then it seems mine is working as designed. My system uses the WAN for it's Tx/Rx. I'd have to mangle the packet, or have non 44 traffic masquerade to 44.0.0.0/8 from my location.
Since I often test accessibility on the Public Internet and AMPRNet (and I don't want non-Hams at my QTH on the AMPRNet), I'll leave it as-is. I can disable the discovery if it's an issue, it's OK with me.
- Lynwood KB3VWG
Sorry, what works as designed? You have an daemon running on a tunnel, with a 44net address, creating routes to other 44net entities.
You don't send traffic destined to those partners from a 44net address with a 44net source.
Instead you use a public address to reach those nodes.
Ok. Now could you please explain why do you think the mesh network was designed to work like that?
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.
On 04.06.2017 01:21, lleachii--- via 44Net wrote:
Marius,
Cool...then it seems mine is working as designed. My system uses the WAN for it's Tx/Rx. I'd have to mangle the packet, or have non 44 traffic masquerade to 44.0.0.0/8 from my location.
Since I often test accessibility on the Public Internet and AMPRNet (and I don't want non-Hams at my QTH on the AMPRNet), I'll leave it as-is. I can disable the discovery if it's an issue, it's OK with me.
- Lynwood
KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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
On 04.06.2017 03:22, lleachii--- via 44Net wrote:
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.
So, the ampr-ripd was designed to work on ampr addresses, running on ampr machines, to be used in ham radio gateways. And it assumes that it has access to the own tunnels it maintains. From my point of view, any other usage is out of scope.
So the solution is not for me to code anything. The solution is for you to create a derivative work if you need it. It is open source, please feel free to do it.
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).
These anomalies are there since ages, at least there where there since at least 17 years now (I started my first gateway in 2000, with that "mirrorshades.ucsd.edu" gateway) but the internet was much more permissive in those days. The sad thing is that, exactly because of that, not much has changed until the advent of RIPv2 announcements and Hessu's first daemon. Of course providers implementing source filtering helped a little in normalizing the networking approach.
But you actually can sit in your house on a non44 network and use it. You just need to create proper mapping, routing and NAT rules for it to work.
Marius,
Fair enough, my friend. In the past I used ampr-ripd on a downstream Linux server. Since my GW/AMPR-Router is now on my border, it seems to be another anomaly that's the "nature of the beast".
As with all other system applications on a router, I'll have to brush up on my C (C++) to add an argument to specify SRC IP, if needed. I'll disable the discovery, it's not that major to me, until it enters DNS LOC.
Otherwise, I'll consider mangling all packets destined to 44/8 (that may cause another security issue) to use tunl0, even for those users at my QTH not possessing a Ham license.
Thanks and 73,
- Lynwood KB3VWG
I don't thing doing a src-nat will create any security breach, because NAT has this nice firewall side effect.
And you could do it only for a specific local machine, not for all.
If you use static address assignment, it is simple, if you use DHCP, then just reserve fixed addresses for 44net capable hosts, and mangle only those.
Myself, I use a VLAN for my machines, so basically they have dual connections. LAN and AMPR. But this option is not trivial since not network adapters support it, and not straight forward out of the box.
On 04.06.2017 03:59, lleachii--- via 44Net wrote:
Marius,
Fair enough, my friend. In the past I used ampr-ripd on a downstream Linux server. Since my GW/AMPR-Router is now on my border, it seems to be another anomaly that's the "nature of the beast".
As with all other system applications on a router, I'll have to brush up on my C (C++) to add an argument to specify SRC IP, if needed. I'll disable the discovery, it's not that major to me, until it enters DNS LOC.
Otherwise, I'll consider mangling all packets destined to 44/8 (that may cause another security issue) to use tunl0, even for those users at my QTH not possessing a Ham license.
Thanks and 73,
- Lynwood
KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
I don't thing doing a src-nat will create any security breach, because NAT has this nice firewall side effect.
And you could do it only for a specific local machine, not for all.
If you use static address assignment, it is simple, if you use DHCP, then just reserve fixed addresses for 44net capable hosts, and mangle only those.
Myself, I use a VLAN for my machines, so basically they have dual connections. LAN and AMPR. But this option is not trivial since not network adapters support it, and not straight forward out of the box.
SNAT is possible, and my machines are already on a VLAN, but no "dual-connectivity" (I discovered another anomaly in the Linux Kernel that makes ping-44.php fail). DHCP is not used on my 44LAN, but I could implement it.
...but, this doesn't solve anything as you described, though, since (as I noted) this only occurs because this is my REAL router. The only thing I can do is make routes, mangles and policies specific to 44.60.44.1...or simply code an argument for SRC IP in ampr-ripd.
- Lynwood
Wouldn't it be much easier to add some simple stuff to your system:
I understand you use table 44, local ip is 44.60.44.1 on tunl0, and br-amprlan is your local 44net bridge. So you probably have already a default route via 169.228.34.84 in that table, and a lot of routes created by ampr-ripd.
And you have some policy routing in place, like:
ip rule add from 44.60.44.1 table 44
Now if you add:
ip rule add from 44.60.44.1 to 44.60.44.0/24 table main
ip rule add from 44.60.44.1 to 44.0.0.0/8 table 44
This should make your system use table 44 for outgoing 44net traffic, including the interface address 44.60.44.1 This will not affect your outward forwarded traffic which will never have source address 44.60.44.1, and your incoming 44net traffic will be routed by the table main, which should hold your local routes.
Marius, YO2LOJ
On 04.06.2017 04:16, lleachii--- via 44Net wrote:
SNAT is possible, and my machines are already on a VLAN, but no "dual-connectivity" (I discovered another anomaly in the Linux Kernel that makes ping-44.php fail). DHCP is not used on my 44LAN, but I could implement it.
...but, this doesn't solve anything as you described, though, since (as I noted) this only occurs because this is my REAL router. The only thing I can do is make routes, mangles and policies specific to 44.60.44.1...or simply code an argument for SRC IP in ampr-ripd.
- Lynwood
Marius,
ip rule add from 44.60.44.1 to 44.0.0.0/8 table 44
This should make your system use table 44 for outgoing 44net traffic, including the interface address 44.60.44.1
No, it would not, my Kernel received an IP and Gateway via DHCP from my Carrier. My ampr-ripd is executed by that same Kernel.
For clarity, technically, 44.60.44.1 is assigned to br-amprlan. I did assign 44.60.44.2 to tunl0 (I do this EVERY time someone suggests my problem is because tunl0 doesn't have an de-encapsulated IP address), but it never has affect. Keep in mind that I also have other 192.168.x.x networks...none of which should reach 44 hosts via AMPRNet. Perhaps sending via 44.60.44.1 or 44.60.44.2 works in RAW mode using ampr-ripd; but I use Linux Kmod-ipip as my true AMPR tunnel, it does not work.
You stated:
Actually when sending the notification, you can not tell it where to send the info.
I was asking about an argument to tell a system application to use SRC IP, like Ping, traceroute, ip(8), etc. When I use them, I always have to specify the SRC for them to work on an interface other than WAN.
73,
- Lynwood KB3VWG
On 04.06.2017 05:25, lleachii--- via 44Net wrote:
Marius,
ip rule add from 44.60.44.1 to 44.0.0.0/8 table 44
This should make your system use table 44 for outgoing 44net traffic, including the interface address 44.60.44.1
No, it would not, my Kernel received an IP and Gateway via DHCP from my Carrier. My ampr-ripd is executed by that same Kernel.
Now I really don't understand what one has to do with another. 1. You get an IP from your carrier, whatever that is. 2. You set up an IPIP tunnel on the same machine (with IP 44.60.44.2). This info you have been omitting all the time. 3. You have some interface to connect to your local 44 network (br-amprlan).
Now you run ampr-ripd.
Now what is wrong with:
ip rule add from 44.60.44.2 table 44
ip rule add from 44.60.44.2 to 44.60.44.0/24 table (whatever table you rute your internal 44net with)
ip rule add from 44.60.44.2 to 44.0.0.0/8 table 44
And all of this because your gateway is actual 44.60.44.2, 44.60.44.1 being just another IP on your subnet. Now, when your gateway (including ampr-ripd) sends out data to another 44net host, it will be sent with source IP 44.60.44.2 via the tunnel.
For clarity, technically, 44.60.44.1 is assigned to br-amprlan. I did assign 44.60.44.2 to tunl0 (I do this EVERY time someone suggests my problem is because tunl0 doesn't have an de-encapsulated IP address), but it never has affect. Keep in mind that I also have other 192.168.x.x networks...none of which should reach 44 hosts via AMPRNet. Perhaps sending via 44.60.44.1 or 44.60.44.2 works in RAW mode using ampr-ripd; but I use Linux Kmod-ipip as my true AMPR tunnel, it does not work.
Now this is new and should have been here from the beginning.
-
Brian Kantor -
Gustavo Ponza -
lleachii＠aol.com -
Marius Petrescu -
R P -
SP2L Tom