44net

44net@mailman.ampr.org

3194 discussions

rip sender bug
by Brian Kantor 26 Apr '17

26 Apr '17

I just found and fixed another off-by-one error in the rip sender; this one had the effect of omitting the last route in each sent packet. Packets should hold up to 25 routes; they were being sent one route short at 24. Effectively, 25 subnets were missing from the rip transmissions. Oops. Sorry folks. - Brian

1 0

Revised amprgw firewall rules
by Brian Kantor 25 Apr '17

25 Apr '17

These are the rules that route AMPRNet traffic to and from the ipip daemon (FreeBSD ipfw syntax): # # AMPR routing # # table(1) contains all registered/routable 44net addrs. # table(2) contains all registered gateways. # outbound encapsulated packets # should go only to registered gateways 00100 allow ipencap from me to 'table(2)' # inbound encapsulated packets # should only come from registered gateways 00200 allow ipencap from 'table(2)' to me # filter the 44net input side of things # valid destination addresses go to the router socket: ipipd 00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547 # filter the 44net output side of things 00400 allow ip from 'table(1)' to any Explanation: Preliminary filtering of incoming packets is done by the BSD ipfw firewall because it's easy to set up and very fast. Quite a bit more filtering is done by the ipip router daemon. Ipfw table 1 contains a list of the 44-net host addresses from the AMPR.ORG DNS zone file that are routable according to the encap file. Table 2 contains a list of the gateways from the encap file. Once an hour, the AMPR.ORG DNS zone file is fetched, normally at 10 minutes past the hour. Also hourly, the encap file is fetched from the portal, normally at 20 minutes past the hour. Whenever these files differ from their previous version, the ipfw tables are flushed and reloaded. When the encap file changes, the ipipd routing and the rip sender tables are also reloaded. Rule 100 allows the encapped packets out to registered gateways. Rule 200 allows encapped packets in only from registered gateway source addresses. Rule 300 diverts incoming IP to the ipipd encapsulating router if the destination address is for a registered/routed address and not for certain destination ports. Rule 400 allows outgoing IP with source addresses from registered/routed hosts. That's about all the filtering that can be done without looking inside the encapped packets, which the BSD firewall can't do. The ipipd daemon handles that, and is much stricter. - Brian

3 6

Mikrotik router corrections
by Marius Petrescu 25 Apr '17

25 Apr '17

Hello, Since the appearance of the 44.0.0.1 route in RIP, some of you using the Mikrotik script may have noticed the disappearance of the RIP broadcasts and missing updates. This happens because of the creation of a alternative tunnel from your router to ampr-gw (ampr-169.228.66.251), which highjacks the normal ampr-gw tunnel. To correct this, follow the following steps: 1. under routing->prefix list create the following rules in the given order: chain ampr, prefix 44.0.0.1, prefix length 32 discard chain ampr, prefix 44.0.0.0/8, prefix length 8-32 accept chain ampr, prefix 0.0.0.0/0, prefix length 0-32 discard 2. under routing->rip->interfaces on your ucsd-gw set the 'ampr' prefix list as 'In Prefix List' 3. under interfaces find and delete interface ampr-169.228.66.251 4. under ip->routes find and delete the route to 44.0.0.1 via unknown 5. Optional: if you like to have 44.0.0.1 routed via tunnel, add a static route for 44.0.0.1 via interface ampr-gw. Marius, YO2LOJ

3 5

Re: [44net] more gateway router follies
by Rob Janssen 25 Apr '17

25 Apr '17

> Belows IP's belong to SR3BBS gateway > which _IS OFF LINE_ for a long time! Then why is it in the table? Maybe it should again be considered to add a mandatory field to a gateway registration with a net-44 IP that should be pingable via the tunnel (e.g. the IP of the gateway itself) and run some very infrequent ping to that address from a monitoring system that is also on the tunnel network (not amprgw as some people apparently choose not to tunnel to that system). When e.g. one ping per hour is made and nothing is heard for 7 days or even more, the gateway can be marked down and removed from the encap.txt and RIP broadcast. The operator can then re-enable it via the portal. Rob

3 2

Clarifications on the working of ampr-ripd and amprd for BGP announced gateways
by Marius Petrescu 25 Apr '17

25 Apr '17

Hi everybody, Just to clarify the issues related to "strange routes" appearing during the use of the rip daemons. Together with Jann, DG8NGN, we devised a solution for interoperating BGP announced 44 subnets with the current full mesh tunnel system. Initially I implemented the system for testing and proof of concept in the Mikrotik script v.3.0, and later in the ampr-ripd starting with version 1.16 and amprd version 1.5. Current versions are 1.16.3 for ampr-ripd (bug fixes and small enhancements) and 1.6 (bug fixes), please use these. Now to the idea behind it... Directly BGP announced gateways need to be reached, well, directly, as any other gateway. If we have a default route by which we could reach the BGP announced hosts (via your public IP, please don't use default routes via amprgw!), on installing a subnet route via the RIP daemon, e.g. 44.130.121.0/24 (it is a working test host) then the endpint 44.130.121.2 will also be routed via the tunnel, creating a loop, which is of course wrong. So ampr-ripd will detect your default gateway on the system, and set host routes for those direct gateways via the default gateway, if the RIP announced gateway has a 44 address. The detection of the default gateway is done by getting the route to 8.8.8.8 from your kernel tables. So you will end up with 2 routes for that entry, like: 44.130.121.0/24 via 44.130.121.2 dev tunl0 proto 44 onlink 44.130.121.2 via 192.168.1.1 dev eth0 proto 44 onlink. In this case, traffic for those subnets (in this case to 44.130.121.0/24) will be encapsulated and sent directly to 44.130.121.2, which is reachable via internet. It is expected that your system will nat those destinations to your public IP (which probably happens). If the detection of your default gateway is not correct, there is a parameter '-g' by which you can set your gateway IP by hand. Your internal addresses are not published, nor are the known to the gateway. It is a local lookup performed by the daemons. At the moment there are 4 functional gateways using this setup: 44.130.121.2, 44.130.122.2, 44.130.124.2 (as test systems) and 44.131.14.255 as a live setup. Reachable tests hosts are: 44.130.121.3, 44.130.121.130, 44.130.122.3, 44.130.122.130, 44.130.124.3, 44.130.124.130, and of course the end points. (44.130.121.2 runs amprd, 44.130.122.2 runs ampr-ripd and 44.130.124.2 runs the Mikrotik script). I hope this clarifies some of the questions that may arise. Have fun with the hobby, Marius, YO2LOJ

2 1

more gateway router follies
by Brian Kantor 25 Apr '17

25 Apr '17

amprgw has recently logged several discarded packets like the following: Apr 24 18:44:03 <local0.info> amprgw ipipd[1518]: IBCAST: len 149, os 208.110.114.235, od 169.228.66.251, is 44.135.193.18, id 255.255.255.255, ttl 64, proto 17 encapped packets aren't supposed to send to the broadcast address (255.255.255.255). Apr 24 18:44:05 <local0.info> amprgw ipipd[1518]: ISRC0: len 122, os 77.138.34.39, od 169.228.66.251, is 0.0.0.0, id 255.255.255.255, ttl 64, proto 17 encapped packets aren't supposed to come from address 0.0.0.0 and encapped packets aren't supposed to send to the broadcast address (255.255.255.255). Apr 24 18:44:06 <local0.info> amprgw ipipd[1518]: TIMXCEED: len 52, os 85.234.252.133, od 169.228.66.251, is 44.165.53.254, id 224.0.0.9, ttl 1, proto 17 Looks like a routing loop on RIP packets. Ah well, variety is the spice of life... - Brian

2 2

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> Yes, it was intentionally dropped by the daemons. If it will be > reachable, I will update the code accordingly. I see it in the code now, just a couple of lines that can be deleted around line 1346: /* drop 44.0.0.1 */ if (rip->address == inet_addr("44.0.0.1")) { #ifdef HAVE_DEBUG if (debug && verbose) fprintf(stderr, " - rejected\n"); #endif return; } A temporary workaround until everyone has again updated ampr-ripd could be to announce 44.0.0.0/30 instead of 44.0.0.1/32 in the RIP sender. Rob

1 0

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> ampr-ripd does not set a route for 44.0.0.1, because that IP is not > reachable via the tunnel, only via the internet. Ah, it is treated as a special case? Brian has been working on that problem and now this route is announced again. (it had been deleted from the RIP broadcast before) I think it is added in the RIP sender, maybe it would be better to just register a portal entry so it is in encap.txt as well. Rob

2 1

Re: [44net] more gateway router follies
by Rob Janssen 25 Apr '17

25 Apr '17

What you logged there are probably DHCP packets and private use of RIP, not the AMPR-RIP. Well, I do see a lot of those things here either... Recently I again worked on the filters and found e.g.: - router-sourced traffic with inner source address equal to the external IP (bad source address selection) - router sending some of the traffic outside of the tunnel (net-44 to net-44 traffic unencapsulated) the funny thing is that e.g. when pinging them it returns via the tunnel but when doing BGP the SYN ACKs from port 179 come outside the tunnel. when the sender had proper source address filtering at their ISP I would not see those packets at all. - of course still a lot of traffic with inner source address in RFC1918 range The first two above are blamed on "MikroTik VRF". I never use it, I always use a manual implementation using multiple routing tables, ip routing rules and maybe some mangle rules just as I am used to do on bare Linux, and I don't have those problems. Another group swears by VRF and they always have issues. As I believe MikroTik VRF is just an an automatic configuration of the mentioned features and it apparently does not work completely OK (and may need some help e.g. some extra mangle rule). I tried to get information on what really happens when you define a VRF, but I was unable to get answers. Rob

1 0

Re: [44net] rip sender change
by Rob Janssen 24 Apr '17

24 Apr '17

> Yes, there was an off-by-one error in the count of entries in > the last packet. This error was not present when we were sending > in gateway major order, but was there in packet-major-order which > change I made early today. It has been corrected. Please check > the next RIP update and see if that fixes things. Ok, now I get the correct RIP packet :-) But the entry still does not appear in the route table... :-( IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 IP Address: 44.0.0.1, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.0.0.1 (44.0.0.1) Netmask: 255.255.255.255 (255.255.255.255) Next Hop: 169.228.66.251 (169.228.66.251) Metric: 1 44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1 44.2.2.0/24 via 24.52.189.1 dev tunl0 proto ampr-ripd metric 4 onlink So now I can continue local debugging to see what is going wrong... It fails both on the gateway (running latest ampr-ripd) and the Raspberry Pi (running earlier version). It does not appear in /var/lib/ampr-ripd/encap.txt either. Never assume there is only one bug... Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net