44net

44net@mailman.ampr.org

3196 discussions

ampr-ripd 2.1 released
by Marius Petrescu 29 May '17

29 May '17

Hello everyone, I released a new version of ampr-ripd (2.1) with fixes and additions. Changelog: - Fixed a segfault when using the -F option - Added the possibility to use interface names for the -g option - Interface used for raw RIP forwarding restarts on interface error Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.tgz Have fun, Marius, YO2LOJ

4 7

Latency in various protocoles
by R P 29 May '17

29 May '17

Im experimenting two net cameras on the AMPRNET One is http streaming the other is RTSP streaming The http uses tcp port 80 the rtsp uses udp (dont remember the port now ) The http replace photo every 250 MS (i assume after it get ACK and then send the next image) ( i see about 4 frames per second) and make a traffic of about 1000 kbit/sec the RTSP send photos in about 10 frames per second and produce traffic of about 500-800 Kbit sec all this over the amprNet May someone explain this ? how come that the RTSP photo is like movie and the http is 4 frames per second (of course that if i view the http camera direct on the net i see the 10 frames per second i set the camera for) And why i tell you all of this ? Because i wonder how a DMR repeater connection will work on the amprNet ... If i can see in RTSP video without problems or frame loss should a VOIP (or more exact) data stream of the DMR work ? after all it is less data .... Is there anyone that can light my eyes on the subject ? Regards Ronen - 4Z4ZQ

2 3

unreachable gateways and hosts
by Brian Kantor 28 May '17

28 May '17

I'm experimenting with a new technique in the routing daemon on amprgw: if during a send to a gateway, the router gets certain ICMP UNREACHABLE packets from the gateway it's sending to, it drops the host or gateway from the routing table for a time. This has the effect that if a gateway tells us that they don't want packets from us by means of sending us a HOST or NET unreachable ICMP response, we'll stop sending to them for a while. Specifically, PORT UNREACHABLE is ignored. We don't route based on ports. Any of the various HOST UNREACHABLE packets will defer just the one destination host that was being sent to from the routing table; any of the NET UNREACHABLE or PROTOCOL UNREACHABLE packets will defer the subnet from the routing table. The deferral period is currently set to 15 minutes. Watching this happen, one can observe that every 15 minutes, there are a number of hosts and a subnet or two deferred out of the table as packets are sent to them and rejected by the gateways. The number added to the deferral list drops in rate as time goes on. When a gateway changes its address, it is immediately removed from the deferral list. As with the ICMP response suppressing sending RIP transmissions, the purpose of this is to not bombard gateways with packets they don't want and aren't going to deliver anywhere. This is especially important with the number of dynamic gateways we have, where a change in the gateway address may wind up sending IPIP packets to an innocent host that has inherited the gateway's old address. Packets to unreachable destinations are dropped; we don't send UNREACHABLES ourselves. (With all the backscatter and probes, we'd be sending a LOT of them.) We're trying to be good net neighbors. - Brian This is what the log entries look like: May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.104 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.236 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.4 deferred May 28 03:54:37 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 97.84.0.85: subnet 44.102.132.0/24 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.153 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:42 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 40.143.112.188: subnet 44.88.8.32/28 deferred May 28 03:54:43 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 216.161.250.190: host 44.22.128.10 deferred May 28 03:54:44 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.102 deferred May 28 03:54:45 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 78.226.112.146: host 44.151.67.67 deferred

4 8

icmp redirects to the new router
by Brian Kantor 28 May '17

28 May '17

On Fri, May 26, 2017 at 04:04:24PM -0700, David Ranch wrote: > Hey Brian, > What about configuring an ICMP direct on the old IP to point to the new IP? > --David > KI6ZHD Well, after thinking about it a bit and reading the relevant RFCs, I thought I'd give it a try and wrote some code in the router daemon to do this. Unfortunately, the FreeBSD kernel prohibits a user-space process from sending ICMP Redirects - you get 'Permission denied' errors when you attempt to write one to the outgoing ICMP socket. Too bad, it would have been an interesting experiment. Maybe there's some way to fiddle the routing table so that the kernel itself sends them. I'll look into it, but a quick peek into the kernel source suggests it's not doable. - Brian

2 2

ampr-ripd test version 2.1
by Gustavo Ponza 28 May '17

28 May '17

After Marius continued efforts [TNX] see the results of the new feature *raw AMPR-RIPD forwarding* at: http://44.134.32.240/www/tun0.html ampr-ripd traffic slowed down from 5.3 kb/s to 1.6 kb/s maintaining/obtaining the same effect. The blue peaks (outgoing traffic) denote the various kinda attacks on the structure. -- 73 and ciao, gus i0ojj A proud member of linux team Non multa, sed multum

2 1

ampr-ripd-1.16.3 and saving routes?
by Steve L 28 May '17

28 May '17

Has anyone else had an issue where even though you use the -s option, you don't have a /var/lib/ampr-ripd/encap.txt file? I know this was working for me in prior versions.

3 2

How to modify the mikrotik scripts to work in current "dual gateway" setup
by Marius Petrescu 28 May '17

28 May '17

Hi guys, I tried to set up my router so match the current situation, so here are the steps to get it working: 1. add a filter to Routing->prefix lists to drop 44.128.0.0/16, prefix length 16-32, similar to the one for 44.0.0.1 (IMPORTANT - the dynamic created ampr-169.228.34.84 would interfere with our tunnel base interface , having the same IP endpoint and taking precedence over it being newer) For the RIP protocol, you should now have drops on 44.0.0.1 pref len 32, 44.128.0.0 pref. len 16-32 and your local subnets (if any are there), accept the rest. 2. Change your endpoint in the current ucsd-gw interface from 169.228.66.251 to 169.228.34.84 3. Delete the interface ampr-169.228.34.84 in Interfaces 4. Delete the now invalid route to 44.128.0.0 in IP->Routes Wait a while for the first RIP update. Mesh access should work fully now and you should see RIP updates in Routing->RIP->Routes If you need access from internet to your 44net hosts, these are the additional steps: 3. Add a new IPIP interface, lets say 'ucsd-gw-old' with endpoint 169.228.66.251 (like the old one) 4. Add an unused 44 local ip other than your gateway IP witm mask /32 to the 'ucsd-gw-old' interface in IP->Addresses 5. Add similar connection marks as the ones for ucsd-gw for uscd-gw-old under IP->filter->mangle 6. Check your firewall filters to allow incoming connections from ucsd-gw-old like tho ones from ucsd-gw (input and forward) These latter changes will be removed after full switch to the new gateway. Marius, YO2LOJ

2 3

Good News! and some changes coming
by Brian Kantor 27 May '17

27 May '17

Good News! Our friends in the CAIDA research group at UCSD have come up with a new machine for amprgw, quite a bit newer than the existing one, and with faster CPU, more cores, and more memory. It also has RAIDed disk and dual power supplies, although unlike the current amprgw, it won't be on a UPS. (There isn't a UPS in the new building where the new machine is located. Luckily our power is pretty reliable; besides buying utility power, UCSD also generates its own from solar and natural gas sources. And we don't have lightning storms very often here in the almost-desert.) There will be some minor differences between the machines, of course, although small enough that I hope to move all the services over from the old machine to the new one over the next several weeks. The primary difference is that the gateway will have a NEW ADDRESS and a slighly DIFFERENT NAME. Instead of being known as 'AMPRGW.SYSNET.UCSD.EDU' as the current one on address 169.228.66.251 is known, the new machine will be 'AMPRGW.UCSD.EDU' (no 'sysnet' in the name), and will be on address 169.228.34.84. You should probably adjust your firewalls soon, letting both machines in for a while, as they will both be operating at the same time as services are moved from old to new. Do not move your tunnel endpoints to the new machine quite yet; that won't work until the routing software is installed and reconfigured for the new address. I'll let you know what it's ready for that. - Brian

8 27

documentation of gateway move
by Michael Fox - N6MEF 27 May '17

27 May '17

I can find where the new amprgw info is documented. Shouldn't the old/new hostname, external IP address and cut-over date appear prominently somewhere? Michael N6MEF

3 4

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> Yes, it's on the same box, but because the two boxes are on physically > different networks, I can configure them both to be 44.0.0.1 without > conflict. One of them won't get any packets except those originating > on its own physical network, but they won't conflict. That's what I've > done; when the 44/8 route next hop is moved from old amprgw to new amprgw, > which machine serves 44.0.0.1 to the outside will automatically change. I think when you announce 44.0.0.1 with the new gw address on the gateways list (encap, RIP) and keep the 44.0.0.0/8 BGP pointed to the old box, users with a tunnel will connect to the new box and those connecting from internet will get the old box, without any conflict or need to re-route things inside the campus network. That makes it possible to test tunnels two-way. But it is not that important, it will probably work right away and obvious mistakes will be found and fixed within one or some days, which is good enough. I have been doing quite some rebuilding lately, short downtimes sometimes are unavoidable when working within hobby constraints. Rob

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net