Sorry to ask but what has accepting RIP to do with the gateway IP? RIP is encapsulated into IPIP, so no firewall will ever care about that. And no sane firewall setup will accept RIP on its WAN. From both the gateway's point of view it's just protocol 4, nothing else.

What I mentioned in my earlier post is that a "protocol unreachable" (for protocol 4 packets) is a serious condition although it could still be valid when encountered by amprgw and not by the other gatways.

A "port unreachable" for UDP port 520 indeed is not an error condition. The gateway may not be using RIP. Or, the firewall may have been configured to reject port 520 traffic while ampr-ripd -r is still processing it. (not likely because the RIP traffic is multicast so would not normally be replied to by the firewall)

To do some better "gateway alive" testing I think some extra steps are required:

1. a mandatory field has to be added to a gateway registration entry, with an IP address inside the routed subnets that is pingable. (of course getting everyone to enter this data will be difficult)

2. a separate "monitoring station" has to be setup that acts as a gateway and pings that address regularly (but not overly often) and keeps stats on the returned pings.

The monitoring station has to be separate from amprgw because some people choose not to tunnel to amprgw.

Alternatively, a checkbox could be added to gateway registrations to specify if the gateway wants to receive internet traffic (to be handled by the amprgw firewall table) and it could be made mandatory to tunnel to amprgw. That would probably be preferable, as it would also make 44.0.0.1 reachable for those gateways that do not want to get internet traffic.

Adding the fields to the gateway registration system should be straightforward, but of course getting everyone to enter them wouldn't be. Not responding to a request to enter information of course could be treated as an indication that the gateway is no longer active.

Rob