44net April 2017

44net@mailman.ampr.org

41 participants
78 discussions

Peculiar packet
by Brian Kantor 27 Apr '17

27 Apr '17

A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8) is sending an encapped packet that is peculiar: it is either 40 or 44 bytes long, but the length field in the IP header is set to a varying but very large packetsize (for example, 61,683 bytes) and the Don'tFragment bit is set so the amprgw IP kernel sending routine can't break it up into MTU-sized fragments - thus it gets a transmit failure and isn't sent anywhere. The inner source is always 44.4.39.8, but the destination varies a lot. I'm completely puzzled by this: I don't know how any common operating system would be generating such a packet. I can see how a naive IP implementation might have a problem when receiving a packet that is relatively small but claims to be large. Does anyone know: is this a deliberate attempt to sabotage the destination host? - Brian

2 3

rip sender
by Bill Vodall 26 Apr '17

26 Apr '17

> the rip sender; Is there any tool for doing local Rip packet generation similar to the main AMPRNet one? Perhaps Github or ? I'd like to use it for testing and, prior to opening up with the official system, building both local and community 44-net subnets. 73 and thanks.. Bill, WA7NWP

2 2

Subnets
by Tom Hayward 26 Apr '17

26 Apr '17

How do you add a subnet to a gateway? I have a /24 assigned to me and I want to use a /32 of it with an IPIP gateway. I added the gateway in the portal. Then when I went to add the network, the /24 is listed in the dropdown but I can't figure out how to add the network with a larger prefix. I don't want the whole /24 to route through this one gateway. Tom KD7LXL

3 4

Re: [44net] Subnets
by Rob Janssen 26 Apr '17

26 Apr '17

> How do you add a subnet to a gateway? I have a /24 assigned to me and > I want to use a /32 of it with an IPIP gateway. I added the gateway in > the portal. Then when I went to add the network, the /24 is listed in > the dropdown but I can't figure out how to add the network with a > larger prefix. I don't want the whole /24 to route through this one > gateway. That cannot be done. You can only gateway registered subnets. You would have to get the /32 assigned to you as well, and I think that will be rejected when the /24 already is of the type "End user". Maybe it can be done manually by one of the portal admins.... Rob

2 1

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2017