44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] Routing update issue
by Rob Janssen 15 Oct '18

15 Oct '18

It looks like we have the correct routes, but maybe the situation already rectified itself. 44.182.21.0/24 via 89.122.215.236 dev tunl0 proto ampr-ripd metric 4 onlink 44.182.21.1 via 89.33.44.100 dev tunl0 proto ampr-ripd metric 4 onlink This weekend we had another issue. I use a script to download the ampr.org zone from ftp://gw.ampr.org/pub/ampr.tar.gz to have it available locally in case there is a DNS problem on internet or we get isolated (lost connectivity on our gateway). Our local DNS servers 44.137.0.1 and 44.137.0.2 operate from this downloaded zone rather than from internet, and a regular check of the version number is made and the new file downloaded when it changes. As I experienced before that download of this file sometimes is not complete due to DDoS or other issues that make the download very slow, I added a sanity check: verify that the PTR entry for 44.255.255.255 is present in the 44.rev file before replacing our copies with the downloaded one. That entry was the last line in 44.rev, however someone has removed it so my script permanently rejected the download. Well... maybe a line can be added at the end of the files like there is at the end of encap.txt saved by ampr-ripd, so scripts can check for that to see if the file is complete: # --EOF-- Of course it is always better to have a documented check criterium than to rely on something like the 44.255.255.255 -> broadcast.ampr.org entry... Rob

3 2

Routing update issue
by Marius Petrescu 14 Oct '18

14 Oct '18

Hello, I think we have an route update/setup issue in our network that may need some attention. First of all, I don't see the root cause so maybe we should investigate a little. As you may have noticed, a technical bulldozer issue forced me to move the yo2tm server to a VPS cloud machine, which is not a bad move by itself. I put a gw with amprd on it and added a new new portal entry, 44.182.21.1 via 89.33.44.100. The route appeared in the RIP broadcasts a few minute later and everything seems to be working as expected. Ping was ok, connecting also. So at the moment there are 2 overlapping subnets, 44.182.21.1/32 at the new gw, and 44.182.21.0/24 at the old one. Since I moved the call home map to the new location, too, I was expecting that all nodes would show up in the new map, since all notifications go to 44.182.21.1. Normally, for routing purposes, the more precise route (/32) should take precedence over the old one, and everything should be fine. On the maps, there where some nodes appearing promptly via the new gateway, like N1URO and some related radio nodes, but that was it. So after 2 days, only 8 nodes switched to the new route, all others sending their notification to the old address, WHICH SHOULD NOT HAPPEN. The gateway was certainly updated as the internet pings hitting it moved to the new target (some 20 public IPs). Also, my netrom partners also followed after setting up the end axip endpoints on the new machine. I can not find an explanation for this, other than that there is some route caching involved. Maybe some of you have ideas/explanation on this behavior, and how to fix it. Marius, YO2LOJ

7 18

Re: [44net] IP-IP Mikrotik
by Rob Janssen 08 Oct '18

08 Oct '18

> thanks! I will read and do some tests on a spare MT router prior to > modifying our primary router Remember you can use CHR to do testing. Install it on a virtualization platform and you don't even need a physical system. It can do 1 Mbps for free (usually enough for IP-IP). When you have an existing ESXi host it is very easy to deploy it (using OVA template). It can also run on many of the available VPS services so you can have an IP-IP gateway when you cannot meet the requirements to reasonably run it at home (static IP, incoming protocol 4 without issues). You can then run an outbound VPN from your home to the CHR instance. Rob

1 0

IP-IP Mikrotik
by Dan Keizer 08 Oct '18

08 Oct '18

Hi there - Dan ve4drk here. I want to setup an IP-IP gateway on one of the Mikrotik devices we have on our network. We have a number of subnets defined in the 44 address space that we host locally via BGP. We'd like to ensure they are available to the IP-IP tunnels. I looked at this link: http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers and there is a reference to the MIkrotik setup by yo2loj - but it's a bad URL. Is there an update somewhere else I can't seem to find? I was checking the list and I see his link is down for a bit. 73, Dan ve4drk

3 3

Server down
by Marius Petrescu 08 Oct '18

08 Oct '18

Hello, Due to some bulldozer guy, yo2loj.ro and yo2m.ampr.org are down for the moment, probably for the whole week (they cut a main cable with some 200 pairs). I am migrating to a VPS, to get the download section up asap. Tnx, 73s, Marius, YO2LOJ

1 0

Recent news regarding Mikrotik remote root access
by John Ricketts 07 Oct '18

07 Oct '18

Fresh from DerbyCon/Jacob Barnes: "Hey @derbycon if you didn't wake up early enough to catch my talk, I just dropped a variation on CVE-2018-14847 that allows attackers to remotely root a Mikrotik router: " https://github.com/tenable/routeros/tree/master/poc/bytheway

4 6

TAPR Elections
by Brian 06 Oct '18

06 Oct '18

I was asked by one of the current TAPR board members to throw my name into the hat for this year's elections which I have done. One thing I would like to try to do is help us get some exposure on TAPR with our projects amongst other things I'd like to help accomplish. TAPR has been at some of our EastNet meetings and they know what we're about and are supportive of our use of IP over RF. I also would like to think having someone from within amprnet on the TAPR board could be beneficial to both. They should have emailed you a ballot with your membership ID number and expiration date of your membership. You'll need that to cast your 3 member vote. With that said, please cast a vote for me so that I'll be able to help achieve some great things for us all. Thanks in advance. -- Do Lipton Tea employees take coffee breaks? ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

1 0

Re: [44net] Right Way to Add IPIP Connections to BGP-Announced Network
by Rob Janssen 06 Oct '18

06 Oct '18

Jason, It is difficult to define "right way" because there always is someone with a setup that breaks when you do it in some way. Who is wrong and who is right is difficult to tell in such cases. We have a BGP-announced /16 for the Netherlands and we also announce the same /16 on the IPIP tunnel network. Subnets from this are routed internally (using BGP as well, but not related to the internet BGP, we use private AS numbers) and also some people have IPIP tunnels with subnets or addresses that are within the /16. We use ampr-ripd to get the IPIP routes. This works OK. People communicating to others that are on IPIP as well use the IPIP tunnel, when they want to talk to others they send it via IPIP to our gateway (i.e. our gateway is the default gw on the 44-net routing table, instead of amprgw as in the examples) and we decapsulate it and forward the internal IP packet to our internal systems or to internet. To have it working this way it is important that all routes are in the same routing table. You can use different metrics to avoid collisions between BGP routes and IPIP routes for the same subnet, but it is not a good idea to use different routing tables for BGP and IPIP routes and then use ip rules to lookup in those tables until a route is found. This is because a more specific route should always be preferred, independent from the routing protocol. So when a packet is to be routed, it is looked up in the table and either a route via the IPIP mesh or some other route is used to forward it. A destination on IPIP can be within the BGP routed subnet without problem, and vice-versa. It will work fine when the remotes on IPIP correctly route back to you via IPIP as well. But some stations use clever hacks to work around certain problems and the result can be that they are unreachable for people using this solution. Who is right and who is wrong is difficult to determine, as has been shown in earlier discussions on the list. Rob

1 0

Right Way to Add IPIP Connections to BGP-Announced Network
by Jason McCormick 05 Oct '18

05 Oct '18

With is the correct AMPRNet way to connect a BGP-announced AMPR netblock to the IPs that live behind IPIP tunnels? Should I just use one of my IPs in the /24 for the IPIP tunnel on my side, connect to 44.0.0.1/169.228.66.251, and use ampr-ripd? Or do I need a second subnet as in a "pure" IPIP setup and route between those networks myself? I'm not finding any good docs on the topic, but if I'm missing something please point me in the right direction. My understanding is that AMPR networks behind IPIP-based gateways can't necessarily get out to the wider Internet but rely on IPIP tunnels to different networks they want to reach via the rip44 service. We're working on setting up a larger Allstar-based repeater network and once we get it finally going, I want networks elsewhere in AMPRNet to be able to connect if they desire. Thanks. Jason

1 0

Re: [44net] Difference between RIPv2 and RIP44
by lleachii＠aol.com 04 Oct '18

04 Oct '18

Aaron, As Brian said, I have the following IPs online: 44.60.44.1 - ping, NTP44.60.44.3 - ping, DNS44.60.44.10 - ping, HTTP44.60.44.254 (only accessible on AMPRNet) - ping I allow ping from your Public IP endpoint address and your 44 subnet(s) in the Portal. If you're on AMPRNet, a folder containing the ITU Radio Regulations and compiled ampr-ripd versions will be visible on the web server at: http://44.60.44.10/amprnet_docs/ -------------------------- Miguel, Also, I've added Marius' information to the Wiki: http://wiki.ampr.org/wiki/RIP -------------------------- Marius, FYI, I am able to ping 44.0.0.1: root@OpenWrt:~# ip route get 44.0.0.1 from 44.60.44.144.0.0.1 from 44.60.44.1 via 169.228.34.84 dev tunl0 table 44 uid 0 cache expires 582sec mtu 1480 window 840 root@OpenWrt:~# ping 44.0.0.1 -I 44.60.44.1 -c 3PING 44.0.0.1 (44.0.0.1) from 44.60.44.1: 56 data bytes64 bytes from 44.0.0.1: seq=0 ttl=62 time=67.768 ms64 bytes from 44.0.0.1: seq=1 ttl=62 time=67.814 ms64 bytes from 44.0.0.1: seq=2 ttl=62 time=67.492 ms --- 44.0.0.1 ping statistics ---3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max = 67.492/67.691/67.814 ms 73, - Lynwood KB3VWG

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net