44net May 2017

44net@mailman.ampr.org

56 participants
149 discussions

netflow
by Brian Kantor 25 May '17

25 May '17

I'm now gathering netflow-like statistics from the router daemon. It's a lot of data. I've been unable to find a clear definition of the standard (v1 or v5) netflow disk file format, so I don't have input suitable for any of the good analysis tools. Does anyone have such a description? And what are your favourite analysis tools? - Brian

6 20

Re: [44net] Traffic not routing to my gateway
by Rob Janssen 25 May '17

25 May '17

> IPIP is possible on the SRX but not in cluster (virtual chassis mode) Being able to setup a single or even multiple IPIP tunnels is not suffcient to be a member of the AMPRnet IPIP mesh. See what Brian wrote: > This is a mesh network, not a star, so there is no default route; you > need a separate tunnel route to each gateway you want to communicate with, Marius has written a very nice script to get it working on a MikroTik router, but most other commercial routers lack the scripting capabilities to pull this off on their own. Someone wrote a script to use a Cisco router but it requires a separate machine to run it. Rob

5 9

Re: [44net] non-operational gateways
by Rob Janssen 24 May '17

24 May '17

> I've added code to the rip sender that watches for ICMP unreachable > packets coming back to amprgw during the rip sending cycle, which repeats > every 5 minutes. Make sure you act only on ICMP unreachables that refer to the protocol 4, not to the port 520! When protocol 4 is unreachable, it sure means the gateway is not operational, as it rejects operational traffic. When it rejects port 520, it could be that it is not using RIP to update its tables (it could be downloading encap files!) or even that it *is* using RIP but via raw sockets (ampr-ripd -r) and has a firewall that rejects the packets. ampr-ripd would still see and process them! That condition could be flagged in yet another status report, but it should not be a base to declare the gateway inactive. Also, we recently have seen some postings that indicate that some people operate a gateway that has tunnels to all other gateways, but explicitly have excluded a tunnel to amprgw. Because that brings mostly internet traffic and they don't want to have that. Of course another (not exclusively deciding) check on gateway activity could be to check if you actually receive any tunneled packets from them. I do have that as a byproduct of having an access list that accepts protocol 4 traffic only from addresses of registered gateways. At the moment it shows traffic from 34 different gateways (including amprgw). Of course, when the external address of a gateway changes, its history is lost. Rob

6 14

Re: [44net] non-operational gateways
by Rob Janssen 24 May '17

24 May '17

> Sorry to ask but what has accepting RIP to do with the gateway IP? > RIP is encapsulated into IPIP, so no firewall will ever care about that. > And no sane firewall setup will accept RIP on its WAN. > From both the gateway's point of view it's just protocol 4, nothing else. What I mentioned in my earlier post is that a "protocol unreachable" (for protocol 4 packets) is a serious condition although it could still be valid when encountered by amprgw and not by the other gatways. A "port unreachable" for UDP port 520 indeed is not an error condition. The gateway may not be using RIP. Or, the firewall may have been configured to reject port 520 traffic while ampr-ripd -r is still processing it. (not likely because the RIP traffic is multicast so would not normally be replied to by the firewall) To do some better "gateway alive" testing I think some extra steps are required: 1. a mandatory field has to be added to a gateway registration entry, with an IP address inside the routed subnets that is pingable. (of course getting everyone to enter this data will be difficult) 2. a separate "monitoring station" has to be setup that acts as a gateway and pings that address regularly (but not overly often) and keeps stats on the returned pings. The monitoring station has to be separate from amprgw because some people choose not to tunnel to amprgw. Alternatively, a checkbox could be added to gateway registrations to specify if the gateway wants to receive internet traffic (to be handled by the amprgw firewall table) and it could be made mandatory to tunnel to amprgw. That would probably be preferable, as it would also make 44.0.0.1 reachable for those gateways that do not want to get internet traffic. Adding the fields to the gateway registration system should be straightforward, but of course getting everyone to enter them wouldn't be. Not responding to a request to enter information of course could be treated as an indication that the gateway is no longer active. Rob

3 2

Re: [44net] non-operational gateways
by Rob Janssen 24 May '17

24 May '17

> There is also the question of how this data is to be transferred > from the portal to amprgw. We currently download the same encap > file that any gateway would use. Some new file format would also > be needed. It should be trivial to add another file, gateways.txt, that contains the per-gateway information. Or it could be added as comment lines into the existing encap.txt file. Maybe it would also make some tunnel creation scripts simpler when there is a section with gateway info (one line for each gateway, with a unique ID, the external IP, and info like proposed today: an internal IP and the "accept internet traffic" flag) ahead of the traditional route lines. It would allow the preparation of all required tunnel interfaces in environments where that is required before parsing the subnet routes. Rob

1 0

Reported AX.25 repository 'bug' on OpenWRT/LEDE
by lleachii＠aol.com 24 May '17

24 May '17

All, FYI, I'm not sure if anyone may be interested in setting up a portion of their allocation with an AX.25 ports (I definitely am). I informed the LEDE developers that they provide the kmod-ax25 package and its dependency; but do not provide libax25, ax25-tools and ax25-apps. The bug report can be found here: https://bugs.lede-project.org/index.php?do=details&task_id=802 73, - Lynwood KB3VWG

1 0

non-operational gateways
by Brian Kantor 23 May '17

23 May '17

I got to thinking about Ronen's question as to how to find non-functional gateway, and I've come up with a scheme. I've added code to the rip sender that watches for ICMP unreachable packets coming back to amprgw during the rip sending cycle, which repeats every 5 minutes. If an ICMP unreachable packet is received, the matching gateway is removed from that cycle, so with luck (if the unreachables get here quickly enough) we'll only send one or two packets to a gateway that's not reachable. The time and gateway address are logged; some future process should be able to analyze this log and do something about the gateway if it's out of service long enough. (What it will do about it isn't exactly clear right now.) This doesn't seem to have slowed down the rip sender much if at all. - Brian

2 2

Re: [44net] RIP transmission question
by Rob Janssen 23 May '17

23 May '17

> That's actually a limitation on how multicast works. In usual > circumstances, a router does not listen to multicasts not originating > from the subnet its interface is connected to. Could that be the reason why ampr-ripd multicast mode does not work for me? I always put the local address /32 on the tunnel interface. Maybe it would work when that is changed to /8 ? Rob

5 5

Re: [44net] RIP transmission question
by Rob Janssen 23 May '17

23 May '17

> I'm curious, what Router OS are you using? Debian Wheezy with backport kernel 3.16 Also Raspbian Wheezy with kernel 4.1.19+ Well, it probably is some setting. It has worked before but lately I have not seen any RIP packet in the iptables counters, even though I see them with tshark. Now I just use -r and that works. Not worth to spend effort on. Rob

1 0

RIP transmission question
by R P 23 May '17

23 May '17

Hi there I understand that two ways optional to send RIP info 1) multicast (what now is operative) 2) direct transfer The multicast require that both interfaces AMPRGW and the ham gateway will have same netmask (in our case /8) is it the same with the direct transmit ? If yes why the multicast way was chosen ? what is the benefit ? Thanks for any info on the subject Ronen - 4Z4ZQ

4 5

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net May 2017