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.
This is about 5% of the database. Not a large amount but
a definite place to start.
I propose to delete these entries from the AMPR.Org DNS around July 1st.
- Brian
I've switched the AMPR.Org and 44.in-addr master nameserver over to
using a new database and maintenance software. All seems to
be working correctly.
If you encounter any problems looking up a hostname or IP address
in the relevant ranges, please let me know.
- Brian
Josh.
Just to confirm availability of your host:
root@linux:/# ip route get 44.136.24.60 from 44.165.2.2
44.136.24.60 from 44.165.2.2 via 110.175.89.41 dev tunl0
cache window 840
root@linux:/# traceroute 44.136.24.60
traceroute to 44.136.24.60 (44.136.24.60), 30 hops max, 60 byte packets
1 net.vk2hff.ampr.org (44.136.24.60) 717.780 ms 740.340 ms 762.076 ms
root@linux:/#
Best regards.
Tom - SP2L
Hi Rob,
Bob VE3TOK tested connectivity from his gateway and had no issues getting in to mine, which should rule out a conntrack issue.
I've also ran traceroute and ping tests from other gateways via a different internet connection to asses this as well.
Another test I tried along that line was sending ipip packets to amprgw for 15 minutes straight to see if any encapsulated rip packets might find their way in, but nothing. It seems like every gateway except the new amprgw can send and receive ipip packets to/from my gateway which is why I thought it might be a very specific host+protocol block implemented by my ISP.
Everything was working fine for me up until a week or so ago.
Josh - VK2HFF
-------- Original message --------
From: Rob Janssen <pe1chl(a)amsat.org>
Date: 16/06/2017 19:11 (GMT+10:00)
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] 44 net connectivity problems ?
> My vdsl modem is a Huawei HG659b. The modem routes all DMZ traffic to an
> interface on a Broadcom based AP running OpenWRT via a cisco WS-C3750g-24PS.
> I can see all manner of connections hitting my DMZ interface from my
> public IP (typical portscans etc) so the modem->DMZ forwarding seems ok.
But do you ever see any unsolicited incoming traffic that is not ICMP, TCP or UDP?
A "quite common" DMZ bug is that the router actually forwards only these protocols
to the DMZ host, and not protocols like IPIP (4).
However, it DOES return the replies on outgoing IPIP packets you send.
So, when you try to ping someone on a tunnel it works, but when the NAT translation
rule has disappeared (after a few seconds up to 3 minutes or so) an outgoing ping
from the same host you just pinged does not work anymore.
I have seen this several times on the IPIP mesh. People claiming their system
works fine but still it is unreachable for unsolicited connections.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
> My vdsl modem is a Huawei HG659b. The modem routes all DMZ traffic to an
> interface on a Broadcom based AP running OpenWRT via a cisco WS-C3750g-24PS.
> I can see all manner of connections hitting my DMZ interface from my
> public IP (typical portscans etc) so the modem->DMZ forwarding seems ok.
But do you ever see any unsolicited incoming traffic that is not ICMP, TCP or UDP?
A "quite common" DMZ bug is that the router actually forwards only these protocols
to the DMZ host, and not protocols like IPIP (4).
However, it DOES return the replies on outgoing IPIP packets you send.
So, when you try to ping someone on a tunnel it works, but when the NAT translation
rule has disappeared (after a few seconds up to 3 minutes or so) an outgoing ping
from the same host you just pinged does not work anymore.
I have seen this several times on the IPIP mesh. People claiming their system
works fine but still it is unreachable for unsolicited connections.
Rob
> Unless Hotmail is still silently deleting automated messages - it used
> to do that years ago, much to the annoyance of a place I previously
> worked for. Clients would complain that their booking confirmations
> would never arrive.
Hotmail is not usable for production. It is as unreliable as most Microsoft stuff.
Recently I sent a couple of messages about a network configuration problem to
a user on the Dutch hamnet, and later he claimed he never got them. But my own
outgoing mailserver has the logs of the delivery to the hotmail MX and accepted status.
Rob
> I get no reply on an update mail to the ampraddr robot, but the changes did get processed...
Ah, now I got the reply... too impatient, it got delayed by a greylister probably because the sender address changed.
Rob
> I don't plan to change the format of the new zone files; they are what is
> being loaded into the nameserver. Please accept my apologies for the
> difficulty.
Ok no problem, I make the small changes required to ignore case and that TTL value
when comparing the zone file to what comes out of my hosts->zone converter.
Rob
