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
> 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.
There is a change in the content of the downloadable zone file ampr.org.gz
This causes problems in my scripts. I can modify the scripts, but first let's
see if you can make them like before so similar issues for others could be
avoided...
Rob
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
