44net March 2015

44net@mailman.ampr.org

22 participants
20 discussions

TUNNEL vs DIRECT connection of subnets
by Brian Kantor 14 Mar '15

14 Mar '15

At the current moment I can see no way for an AMPRNet subnet to be both TUNNEL and DIRECT (BGP-announced) connected, unless a special provision has been made to operate a gateway from a non-44/8 address into the BGP-connected subnet. This is because the tunnel mesh can't reach 44/8 addresses that aren't reachable via a non-44/8 tunnel entrance. This means that we can't have gateways whose entrance address is in 44/8. This implies that TUNNEL and DIRECT should be mutually-exclusive options in allocation requests. I'd be happy to be wrong about this. - Brian

3 3

Re: [44net] TUNNEL vs DIRECT connection of subnets
by Bryan Fields 14 Mar '15

14 Mar '15

On 3/13/15 9:30 PM, Brian Kantor wrote: > At the current moment I can see no way for an AMPRNet subnet to be both > TUNNEL and DIRECT (BGP-announced) connected, unless a special provision > has been made to operate a gateway from a non-44/8 address into the > BGP-connected subnet. > > This is because the tunnel mesh can't reach 44/8 addresses that aren't > reachable via a non-44/8 tunnel entrance. > > This means that we can't have gateways whose entrance address is in 44/8. This has been a known issue for about two years now. The solution to this is to fix the routing on the gateway at UCSD for the IPIP encap users. If UCSD network department is unwilling to fix this I'm sure we can find an alternate IX who would be willing to make it work. I know my users are more concerned with access to the internet than access to the rest of 44net, and the ipip encap mesh cannot be configure on the border router (IPIP encap needs an hardware option). I'm experimenting with a vRR that might be able to do it in software, but it's not high on my list of things to do. I believe Tim Osburn did some work regarding a tunnel endpoint to bridge the gap here, but this single gateway design for the IPIP users is holding amprnet back, and has been for some time. 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] Portal changes
by Rob Janssen 13 Mar '15

13 Mar '15

> Subject: > Re: [44net] Portal changes > From: > Chris <chris(a)g1fef.co.uk> > Date: > 03/12/2015 08:12 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > This is an issue that has cropped up before and was on my TODO list: as you quite rightly point out, some networks are connected via multiple means, e.g. BGP and Tunnels, etc. > > So today I have crossed off one more item from my TODO list, networks now have three separate checkboxes for connection type and you can check more than one (or leave them all unchecked if the network is not yet connected). > > The changes involved several processes so if anyone finds any bugs that have crept in, please let me know. > > Also, for anyone that has an allocated network, please ensure that the correct box(es) are ticked for your network(s). > > Thanks, > Chris > Please make it possible for coordinators to enter regional networks and edit existing ones. Also when hosts and/or subnets already exist in those ranges (i.e. please get rid of the "there are children" error message and allow the operation anyway). It is very difficult to restructure the network registrations as it is now. One really cannot expect that everything will be correct from the start. I entered network descriptions in the HamnetDB and it does not show those issues: there one can define a subnet between the country- and user networks without problem, and also remove or resize it at will. Rob

1 0

VPN tunnel FAIL
by Mathison Ott 13 Mar '15

13 Mar '15

I need help trouble shooting the vpn tunnel ive setup on my RPI its part of a mesh network, here in berkeley,CA. pi@KJ6DZB-4 /etc/openvpn $ service openvpn restart [ ok ] Stopping virtual private network daemon:. [....] Starting virtual private network daemon: clientEnter Private Key Password: failed! Ive set up the same Cert and key file on a windows box and it works. 73 Mathison kj6dzb

2 1

Portal changes
by Chris 12 Mar '15

12 Mar '15

Hello Everyone, I finally found some free time and have been working on the Portal code today: Fixed a few bugs that have been reported to me; Altered the wording on the emails that are sent out following feedback; Removed validation checks for co-ordinators rejecting IP allocation requests; Removed strict control over what networks can be added to gateways. The last point probably requires further explanation: I added a filter that only allowed gateway owners to link networks to their gateways that were a) allocated and b) owned by them. This caused some issues as some people have their networks announced by gateways controlled by other people. So now, anyone can add any network to their gateway that a) has been allocated, and b) has the "connection type” field set to “TUNNEL”. You just select which network you want to add from the drop down box. If the network you wanted to add doesn’t appear in the drop down box, please check that it has been allocated and that it’s connection type is set to “TUNNEL”. Any problems, bugs, etc, please let me know. Thanks, Chris

6 8

Re: [44net] portal changes
by F6CNB 12 Mar '15

12 Mar '15

Chris, Thanks for the work. In the portal gateway network allocations, I think a free typing instead of the lis twill be more useful. It'll allow to add allocations which were not classified as tunnel at the time of the creation and more important i twill allow the group multiple allocated subnets in a single one for gateways which are handling multiple allocations. This will reduce the size of the routing table. 73 de Remi F6CNB

2 1

Re: [44net] Portal IPIP Mesh Announcements
by Brian Kantor 05 Mar '15

05 Mar '15

On Thu, Mar 05, 2015 at 12:00:00PM -0800, 44net-request(a)hamradio.ucsd.edu wrote: > > I've been asked to host 44.158.144.0/22 on my Gateway DB0FHN. It seems > > the portal has changed the policy. I can't add 44.158.144.0/22 to my > > gateway 141.75.245.225. > > > > I guess I need to foward this to Chris? Jann, I added it for you. - Brian

1 0

Portal IPIP Mesh Announcements
by Jann Traschewski 05 Mar '15

05 Mar '15

Hi! I've been asked to host 44.158.144.0/22 on my Gateway DB0FHN. It seems the portal has changed the policy. I can't add 44.158.144.0/22 to my gateway 141.75.245.225. I guess I need to foward this to Chris? 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

2 1

Multicast problem?
by Rob Janssen 02 Mar '15

02 Mar '15

While debugging the "suddenly lost route" that happened again at our gateway today, I stopped and restarted ampr-ripd to use the debug option, and now it suddenly no longer receives any multicast packets. I think I have read on this list or elsewhere that there is an issue with a recent glibc update or kernel update (not sure which one it was). Does anyone have details? Now ampr-ripd only works when the -r flag is passed. Without -r it sets up everything and it opens the multicast socket (which appears to work OK when looking in the trace, it is opened on the tunl0 interface), but nothing is ever received. It looks like it worked OK during the previous run, which was probably using an older glibc that was updated recently (but the system had not been rebooted). It is a Debian Wheezy system, so similar issues probably occur on the Raspberry Pi. W.r.t. the problem I was tracking: the route to 44.137.33.48/28 via 92.108.199.241 dev tunl0 has suddenly vanished at 17:00 local time (16:00 UTC), but when I looked in a wireshark dump it was appearing in the RIP broadcast. ampr-ripd did not pick it up. To trace that I recompiled ampr-ripd with debug code, started it, and then I noticed it would no longer receive ANYTHING. With -r it again receives packets and it also inserted the route to 44.137.33.48/28 again, so I am still at a loss what happened there. Rob

5 6

Re: [44net] Multicast problem?
by Rob Janssen 02 Mar '15

02 Mar '15

> Subject: > Re: [44net] Multicast problem? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 03/02/2015 08:44 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > ampr-ripd works as expected without the -r option on my debian 7 setup with > kernel 3.2.0-4 and libc 2.13.38-0deb7u7. > I never upgraded to 2.13.38-0deb7u8, so the problem could be there. > > By the way, as sugested by Brian, N1URO, I think the -r option could be > dropped so that the daemon always uses raw sockets. Ok, the status on this machine now is: Linux gw-44-137 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux (a kernel update to Debian version 3.5 (still kernel 3.2.0-4 of course) has been installed but the system has not been rebooted yet) libc is version 2.13-38+deb7u8 So indeed it could be that version that is the problem. With -r it works ok, but of course it means that ALL received tunnel packets are passed to ampr-ripd to be filtered there in user mode. The multicast socket should be more efficient. It has worked quite well for a long time, why would it suddenly fail? (of course there is still the problem of sometimes disappearing routes that you may notice I am already hunting down for quite some time and I am not even sure if it is in ampr-ripd, in the RIP transmitting server, or somewhere else) Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2015