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
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
> 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
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
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
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
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
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
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
> 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
