- 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
> - 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
> 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
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
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
> 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
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
