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

I get this just fyi root@w9bbs:~# ping 44.60.44.1 PING 44.60.44.1 (44.60.44.1) 56(84) bytes of data. 64 bytes from 44.60.44.1: icmp_req=1 ttl=46 time=211 ms 64 bytes from 44.60.44.1: icmp_req=2 ttl=46 time=237 ms 64 bytes from 44.60.44.1: icmp_req=3 ttl=46 time=213 ms 64 bytes from 44.60.44.1: icmp_req=4 ttl=46 time=217 ms 64 bytes from 44.60.44.1: icmp_req=5 ttl=46 time=222 ms 64 bytes from 44.60.44.1: icmp_req=6 ttl=46 time=233 ms From: 44net-bounces+n9lya=blueriver.net(a)hamradio.ucsd.edu [mailto:44net-bounces+n9lya=blueriver.net@hamradio.ucsd.edu] On Behalf Of Don Moore Sent: Saturday, January 19, 2013 6:01 PM To: AMPRNet working group Subject: Re: [44net] Gateways Unreachable after Dynamic IP Update I use jnos on slackware. I am still using the daily download of the encap.txt file from the gateway and they all work pretty much flawlesly. This is what jnos sends out when I ping 44.60.44.1 22:53:44.182169 IP 192.168.1.150 > 98.252.61.22: IP 44.135.90.2 > 44.60.44.1: ICMP echo request, id 162, seq 0, length 12 (ipip-proto-4) But I get no response back which is the reason I had asked if your system is actually enaping the 44. address(es) to the ampr stations. If not they just won't make it to them. I know the information is up to date or I wouldn't be encaping to the correct address. I can ping your internet address but not 44.60.44.1 Don - ve3zda

I don't know what to say Lynwood.. I've just tried to telnet from 12 other stations to 44.60.44.1 and got no response from any but one and that one came back as busy. All of the ones I tried from have not had their internet ip changed in weeks. It could be that 44.60.44.1 is the router and not actually any software and that's why it's not possible to ping or telnet to it? response from any of them. 73, Don On Sun, Jan 20, 2013 at 11:42 AM, <lleachii(a)aol.com> wrote:

Marius, I'd like to understand the recommendation regarding using Source NAT, I am not using NAT, as all my IPs are directly routed to their hosts, and all my AMPR hosts possess 44 IP address and are routed directly. Every device on my network has a source IP in the range of 44.60.44.0/24, and knows of no other routes but other AMPR subnets and the gateway (when used) via my 44.60.44.1. Also, when using the default route, 44.0.0.1 populates in rip44 as: 44.0.0.1 dev tunl0 via 169.228.66.251 onlink. Therefore, all AMPR networks are in-fact on my route table, including 44.0.0.1. '44.0.0.1 via 169.228.66.251' is a valid and operational route (as removing it causes announcements not to populate). Also, 'default via 169.228.66.251' is valid as it provides connectivity to the Internet and routes to populate (since the default route is in-fact a link to the next hop, 44.0.0.1). I understand that 44.0.0.1 is known to be un-pingable via AMPR, I have never been able to ping it. There are various reasons that could be so, but Brian would be better to explain that (looping packets sent by a rogue or misconfigured station using 44.0.0.1 as its IP are very good reasons). Please note that it would be technically improper to say it's unreachable, as we all have a route to 44.0.0.1; and we (all registered gateways) receive subnet announcements when the 44.0.0.1 route is installed. Just because an address is not pingable, telnet-able, etc, does not mean it's invalid and in-operational (for example, for safety's sake [RFC 2003 -IP Encapsulation within IP - section 3.2], I firewall forwarding of any IP whose source matches an interface on my AMPRrouter). You would be correct that 44.0.0.0/8 is an invalid route within AMPR, as you cannot reach subnets within AMPR without their direct route. We all confirm that we have direct routes installed to the subnets we are testing. I have not had issues with Windows hosts pinging 44 addresses over AMPR. Before I used BIND DNS on 44.60.44.3, I used Microsoft DNS, that host worked fine (Windows DNS simply required more memory to maintain than BIND). ~Lynwood

Marius, I understand, but not to belabour the point; are you saying that you have custom configured routes on your device using the public Internet to contact 44.0.0.1? We are testing connections over AMPR. We both agree '44.0.0.1 via 169.228.66.251' is not a gateway, it is only a connection to AMPRGW. I noted that 'default via 169.228.66.251' is both a GW and connection to 44.0.0.1 (confirmed as my firewall only permits 44.0.0.1 on the RIP network port). You noted: "To reach 44.0.0.1 properly you need a smaller metric route to circumvent the tunnel and use public addresses." In that case, you would agree that you are NOT reaching 44.0.0.1 over AMPR? Under your scenario, Source NAT must be used, as you are using the public Internet for 44 hosts in your network to reach 44.0.0.1. ~Lynwood

Don, Marius, and All: Marius, RIP44 is a TCP connection, in the most simple terms, there MUST be communication BOTH ways (ACK, SYN ACK, the password, EST) via Encapsulation from your station to 44.0.0.1. It is safe to say that the encap route for 44.0.0.1 is operational if you seeded your router with a route to 44.0.0.1 OR with default; and are receiving announcements. Just because a host does not ping telnet, etc doesn’t mean it's not operational (more below about how Don and I troubleshooted the issue). Thanks to Don for his assistance. With his help, it was determined that the reason I was not able to connect to stations originally was because some had not yet updated their encap. That problem slowly worked itself out; but other stations are unable to connect to me. A number of reasons were found: - all stations are not using JNOS as their Network OS; operators simply (and understandingly) assume identical services and commands were available (telnet, SMTP, etc.), and then noted I was down because I did not have those same services available - (thanks to Don for pointing this out) in my setup, the DNS entry for my station ('kb3vwg.ampr.org') was not intended for my JNOS device (as I do not use JNOS at this time); I understand now that in JNOS, to connect to a station, you simply enter the callsign and the domain is appended - this built-in scheme and command set is based in an assumption that the remote station is running JNOS and has DNS configured for such - if this is common on AMPR (which I assume), we definitely need to add this to the Wiki - some stations were testing me using telnet (I understand this services comes enabled for APRS/Convers/etc.), but I am not running those services at this time ~Lynwood KB3VWG

Brian, I definitely agree that all valid hosts should be ping-able, all of my valid hosts should respond to ping. Would you suggest a NAT configuration to reach 44.0.0.1 via ping? I used as my premise a previous conversation where you noted that 44.0.0.1 is known not to respond to pings. ~Lynwood

I stand corrected, I relied on an engineer in the office, and not the firewall entry on my router that obviously said "UDP" when preparing my response. Hessu confirmed that a route to 44.0.0.1 should not be necessary, in practice, that doesn't appear to be the case, when I remove '44.0.0.1 via AMPRGW' or do not use 'default via AMPRGW' my routes never populate. I'm going to look into creating a JNOS device for testing and understanding better the software that a majority of us use for AMPR. Can anyone suggest a manual page or tutorial? ~Lynwood

Hessu, The thread IS NOT about JNOS. I am trying to understand why users have varying experiences connecting to one another. We've narrowed it down to Network OS or user issue. I intend to setup a JNOS node to better understand users employing the JNOS software suite. I am running Ubuntu GNU/Linux 12.04.1 LTS, and the route appears to be needed. When I remove the route, the RIP44 updates do NOT occur, you noted that the route is undeed and should populate without. Please assist by providing more clarity regarding why you feel the route can be safely removed; and why in practice, that isn't the case. ~Lynwood

Hessu, I'm using RIP44 v1.1 for route population. Line 201 is modified to add routes to table '44.' My setup is rather straightforward. You will find my configuration files at: http://kb3vwg-013.ampr.org IP rules specify: - FROM 44.60.44.0/24 TO my 192.168.LAN.0/24 use main table, priority 1 (not required for operation) - TO 44.0.0.0/8 use table 44, priority 44 - FROM 44.0.0.0/8 use table 44, priority 45 My main table (that tunl0 uses) has the following 3 routes: - default via 192.168.LAN.1 dev eth0 metric 100 - 44.60.44.0/24 dev eth1 proto kernel scope link src 44.60.44.1 - 192.168.LAN.0/24 dev eth0 proto kernel scope link src 192.168.LAN.IPofRouter Table 44 contains 2 routes at startup: - EITHER (1) - 'default via 169.228.66.251 dev tunl0 onlink' (for Internet access for 44hosts - the 44.0.0.1 via AMPR populates via RIP44 when I use this route) -OR- - '44.0.0.1 via 169.228.66.251 dev tunl0 onlink' (I need one of these seeded in my router RIP44 to operate, if I use the default, the 44.0.0.1 route above is added by RIP44 automatically as '44.0.0.1 via 169.228.66.251 dev tunl0 onlink window 840') AND (2) - 44.60.44.0/24 dev eth1 ~Lynwood

JJ You can add a SD Card to some of those routers like the WRT54GL I have one here but without the SD card... May add one... keep me posted on your efforts and maybe I can get mine modified and let you know.... 73 jerry -----Original Message----- From: 44net-bounces+n9lya=blueriver.net(a)hamradio.ucsd.edu [mailto:44net-bounces+n9lya=blueriver.net@hamradio.ucsd.edu] On Behalf Of jj Sent: Thursday, January 24, 2013 7:17 AM To: AMPRNet working group Subject: Re: [44net] SOLVED - Gateways Unreachable after Dynamic IP Update (Please trim inclusions from previous messages) _______________________________________________ On 13-01-23 07:03 PM, lleachii(a)aol.com wrote: Has anyone tried rip44d on a dd-wrt router? Probably not enough room for the ip table? Just curious as I have a couple of these routers, also have an e2500 running tomato....was thinking I could just dedicate a router to amprnet to simplify my setup... Cheers, John (BRRR...-20c here with wind chill -30) _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

On Thu, Jan 24, 2013 at 11:23:31AM -0500, lleachii(a)aol.com wrote: When you find out, would you please write a brief article for the new wiki with the information? We can't recover the previous wiki content so it has to be written afresh. Thank you. - Brian

Brian, I checked some of my notes, the following packages are needed on Ubuntu 12.04.1 LTS to run RIP44d: included on a base installation: - perl - perl-base - perl-modules must be added: - libio-socket-multicast-perl - libio-interface-perl 'sudo apt-get install libio-socket-multicast-perl libio-interface-perl' I will make a Wiki entry shortly after Chris creates an account (I've already dropped him an email). ~Lynwood KB3VWG

@Lynwood: RIP44, is a UDP communication, using src and dest port 520, multicast address 224.0.0.9 as destination and source is 44.0.0.1. Before receiving these broadcasts the user have to join a multicast group and enable multicast on the receiving interface. This is why you need a route to 44.0.0.1 on the tunnel interface, so that the group subscribe message gets sent to 44.0.0.1. Feel fre to use a network sniffer like wireshark and see for yourself. @Brian: If it works, lets try not to fix this. 44.0.0.1 doesn't respond to ping via tunnel. I think we can live with this :-) 73's de Marius, yo2loj -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Tuesday, January 22, 2013 19:48 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] SOLVED - Gateways Unreachable after Dynamic IP Update Marius, RIP44 is a TCP connection, in the most simple terms, there MUST be communication BOTH ways (ACK, SYN ACK, the password, EST) via Encapsulation from your station to 44.0.0.1. It is safe to say that the encap route for 44.0.0.1 is operational if you seeded your router with a route to 44.0.0.1 OR with default; and are receiving announcements. Just because a host does not ping telnet, etc doesn't mean it's not operational (more below about how Don and I troubleshooted the issue).

On Tue, 22 Jan 2013, lleachii(a)aol.com wrote: That's not quite true. The RIP packets are UDP packets, not TCP, and the communication is strictly one-way. The 44.0.0.1 gateway router blindly transmits encapsulated RIP packets to all gateways listed in the encap routing file, and the gateways may decode them and apply them in the routing table, or ignore them. I wrote the rip44d for Linux, so I had to take a serious look at how it works. - Hessu, OH7LZB