The encap.txt file is missing from the portal.
The last "encap.txt-<date>" is encap.txt-20170714073337
Starting after that, there are some "new_encap_<date>" files. But no
"encap.txt".
Michael
N6MEF
> Ok, they're gone too. What about
> pe5hwg IN A 62.108.10.22
> which appears to be an anomoly, being outside net 44.
Hmm that is a strange one!
I don't think I added that, and pe5hwg is not a valid callsign.
The IP address is in the Netherlands, though.
Maybe you can still trace who submitted that?
Rob
> There were 23 44.137 addresses on the list of potential deletions.
> They have been removed from the list.
Thanks! There are 13 CNAME records as well:
pd1aay IN CNAME pe1sac
pe2ro IN CNAME pa7o
links.pi1ehv IN CNAME pi1ehv
pi8brd IN CNAME pi1brd
www.pi8cdr IN CNAME pi8cdr
smtp.pi8cdr IN CNAME lx.pi8cdr
pop.pi8cdr IN CNAME lx.pi8cdr
ns.pi8cdr IN CNAME lx.pi8cdr
news.pi8cdr IN CNAME lx.pi8cdr
ftp.pi8cdr IN CNAME pi8cdr
pi8dec IN CNAME pi1dec
pi8rmd IN CNAME pi1rmd
sys2.pi8shb IN CNAME sys2.pi1shb
Rob
> Returning to the perennial subject of cleaning up the AMPR.Org DNS
> database, Neil Johnson has done a thorough job of investigating the
> entries in the current database. He has generated a file available from
> the gw.ampr.org anonymous FTP server "Hosts-TBD.txt" which lists 2,045
> callsign-based entries in the DB where
> 0. They're in the current AMPR.Org DNS.
> 1. They're not found in active entries on QRZ.com.
> 2. They're not found in the online Callbook database.
> 3. They're not in the portal.
> 4. They're not in HamNet.de.
> 5. They were NOT entered into the AMPR.Org DNS after 2011.
> 6. Or they are listed as expired in QRZ.
All hosts in the 44.137.0.0/16 network are validated against the license authorities'
callsign list on a weekly basis and expired licenses are deleted. Entries have
been re-confirmed in 2014 and 2016 by sending a mailing and news bulletin and keeping
only those entries for which a mail reply was received or that were otherwise confirmed
as still active. About 1/3 of the hosts were deleted in 2016.
Please don't delete further hosts from 44.137.0.0/16 (hostnames p[a-i][0-9][a-z]* )
Rob
I've been downloading the encaps.txt file from portal.ampr.org. Mostly,
that's been OK except for the recent outage and some hick-ups in the data a
year or so ago. Now the file is also on gw.ampr.org (if I understand
correctly) in a slightly different format (<sigh>).
The question is: which is the better source to use, considering likely
uptime (network reliability, UPS, etc.) and reliability of data (fewest
transforms from original data, etc.)?
Thanks,
Michael
N6MEF
Any way in which we will know what is getting deleted ?
At 05:59 AM 6/13/2017, you wrote:
>Returning to the perennial subject of cleaning up the AMPR.Org DNS
>database,
>
>I propose to delete these entries from the AMPR.Org DNS around July 1st.
> - Brian
----------
Wm Lewis (KG6BAJ)
AMPR Net IP Address Coordinator - Northern and Central California Regions
(A 100% Volunteer Group)
----------
William Lewis, 51-701 / KG6BAJ
Deputy Chief Comm Reserve Officer (North)
Deputy State RACES Officer (North)
Communication Reserve Unit
California Governor's Office of Emergency Services
(530) 648-4920 Cell
<mailto:wlewis@acscalifornia.org>wlewis<mailto:wlewis@acscalifornia.org>@acscalifornia.org
**Confidentiality Notice: This e-mail, including any attachments, is for
the sole use of the intended recipients and may contain confidential and
privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited. If
you are not the intended recipient please notify the sender by reply e-mail
and destroy all copies of the original message**
Hi Brian, thanks for your explanation. I was not aware of that
requirement. I thought that every entry in the encap file, either host
or network, it was fully routed. I will email Pedro LU7ABF to ask for
the update.
Also thanks to Brian N1URO and Tom SP2L for their feedback.
73!
Gustavo
LU7WA
Date: Fri, 9 Jun 2017 20:44:38 -0300
> Date: Fri, 9 Jun 2017 17:56:14 -0700
> From: Brian Kantor <Brian(a)UCSD.Edu>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] Routing problem?
> Message-ID: <20170610005614.GB9749(a)UCSD.Edu>
> Content-Type: text/plain; charset=iso-8859-1
>
> Amprgw filters at the per-host (/32) level. Each host which is to receive
> traffic from the Internet into AMPRNet must individually be listed in
> the permissions file, which is built from the AMPR.ORG DNS 'A' records.
>
> The only host on your subnet which is listed (and therefore is the only
> one authorized) is 44.153.164.5. If you want .6 or other hosts on your
> subnet to be able to communicate with the Internet, you will need to
> have your local coordinator add them to the DNS for you. Or I can do it.
> - Brian
I updated the map site (sorry for a lot of interruptions) to somehow
work on all the browsers I had on hand.
It uses websockets and eventstream as fallback.
This is the current status:
- Mozilla Firefox (latest): Full
- Chrome Desktop (latest): Full
- IE 11: No pulse animation due to the lack of full SVG support
- Chrome Android (latest): No 'pew' sound. Sometimes horizontal clipping
on HD displays occurs."Request desktop site" fixes this.
- Android internet browser (latest): No pew sound
- Iceweasel 3.5 (Debian 6): Not supported
Lynwood,
It appears that your dynamic address gateway 'www.kb3vwg.info'
keeps cycling between address 173.66.138.32 and 71.178.210.39.
When it resolves to the latter address, your 44net hosts are
reachable. It did so this morning whilst I happened to be looking:
Jun 9 03:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
and I was able to connect to your web server on 44.60.44.10.
I don't know why this is happening. Is your commercial IP really changing
as often as it appears from the logs or is this a problem at your dynamic
address provider?
- Brian
Jun 8 07:13:43 <local0.info> amprgw ipipd[51724]: route changed [129]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 07:18:02 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 08:04:37 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 08:15:05 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 09:15:05 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 15:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 16:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 19:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 22:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Hi All, I'm new to the list and I find it very interesting.
Let me introduce myself: ham since 1996, former call LU8WFY, primary
interests CW, HF and later digital communications. Devoted to linux for
more than ten years. Work in telecommunications since 2001.
Now the problem: I got the assignment 44.153.164.4/30
<http://44.153.164.4/30> from the local coordinator (LU7ABF) and (after
some NAT fighting with my Cisco 877 router) I was able to put it online
from dynamic IP. From the gateway IP 44.153.164.5 there's no problem
pinging to 44/8 and to the outside world. Ping from outside to .5 is
also ok. But when I ping from outside to 44.153.164.6 there's no
response. The strange thing is that, using tcpdump, I see no packets
coming into the gateway from amprgw (of course they do show when the
ping is to .5). Further testing from 44 net (using yo2tm.ampr.org
network tools) showed that from 44 to my host everything works as expected.
I guess that there's some routing problem between outside world and
44 net. I don't know in which way the routes from 44 are propagated to
the rest of the internet.
Maybe I´m missing something but I can't find the problem.
Any help will be appreciated.
Thanks!
73
Gustavo
LU7WA
