I have noticed there is something with 44 addresses and Windows too.
I have never been able to ping a 44 address from Windows, while they work proper from a Linux terminal.
All pings to 44 address from Windows result in "Destination host unreachable" (even 44.0.0.1)
It's no big deal for me, but have never really figured out why this is.
Date: Sun, 20 Jan 2013 00:34:06 +0200 From: "Marius Petrescu" marius@yo2loj.ro To: n2nov@n2nov.net, "'AMPRNet working group'" 44net@hamradio.ucsd.edu Subject: Re: [44net] Gateways Unreachable after Dynamic IP Update
Hi,
I'm running debian 6, updates via RIP. Working from a windows PC behind the server acting as router.
Check the route your response packets take on their way out. If you initiate the ping you get the response correctly back due to connection tracking mechanisms. This doesn't mean that responses to icmp requests necessarely do the same. E.g. responses may go via a default gateway which is not correct. Make sure your answers go out on the same interface they came in.
sooo...
Pinging 44.2.10.1 with 32 bytes of data: Reply from 44.2.10.1: bytes=32 time=226ms TTL=222
Pinging 44.68.41.1 with 32 bytes of data: Reply from 44.68.41.1: bytes=32 time=160ms TTL=28
But then...
C:\Users\Marius>ping 44.60.44.1
Pinging 44.60.44.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out.
Ping statistics for 44.60.44.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
73's Marius, yo2loj
On the machine hosting the tunnel endpoint, there must be a proper source nat done so that outgoing packets use ampr addresses as source. Anything else results in icmp responses being routed back through regular internet, returning via another interface, thus getting ignored by the system. Connection tracking implies that responses are received on the same interface on which the request was sent. And no packet other than 44.x.x.x registered in the encap file should go via the tunnel interface (and be sent directly to their end points).
44.0.0.1 should be reachable by ping on every machine, since this is a real internet address on the public internet. The failure to reach it is the result of the existence of a 44.0.0.1 entry in the encap file, which is invalid and which results in trying to reach the ampr gw via tunnel. 44.0.0.1 via 169.228.66.251 actually doesn't work... And also 44.0.0.0/8 doesn't, since forwarding via the gw needs an established link (to permit responses from the regular internet), while 44 destinations have to be reached directly by encapsulation. So 44.0.0.1 and 44 addresses not in the encap file should be routed like any regular public address, and NAT-ed to your own public IP address.. They have to go via public wan ip -> ampr gw (44.0.0.1) -> (ipip tunnel) -> ampr host and back. Not encaped via tunnel.
Marius, yo2loj
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of kb9mwr@gmail.com Sent: Monday, January 21, 2013 00:48 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] 44Net Digest, Vol 2, Issue 8
I have noticed there is something with 44 addresses and Windows too.
I have never been able to ping a 44 address from Windows, while they work proper from a Linux terminal.
All pings to 44 address from Windows result in "Destination host unreachable" (even 44.0.0.1)
It's no big deal for me, but have never really figured out why this is.
-
kb9mwr＠gmail.com -
Marius Petrescu