- 44net - mailman.ardc.net

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

Re: [44net] OpenWRT Security Notice
by Rob Janssen 03 Feb '16

03 Feb '16

The main problem with spoofing of course is not that it "attacks" our systems, but that our systems are being hit by backscatter from others that are being attacked, or that we attack others when we are used as reflectors. So be careful to have the right filters so you don't send too much traffic "back" to senders with spoofed addresses. It is correct that you need to allow protocol 4 only on the external network card and NOT on the tunl0 interface. If you do, you allow tunnel-within-tunnel packets, and they could be malicious, but in any case they are incorrect. In the past we have sometimes seen encap loops where some incorrectly configured system kept putting packets into another encap layer and forward them, and this kind of looping can easily be stopped by not allowing protocol 4 over protocol 4. There is an additonal filter that you can make, and which I explained earlier on the list. With Marius' ampr-ripd you can call an external script when the encap route table is changed, and in this script you can maintain an address list of valid IPIP peers, and use that in the firewall to accept IPIP packets only from peers that are announced by the RIP daemon. This will guard you against funny IPIP packets sent by random hackers. Of course it is not sufficient against the determined people, because they can spoof the IPIP packet to come from one of the gateways in the list, and it will be accepted anyway. Blocking "non-44 source addresses on tunnel interface" of course is only possible when you do not want to communicate between net-44 and the rest of internet. However, you can always use the regular firewalling techniques like blocking all incoming traffic with a source address that is local to your network (and of course all RFC1918 traffic like 192.168.0.0/16), and use connection tracking (-m state --state ESTABLISHED, RELATED) to block most incoming traffic that is not a reply to outgoing connections, and then carefully allow what you like to come in. This has to be done separately for the external interface and the tunnel interface, as the things you want to allow on those two interfaces are completely different. Lots of firewall howto's only show you how to put lots of rules in the INPUT or FORWARD table, which quickly make things inefficient and difficult to maintain. It is usually better to setup a number of tables with iptables -N tablename, each with the rules for a specific interface or even for a protocol, and put rules in the INPUT and FORWARD tables that match on some input/output interface and branch to the table for that case. iptables -N eth0ipip .... iptables -N eth0input iptables -A eth0input -p 4 -j eth0ipip ... iptables -N tunl0input iptables -A INPUT -i eth0 -j eth0input iptables -A INPUT -i tunl0 -j tunl0input ... Rob

1 0

Re: [44net] OpenWRT Security Notice
by Rob Janssen 02 Feb '16

02 Feb '16

> Subject: > [44net] OpenWRT Security Notice > From: > lleachii(a)aol.com > Date: > 02/02/2016 04:11 AM > > To: > 44net(a)hamradio.ucsd.edu > > > > the least computationally difficult method to protect our gateways from rogue packets is to not publicize/announce our Public WAN-facing IP address. Of course that does not work very well. All other gateway stations know your public IP and those who really want to know it can probably obtain it. The only way to protect your system is by using appropriate filters. And yes, these can be difficult to design, especially in the world of lousy internet service providers that do not bother filtering clients that spoof addresses.... Rob

2 1

Re: [44net] NTP Server Test
by lleachii＠aol.com 01 Feb '16

01 Feb '16

All, - Time - NTP UDP/123 - This is odd, I'm able to reach the server and 44.60.44.1 from AMPR and the Public Internet (what exactly are you trying to 'reach' at 44.60.44.1 to determine its status, as I've only announced NTP as being available there) - using 'ntpdate -q 44.60.44.1' or 'ntpdate -q kb3vwg-001.ampr.org' works for me anywhere on the Internet kb3vwg@kb3vwg:~$ ntpdate -q 44.60.44.1 server 44.60.44.1, stratum 2, offset 0.001173, delay 0.02589 30 Jan 18:00:19 ntpdate[1058]: adjust time server 44.60.44.1 offset 0.001173 sec - I have now permitted access from the Public Internet (previously, it was only available to 44 hosts), let me know - Lynwood KB3VWG

7 11

Re: [44net] Just received allocation... next steps?
by lleachii＠aol.com 01 Feb '16

01 Feb '16

Stephen and Ed, I have setup the tunneling routers on devices using OpenWRT and Ubuntu Linux. Since OpenWRT is actually designed to be a router OS, I highly suggest it. There are instructions for setting up a gateway using both OSes at http://wiki.ampr.org/ In order to route using Ubiquiti or VyOs, you must be able to compile and run ampr-ripd in order to provide RIP44 (which is not the name as RIPv2) on the tunnel interface. Since VyOs is a distribution of Linux, there may be instructions on the Internet on how to compile and/or execute ampr-ripd or rip44d. 73, Lynwood KB3VWG

2 2

Just received allocation... next steps?
by Stephen - K1LNX 01 Feb '16

01 Feb '16

Hi guys, I just received an allocation for 44.34.96.0/24 to begin experimenting with. I plan on doing mesh networking as well as offering services as time permits. I have two questions regarding connectivity to the network: - I understand most folks are doing IPIP tunneling, has anyone ever done this on a Ubiquiti Edgerouter Lite or VyOS? Anyone in or near Tennessee that can accomodate a tunnel for me? - BGP... thinking entirely out loud here, but are there any VPS providers anyone is aware of that will accept announcements from 44 net that I could handle with say BIRD or another BGP daemon under linux? This would be my ideal setup and I could tunnel my own connectivity, but not sure this is possible.. looking for ideas here. 73, and glad to be a part of AMPR, I love networking :) Stephen K1LNX

4 4

NTP - Reference
by lleachii＠aol.com 01 Feb '16

01 Feb '16

An inquiry was made into the Stratum of the NTP server: - Servers referenced are Stratum 1 or Stratum 2 Servers which reference a Stratum 0 Atomic Clock maintained by a University or Government Institution in Canada, the US or Mexico time-d.nist.gov nist1-pa.ustiming.org time.nist.gov time.nrc.ca time.chu.nrc.ca gnomon.cc.columbia.edu tick.gatech.edu cronos.cenam.mx

3 3

Re: [44net] Just received allocation... next steps?
by Steve L 01 Feb '16

01 Feb '16

Your next step is to build a gateway. "google: build amprnet gateway" Your are correct most folks are doing the IPIP (aka IPencap) method, as BGP is typically for /24's or bigger and isn't something attainable for most. The most common method is to do this on some sort of Linux computer.

1 0

Questions from Rob and Marius
by lleachii＠aol.com 01 Feb '16

01 Feb '16

- all 44/8 hosts should be able to traceroute and ping my hosts - the Internet and AMPR should be able to reach: 44.60.44.1 (Gateway, DNS and NTP), xxx.3 (DNS) and xxx.10 (HTTP) - I am running Verizon FiOS directly into the WAN interface of the OpenWRT device, I have explicitly opened IPENCAP on it, and tunl0 and rip44 are running on it - In order to provide MoCA (Coax) Ethernet device Internet, connect the carrier-provided router to the LAN interface, and provide IGMP Proxy for multicast - a Trunk port interface carries all VLANs (including AMPR LAN to my Virtual Server interface, HSMM devices, etc.) - 44/8 hosts should not be firewalled - I have a raw filtering of TTL > 2 on the WAN interface (preventing TTL Expiry DDoS Attacks); but AMPR hosts with a source of 44/8 can traceroute on AMPRNet to 44.60.44.0/24 and see 44.60.44.1 and hosts - Lynwood KB3VWG

1 0

Re: [44net] NTP Server Test
by Rob Janssen 31 Jan '16

31 Jan '16

> - This is odd, I'm able to reach the server and 44.60.44.1 from AMPR and the Public Internet > (what exactly are you trying to 'reach' at 44.60.44.1 to determine its status, as I've only announced NTP as being available there) > > - using 'ntpdate -q 44.60.44.1' or 'ntpdate -q kb3vwg-001.ampr.org' works for me anywhere on the Internet Maybe you are suffering the problem with some types of cable router that I noticed when trying to reach another US amprnet station. Those routers claim to support a DMZ mode and you set the IPIP tunnel server as the DMZ host, but in reality they do not forward new incoming IPIP packets to the DMZ host, they only forward "replies" to outgoing IPIP tunnel packets just like they do for normal NAT traffic. So, you configure your IPIP tunnel host, you test connectivity with other systems by pinging or telnet or whatever, and all appears to be fine. However, when anyone else attempts to connect to you from the outside, your system is just unreachable. When you do a ping to one of them and they try to reach you, it works OK. But when there is no traffic for a few minutes, the gate closes again and you are unreachable. The DMZ feature probably only works for TCP and UDP. For IPIP, you are just relying on the standard NAT feature which of course is causing the problem described above. Rob

1 0

Re: [44net] NTP Server Test
by Rob Janssen 30 Jan '16

30 Jan '16

> Subject: > [44net] NTP Server Test > From: > lleachii(a)aol.com > Date: > 01/30/2016 09:13 AM > > To: > 44net(a)hamradio.ucsd.edu > > > 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 > Like the others, I cannot reach your server. However, when people want to have an NTP server from AMPRnet, we are running one on our gateway in Amsterdam at 44.137.0.1 It is referenced off 8 stratum-1 GPS-locked servers that are part of our co-channel diversity FM repeater network. remote refid st t when poll reach delay offset jitter ============================================================================== *44.137.8.140 .PPS. 1 u 414 1024 377 4.918 -0.052 0.079 -44.137.41.97 .PPS. 1 u 689 1024 377 13.387 -1.770 0.104 +44.137.72.10 44.137.72.16 2 u 490 1024 377 8.022 0.037 0.045 -44.137.72.16 .PPS. 1 u 842 1024 377 7.952 0.036 0.077 -44.137.72.130 .PPS. 1 u 123 1024 377 8.604 -0.122 0.036 +44.137.72.131 .PPS. 1 u 489 1024 377 8.756 -0.135 0.055 -44.137.73.3 .PPS. 1 u 993 1024 377 13.443 0.128 0.022 -44.137.73.4 .PPS. 1 u 674 1024 377 13.358 0.158 0.064 -44.137.73.50 .PPS. 1 u 158 1024 377 18.075 0.249 0.173 Only (S)NTP. So no Time/TCP, Time/UDP or other time protocols. Rob

2 1

Might be of interest
by Steve L 30 Jan '16

30 Jan '16

If anyone has some new ideas for 44net, then this cloud server offer (One time free) might be of interest. http://www.cloudatcost.com/

1 0

Nevada IP Assignments
by Harold (K7ILO) 22 Jan '16

22 Jan '16

Hello all. I am the ip coordinator for the State of Nevada and responsible for 44.125.0.0/16 I decided to take a look at amprhost file and found many entries that I did not issue and not sure if these were added before I volunteered to handle the region or people have taken upon themselves to create these entries. This includes one that I recently assigned to someone who is actively using his assignment I would like to know if these are in use so that the amprhost file can be update by me getting rid of them if possible. Thanks Harold K7ILO Nevada IP Coordinator 44.125.10.1 kj6ix.ampr.org kj6ix (Just assigned via portal) 44.125.10.1 kmev.ampr.org kmev 44.125.128.1 ke7kd.ampr.org ke7kd 44.125.128.2 kb7llk.ampr.org kb7llk 44.125.128.5 n7ktl.ampr.org n7ktl 44.125.128.6 n7msd.ampr.org n7msd 44.125.128.8 wa1wsx.ampr.org wa1wsx 44.125.128.9 n7rad.ampr.org n7rad 44.125.128.11 w7kju.ampr.org w7kju 44.125.128.13 nr7a.ampr.org nr7a 44.125.128.14 n6whz.ampr.org n6whz 44.125.128.15 kd4iee.ampr.org kd4iee 44.125.128.17 ki7sy.ampr.org ki7sy 44.125.128.18 nt7e.ampr.org nt7e 44.125.128.20 kj7ca.ampr.org kj7ca 44.125.128.128 prg3.router.ampr.org prg3.router 44.125.128.129 dx9600.router.ampr.org dx9600.router 44.125.128.131 hamgate.n8khn.ampr.org hamgate.n8khn 44.125.129.1 wa6ewv.ampr.org wa6ewv 44.125.129.2 kb7pjb.ampr.org kb7pjb 44.125.129.3 wa4ist.nv.ampr.org wa4ist.nv 44.125.129.4 wi7c.ampr.org wi7c 44.125.129.5 kd6ulm.ampr.org kd6ulm 44.125.129.6 kb7mty.ampr.org kb7mty 44.125.129.7 nx6w.ampr.org nx6w 44.125.129.8 kf7go.ampr.org kf7go 44.125.129.32 kb6imj.ampr.org kb6imj 44.125.129.34 kd6mve.ampr.org kd6mve 44.125.129.64 n7vxb.ampr.org n7vxb 44.125.129.103 n8khn.ampr.org n8khn 44.125.129.105 hamgate2.n8khn.ampr.org hamgate2.n8khn 44.125.130.2 n0zte.ampr.org n0zte 44.125.131.2 kb7qbs.ampr.org kb7qbs 44.125.131.3 n7xbm.ampr.org n7xbm 44.125.132.1 kb7eiu.ampr.org kb7eiu 44.125.132.2 n7vle.ampr.org n7vle 44.125.132.3 ke6icy.ampr.org ke6icy 44.125.132.5 nf7v.ampr.org nf7v 44.125.132.6 kb7pux.ampr.org kb7pux 44.125.132.7 w6old.ampr.org w6old 44.125.132.9 kb7pdf.ampr.org kb7pdf 44.125.132.12 ww7e.ampr.org ww7e 44.125.132.13 wb6w.ampr.org wb6w 44.125.132.34 n7npb.ampr.org n7npb 44.125.132.35 kb7no.ampr.org kb7no 44.125.132.36 kb7pde.ampr.org kb7pde 44.125.132.37 n7zfc.ampr.org n7zfc 44.125.132.38 wt8k.ampr.org wt8k 44.125.132.64 kc6rho.ampr.org kc6rho 44.125.132.67 kc7cex.ampr.org kc7cex 44.125.132.68 kc7cey.ampr.org kc7cey

16 37

*.ampr.net mappings
by Jim MacKenzie 21 Jan '16

21 Jan '16

Hi, I've got a subnet (44.135.130.0/23) and with the help of Brian in San Diego (thank you!), I got reverse DNS delegated to me (the subnet is routed via BGP). I got ve5eis.ca and mapped a couple of names in that domain to the IPs that are in service. Should I have a CNAME or some other alias in ampr.net also? Is this desirable practice or just what most people do? I'm pretty Linux- and Internet-savvy so so far I've just been doing my own thing. Thanks, Jim VE5EIS/VA5EIS/VE0EIS

3 3

Re: [44net] looking for Phil Karn KA9Q
by Assi Friedman 21 Jan '16

21 Jan '16

Karn (at) ka9q.net -----Original Message----- From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of R P Sent: Thursday, January 21, 2016 9:59 AM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] looking for Phil Karn KA9Q (Please trim inclusions from previous messages) _______________________________________________ Does anyone have a contact with Phil Karn (ka9q) ? The email in QRZ didn't get any answer by him Thanks for any assistance Ronen - 4Z4ZQ _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] AMPRNet DNS cleanup
by Rob Janssen 21 Jan '16

21 Jan '16

> Subject: > Re: [44net] AMPRNet DNS cleanup > From: > Pedja YT9TP <yt9tp(a)uzice.net> > Date: > 01/20/2016 09:42 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > > On 19.1.2016. 20:09, K7VE - John wrote: >> I think people are making this way more complex than necessary: >> >> Two conditions exist: >> >> 1 - A DNS entry is essentially dead, nobody will notice if it's deleted. >> (probably > 95%) >> 2 - A DNS entry is in use. If it disappears, the affected party will >> notice and it can be corrected. > > Agree. I would not prefer to use this method. There is no guarantee that an affected party will notice that an address that they use disappears from DNS. Note that the list of addresses serves both as a registration list and a way to load the DNS zone, and people can be actively using their address without ever using the (public) DNS entry for it. > >> In general, it's time to flush old entries. > > > I do not know how whole process works, but on other service I use inactive accounts (and thus IP and DNS records) are not deleted, just disabled. Please understand that there currently is no such thing as "accounts" under which DNS records are registered. The registrations are made by local coordinators (for which there is some information available) on behalf of users who request an allocation. Local coordinators have varying amounts of detail available about the users. There certainly is no list of e-mail addresses of all users available, where they could be contacted about their allocation. Sure it would be nice to move to a new system where more detail is available about every record, like the date of registration and last re-confirmation and a contact address for the user. However, that also has some associated problems (in many countries it is not straightforward to setup such a database, especially not one accessible over internet, while remaining within legal restrictions about storing personal data). It will not be practical to contact everyone and ask them to create some account to manage their allocation. When it is decided to move to such a system, something has to be done about the existing allocations, to the very minimum those addresses that are allocated now should be protected or at least flagged when the new system tries to re-allocate them to someone else. Only unallocated addresses or confirmed obsolete addresses should be re-allocated, and in fact even within the current manual system I almost never re-allocate an abandoned address to someone else. There is no need to do so because of the vast amounts of empty space we have. Rob

1 0

Re: [44net] Traceroute for IPIP ?
by Steve L 20 Jan '16

20 Jan '16

Ronen, Traceroute over IPencap should work. You may need to ensure the TTL is 64 for your encapsulated routes. Your tunnel packets might be inheriting the TTL from some other interface like an IPV6 one. root@ampr-gw:~# traceroute hambook.de.ampr.org traceroute to hambook.de.ampr.org (44.225.164.16), 30 hops max, 60 byte packets 1 db0fhn.as64626.de.ampr.org (44.130.60.100) 134.560 ms 141.343 ms 139.976 ms 2 hamnet.db0fhn.as64626.de.ampr.org (44.130.60.101) 141.220 ms 140.716 ms 140.461 ms 3 bb-db0fhn.db0gw-2.as64621.de.ampr.org (44.224.2.5) 151.931 ms 152.563 ms 152.748 ms 4 bb-hubwest.db0hsn.as64621.de.ampr.org (44.224.2.18) 158.393 ms 159.046 ms 158.744 ms 5 44.224.53.158 (44.224.53.158) 158.890 ms 178.360 ms 178.948 ms 6 koedsp-core.db0dsp.as64632.de.ampr.org (44.224.24.59) 203.592 ms 162.314 ms 164.085 ms 7 link-kpg-koe.db0ko.as64634.de.ampr.org (44.224.28.157) 174.770 ms 206.083 ms 207.899 ms 8 eth3-core.db0kpg.as64634.de.ampr.org (44.224.28.158) 206.909 ms 206.145 ms 205.800 ms 9 bb-db0kpg.db0ko.as64634.de.ampr.org (44.224.28.161) 205.897 ms 206.280 ms 207.114 ms 10 bb-db0kpg.db0ko.as64634.de.ampr.org (44.224.28.161) 3189.252 ms !H 3191.819 ms !H 3192.353 ms !H root@ampr-gw:~# C:\Users\user>tracert hambook.de.ampr.org Tracing route to hambook.de.ampr.org [44.225.164.16] over a maximum of 30 hops: 1 2 ms 1 ms 1 ms 44.92.21.129 2 137 ms 134 ms 135 ms db0fhn.as64626.de.ampr.org [44.130.60.100] 3 135 ms 132 ms 135 ms hamnet.db0fhn.as64626.de.ampr.org [44.130.60.101] 4 147 ms 147 ms 146 ms bb-db0fhn.db0gw-2.as64621.de.ampr.org [44.224.2.5] 5 153 ms 153 ms 153 ms bb-hubwest.db0hsn.as64621.de.ampr.org [44.224.2.18] 6 175 ms 157 ms 155 ms 44.224.53.158 7 160 ms 181 ms 158 ms koedsp-core.db0dsp.as64632.de.ampr.org [44.224.24.59] 8 176 ms 159 ms 161 ms link-kpg-koe.db0ko.as64634.de.ampr.org [44.224.28.157] 9 164 ms 161 ms 162 ms eth3-core.db0kpg.as64634.de.ampr.org [44.224.28.158] 10 170 ms 168 ms 197 ms bb-db0kpg.db0ko.as64634.de.ampr.org [44.224.28.161] 11 bb-db0kpg.db0ko.as64634.de.ampr.org [44.224.28.161] reports: Destination host unreachable. Trace complete. C:\Users\user>

2 1

Re: [44net] Traceroute for IPIP ?
by Assi Friedman 20 Jan '16

20 Jan '16

Ronen: I do not know of a tool that can truly traceroute a tunnel encapsulated frame. When I do testing, I check the route to the to the tunnel endpoint (non 44 address) and when it uses the default router to uscd, I check to see that it gets to mirroshades. Assi

2 1

Re: [44net] AMPRNet DNS cleanup
by Steve L 20 Jan '16

20 Jan '16

I don't know how practical it would be to to try and monitor the dns server queries to help id which entries are used vs unused. But it might be something to consider sooner than later as you'd want to let this run for quite some time to build some statistics. Just throwing the idea out there. >As for figuring out what is unused or not, there isn't any good way of >determining that.

4 3

Re: [44net] DNS
by Steve L 20 Jan '16

20 Jan '16

Neil, Does your script count the BGP'd address space as gateways, or will it kick back GATENOTFOUND for those too? You can get those here: http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44\."

2 1

Re: [44net] Verifying the identities of IP coordinators
by Rob Janssen 20 Jan '16

20 Jan '16

> Re: [44net] Verifying the identities of IP coordinators > From: > Don Fanning <don(a)00100100.net> > Date: > 01/13/2016 05:56 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, Jan 13, 2016 at 6:25 AM, Brian Kantor<Brian(a)ucsd.edu> wrote: > > I just thought of another possibility. We could ask that the regional > coordinators do an audit of their IP spaces in conjunction with the > above suggestions as they're likely to have closer relationships with > the end user or be more familiar with the record keeping of their > countries amateur radio licensing. Then we can check off that IP > space as "claimed" or "reclaim" it back into the pool. > I have made an effort to do that. I tried to contact all hams that are in the current allocation for the Netherlands, and asked them if they want to maintain their allocation. As a result, some have replied they no longer want to use it, and I have deleted those allocations. The ones that confirmed their allocation I put on a list with a datestamp. But the vast majority of the hams could not be reached. I have no uptodate contact info and even the old contact info is difficult to access (it is a folder in my mail program that stores all original requests starting in 2002, I don't even have those for the addresses requested before 2002). I also regularly delete the allocations for hams that no longer appear in the official callsign listing for the Netherlands. (I have done this every year, but recently I have done it weekly because starting from this year there is a fee for keeping an amateur callsign and lots of inactive hams have removed their registration as a result) I only keep the registrations in a hostsfile and use a script to send the updates to the mail robot. As an afterthought, I should have kept a file with more info like date of registration and contact address for each entry, but it would require a filtering system so this information does not end up in the publicly visible file. I like to keep everything in a textfile as opposed to some database with a web form frontend, because it allows me to browse through the file to see where a new allocation is to be put, something lacking from many address allocation systems including the amprnet portal. Rob

6 5

Re: [44net] DNS Clearout
by Rob Janssen 19 Jan '16

19 Jan '16

> Subject: > Re: [44net] DNS Clearout > From: > "John Wiseman" <john.wiseman(a)cantab.net> > Date: > 01/19/2016 04:17 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Thanks, Brian, > > I've just checked on the portal, and it seems I'm too late - they have > already been allocated to someone else. (44.131.4.18-21). So they won't get > removed by the clearout, but I'll need to replace them anyway. But it > highlights a problem with your suggested approach - It won't pick up unused > names which are in address ranges that have been reallocated. And glancing > though the uk dns records I suspect that applies to a lot of entries. > > But I can't think of a better solution, and I guess an incomplete clearout > is better than none! > > 73, > John Note that your entries are registered in the ampr.org DNS, but the portal apparently does not respect that. This is one of the problems with the way the DNS part of the portal works: there is no way to see what is already in use before allocating something new. But nothing has been done about that yet, and the issue is open for many years. Rob

1 0

Re: [44net] DNS (was: Nevada IP Assignments)
by Rob Janssen 19 Jan '16

19 Jan '16

> Subject: > Re: [44net] DNS (was: Nevada IP Assignments) > From: > Neil Johnson <neil.johnson(a)erudicon.com> > Date: > 01/19/2016 02:10 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > The initial script is done: > > " 44.225.65.22 ","GATENOTFOUND" > " 44.50.192.22 "," 108.160.233.78" > " 44.225.66.220 ","GATENOTFOUND" > " 44.225.65.220 ","GATENOTFOUND" > " 44.225.64.220 ","GATENOTFOUND" > " 44.225.66.221 ","GATENOTFOUND" > " 44.225.64.221 ","GATENOTFOUND" > " 44.225.66.222 ","GATENOTFOUND" > " 44.225.64.222 ","GATENOTFOUND" > " 44.225.66.23 ","GATENOTFOUND" > " 44.225.65.23 ","GATENOTFOUND" > " 44.50.192.23 "," 108.160.233.78" > " 44.225.66.24 ","GATENOTFOUND" > > and so on > > Of the 36059 address records 30176 don't have a gateway associated with > them. Seems kind of a large amount. I'll do some more sanity checking. This is going to fail big time!! That 44.225 network is probably the most active net-44 network in the world, but it is not gatewayed to internet. People will not like it when you try to delete that!! Also, again the proposal is made to transfer things to the portal. I do not consider the portal ready for production use for this, and I question if it ever will be. Changes to functionality and replies to questions are so far between that I don't think the maintainer has enough resources to keep this project moving. Note I don't want to blame him for this in any way, but I don't think we should become more dependent on it than we are. Rob

2 1

AMPRNet DNS cleanup
by Don Fanning 19 Jan '16

19 Jan '16

Last year I tried to attack the task of cleaning up the DNS. Brian at one point did an AND against the gateway subnets with the DNS and it produced ~19k A records - hundreds of times what is valid or even being used. So as a curiosity exercise, I wrote some script to import the DNS into MySQL. The result was 16653 unique callsigns in the DNS and 2211 aliased/bad call signs as of June 2015. I then imported the FCC amateur database and compared it to US (A,K,N,W) callsigns - that produced 3742 unique US callsigns matching the DNS. Out of those, 1373 callsigns matched an expired, canceled or terminated license. This doesn't take into account all the vanity call signs for the 1x2/2x2/2x1/1x3 callsigns which may be attributed to another operator. While we can get good grips on the US callsigns, as soon as it crosses an international border, it goes to pot as every country has their own licensing structure. Many do not have online databases. So that's what we're faced with. Ideas welcome as to how we can validate the DNS tables.

2 2

Re: [44net] (no subject)
by Steve L 19 Jan '16

19 Jan '16

Neil, A couple years ago I created a script to do this. http://www.qsl.net/kb9mwr/wapr/tcpip/checkampr.txt Anyone is welcome to use it/modify whatever.

1 0

Updating Records
by Peter Mallett 19 Jan '16

19 Jan '16

Hi All, I have been looking at my allocations and would like to weed out the dead wood. What is the easiest way to do this ? Regards ..... Peter ZL2BAU

2 2

Re: [44net] Proposal for Cleaning up ampr.org DNS file
by William Lewis 18 Jan '16

18 Jan '16

That wont work, as the DNS function of the portal is not live yet. At 12:13 PM 1/18/2016, you wrote: >I could then attempt to send an e-mail message asking the call sign owner >to update their DNS entries via the portal. ---------- Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

1 0

Proposal for Cleaning up ampr.org DNS file
by Neil Johnson 18 Jan '16

18 Jan '16

All, I've hacked together a script that goes through the ampr.org DNS zone file and pulls out callsigns and related A, CNAME, and MX records. Example: CALL: N0SFH dhcp-20.n0sfh IN A 44.50.192.20 dhcp-21.n0sfh IN A 44.50.192.21 dhcp-22.n0sfh IN A 44.50.192.22 dhcp-23.n0sfh IN A 44.50.192.23 dhcp-24.n0sfh IN A 44.50.192.24 dhcp-25.n0sfh IN A 44.50.192.25 dhcp-26.n0sfh IN A 44.50.192.26 dhcp-27.n0sfh IN A 44.50.192.27 dhcp-28.n0sfh IN A 44.50.192.28 dhcp-29.n0sfh IN A 44.50.192.29 dhcp-30.n0sfh IN A 44.50.192.30 gw.n0sfh IN A 44.50.192.1 n0sfh-1 IN A 44.50.192.5 Line count= 13 I could take the call signs and run them against QRZ.com (I have a XML subscription) and/or the Radio Amateur Call Book Data (The "Flying Horse" CD - I'm willing to buy the data). I could use that data to 1) determine if the call sign was still active 2) try to find an e-mail address associated with the call sign. I could then attempt to send an e-mail message asking the call sign owner to update their DNS entries via the portal. In the e-mail we could give the call sign owner 60-90 days to update their DNS entries or they would be deleted. I came up with 17899 potential call signs in the zone file. I would need: 1. Permission from the ARDC to send e-mails on its behalf. 2. A way to whittle down the file further, if possible. 3. Volunteers to translate the notification e-mail into multiple languages. 4. Someone who has an ISP or mail host willing to allow the sending of 10's of thousands of e-mails without it getting flagged as SPAM (I would want to try and contact each call sign owner with a valid e-mail at least three times before the deadline). 5. Access to the portal's DNS database to determine if someone registered their entries. Thoughts? -Neil -- Neil Johnson

2 1

Why Subject lines have squat to do with message content.
by Jerry Kutche 18 Jan '16

18 Jan '16

Guys I am not a moderator, owner or anything else... just a quickly becoming disinterested Coordinator in this group. 1 Reason the thread topics are out of whack. Take this one.. below titled (Verifying the Identities of IP Coordinators,)yet contains only discussions about DNS. It is no longer about identities, of IP Coordinator yet it goes on and on and on about DNS under a misleading Subject line. Then there is the THREAD more correctly titled Dynamic Addresses. How is anyone following both of these and making sense out of them. ? I really do not care what we talk about.. But I personally like being able to pick and choose what I read about.. without having to fish every message. When we are talking about orangutans, under a title of Planets from Space.. Sure is miss leading.. Just todays gripe.. Carry on I am sure nothing will change. Also remember to... > (Please trim inclusions from previous messages) 73 Jerry N9LYA

1 0

Re: [44net] Verifying the identities of IP coordinators
by Assi Friedman 18 Jan '16

18 Jan '16

My guess would be that it's not a DNS server load issue but more of an administrative / architecture issue. If stale/abandoned entries are not purged, it makes the task of design and coordination a tad more difficult since new hosts/networks have to work around the already assigned ones. Assi kk7kx -----Original Message----- From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of R P Sent: Sunday, January 17, 2016 10:18 PM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Verifying the identities of IP coordinators (Please trim inclusions from previous messages) _______________________________________________ I ask again What is so important to clean the DNS from all the amount of unused hosts ? is it a matter of load on the DNS that result in a slow response ? or any other effect im not aware of ? The only thing i can think of is making zone transfer of big file twice a day but in this days transferring even 10 MegaByte file each day consider nothing Maybe Brian can answer this ? However to answer your question Authorized users can change the DNS data there is a format needed to be sent in the email that the robot know to inter-prate something such as : <host name > <add or delete> <what kind of record should it be (MX A etc)> <Ip adress> you send each host as a single line and you can more then one line Since the robot have a format checking mechanism you dont have to be a DNS expert in order to add or delete hosts specially if you want only to add host name and not complex things such as MX records or CNAME Regards Ronen - 4z4zq http://www.ronen.org ---------------------------------------------------------------------------- ------------------------------------------ 1. What information must a coordinator send to the ampr.org DNS to create/modify a listing? 2. Is there a standard entry format for the information a coordinator sends in, or is it parsed by hand? 4. Is it possible for me to reformat the existing files, knowing little about DNS? hth. 73, Bill KW4OC _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] dynamic addresses
by Rob Janssen 18 Jan '16

18 Jan '16

> Subject: > Re: [44net] Verifying the identities of IP coordinators > From: > K7VE - John <k7ve(a)k7ve.org> > Date: > 01/15/2016 10:05 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > I beg to differ. I agree with the NAT position, but there are definitely > cases for the use of dynamically allocated addresses. > > Here is one: D-STAR data protocol encapsulates Ethernet frames inside of > D-STAR frames, in turn those can contain IP frames. If I am in a mobile, > driving down a highway and using a series of access points, then receiving > a new 44.x.x.x address via DHCP from those access points keeps me connected > for services I am using. I would implement that using a dynamic routing of a fixed address rather than assignment of a dynamic address (and having to cope with a changing address). Rob

3 3

Re: [44net] RIP Question
by Steve L 16 Jan '16

16 Jan '16

Yes the RIP broadcasts come over protocol 4 from amprgw.sysnet.ucsd.edu Here is a network dump of some directed to my gateway: Network dump of Incoming RIP ############################# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 04:00:00.218059 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504 04:00:00.218108 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 57644 unreachable, length 540 04:00:00.218121 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 04:00:00.218130 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504 04:00:00.218141 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 57644 unreachable, length 540 04:00:00.218262 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 04:00:00.218550 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504 04:00:00.218573 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 57644 unreachable, length 540 04:00:00.218582 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: >Hi there >Did I understand correct that the RIP system we use is RIP over the Tunneling ? >Or in other words we need at first to have Tunnel to AMPR Router > >and only then the RIP data can pass through ? > >Any Info Welcome >Thanks Forward >Ronen - 4Z4ZQ >http://www.ronen.org

1 0

Re: [44net] Verifying the identities of IP coordinators
by Rob Janssen 16 Jan '16

16 Jan '16

> Subject: > Re: [44net] Verifying the identities of IP coordinators > From: > Bill Vodall <wa7nwp(a)gmail.com> > Date: > 01/14/2016 10:19 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > >> >When someone applies for an address... > Transient users don't need static or even real IP addresses. We could > re-invent DHCP... I am firmly against that. Contrary to the Internet as it is now, we are not a collection of transient users that only use a couple of centralized services, but we are all peers that should be able to both use and offer services and make connections in all directions. That is what makes us different from ordinary internet users, and using dynamic or even translated addresses kills all that and makes the whole AMPRnet superfluous. Rob

6 7

Need a New Thread titles.. WAS:RE: Verifying the identities of IP coordinators
by Jerry Kutche 15 Jan '16

15 Jan '16

Can we start a new thread title for all the items that are coming up... I marked this thread on my system as DOA and I see I am confused going by the thread titles... No Offense.. Just asking for some semblance of order.. Many Thanks 73 Jerry N9LYA -----Original Message----- From: 44Net [mailto:44net-bounces+n9lya=nwcable.net@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Friday, January 15, 2016 5:41 PM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Verifying the identities of IP coordinators (Please trim inclusions from previous messages) _______________________________________________ Now really... You actually want a dynamic DNS? We can not manage the regular DNS entries in the portal yet. But what is stopping you to send a DNS robot update mail on IP change? Marius, YO2LOJ _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Verifying the identities of IP coordinators
by Steve L 15 Jan '16

15 Jan '16

While using LOTW certificates is quite ingenious, I think the whole process to extract the keys will be a big hangup for the less technical folks. It really needs to be as easy as possible, like how you can use you facebook login (oauth token) to log into other sites. Basically it your ARRL login should work like that, so you can login to the ampr portal, qrz, etc.

24 38

Re: [44net] Verifying the identities of IP coordinators
by Rob Janssen 15 Jan '16

15 Jan '16

> Subject: > Re: [44net] Verifying the identities of IP coordinators > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 01/14/2016 08:10 AM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > The reason is simple why not to allow automatic requests: > The coordinators may have a certain IP allocation scheme in there minds. Maybe regional, maybe some other criteria. > That means that not every request out of the blue fits that scheme. > So an IP range may be unallocated, but it does not fit the allocation scheme. > An coordinator would change the requested one allocate the right one, which would not happen in an automated system. > > e.g. in YO, I allocate IP ranges based on regions, so that the first number in the block fits the requestors region number (the same as in the callsign). > I had requests like "please allocate 44.182.35.xx to me", the user being in region 8. > It resulted in allocating the first unused 44.182.8x.xx /24 subnet to him, and not the original requested one. > This would not have been possible in an automated system. > > Marius, YO2LOJ It is the same here, Marius. When someone applies for an address I need to know where they are located, if applicable to which access point they want to link, if they want a single address or a subnet, what size of subnet they need, a motivation when that is larger than the default /28, etc. Once I have that information I look at the already assigned addresses, and assign them one that fits. (there is a different area in each subnet where single addresses and subnets are allocated) Sure it could all be catered for in input forms, but the amprnet portal currently doesn't, and upgrades to its functionality appear to occur only very infrequently. I don't think it is worthwile to spec out everything and have someone spend time on implementing it, only to find ourselves locked into that system which may not be optimal once some decision is made to handle things differently. Furthermore, many applicants really need some guidance and make requests that are incomplete or not justified (e.g. request allocation of a /22 network for a single station). The semi-automatic mechanism appears to work well and makes it easy to ask for more information. Rob

3 2

Portal volunteers [was: Verifying the identities of IP coordinators]
by Tom Hayward 14 Jan '16

14 Jan '16

On Wed, Jan 13, 2016 at 6:25 AM, Brian Kantor <Brian(a)ucsd.edu> wrote: > The existing portal works fairly > well for a first cut at making one. Undoubtedly we'll refine it but that > depends on volunteers to do the design and programming (PHP, Javascript), > and so far several calls for volunteers have fallen on deaf ears. This isn't completely true. You can grep the archives for "I'll be happy to help with the programming" to find at least one offer. Alternatively, my opinion is that Chris would get more help if the project were open sourced. Now instead of recruiting volunteers, he will have contributors. This allows for a lot more flexibility. For example, a ham in one part of the world is stuck at home on a rainy weekend is setting up an AMPR system and encounters a bug. Meanwhile, Chris is enjoying a weekend away from the computer in a part of the world with more favorable weather. With an open source project, the first ham can dig around for the bug and send Chris a patch without any pre-approval. When Chris returns, he can vet the patch before applying it to the SVN [or whatever technology] repo. This significantly lowers the bar for volunteers and administration. If the portal is open sourced, expect a patch from me within the first week. Tom KD7LXL

4 3

Re: [44net] Verifying the identities of IP coordinators
by Steve L 13 Jan '16

13 Jan '16

Re-validating on a regular/annual basis should be for everyone not just coordinators and gateway ops. It keeps contact information current and could also confirm if they wish to keep their netblock allocation. Think of it as a subtle reminder to maybe get back on board with something they may have put off. : And allows address space to be returned to the pool, and any associated DNS entries in that address space to be removed as well as any associated gateways. I think I might have been the first to ask of the portal project was going to be open source. My thoughts at the time was it seemed like a number of regional BGP connected chucks where breaking off and I figured they may also want to implement a user end kind of portal. If there are some security by obscurity concerns in its design, then we just need a github type of thing hosted on 44net so that non hams are restricted from viewing and submitting to the project. And even if that doesn't happen for the portal, I think a ham only github type of thing might be a good idea. A number of ham projects get picked up and spun by commercial folks. The earliest example is probably Phil Karn's NOS code. And now a present day example would be about non licensed folks getting access to modified atheros drivers or the CS7000 firmware, etc.

3 2

Re: [44net] 44Net Digest, Vol 5, Issue 12
by f5pbg＠free.fr 12 Jan '16

12 Jan '16

Le 12/01/2016 20:00, 44net-request(a)hamradio.ucsd.edu a écrit : > The original suggestion was that there was a way to bypass simple > address assignment by automating the process. No possible i think, because we must verify the real identity of the persons requesting IPand if this verification is automatic it will be very easy to pirat the system... For example if I have a doubt about the person, I phone him to check the identity. An automatic system can do this. ;o) Best regards, Ludovic - F5PBG.

1 0

Re: [44net] Verifying the identities of IP coordinators
by ve1drg 12 Jan '16

12 Jan '16

Third ed it.. --Ted Gervais 1464 luxury aveWindsor OntarioN8p0a9 -------- Original message -------- From: ve1jot <ve1jot(a)eastlink.ca> Date: 2016-01-12 12:00 AM (GMT-05:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Verifying the identities of IP coordinators (Please trim inclusions from previous messages) _______________________________________________ seconded! On 16-01-10 01:40 PM, Paul Lewis wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Thank you Brian for those kind words > and also for the work you do and your team in the background support > for the past 25+ years > paul g4apl > In message <20160110145927.GA32116(a)UCSD.Edu>, Brian Kantor > <Brian(a)UCSD.Edu> writes >> (Please trim inclusions from previous messages) >> _______________________________________________ >> There seems to be some confusion here. The discussion was never about >> verifying the identities of coordinators. >> >> The original suggestion was that there was a way to bypass simple >> address assignment by automating the process. >> >> I explained at the time that the coordinators perform a valuable service >> that can't be automated in any practical way. >> >> In fact, many coordinators do far more than assign addresses - they >> consult with users and provide assistance in getting their stations on >> the net. Many of the people currently using AMPRNet would not have been >> able to do so without the help of their local coordinator. >> >> I think the coordinators, many of whom have been performing that service >> for years, deserve a round of thanks from the community. They certainly >> have my appreciation for their hard work and dedication. >> - Brian >> >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net > _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

mail relay for *.ampr.org adress or IP ?
by R P 10 Jan '16

10 Jan '16

Id there any SMTP server (mail relay) that can pickup any from *.ampr.org email adrss or any 44.** IP adtress and can send it to the outside world ? If yes what its ip adress ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org

1 0

Verifying the identities of IP coordinators
by Bill Horne 10 Jan '16

10 Jan '16

> The question of automating address assignment has been looked into; > about the only way it could be done would be if we had a secure method > of making sure that the applicant is a bona fide ham radio operator. > At the moment, the only known automated way of doing this is to use > Logbook of the World certificates, which greatly restricts the number > of people who could prove their eligibility and has its own set of > problems. Brian, The problem of knowing who we're corresponding with is as old as the written word. I feel that PKI provides the best solution available. I'm not familiar with LOTW, but I know the PKI process well, and I'm confident that it provides a simpler and more robust solution. There are, of course, many different ways to implement a secure process: for the moment, I'll ask that we leave aside the implementation details and talk about the idea. We could use a secure web site to give access to coordinators, or restrict ssh access to key holders, or accept only signed emails: the process is essentially the same for all. It boils down to authentication: we can issue private keys to every coordinator who seeks to use an automated process to issue IP addresses. * PGP/GPG users have access to "Keysigning parties" where other keyholders will verify their meatspace identities by inspecting their drivers license, passport, etc. * SSH and SSL users could, in theory, employ the keysigning process to verify their identity, even though it's not customary. They could also provide letters from attorneys or ministers or other public figures, attesting to their identities, in the same manner that Thawte used to verify X.509 certificates. Long story short, LOTW isn't the only way to verify an identity. There are other methods, already implemented and available, which can be used instead. Bill, KW4OC

2 1

Re: [44net] Coord delay
by f5pbg＠free.fr 09 Jan '16

09 Jan '16

Le 08/01/2016 20:00, 44net-request(a)hamradio.ucsd.edu a écrit : > Delays of months and years by coordinators continues to be heard Some coordinators works very slow... For me i validate IP ask in few hours and sometimes few days (week-end...). I create a subnet for some friends in order to have an IP more faster for them because the coord does not validate the IP. It will be nice to have an alert to the big admin of ampr.org when a IP ask is not validate after two weeks (for example). Then, itwill be nice to change the local coordif he does not do his job in ham'spirits conditions... ;o) Best regards, Ludovic - Coord 44.151

1 0

locked
by Dale Yanz 08 Jan '16

08 Jan '16

Hi All Question is that am I being locked out ? 44.125.10.0/24 0 0.0.0.0 E 0 0 Locked Dale KJ6IX

8 13

Re: [44net] Is someone read the contact us in the portal ?
by Rob Janssen 08 Jan '16

08 Jan '16

> Subject: > Re: [44net] Is someone read the contact us in the portal ? > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 01/08/2016 06:53 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > The question of automating address assignment has been looked into; > about the only way it could be done would be if we had a secure method > of making sure that the applicant is a bona fide ham radio operator. > At the moment, the only known automated way of doing this is to use > Logbook of the World certificates, which greatly restricts the number of > people who could prove their eligibility and has its own set of problems. Also the experience with automation projects is that they often get stranded partly completed, for all kinds of reasons. The question often is what is better: a working manual system or a partially finished automated system that does not offer the flexibility that a manual system has. (e.g. w.r.t. correcting mistakes, accommodating special situations, handling a large batch of updates, etc) Rob

1 0

Re: [44net] How to update the AMPR.ORG DNS records ?
by Steve L 08 Jan '16

08 Jan '16

Kind if wondering the status of this myself. Perhaps the easiest would be to amend the present email robot to ask for a username and password field (kind of how the old gateways robot worked) so the end user can edit their own entries? >Hi there >How do I update the AMPR.ORG DNS records ? >The Portal write that the web page that there is a test and records will >not apear in the real AMPR.ORG zone file >and the email system i used to sent updates to reply with error >Please advice >Thanks Forward >Ronen - 4Z4ZQ >http://www.ronen.org

7 6

IPR Net44
by Dale Yanz 06 Jan '16

06 Jan '16

Hi When I perform a IPR this is what I show for me 44.125.10.0/29 0 0.0.0.0 E 0 0 Locked I don't understand ? what it is showing ? My IP is 44.125.10.1 Network 44.125.10.0/24 Also how do I make sure or determine the correct IPNETMASK ? Is this the same as my subnet mask when I perform a ipconfig ? Then what would be my correct IPNetmask ? On my BPQ32 config file do I still MAP to a IP ADDRESS ? My NAT 44.125.10.2 (Within my APRNET) 192.168.0.198 ( My ip address of my BPQ32 computer) ;====================================================================== ;AMPR Gateway ;====================================================================== IPGATEWAY Adapter \Device\NPF_{0A50287E-EBE5-456D-BDDF-84BC5F7DB088} 44ENCAP 192.168.1.10 # Enable AMPRNET Tunnels and RIP44. Use 192.168.1.10 as Tunnel IPAddr 44.125.10.1 # IP address of the BPQ32 switch on your LAN IPNetmask 255.255.255.248 # Netmask of your AMPRNet allocation IPPorts 1,9 # BPQ Ports to be used for links to IP systems. List of ports, separated by commas NAT 44.125.10.2 192.168.0.198 **** Dale Yanz KJ6IX Nevada State Emergency Communication Volunteer Douglas County, Nv. Packet Coordinator KJ6IX(a)ARRL.NET

8 9

44net Lock
by Dale Yanz 06 Jan '16

06 Jan '16

Ok let see. I'm going to say correct me if I'm wrong is that I need to upgrade my Router to a more current model. I'm using a D-Link DIR-615 that I picked up at a thrift store for $7.00 U.S.. Don't laugh !!! Ok what would be a choice for a router that would fit the bill !! Still showing up 44.125.10.0/24 0 0.0.0.0 E 0 0 Locked Dale Yanz KJ6IX Nevada State Emergency Communication Volunteer Douglas County, Nv. Packet Coordinator KJ6IX(a)ARRL.NET

6 9

44/8 Failed
by Dale Yanz 05 Jan '16

05 Jan '16

John On my BPQ32 Console I have the following error Adding route to 44/8 failed This is the only error that I have there. Dale Yanz KJ6IX Nevada State Emergency Communication Volunteer Douglas County, Nv. Packet Coordinator KJ6IX(a)ARRL.NET

2 4

Re: [44net] How to update the AMPR.ORG DNS records ?
by Jerry Kutche 02 Jan '16

02 Jan '16

My assumption was false Sorry. 73 I'll need to sit down sometime however and figure out how things that do work on the portal only actually work. Not had time. May never. On Jan 2, 2016 11:02 AM, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > On Sat, Jan 02, 2016 at 03:45:56AM -0500, Jerry Kutche (N9LYA) wrote: > > Everything now has to be done via the portal// The email system has been > > eliminated. > > That is false. The portal DNS function is not operational; all DNS > updates must still be done via the email robot. > - Brian > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net

2 1

Re: [44net] Suspected Spam or Phishing Request through the AMPR portal
by Rob Janssen 01 Jan '16

01 Jan '16

> Subject: > [44net] Suspected Spam or Phishing Request through the AMPR portal > From: > Elias Basse <kd5jfe(a)gmail.com> > Date: > 12/31/2015 02:17 PM > > To: > AMPRNet Working Group Email <44net(a)hamradio.ucsd.edu> > > > All, > > Received a strange request today for an allocation. > > You have received a request for an IP allocation from: > Name: Rickey Francis > Email:Admin@abc-hosters.com <mailto:Admin@abc-hosters.com> > Callsign: RSF8192 > > The request details are as follows: > Type: user > Network: 44.108.230.0 / 32 > Connection: TUNNEL > > Please note that this has an invalid callsign, email address that is a bit hard to believe, and this points to a hosting company somewhere. > > Anyone have any ideas??? > > I Rejected it solely on the basis that it does not have a valid amateur radio callsign attached and I suspect that they are trying to use the address space for personal use (i.e. they are a hosting company) I only see one valid Rickey Francis in the QRZ database and that is in Washington state. > > Has anyone else received any strange request via the portal? > > Thanks! > > Best Regards, > > Elias Basse > KD5JFE > Lousiana Amprnet Coordinator Was there no spammy message in the free text area of the request? (this is forwarded as a separate attachment by the portal) Normally spammers use methods like this (filling in forms on websites) to spread some form of spam, at the minimum some URL of a website they want you to go to. But maybe in this case it was not spam or phishing but an attempt to get something registered. Some users are very confused about how to use the AMPR net. Unfortunately when you do a reject on a portal request that fact is always mailed back to the e-mail contact, I have asked for a way to silently remove requests so invalid requests like this can be deleted without resulting in a mail to an innocent person or invoke another reply by the requester. I think it has not yet been implemented. Rob

3 2

Suspected Spam or Phishing Request through the AMPR portal
by Elias Basse 31 Dec '15

31 Dec '15

All, Received a strange request today for an allocation. You have received a request for an IP allocation from: Name: Rickey Francis Email: Admin(a)abc-hosters.com <mailto:Admin@abc-hosters.com> Callsign: RSF8192 The request details are as follows: Type: user Network: 44.108.230.0 / 32 Connection: TUNNEL Please note that this has an invalid callsign, email address that is a bit hard to believe, and this points to a hosting company somewhere. Anyone have any ideas??? I Rejected it solely on the basis that it does not have a valid amateur radio callsign attached and I suspect that they are trying to use the address space for personal use (i.e. they are a hosting company) I only see one valid Rickey Francis in the QRZ database and that is in Washington state. Has anyone else received any strange request via the portal? Thanks! Best Regards, Elias Basse KD5JFE Lousiana Amprnet Coordinator

1 0

Re: [44net] Ham Class network
by Steve L 30 Dec '15

30 Dec '15

As Brian said there is no central authority. The formula is based off your MAC address. >From memory it simply does HEX to decimal conversion for each of the last 3 octets. I found this: http://bloodhound.aredn.org/products/AREDN/wiki/TechRef/GUI/admin/PerlUI_IP… >The ham meshnet folks use net 10 internally; they assign the addresses >by a formula. They don't have a central IP authority. I don't recall >the exact formula and whether it's based on an encoding of the callsign >or the location of the station, but it was explained in a paper they published >in a past TAPR DCC, either 2013 or 2014. >- Brian

8 12

JNOS Gateway
by Garth Massay 28 Dec '15

28 Dec '15

Hi all, fairly new to the list but definitely interesting and enjoyable reading. On to the specific question, I have recently set up JNOS (PI) BBS, and have a specific AMPR IP for JNOS (44.22.0.11/32 ), is there a specific gateway address I should be using, or do I need to setup a AMPRNET gateway router? Fairly versed in Linux, although by no means an expert, if I do need to setup a router, can this be done on the same PI? Any assistance or guidance would be greatly appreciated,.. Thanks All,.. - Garth

2 1

Re: [44net] Using Cisco Router as a gateway ?
by Rob Janssen 28 Dec '15

28 Dec '15

> Subject: > [44net] Using Cisco Router as a gateway ? > From: > Drorap <drorap(a)netvision.net.il> > Date: > 12/26/2015 10:22 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi there > I have started to config a Cisco rouer to serve as a gateway for the AMPRNET > I put in the command the following lines > > interface Tunnel0 > ip unnumbered Ethernet0 > no ip directed-broadcast > tunnel source Ethernet0 > tunnel destination 132.239.255.131 > tunnel mode ipip Unfortunately due to the way tunnels work in Cisco and other commercial routers you will need to repeat that 300 times with different destinations and setup 500 routes to route the traffic, and repeat that regularly because the destinations and routes change all the time. With a Linux system instead of the Cisco you can automate that very easily. There are possibilities to automate it on the Cisco (see that link Steve gave you) but still it will be a lot easier to just use a Raspberry Pi or other small Linux system. Rob

3 7

Re: [44net] Using Cisco Router as a gateway ?
by Rob Janssen 28 Dec '15

28 Dec '15

> Subject: > Re: [44net] Using Cisco Router as a gateway ? > From: > Drorap <drorap(a)netvision.net.il> > Date: > 12/27/2015 10:09 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Dear Rob > I used to do it 15 years ago and it worked > I even publishe the config file to the Gateways users group that time > I did a bi directional tunneling to UCSD (that time it was called mirrorshades) and let him deal with all the neccessary routes That is considered unacceptable behaviour.... To be a good gateway in the IPIP tunnel system you need to setup tunnels to all the other systems in the network. I think it currently does not even work anymore as the UCSD system now blocks such wrongly routed traffic. In a Linux system as a router, you need only one tunnel interface and the tunnel endpoints are defined in the route table (can be put in a separate route table when you want to use the same system both for internet and 44-net) That route table is automatically kept uptodate using a RIP daemon like ampr-ripd. Simple one-time setup and no more need to look after it and run regular scripts that fetch files and send commands. When someone changes their external address or subnets they route, your system will know about it after 5 minutes. But when you want to do it the difficult way, please go ahead! After all, learning and experimenting is what it is all about. Ready and working setups are not as interesting as finding out yourself how it all works and what are advantages and disadvantages of each method. Rob

2 1

Re: [44net] Using Cisco Router as a gateway
by Steve L 26 Dec '15

26 Dec '15

Use use protocol 4. Beyond that I am not going to be able to help you, as I don't have any Cisco stuff. I snagged this from the list some time back that might be of help. And you might want to reach out to Jason KY9J. http://www.qsl.net/kb9mwr/wapr/tcpip/cisco.txt

1 0

Ham Class network
by Daniel Curry 26 Dec '15

26 Dec '15

Hello all, This is a little off the topic of 44 network, but I am curios. The 44 network is split into many regions for Amateur Radio to use. But does anyone know on how the10.x.x.x network is assign to Amateur Radio Ham Mesh network? Is there someone or a group that have the responsibility on dishing ip addresses? Sorry for the band width, but just curios. K6DLC -- Daniel Curry IPV6 Sage Certified PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92 San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]

5 4

FYI: DNS attack traffic
by Marius Petrescu 26 Dec '15

26 Dec '15

FYI: This is how a DNS attack reply profile looks like... (Seen via AMPR gateway, as someone uses YO addresses as the reply address) The reply amplification can be nicely seen for each attack sequence – targets are some hosts in China. http://www.yo2loj.ro/files/dns_attack_replies.png 73s de Marius, YO2LOJ

2 1

Re: [44net] Portal API: networks and allocations
by Rob Janssen 22 Dec '15

22 Dec '15

> Subject: > Re: [44net] Portal API: networks and allocations > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 12/21/2015 09:20 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Mon, Dec 21, 2015 at 12:02 PM, Rob Janssen<pe1chl(a)amsat.org> wrote: >> >You can do that by simply watching the RIP broadcast and filter your own >> >external address. >> >This is what ampr-ripd also does. > Wouldn't this only work for networks in the encap with assigned > gateways? I was planning to use it with direct/BGP allocations, not > tunneled, so there would be no entry in the encap. > > Tom KD7LXL > I think there is no entry in the portal either... at least there need not be one. Anyway, I never do really basic config using a method this complicated. Risk is to high that it fails, e.g. when the portal is offline. I keep a file with important config items as a shell script and source it wherever it is required. Rob

1 0

Misconfigured router?
by Brian 22 Dec '15

22 Dec '15

I'm getting bombed with these frames: -- IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 1 DF prot UDP UDP: len 142 40445->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162 IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 1 DF prot UDP UDP: len 142 40445->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162 IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 255 DF prot UDP UDP: len 142 6771->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162 IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 255 DF prot UDP UDP: len 142 6771->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... Someone have a misconfigured router? The only thing worse than an extreme left-wing state is an extreme left-wing commonwealth protected by the sovereign doctrine. 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

2 1

Re: [44net] Portal API: networks and allocations
by Rob Janssen 21 Dec '15

21 Dec '15

> Subject: > [44net] Portal API: networks and allocations > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 12/21/2015 08:53 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I just looked through the portal API document > (https://portal.ampr.org/api.php) and don't see an endpoint for the > network list and the user's own allocation list. Is this currently > available? Can it be added? > > This would be useful for automation software. For example, you could > plug your AMPR portal username into the software and it would fetch > your list of allocations and automatically program your router to use > those allocations. > > Tom KD7LXL > You can do that by simply watching the RIP broadcast and filter your own external address. This is what ampr-ripd also does. Rob

2 1

Portal API: networks and allocations
by Tom Hayward 21 Dec '15

21 Dec '15

I just looked through the portal API document (https://portal.ampr.org/api.php) and don't see an endpoint for the network list and the user's own allocation list. Is this currently available? Can it be added? This would be useful for automation software. For example, you could plug your AMPR portal username into the software and it would fetch your list of allocations and automatically program your router to use those allocations. Tom KD7LXL

1 0

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 18 Dec '15

18 Dec '15

Marius: > Coming back to the IP range/AS assignment: > > IMHO there must and shall not be such a correspondence. An AS is used to > group one or more subnets into an well, Autonomous System (AS), and it > should support, based on network architecture and layout, a possible > migration of subnets from/to a specific AS, without any changes in the > peering structure. > e.g. If there is a subnet with access via AS 1 it should be there. But if > later this subnet will be reorganized, and lets say will be accessed via AS > 2, it should be possible to move it to AS 2 without any change in the BGP > peering. This is not possible using AS numbers generated from IPs. The idea behind using the IP address to calculate the AS is to make sure that AS numbers are always unique, without having to use a registry and without having to coordinate. When there is more than one subnet, it does not matter which one is used to calculate the AS number. When the one that was used to calculate the AS is being moved, some care will be required so it is not used again for this purpose at the new site. Up to now we only route to the "regional subnet" level and each region has only a single subnet, so there are no problems. If an additional subnet is added and then the original one is moved there could be problems, but this is not likely. This whole thing can depend on local issues and policies, but it does not really matter how you do things locally as long as everyone uses the same method to generate the prefix of the number. I will stick to that E.212 thing as it uses only 3 digits and because others are already doing this. (if not, I would probably have removed the "44" digits and added 2 available digits at the end, as proposed by Robbie) Rob

7 15

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 12 Dec '15

12 Dec '15

> Subject: > Re: [44net] Proposal for allocation of AS numbers > From: > Egbert - DD9QP <dd9qp(a)db0res-svr.ampr.org> > Date: > 12/11/2015 06:13 PM > > To: > 44net(a)hamradio.ucsd.edu > > > > > EU HAMNET has started thinking about using private 32bit-ASN quite some time ago. Diskussions in our regular meetings pulsed up since 32bit-ASN where available. > > But what we always were missing up to now was an international proposal for all countries using the 44-Net and, of course, a common agreement for using that. It makes no sense when everyone is rolling out a different System without talking to > others. Chances of crashing are high and planing isn't even worth the time. > > Regardless wether there is a registry, policy, human- or computerbased IP-Net-to-ASN-Generator out there, we all have to respect one minimal policy to keep everything running in the future: > > Don't use concurrent private-ASN-proposals in parallel! > Everything else is left to the countries themselves. > > For example: > Using the 42<mcc>xxxxxx in all countries is fine. But if some country starts using eg 42<IP-OctetofCountryDeployment>xxxxx there is high risk to crash with: > > Greece, Netherlands, Belgium, France, Monaco, Andorra, Spain, Hungary, Bosnia, Croatia, Serbia, Montenegro, Italy, Vatican, Romania, Switzerland, Czech Rep., Slovak Rep., Austria, United Kingdom, Denmark, Sweden, Finland, Lithuania, Latvia, > Estonia, Russia, Ukraine > > All of them have mcc-codes between 0 and 255. That is correct, that is why I decided to drop that proposal, although I still think it was better because: - it did not rely on another number list that has questionable status w.r.t. availability (my first attempts to download a complete list ended at some ITU site that requires a subscriber login, but later I found places where the full list is available in the open) - it handles the issue that the USA has much more network space relative to the number of E.212 entries - it left a lot of space in the private ASN range unused for future ideas (4225600000 - 4294967294) However, these issues are not that relevant in practice, and I am willing to go with the E.212 based system because it is already there. It gives all countries at least 100000 AS numbers to work with without any risk of duplicates, and some countries have more than one mcc number. That should be plenty, especially when they are not based on another number like a network address, but generated at some central site. Finally, when space ever runs out we can always assign "reserved" E.212 numbers as an overflow. 100000 numbers is a lot, and allows for regional subdivision where appropriate. Rob

1 0

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 11 Dec '15

11 Dec '15

Unfortunately my mail connection broke down for a few hours shortly after I posted my proposal, so I missed most of the replies in my mail. I am now replying based on the archive, but this means it is difficult to quote your messages. Robbie: that is a good point. In my design I anticipated that one would not want to route a smaller network than a /24, but in fact that could happen in the AMPRnet. The reason I put the 44 in the AS number is to reduce the probability that an AS would collide with another private AS allocated using a different system. However, it of course uses precious space. See below. Marius: that is interesting. This is exactly the kind of response I hoped for, as I prefer to use a method that is already established rather than inventing my own. I found it appealing that the subnet address can be seen and recognized, these E.212 codes are obscure to me (but probably not to the person who invented this method). This method leaves 5 digits within the country range, which allows for smaller subnets as Robbie proposed. I see one problem: because there is no 1:1 mapping between E.212 code and AMPRnet /16 subnet, it will not always be possible to directly number the AS from the subnet. For typical European countries it will work well, but for the USA there is a "problem" because there are many more /16 subnets allocated to them than there are E.212 codes. Of course there are still more than enough AS numbers, but it means they need to use some registry instead of a direct derivation of the number. Pedja: as mentioned early in the message, these AS are not for use on the public internet but only on our private radio network. Gateways between radio and internet are supposed not to be running BGP across them, or to filter the private AS and send out the routing under their public AS. That is already happening. It looks like I will modify the system to look like this for our local use (and others are welcome to follow it: 42eeexxxyy where eee is the E.212 code, xxx is the third octet of the IP address, and yy is a local sequence number 00-99 in cases where multiple AS exist in that subnet. So for 44.137.40.0/22 it will be 4220404000 (204 is the E.212 code for the Netherlands which has 44.137.0.0/16) When I would want an AS for my personal subnet 44.137.41.96/28 it could be 4220404096 or some other arbitrary 42204040xx number. (for now, we only route to the regional subnets level) In my opinion, it is less easy to read than the first proposal, but of course it has the advantage of more AS space within the local area, and the fact that it is already established in some places. That is an important advantage. Rob

6 12

Re: [44net] Proposal for allocation of AS numbers
by DD9QP 11 Dec '15

11 Dec '15

On Thu Dec 10 01:13:16 PST 2015 Sam VK4AA wrote: > You are correct, but we cant count on everyone on the same playing field > But then this is a hobby of learning so it may take a while for us all to be > on the same page. Sam - for (maybe) you and all others who are not sure what the hell we are talking about those 32bit AS-numbers this nice article may be some help to get you on the same page: http://www.networkworld.com/article/2233273/cisco-subnet/understanding-4-by… It's nice to read and gives some hints on how to fit old 16bit and new 32bit ASNs together. (Thanks to Thomas DL9SAU for finding this article in the net.) So whatever method should be used, it should assure to map "old" 16bit-ASNs to the new 32bit-ASNs in a way as easy as possible. Keep in mind that in Europe there is a "European HAMNET" driven by 16 countries. It was founded in early 2000s and is using 16bit-ASNs because the 32bit-range was not available at that time. There is a registry to avoid ASN-doubles and it is working very well. As I know it is by far the largest bgp-driven network within the 44-Net worldwide, as far as the number of countries, number of participants and area is concernd. For more info about that see links at bottom of this mail (all in english). Either the 42<mcc>xxxxx or the 42<dxcc>xxxxx proposals give the chance to map old 16bit-ASNs 1:1 into the new 32bit-ASNs because they leave the lower 16bit-part to the countries for individual use. Even an IP-subnet-coded ASN like e.g. for Austria 42143xxxxx would fit this. The first proposal from Rob PE1CHL does not. It is incompatible to everything that was used or proposed before. Glad to hear that Rob is willing to change this. I don't think that the discussion about either 42<mcc>xxxxx or 42<dxcc>xxxx is only cosmetical. We must keep in mind different sizes of different countries and there networks. MCC has 7 # for USA and 2 # for China. Each other country has 1. Within DXCC every country has 1 # ready to go. I agree with Marius YO2LOJ: At a first glance the mcc proposal seems to be prefereable because it allows more ASN-Range for big countries on the go. On DXCC-numbers something has to be added to make it recognize different sizes of countries. That causes unnecessary work and - to say it with Peja's words: "you will have to provide mapping table and make sure it is updated all the time." for dxcc. I would be very glad to have a worldwide usable sulution (proposal) for the whole 44-Net which is commonly accepted and published on a central site. This gives all new countries willing to join a bgp-routed network within 44-Net something at hand they can deal with from startup. Don't let us hesitate on this topic and let's plan it very well. 73s de Egbert DD9QP -- Infos about European Hamnet: https://www.tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf https://www.youtube.com/watch?v=3A6DDrJRcws

2 1

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

> Subject: > Re: [44net] Proposal for allocation of AS numbers > From: > Egbert - DD9QP <dd9qp(a)db0res-svr.ampr.org> > Date: > 12/10/2015 08:46 PM > > To: > 44net(a)hamradio.ucsd.edu > > > >> Well... We have been using that but the exact reason for this whole >> proposal >> was that I was extremely p*ssed off this week ... > > LOL > > Rob - > > I think this is not the plenum and thread to discuss your emotional situation. > > As I have heard some 3 weeks ago you occupied an additional ASN which was advertised to Slowenia since 2012 without asking maintainers or anybody else and without agreement from slowenia for using it. Well thats community rules and it works for 16 > countries. I personaly think you did it by mistake because it was documented well only on 2 Sites in the net and you had no time to read it or ask some of the maintainers. Taking all this into account I can understand that others than you had some > more reasons to get p*ssed off. We were told that the place to register information was hamnetdb.net and indeed there is a list of AS numbers there. When we ran out of the 4 assigned numbers I took the next one (skipping one that was registered to Slovenia) which was not registered. It was only later that it turned out that there is another place where "blocks" of AS numbers are handed out, and not being registered on hamnetdb does not mean the AS is available. In my experience, asking something to the maintainer of hamnetdb is not an effective way of getting knowledge. > > >> Initially we (the Netherlands) got an allocation of 4 AS numbers,... > > This was kind of an an initial "dummy" block assigned in 2010-2012 when the netherlands not even were thinking about joining that Network. We never heard of them until end 2014. Believe it or not: It was some German Guys that proposed in a very > early planing phase to put the netherlands in for future use because they could not believe that the Netherlands would not be interested in the future. Some more guys that have reason to get p*ssed off now? Well it's your decision not to > participate. Whenever a country ran out of ASN-space it got some more, without doing a caroussel for all others, but _after_ a request to the community/registry. Packet radio has been all but dead here for over a decade, because of the fast deployment of flatrate always-on internet in our densely populated country. The interest in radio networking has only come back the past 2 years. We are setting up a network for experiments and for our multisite repeater network. We are more interested in experimenting than in copying a network concept that has already been rolled out elsewhere. We want to make sure we can interface with others, but we for sure don't want to walk on other people's leech. For example, we have a completely different view on how our network interfaces with Internet than your group has. And I think that is good, you should not blindly follow our ideas either. We were notified of the AS allocation only last year, but apparently it existed longer than that. It turned out that the German Guys had decided how to divide the Netherlands into regions without discussing that concept with us. That is not the way we work anymore here, and it has been some time. Would you have deferred that allocation until after some discussion, that would also have been the moment to explain how those allocations are made and where they are registered. That never happened. But anyhow, the problem was not that I had mistakenly taken an AS number that turned out to be assigned to someone else. I immediately offered to move that AS and asked for another block of numbers to put the AS and the next ones we needed. What p*ssed me off is the SILLY policy of that registry that the AS numbers are assigned to a country by contiguous block, that the blocks are allocated without any space between them, and that the only way to get a block extended is to allocate a new block and move everything over. Now, that would not have been too hard for the 5 numbers that we had in place, but I just don't want to be using a registry with a silly policy like that (there is no reason whatsoever why AS numbers need to be allocated in contiguous blocks!) and risk more and more useless renumbering in the future, so the decision was made to evacuate immediately to avoid further damage. (I was alerted to similar problems experienced by the people operating the DMR repeaters here and they have made a similar move recently) Fortunately the availability of the 32-bit AS range means that there is no need for cooperation with people that want to manage others. We can just setup a system like the one we are discussing now, and there is no more need to work overtime to please the German Guys. > > Rob, what you brought into this list is a question of behavior and how one should interact with a community, but it has nothing to do with technical reasons, so I am not willing to discuss this any more on this list or in this thread. > I think I have explained what the problem was and why we don't want to use your registry anymore. It has policy that has nothing to do with technical issues. The result is problems like the one we experienced. Indeed there is no need to reply anymore. Our position is clear, and the whole problem has been worked around. You can delete our registration, I have already removed all those AS numbers from hamnetdb objects. Rob

1 0

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

DD9QP: > Keep in mind that in Europe there is a "European HAMNET" driven by 16 > countries. It was founded in early 2000s and is using 16bit-ASNs because > the 32bit-range was not available at that time. There is a registry to > avoid ASN-doubles and it is working very well. Well... We have been using that but the exact reason for this whole proposal was that I was extremely p*ssed off this week when I discovered that this registry only wants to allocate 1 contiguous range of AS numbers per country, and allocates only tiny ranges. Every time one outgrows the range of numbers, one is supposed to renumber the entire network. What a joke! Initially we (the Netherlands) got an allocation of 4 AS numbers, and when we needed more, the range immediately after that turned out to be already allocated since before we got our 4. So we apparently had been put in a hole left by someone else moving. When I noted that I did not like this and would like a second block to expand our allocation, the owner of the adjacent block was requested to renumber!!! He even complained that he had to renumber twice before. Then, we could expand our allocation to 19. And this process was completed before I even could note that I did not want to make others do the work that I did not see as useful. So then the decision was made to leave that registry and find another solution where neither we or others were forced to renumber or live with sub-optimal solutions (trying to limit the number of ASN). Our block can be returned to the free pool or be given back to the previous owner in case he did not start the actual renumbering work. Rob

2 1

Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

Some of the radio networks implementing AMPRnet use BGP as a routing protocol, and therefore require some AS numbers that should be unique within those networks. Note I am not referring to BGP routing on internet, but only within local radio networks. There usually are one or more gateways that are connecting those networks to internet, but BGP routing information is not carried across them, they only route a fixed subnet and may or may not use BGP on the inside as well. It is customary to use AS numbers from the "private AS ranges" on those radio networks documented in RFC6996: 64512 - 65534 and 4200000000 - 4294967294. The first (old) range has 1023 available numbers, so it requires some registry where individual areas can get numbers allocated to them to guarantee the uniqueness of the numbers within the network. As always, the policies of such registries lead to discussion and feelings, and I like to solve that by making the allocation fixed up to the regional level, so everyone can determine their own numbers without having to agree with others how it is done exactly and how many numbers each one requires and will get, and whether they need to be changed. Since 2009, BGP implementatations must support 32-bit AS numbers, and the second larger range has become available. My proposal is to map the assigned IP address ranges for countries and states directly to AS numbers in this AS range. Advantages: - the range of AS numbers automatically remains contiguous for countries and regions. - no need for an "international" registry, and probably not even for a "national" registry. - local operators can derive the AS number for their region from the local subnet address. - very sparse use of the available space makes for very low chance of conflicts, even in the presence of other private AS numbers that were allocated outside of this system. - future proof as there is no 1023-AS limit for the AMPRnet radio networks. - very easy to mnemonically map an AS number seen in a table or trace to the place where it is allocated, without need to refer to an allocation database. I propose the following AS number structure: For an IP network with the address 44.xxx.yyy.0/zz, the AS number will be: 4244xxxyyy. E.g. for my local network 44.137.40.0/22 the AS will be 4244137040. When areas of AS allocation are larger, an arbitrary subnet (e.g. the first) within that area can be used to derive the AS number. Alternatively, a national allocation system can be set up to manage the range available for a country or state when local operators like to do so, and use registered AS numbers from 000-999 within the range derived from the /16 address. E.g. the Netherlands has 44.137.0.0/16, so we can use the 1000-number AS range of 4244137000-4244137999 and subdivide it the way we like. There may be a slight chance that some very old equipment would not support 32-bit AS numbers, but the popular MikroTik, Ubiquiti and Linux(quagga) routers have no issue at all, and there is some interoperability with peers running the older version. I'd like to hear the opinions on this and possible enhancements/modifications. Rob

8 9

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

> Now will this be an issue for people like us that already have an asn? > I can see problems arising > > Regards > > Sam Scafe > VK4AA No to the contrary, this proposal is being made to AVOID problems like that. By defining a method to allocate AS numbers in a way that can be directly derived from agreed numbers (like the IP address in my proposal, and the E.212 number in the one that I am going to adapt), we guarantee that the AS numbers that we choose are not going to collide with the ones that others take. Not that this is very likely anyway. There are over 95 million AS numbers in the 32-bit range, and unless you do things like "private AS start at 4200000000 so we'll start numbering from there" it is not very likely that you will meet another network that has chosen the same numbers. And again: this is NOT related to AS numbers used on Internet. Our AS number on internet is 3265 and it will remain the same. Rob

1 0

CONFIIGURATION
by Eduardo Castillo 09 Dec '15

09 Dec '15

HOLA MI NOMBRE ES MARTÍN LU9DMG YA TENGO MI IP 44 --> 44.153.32.96 / 32 QUERÍA SABER COMO SERIA LA CONFIGURACIÓN DE LA RED LA INFORMACIÓN QUE TENGO ES LA INFO QUE NECESITO ES LA PUERTA DE ENLACE ETC QUERÍA CONFIGURAR LO EN UN MIKROTIK O EN LA PC DONDE ESTA EL BBS ------------------ HELLO MY NAME IS MARTIN LU9DMG I have my IP 44 -> 44.153.32.96 / 32 He wanted to know what it would SETTINGS OF THE NETWORK THE INFORMATION I HAVE IS THE INFO YOU NEED IS THE GATEWAY ETC. I WANTED IN A SETTING THE MIKROTIK OR THE PC WHERE IS THE BBS Regional NetworksNetworkDescriptionAllocated to44.153.0.0 / 23LU7ABFLU7ABF44.153.32.96 / 32buenos aires argentinaLU9DMG44.153.52.0 / 24LU7ABFLU7ABF44.153.54.0 / 28 LU7ABFLU7ABF44.153.54.16 / 30LU7ABFLU7ABF44.153.54.20 / 32LU7ABFLU7ABF44.153.54.21 / 32LU7ABFLU7ABF44.153.54.22 / 32LU7ABFLU7ABF44.153.54.23 / 32LU7ABFLU7ABF44.153.54.24 / 30LU7ABFLU7ABF44.153.54.28 / 30LU7ABFLU7ABF44.153.54.32 / 27LU7ABFLU7ABF44.153.54.64 / 26LU7ABFLU7ABF44.153.54.128 / 25LU7ABFLU7ABF44.153.55.0 / 24LU7ABFLU7ABF44.153.56.0 / 23LU7ABFLU7ABF44.153.72.13 / 32GW lu8fjh.dyndns.org for 44.153.72.13/32 LU7ABF44.153.81.0 / 24LU7ABFLU7ABF

1 0

Fw: new important message
by anespo1＠tiscali.it 09 Dec '15

09 Dec '15

Hello! New message, please read <http://store.maxlisshair.com/gone.php?1413b> anespo1(a)tiscali.it

1 0

(no subject)
by Rial Sloan 04 Dec '15

04 Dec '15

Are there any historical records (a la change management) of what has been allocated to individuals in the past? I've got a new request from someone that claims to have had an allocation but I'd like to be able to verify. -- Rial F Sloan II N0OTZ

1 0

Please return 44.182.21.0/24...
by Marius Petrescu 29 Nov '15

29 Nov '15

Could the owner of ‘4x1kw - ham ip network in kibuts dan area’ gateway 31.154.7.2 please return my 44.182.21.0/24, which is alocated to YO, not 4X, subnet to me? Thank you, Marius, YO2LOJ

1 1

New Linux Boot Scripts for Testing
by lleachii＠aol.com 24 Nov '15

24 Nov '15

All, I have worked on a updated version 2.0 RC3 of the STARTAMPR script. I've also included more detailed instructions in the STARTAMPR file, as well as a README. Original versions of the script remain compatible and can continue to run on AMPRNet devices. Also, for those wanting to reload the routing table on boot, I've created a new script called BACKUP_AMPR. Features of BACKUP_AMPR: - creates an hourly output of "ip route get table 44" - table44_bak - creates an hourly executable script to re-add those routes - restore44sh New in STARTAMRPR v2.0 RC3: - DYNAMIC GATEWAY IP SUPPORT, proper configuration of Local Subnets will end need to exclude your subnet using rip44d -a switch - Routing tables and rules used to provide default routes and blackholes independently for each subnet - SECURITY FIX, packets for destinations not listed in TABLE 44 are blackholed - Examples of connecting to Gateways behind 44.0.0.0/s BGPed subnets The files and README are located here for those on AMPRNet: http://44.60.44.10/amprnet_docs/start_ampr_version2 73, - Lynwood KB3VWG

10 67

Accessing AMPRNet via VPN
by Roland Schwarz 16 Nov '15

16 Nov '15

Hi everyone! I am trying to use the access to the AMPRNet by VPN via amprnet-vpn1.aprs.fi I already got hold of a lotw certificate but cannot get access. Is this to place to hope for further help? 73 de oe1rsa -- _________________________________________ _ _ | Roland Schwarz |_)(_ | | \__) | mailto:roland.schwarz@blackspace.at ________| http://www.blackspace.at

12 30

Re: [44net] Amprnet VPN setup, root CAs
by Steve L 27 Oct '15

27 Oct '15

Roland, How did you get this info?

2 1

Re: [44net] Accessing AMPRNet via VPN was Services hosted on AMPRNet
by Steve L 25 Oct '15

25 Oct '15

>>>> Does anyone know if OH7LZB ever documented anywhere how to setup the >>>> server end of the OpenVPN that validates using the LoTW CA? >>The server end is stock openvpn, so you may use the openvpn config >>instructions / documentation to set it up. Nothing fancy, . I have and have been using a stock openvpn server with my own generated certificate authority, server keys. All is fine there. I tried replacing the certificate authority with the amprnet-vpn-ca.crt (lotw) file, and all I get is TLS key handshake/negotiation failed messages when I try and connect. So there is something I am not understanding on if the server keys have to be built specific CA to that somehow? Steve

5 9

Re: [44net] Services hosted on AMPRNet
by Steve L 19 Oct '15

19 Oct '15

http://wiki.ampr.org/index.php/Services Does anyone know if OH7LZB ever documented anywhere how to setup the server end of the OpenVPN that validates using the LoTW CA? Others might like to add the same functionality to their gateway server(s) http://wiki.ampr.org/index.php/AMPRNet_VPN https://github.com/hessu/ham-cert-web-demo

4 4

Re: [44net] Services hosted on AMPRNet
by Steve L 19 Oct '15

19 Oct '15

David, I like the idea. I remember commenting when the hsmm-mesh/hamnet firmware first implemented something like that, we needed that on the amprnet in order to find things on the network. Which will make it more useful. At the very least each gateway needs a dashboard or something. But you are right, it has to be low bandwidth, as we still have a lot of technological challenges when it comes to radio links and speed. Short of that you have to nmap the whole address space :-) Not that long ago I suggested a way to denote the radio link speeds connecting the gateways to the radio LAN's in the portal. Closest thing we have presently is an index webserver at: http://web.oe2xzr.at.ampr.org/ Overall the German Hamnet guys have some good things going Active hosts: http://hamnetdb.net/?m=host&as=0 We need to recruit people with good coding skills to help develop things. I'd be offering to help if I knew more in that department. ---- Quote ---- Back to the original "available services" part of this thread, I've been thinking about this as well. Maybe the group could consider a services advertisement protocol like ZeroConf (Avahi in Linux, Bonjour in OSX) with some modifications to minimize it's chattyness? Things like stations should not beacon what services they offer more than once an hour w/o being directly probed, etc. --David KI6ZHD

1 0

Services hosted on AMPRNet
by Neill Thornton 17 Oct '15

17 Oct '15

Hey fellow AMPRs! I have been playing around with devices in my allocated block today, and realized there doesn't seem to be a consolidated place to show where services might be hosted on the AMPRNet... for example a GPS trained NTP server, IRC server, etc... allowing amateur related traffic to stay on the 44/8. Does something like that exist? Is there any reason to not make services like I am describing available to other hams? Thanks, Neill

1 0

Re: [44net] Accessing AMPRNet via VPN
by Steve L 17 Oct '15

17 Oct '15

Nevermind, turns out one of the files I was using still had some XML stuff in it. So now I have it working with SecurePoint OpenVPN in Windows 7: http://sourceforge.net/projects/securepoint/ And CentOS 5.5 using openvpn 2.2.2, as well as on as Raspberry Pi, raspbian, openvpn 2.2.1 Roland, are you attempting to connect using the GUI in Ubuntu 15.04 or using the command line?

1 0

Re: [44net] Accessing AMPRNet via VPN
by Steve L 17 Oct '15

17 Oct '15

Interesting when I tried it the windows way. Error: private key password failed

1 0

Re: [44net] Accessing AMPRNet via VPN
by Steve L 16 Oct '15

16 Oct '15

[root@kb9mwr openvpn]# nmap 85.188.1.118 -p 1773 Starting Nmap 5.00 ( http://nmap.org ) at 2015-10-16 12:17 CDT Interesting ports on amprgw.rats.fi (85.188.1.118): PORT STATE SERVICE 1773/tcp closed unknown Nmap done: 1 IP address (1 host up) scanned in 0.52 seconds Despite this, it works for me: [root@kb9mwr openvpn]# openvpn client.conf Fri Oct 16 12:18:07 2015 OpenVPN 2.2.2 i686-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Apr 5 2012 Fri Oct 16 12:18:07 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Fri Oct 16 12:18:07 2015 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Fri Oct 16 12:18:07 2015 WARNING: file 'client.key' is group or others accessible Fri Oct 16 12:18:07 2015 LZO compression initialized Fri Oct 16 12:18:07 2015 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Fri Oct 16 12:18:07 2015 Socket Buffers: R=[110592->131072] S=[110592->131072] Fri Oct 16 12:18:07 2015 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Fri Oct 16 12:18:07 2015 Local Options hash (VER=V4): '41690919' Fri Oct 16 12:18:07 2015 Expected Remote Options hash (VER=V4): '530fdded' Fri Oct 16 12:18:07 2015 UDPv4 link local (bound): [undef]:1194 Fri Oct 16 12:18:07 2015 UDPv4 link remote: 85.188.1.118:1773 Fri Oct 16 12:18:07 2015 TLS: Initial packet from 85.188.1.118:1773, sid=af8cd2e6 8b7e00df Fri Oct 16 12:18:08 2015 VERIFY OK: depth=1, /O=AMPRnet/CN=OH7LZB_VPN_service_CA Fri Oct 16 12:18:08 2015 VERIFY OK: depth=0, /CN=ampr-gw.he.fi Fri Oct 16 12:18:10 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Oct 16 12:18:10 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Oct 16 12:18:10 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Oct 16 12:18:10 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Oct 16 12:18:10 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Fri Oct 16 12:18:10 2015 [ampr-gw.he.fi] Peer Connection Initiated with 85.188.1.118:1773 Fri Oct 16 12:18:12 2015 SENT CONTROL [ampr-gw.he.fi]: 'PUSH_REQUEST' (status=1) Fri Oct 16 12:18:12 2015 PUSH: Received control message: 'PUSH_REPLY,route 44.0.0.0 255.0.0.0,route 44.139.11.0 255.255.255.192,topology net30,ping 24,ping-restart 120,ifconfig 44.139.11.58 44.139.11.57' Fri Oct 16 12:18:12 2015 OPTIONS IMPORT: timers and/or timeouts modified Fri Oct 16 12:18:12 2015 OPTIONS IMPORT: --ifconfig/up options modified Fri Oct 16 12:18:12 2015 OPTIONS IMPORT: route options modified Fri Oct 16 12:18:12 2015 ROUTE default_gateway=192.168.1.1 Fri Oct 16 12:18:12 2015 TUN/TAP device tun0 opened Fri Oct 16 12:18:12 2015 TUN/TAP TX queue length set to 100 Fri Oct 16 12:18:12 2015 /sbin/ip link set dev tun0 up mtu 1500 Fri Oct 16 12:18:12 2015 /sbin/ip addr add dev tun0 local 44.139.11.58 peer 44.139.11.57 Fri Oct 16 12:18:12 2015 /sbin/ip route add 44.0.0.0/8 via 44.139.11.57 Fri Oct 16 12:18:12 2015 /sbin/ip route add 44.139.11.0/26 via 44.139.11.57 Fri Oct 16 12:18:12 2015 Initialization Sequence Completed [root@kb9mwr openvpn]# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:44.139.11.58 P-t-P:44.139.11.57 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:48 (48.0 b) TX bytes:0 (0.0 b)

2 1

Re: [44net] 44Net Digest, Vol 4, Issue 144
by Rob Janssen 15 Oct '15

15 Oct '15

> I just followed this, for a CentOS 5 system and it took right off: > > http://wiki.ampr.org/index.php/AMPRNet_VPN > > Make sure you have these files in your /etc/openvpn directory: > amprnet-vpn-ca.crt > client.conf > client.crt > client.key Actually with a modern openvpn client it is possible to combine everything in a single .conf file. (or .ovpn when you want to use it on Windows) The certificates and keys van be put in the file "inline". I use this method for distribution of openvpn configs that can be used with our national VPN gateway (only available for Dutch stations), for which we generate certificates and send them to the users. The file for the amprnet vpn system would look like this: client dev tun proto udp remote amprnet-vpn1.aprs.fi 1773 resolv-retry infinite persist-key persist-tun comp-lzo verb 3 ca [inline] cert [inline] key [inline] <ca> contents of the amprnet-vpn-ca.crt file </ca> <cert> contents of the client.crt file </cert> <key> contents of the client.key file </key> This makes it easier to move the certificate around, use it on Windows, etc. Only really old versions of the openvpn client, today only found on devices like NAS that have not updated for a long time, do not support the [inline] construct. Rob

2 1

Re: [44net] Accessing AMPRNet via VPN
by Steve L 14 Oct '15

14 Oct '15

I just gave it a try for the first time ever. A couple years back I applied for a Log of the World certificate and never really took it any further. I guess I forgot. Mistake #1 for me was only backing up the KB9MWR.p12 and KB9MWR.tq6 files a couple years ago. That was on a former computer. I should have backup up the whole, C:\Documents and Settings\your-username\Application Data\TrustedQSL directory, or just completed the process and made the openvpn keys back then. Anyway no big deal, just a few more hoops to have the certificates re-issued. I just followed this, for a CentOS 5 system and it took right off: http://wiki.ampr.org/index.php/AMPRNet_VPN Make sure you have these files in your /etc/openvpn directory: amprnet-vpn-ca.crt client.conf client.crt client.key Aside from that we are going to need a bit more detail to further help you. What does the openvpn daemon say when you start it?

1 0

Subject: PTD
by Rob Janssen 12 Oct '15

12 Oct '15

> Subject: > [44net] PTD > From: > Brian <n1uro(a)n1uro.ampr.org> > Date: > 10/10/2015 04:13 AM > > To: > 44net(a)hamradio.ucsd.edu > > > Is anyone on PTD.net that's running SNMP? Please MAKE SURE that you block all incoming SNMP traffic from internet to amprnet! (especially when you are using community names like "public") The bad guys use SNMP as an attack amplifier. One time I moved a switch to another address and it became exposed, and within 3 days I had an abuse report. Now I have a general rule that drops all SNMP at our gateway. (of course the real problem is the ISPs that refuse to implement BCP38, source address filtering) Rob

5 8

PTD
by Brian 10 Oct '15

10 Oct '15

Is anyone on PTD.net that's running SNMP? 24.115.114.195.res-cmts.flt.ptd.net.54321 > gw.ct.ampr.org.snmp: [udp sum ok] { SNMPv2c C=AMPRNet_RO { GetRequest(34) R=198102558 E:14988.1.1.1.1.1.7.0 } } 22:08:32.571779 IP (tos 0x0, ttl 114, id 15043, offset 0, flags [none], proto UDP (17), length 81) 24.115.114.195.res-cmts.flt.ptd.net.54321 > gw.ct.ampr.org.snmp: [udp sum ok] { SNMPv2c C=AMPRNet_RO { GetRequest(34) R=198102560 E:14988.1.1.1.1.1.4.0 } } 22:08:32.571848 IP (tos 0x0, ttl 114, id 15044, offset 0, flags [none], proto UDP (17), length 81) 24.115.114.195.res-cmts.flt.ptd.net.54321 > gw.ct.ampr.org.snmp: [udp sum ok] { SNMPv2c C=AMPRNet_RO { GetRequest(34) R=198102562 E:14988.1.1.1.1.1.3.0 } } 22:08:32.571914 IP (tos 0x0, ttl 114, id 15045, offset 0, flags [none], proto UDP (17), length 81) 24.115.114.195.res-cmts.flt.ptd.net.54321 > gw.ct.ampr.org.snmp: [udp sum ok] { SNMPv2c C=AMPRNet_RO { GetRequest(34) R=198102564 E:14988.1.1.1.1.1.2.0 } } -- Dolphins are so smart that within a few weeks of captivity, they can train people to stand on the very edge of the pool and throw them fish. 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Portal API "Heads Up"
by G1FEF 08 Oct '15

08 Oct '15

For those of you using the Portal’s API, this is a “heads up” to check your client code… It was pointed out to me that the JSON encoding the API returns was slightly non-standard. Having looked into the issue this seems to be the case, so I have today corrected the error and bumped the version. Just check your client is still decoding the output correctly - most libraries would have happily accepted the JSON variant I was using, so chances are you won’t need to change anything, but if you coded your own JSON decode routine… Regards, Chris

1 0

Attention PY2ZEN
by Brian 03 Oct '15

03 Oct '15

You may want to fix this... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 161 IP: len 161 10.1.1.5->239.255.255.250 ihl 20 ttl 1 DF prot UDP UDP: len 141 52618->1900 Data 133 0000 M-SEARCH * HTTP/1.1..MX: 2..HOST: 239.255.255.250:1900..MAN: "ss 0040 dp:discover"..ST: urn:schemas-upnp-org:service:WANPPPConnection: 0080 1.... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 161 IP: len 161 10.1.1.5->239.255.255.250 ihl 20 ttl 1 DF prot UDP UDP: len 141 52618->1900 Data 133 0000 M-SEARCH * HTTP/1.1..MX: 2..HOST: 239.255.255.250:1900..MAN: "ss 0040 dp:discover"..ST: urn:schemas-upnp-org:service:WANPPPConnection: 0080 1.... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 160 IP: len 160 10.1.1.5->239.255.255.250 ihl 20 ttl 1 DF prot UDP UDP: len 140 52618->1900 Data 132 0000 M-SEARCH * HTTP/1.1..MX: 2..HOST: 239.255.255.250:1900..MAN: "ss 0040 dp:discover"..ST: urn:schemas-upnp-org:service:WANIPConnection:1 0080 .... -- Dolphins are so smart that within a few weeks of captivity, they can train people to stand on the very edge of the pool and throw them fish. 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Reverse Delegation
by Fredric Moses 03 Oct '15

03 Oct '15

I know a couple of groups now have proper reverse delegation of DNS for their subnets… Wondering who to drop a line to so I can get 44.103.0.0/19 delegated to a.ns.mi6wan.net and b.ns.mi6wan.net ? Didn’t see it in the portal or wiki and my notes from a few months ago are foggy... -- Fredric Moses - W8FSM - WQOG498 fred(a)moses.bz

6 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net