44net

44net@mailman.ampr.org

3196 discussions

amprgw router statistics
by Brian Kantor 30 Apr '17

30 Apr '17

As I've mentioned, I'm now logging statistics for the amprgw router. I could make these available on a web site, but I'm hesitant to do so without consensus from the community because the per-gateway stats have the side effect of revealing what subnet goes to what gateway, thus giving the bad guys more insight into how the AMPRNet-Internet gateway works and what hosts to impersonate to inject bad packets into the network. A sample of the statistics file is below. What do you folks think about making this available? - Brian started at Sat Apr 29 10:15:37 2017 snapshot at Sat Apr 29 10:45:00 2017 uptime: 0+00:29:23 (1763 seconds) packets/bytes ---------/--------- 121781/76089093 ipip encapped input 117631/73371842 forwarded out 0/0 no source gateway 467445/48802372 raw input 467434/48801678 encapped out 0/0 no destination gateway 2646/175516 encap to encap dropped 7692 discarded 0 TTL exceeded 0 ICMP sent 615 routes loaded (gateway counters cleared) 1486 seconds ago at Sat Apr 29 10:20:14 2017 entry subnet encap gateway outpkts outbytes inpkts inbytes ----- ------------------- ----- ---------------- --------- --------- --------- --------- 0 44.0.0.1/32 ipip 169.228.66.251 2 175 0 0 [etc]

7 19

portal down
by Brian Kantor 30 Apr '17

30 Apr '17

The portal has apparently crashed. I have no way to remotely restart it, so it'll probably be down all night until Chris wakes up and can take a look at it. - Brian

10 12

amprgw and IGMP and ICMP
by Brian Kantor 28 Apr '17

28 Apr '17

Recently I noticed people sending IGMP protocol packets to amprgw, which discards them (as it does for all multicast destinations sent to it). I don't think I'm going to write the necessary code to handle group membership, so dropping the packet is probably the best thing to do. Amprgw currently does NOT send 'destination unreachable' ICMP packets, including 'protocol unreachable', because those should be rate limited which makes coding the necessary response mechanism somewhat complicated. (True, I could steal the necessary code from the FreeBSD kernel and adapt it, but that's a lot of work. Maybe someday.) And I also don't want to use up encap bandwidth sending ICMP back to the AMPR hosts. The only ICMP that amprgw currently will originate is TIMXCEED when an encapped packet's TTL reaches zero, so that 'traceroute' will work. - Brian

2 1

Re: [44net] Gateway 77.138.34.39 (MikroTik discovery protocol)
by Rob Janssen 28 Apr '17

28 Apr '17

> That is the Mirkotik discovery protocol indeed. I struggled with this too at first until I found that you can enable/disable it on select interfaces. By default it sends and listens on all interfaces. I'll post a small tutorial on where to find and disable it per interface when I arrive at work (unless someone beats me to it) > I also firewalled in&outbound that on all but my internal interfaces just to be extra certain. I would recomend everyone doing so too unless you need it for some reason on an external interface. > Like with Cisco's CDP or Juniper's LLDP, you normally don't need it on external interfaces. Well, actually it would not be so bad to run this, and implement a receiver program on amprgw and other gateways. It provides useful info about what is at the other end of the tunnel, including the IP address of the router, software version, identity, etc. When everyone would be running this, you would have an immediate overview about which tunnels are alive, etc. A bit problematic could be that the router likely sends all packets at the same time and thus some 400 packets are queued for output at once, clogging up the internet interface. Rob

1 0

amprgw stats
by Brian Kantor 28 Apr '17

28 Apr '17

I've spent the last few hours adding some instrumentation (various counters) to the ipip daemon. Here's a sample of some of the data I now have available. This is a work in progress. The counters are packets/bytes. - Brian started at Thu Apr 27 22:51:19 2017 uptime: 0+00:08:41 15940/8895013 encapped input 13516/8414203 forwarded out 0/0 no source gateway 158252/9266766 raw input 159062/9316591 encapped out 0/0 no destination gateway 1613 discarded 0 ttlexceeded 614 routes (614 ipip, 0 udpip) loaded 521 seconds ago at Thu Apr 27 22:51:19 2017

2 4

Gateway 77.138.34.39
by Brian Kantor 28 Apr '17

28 Apr '17

Once a minute, at 8 seconds past the minute, gateway 77.138.34.39 sends an encapped UDP packet to the amprgw router that has a zero inner source address and an all-ones inner destination address. The payload length is 94 bytes and the source and destination ports are both 5678. The periodicity suggests that it's some process that runs every minute (out of crontab?) and takes about 8 seconds to complete. There is a list of things port 5678 may be used for at http://www.speedguide.net/port.php?port=5678 This may be Mikrotik Neighbor Discovery protocol. Here's a log record of one such packet: Apr 27 17:02:08 <local0.info> amprgw ipipd[22702]: 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 And here's a tcpdump of one: 17:06:08.419945 IP (tos 0x0, ttl 242, id 36314, offset 0, flags [none], proto IPIP (4), length 142) 77.138.34.39 > 169.228.66.251: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 122) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 94 The portal record shows that this gateway belongs to Ronen Pinchuk [4Z4ZQ]. Ronen, when you have a few spare minutes, could you look at your gateway and see if you can stop this from happening? - Brian

6 10

Re: [44net] Peculiar packet
by Jeremy Cooper 27 Apr '17

27 Apr '17

This is my gateway. I'll shut it down until I can figure out what is happening. I run FreeBSD and 44ripd, so that's why I am unusual. Someone did indeed try a very aggressive portscan from a very diverse set of hosts against me recently: Apr 26 21:28:33 bbs kernel: Limiting closed port RST response from 402 to 200 packets/sec Apr 26 21:31:45 bbs kernel: Limiting closed port RST response from 208 to 200 packets/sec Apr 26 21:31:48 bbs kernel: Limiting closed port RST response from 395 to 200 packets/sec -J > On Apr 26, 2017, at 20:30, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > 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 > ...

3 5

minor RIP change
by Brian Kantor 27 Apr '17

27 Apr '17

I've implemented a new faster gateway search algorithm for the ipip daemon (it looks up what gateway a given packet is to be sent to). This required that the routes be stored in the global routing table in ascending order, which is opposite from before, so the order of routes in the RIP packets has also reversed. I don't think this matters to anything but I thought I'd better let you folks know just in case something started behaving oddly a few minutes ago. - Brian

2 2

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net