44net

44net@mailman.ampr.org

3 participants
3195 discussions

Re: [44net] Dumb question - 44.130 IP address?
by Dg7nef 08 Feb '16

08 Feb '16

Hi group, hello Thomas, IIRC the initial assignment was in fact given to me by you and Paul, so I'm happy to hear from you again. :) On 02/07/16 23:55, Thomas Osterried wrote: > Hello, > > well, a longer tradition than the quite new portal are the country-wide IP-Koordinators. > > In DL, we have the coordination team of three people (dd9qp, dg8ngn, dl9sau) and we delegate the responsibility of the local assignments to the regional coordinators. This concept goes back to the last century. > From the regional coordinator, Wolfgang had got the initial assignment of his IP addresses. That is correct. And that was kind of "status quo" when I had to quit Packet Radio activity. But the first thing I found when I searched for infos on the current state of IP in PR was that my IP's no longer do exist (which in fact is not really the problem for me, as I really was not active for a long time. So, no complaints on that from me, that's perfectly OK if there's some need for IPs. > Some time ago, we did a clean-up of the old 44.130 packet-radio block in communication with the regional coordinators. > > What's with the portal? - I think we need discuss that. It had been no relevance for us (since no one requested it), and I'm not sure, how it fits in a concept of the country coordinator system (unless a country coordinator defines a do-what-you-want-netblock for self-allocation - but how this may be integrated in a working routing concept??). I think the portal would not work that good with a concept like the formerly used one with using the IP for granular routing over PR network. But I seem to remember discussions that the "routing feature" would not be needed any more and the whole german IP PR network should be seen as one big block (which I do not really support from my standpoint as sysadmin). > Region ofr.de (44.130.62.0/24) was resigned 2013-07-31. Regional Coordinator was DL1NAT. > The zone file of that region expired with serial 2004041601. Nine years after the last update. forward- and reverse- entries were inconsistent: the reverse file had the serial number 2002062201 (I assume 2 years before). > > I do not like to blame anyone, but it may be useful in that discussion. 9 (or 11) years after the last coordination of the subnet and 2.5 years after your regional coordinator stated that all records could be removed, you recognize that dg7nef, dg7nef-2 and dg7nef-gate ( 44.130.62.20, .18, .19) have been passed back. And that lead to my problem with portal.ampr.org as I still had my own local acting DNS serving as "Master" for the zone on requests from my network, so I could at least keep the IP adresses I did contact in a state that did work for me. Yes, split DNS and multiple masters are an ugly thing. But it did work locally then. > This emphasizes both, the difficulties we'll get, even years after a clean-up, and on the other site the need to have a clean-up (the /24 had 57 entries (22%) and we finally got one complain (Wolfgang had 3 addresses -> 5 %). For most cleaned subnets we got 0 responses at all). Well, in fact no complains from me so far, just a bit confusion on my side. ;) > And imho, it also shows the country- / regional-wide coordination concept makes sense. Currently, we've 35866 IN A records in ampr.org. Imagine we'll have 10 requests a day on the list of the pool of every user, we all will have to read the next 10 years about every individual issue.

1 0

Dumb question - 44.130 IP address?
by Dg7nef 07 Feb '16

07 Feb '16

One kind question, first of all, after a forced break due to changing my home address and various other reasons not to be discussed here I had to learn my IP adresses assigned to me long ago and that I used for a long time ago are no longer existing. OK, maybe I can understand the reason for that. Now I'm searching for that "portal" to register myself for getting a new IP assignment for being able to start playing with Amateur Radio Packet applications and so on, so I search for the portal. Well, there is a portal. But that portal is not showing up at all when you try to contact it. Does that mean you have to have an IP to register for an AmPR IP, but no wait - I just want to register for it? Can you please enlighten me what is going on here? I just don't understand it right now. Thanks, Wolfgang

3 2

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> What would you have me do? It's clear that the majority of the entries in > the DNS are bogus. We have NOTHING to reference except the portal data. > Doesn't it make sense to try to get that data in order? Yes, but as I mentioned many times before, there is no sane way of migrating the data that *is* still valid towards the portal. There is no clear way for the user to request their existing allocation to be loaded into the portal. Not automatically (e.g. by querying the DNS), not manually (by filling in a form with existing addresses). One can only ask for new allocations and place a comment that says in fact one wants to move an existing allocation. I cannot ask the users to do that, and I don't like to edit all those requests manually. I think the portal should facilitate migration of existing data at least until that process is completed. There should also be procedures to migrate large blocks of data, as our own network infrastructure has hundreds of hosts that I do not want to enter in a webform one by one! I have recovered all update mail messages sent to the portal after 1994-01-01 and have added a date stamp to all the lines in my own hosts file with the latest date of an addition of data for each callsign. The file is available at http://pe1chl.nl.eu.org/hosts/hosts.137 Today I have done another mailing and a local amateur radio newssite has placed it on their newspage. This time I requested all the users that want to *keep* their allocation to reply by mail. When I get a reply or make a new registration I update the stamp to the current date. Next month I will just delete all records with a date before 2010. That should get rid of all the records from "the old days" and only leave those that were added during our more recent experiments. Last time I did this (two years ago) I kept the records for those that I could not reach, but this time those will get deleted. (of course they can always request to get them back when they notice it) Rob

5 4

Re: [44net] DNS cleanup
by Steve L 07 Feb '16

07 Feb '16

Brian Kantor wrote: >That was going to be a subsequent phase of the project. At the moment, >there is no way to "mark" the data at all - it either exists or it >doesn't. What we were considering doing is importing the DNS entries >into the portal, then requiring that each be claimed by someone within >some period of time - perhaps a year or two. After that, unclaimed entries >would be deleted. Sounds logical, that seemed to work well with the gateways portal phase in. I really can't think of any other approach. So delete as much for sure dead wood as possible; import what remains to allow it to be claimed. And then finally purge all unclaimed > >The existing DNS entries have an ownership field, based on who entered >them into the DNS database. That was added a few years ago, so there >are a lot of entries with null ownership. Unfortunately, there are >older entries which are still valid but have null ownership because >they were added to the database before it had an ownership attribute. I was wondering about this. Thanks for explanation. >This brings up the question of who is to be the owner of a DNS entry. >Should it be the individual or group who asked for it to be added to >the DNS or should it be the coordinator who entered it? The former >would mean that hundreds of people would have to register with the >portal and take ownership of each of their entries. The latter would >mean that it would be up to the coordinators to keep track of who is >still active (or still alive!) and delete entries for people who are >no longer around. Neither is a satisfactory solution. > In my opinion the end user should be the owner. But it might be logical to have a group owner ship flag available too. So people like coordinators can enter and edit for other people who may be less in the know in terms of what they are doing. >The goal is to have a tidy DNS database, with only entries that are >valid as is possible. I am open to suggestions. >- Brian

1 0

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> My speicific issue here is that my local AMPR coordinator recently told me that unless all my IP addresses had a DNS entry, I risked loosing my allocations. I think this is a policy that *he* is setting himself (not a global AMPR policy) and > though I don't agree with his view, I obliged to give him ~1024 hostnames to fill things out. If other AMPR coordinators have similar approaches, then DNS entries mean everything to the IP allocation be it a subnet or a /32. > > --David > KI6ZHD This is not how I handle allocations... in the area I manage one can allocate individual addresses or subnets, and when they are subnets the address range of the subnet is reserved but not each address in the subnet needs to have a name attached. However, all traffic for addresses without associated name in .ampr.org is filtered at our internet gateway. So when you want to actually *use* an address outside the local radio network, it has to have a name. (this is the same policy as in the gateway at UCSD) Rob

1 0

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> Subject: > Re: [44net] DNS cleanup > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 02/07/2016 08:52 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Sun, Feb 07, 2016 at 08:37:23PM +0100, Rob Janssen wrote: >> >I wonder what the database structure is and if you could maybe just delete the >> >record from the database without affecting the children. > I can't; I don't really have access to the underlying database. > - Brian That is why I initally sent the request via the contact page on the portal. However, it was not processed. This makes me pessimistic about the maintenance resources at the portal, and reluctant to spend a lot of time filling it with information that apparently can never be modified. Rob

1 0

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> Rob, if you'll tell me which subnet that has "children" should be removed > and which of those "children" should be kept, I'll make a note of the > "children", delete them, delete the erroneous subnet, and add the > "children" back in. Annoying, but it should take only a few minutes, > less time and more productive than arguing about it on the mailing list. It is the 44.137.24.0/22 subnet as I mentioned before. But be careful: those children are IPIP gateways and have that subnet registered in their gateway system. I'm sure when you delete them through the UI, the subnet will be deleted from their gateway as well. That is not good. I wonder what the database structure is and if you could maybe just delete the record from the database without affecting the children. When there are all kinds of pointers back and forth between parent and child records, that would be something that needs to be fixed. It should be easy to add and delete subnet levels between existing ones, e.g. a new regional subnet between a country subnet and users. We are re-arranging things all the time as the network develops. Probably the subnets should just be stored neutrally, and the parent/child relationship should only be established at the time the records are retrieved for display. And deleting a subnet should not infer deleting everything that is in it, the contents should just be promoted to the next higher level. Rob

2 1

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> Were there multiple entries for 44.137.24.0/22 ? > I still have it in my allocation list. the whole subnet was in use for > the regional local access point I was co-sysop for. That access point is > not operational at the moment, but I would like to keep that allocation > for when it comes back in the future. It is precisely this flexibility that is missing in the portal. There is no way to insert or delete regional subnets when there already are user subnets registered below that level. And there is no way to resize a subnet or transfer ownership either. I would like to register all regional subnets for clarity of the allocation tree, and transfer them to the proper user when that is appropriate. This can be done in HamnetDB and there I have registered those subnets to make the structure of the network visible to anyone, but the portal cannot do that. This particular subnet has been planned to be used by the soon to be deployed access point at the Eindhoven UHF repeater site which will route it using BGP via radio link to PE1RDP. So I prefer to delete this entry for now, to clean the allocation list. Rob

2 1

NTP Server Test
by lleachii＠aol.com 05 Feb '16

05 Feb '16

All, I have an NTP Server online at kb3vwg-001.ampr.org. Let me know if it's reachable from your hosts. This is currently in testing (the domain may move perhaps to tick.ampr.org.). 73, KB3VWG

9 10

OpenWRT Security Notice
by lleachii＠aol.com 03 Feb '16

03 Feb '16

All, I've noticed that if someone performs a traceroute to a 44net address routed via an IPIP tunnel on OpenWRT versions 14 or 15 (tested) results in the router giving the Public, Commercial IP address of the device instead of a 44net IP on tunl0, or any assigned forwarded interface. Without intricate detail, this is by design of the Operating System, as the kernel re-packets an ICMP TTL Exceeded, and seems not to connect that new pack as RELATED to the Received Packet in which the TTL had Exceeded. This is fine when all local IPs are Private IPs, or should be forwarded via the Kernel's Gateway; but as they are not, and the only gateway the kernel knows is the physical WAN. The ICMP TTL Exceeded Packet is given the Kernel's source address (with Gateway), and sent hence - a leaked TTL Exceeded packet. Reason: the least computationally difficult method to protect our gateways from rogue packets is to not publicize/announce our Public WAN-facing IP address. In order to prevent this, a RAW Packet Filter rule for all packets received via tunl0 < 2 can be created, preventing processing of TTL exceeded packets for non-44net IPs: iptables -t raw -I PREROUTING -i tunl0 -m ttl --ttl-lt 2 -j DROP iptables -t raw -I PREROUTING -s 44.0.0.0/8 -d 44.xxx.xxx.xxx/xx -i tunl0 -m ttl --ttl-lt 2 -j ACCEPT Those using OpenWRT, please test and confirm issue and its fix. 73, -Lynwood KB3VWG

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net