On Fri, Jun 02, 2017 at 05:14:57PM +0300, Marius Petrescu wrote: 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. 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

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:

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:

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. 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 &lt;marius(a)yo2loj.ro&gt; napisał:

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

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:

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(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

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

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

Marius, The application ampr-ripd works as designed. I asked: You responded: 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. That is correct, You must be plugged into a physical AMPRNet interface to connect to AMPRNet at my QTH. Correct. 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. 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

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

Marius, 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, 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: 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