44net

44net@mailman.ampr.org

3196 discussions

Pls help! on adding subnet
by Pedro Converso 26 Mar '15

26 Mar '15

I am unable to set a subnet either thru portal or Robot email. Thru portal added dynamic GW lu8fjh.dyndns.org actually on 201.253.187.32 Trying plaintext email to gateways(a)ampr.org: Gateway: lu8fjh.dyndns.org Password: xxxxxxxx Subnets: 44.153.072.013/32 Title: GW lu8fjh.dyndns.org for 44.153.72.13 New Entry I get answer back as a line just saying: *** Gateways V 6.0 ** Thru portal there are many subnets to choose, but there is no way to add a new one. Emailed to ampr development but no answer up to now. Don't know if have something to do, have seen on 44net msgs there is a setting to specify either TUNNEL or BGP but don't see where to specify. Appreciate any advice! 73, lu7abf, Pedro 44.153 Argentina ampr Coord

1 0

help for changing an existing allocation
by F6CNB 24 Mar '15

24 Mar '15

I need to add the subnets 44.168.52.0/24 and 44.168.254.24/29 to my gateway but the 44.168 coordinator seems to be out of reach. I am running the French gateway for 44.168.0.0 and this subnet is not allocated to me neither defined (I assume) as connected thru a tunnel. Is somebody can change the flag to tunnel. That way , I can add it to my gateway and get the proper routing for Ile de La Reunion which just joined the "European" HAMNET network. Chris, The flags are confusing in the case of HAMNET France. Most of the subnets are radio connected to my gateway thru high speed 5.6/5.7 links. It is not obvious at all for them that they need to check gateway/tunnel and not radio. As I operate a large gateway to a fast growing network, The old free typing gateway subnet routing was a lot of more convenient. 73 Remi F6CNB (or W5/F6CNB)

2 1

Re: [44net] Multicast problem?
by lleachii＠aol.com 23 Mar '15

23 Mar '15

I'm also experiencing the same issue (no routes received) with rip44d... There is no -r option. Suggestions? - KB3VWG

1 0

Proposal on using the "Radio" flag
by marius＠yo2loj.ro 17 Mar '15

17 Mar '15

In light of what was discussed here, I would propose the following usage of the "radio" flag: A subnet marked as "Radio" should use this flag exclusively and inherit the Tunnel or BGP flag from its parent network. For allocation only purposes only, a network without any flags is enough. Rationale: A pure radio network doesn't exist from the point of view of ampr-net since it would not present any internet connectivity. If this connectivity is present, meaning it is reachable by any kind of means, IPIP or BGP routed, it will allow a connectivity method, the same as its parent network. 73s, Marius, YO2LOJ

8 8

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

14 Mar '15

> Subject: > [44net] TUNNEL vs DIRECT connection of subnets > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 03/14/2015 02:30 AM > > To: > 44net(a)hamradio.ucsd.edu > > > 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. Sure, but I think that is not unreasonable. We do it on our gateway and there is no problem with it. The provider has issued a small non-44 subnet to the gateway machine and it routes the net-44 traffic to that address. (i.e. our provider announces 44.137.0.0/16 on BGP and accepts the traffic on their core router and they forward it to us, we forward our traffic for internet to them on another address in that subnet on which their router listens). We are also on the IPIP mesh with our /16 and the tunnel endpoint is that same non-44 address (213.222.29.194). This means that other IPIP gateways forward traffic via a tunnel. This works just fine. It also means the others do not have to setup exceptions for our subnet in their IPIP tunnel systems. Getting the /30 network required for this should be no problem even today. Rob

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net