Great. Thanks.
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 6/17/17 15:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] alternate encap.txt download
Sure, why not? It's all automatic anyway.
- Brian
On Sat, Jun 17, 2017 at 02:59:38PM -0700, Michael Fox - N6MEF wrote:
> Brian,
> Do you intend to continue to generate the alternate encap.txt file on
> amprgw.ucsd.edu?
> If so, I'd like to update my scripts to try that location if the portal
> fails.
> Michael
> N6MEF
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian,
Do you intend to continue to generate the alternate encap.txt file on
amprgw.ucsd.edu?
If so, I'd like to update my scripts to try that location if the portal
fails.
Michael
N6MEF
Thanks Tom.It's reassuring to see that your connection made it through too, and that you didn't get your ipip packets dropped just upstream of me like amprgw's. I think I'll try and convince my ISP's network engineers to take a look at Brian's ipip traceroute output, maybe they overlooked something last time.
Cheers,Josh
-------- Original message --------
From: Tomasz Stankiewicz <sp2l(a)wp.pl>
Date: 16/06/2017 20:18 (GMT+10:00)
To: josh(a)festy.org
Cc: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] 44 net connectivity problems ?
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
I concur with Charles.
Exactly the same I obswerve on my Windows 7/64b __NOT 44-net aware__
Cable ISP Vectra, Poland.
Tracing route to net.vk2hff.ampr.org [44.136.24.60]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 5 ms 6 ms 7 ms 10.149.64.1
3 6 ms 7 ms 8 ms 172.20.253.1
4 12 ms 13 ms 13 ms 172.17.0.249
5 12 ms 11 ms 14 ms 172.17.0.250
6 14 ms 12 ms 18 ms 172.17.0.133
7 12 ms 14 ms 13 ms 172.17.28.238
8 13 ms 13 ms 13 ms 172.17.28.238
9 27 ms 14 ms 12 ms ae48-48.r7.poland-rs.thinx.atman.pl [212.91.0.10]
10 40 ms 42 ms 46 ms limelight.plix.pl [195.182.218.35]
11 148 ms 147 ms 149 ms lag23.fr4.ord.llnw.net [68.142.88.56]
12 166 ms 171 ms 167 ms 68.142.88.147
13 187 ms 187 ms 188 ms 68.142.88.155
14 187 ms 187 ms 188 ms lag7.fr4.aza1.llnw.net [68.142.64.50]
15 189 ms 188 ms 189 ms tge1-1.fr3.aza1.llnw.net [69.164.62.16]
16 198 ms 201 ms 198 ms lag16.fr3.lax.llnw.net [69.28.189.233]
17 201 ms 197 ms 197 ms 198.32.251.189
18 200 ms 198 ms 199 ms dc-tus-agg3--lax-agg6-100ge.cenic.net [137.164.11.7]
19 201 ms 201 ms 202 ms dc-sdg-agg4--tus-agg3-100ge.cenic.net [137.164.11.9]
20 226 ms 202 ms 203 ms dc-ucsd-1--sdg-agg4.cenic.net [137.164.23.54]
21 202 ms 202 ms 203 ms nodem-core-6807-vlan2767-gw.ucsd.edu [132.239.254.61]
22 203 ms 203 ms 203 ms rci-nodem-p2p.ucsd.edu [132.239.254.177]
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
Next test with IP address 44.139.11.30 assigned from AMPRNet VPN:
Tracing route to net.vk2hff.ampr.org [44.136.24.60]
over a maximum of 30 hops:
1 57 ms 57 ms 57 ms dyn1.oh-vpn.ampr.org [44.139.11.1]
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 474 ms 478 ms 470 ms net.vk2hff.ampr.org [44.136.24.60]
Trace complete.
Yet another test, with IP address 44.165.15.17 assigned from SP2L VPN:
Tracing route to net.vk2hff.ampr.org [44.136.24.60]
over a maximum of 30 hops:
1 74 ms 77 ms 71 ms avpn1.sp2l.ampr.org [44.165.15.1]
2 565 ms 549 ms 549 ms net.vk2hff.ampr.org [44.136.24.60]
Trace complete.
One more test, with IP address 44.137.40.185 assigned from Netherland's VPN:
Tracing route to net.vk2hff.ampr.org [44.136.24.60]
over a maximum of 30 hops:
1 42 ms 44 ms 43 ms gw-44-137.pi9noz.ampr.org [44.137.0.1]
2 467 ms 474 ms 475 ms vk2hff.ampr.org [44.136.24.60]
Trace complete.
Best regards.
Tom - SP2L
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
