On 15/11/2014 5:02 PM, John Wiseman wrote:

But if I try pinging any other address in my subnet, I don't get anything. I'd expect amprgw to send me packets for any address in my subnet.

Do the other addresses in your subnet that you're trying to ping have ampr.org DNS entries? If not, then no forwarding of those IPs by amprgw.

73 Gavin VK6HGR

Which may need clarification for some - how to get an address into the DNS.

On Sat, November 15, 2014 4:29 am, Brian Kantor wrote:

amprgw has a filter in it that only allows traffic to hosts that are in the DNS. 44.131.56.1 is there; 44.131.56.2 is not, so pings and other traffic to 44.131.56.2 will not be forwarded. - Brian

-- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.

NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org

NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins

"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan

"The more corrupt the state, the more it legislates." - Tacitus

"Molann an obair an fear" - Irish Saying (The work praises the man.)

"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

John et al;

On Sat, 2014-11-15 at 09:02 +0000, John Wiseman wrote:

I'm adding a rip44 processor and ipip tunnel support to my BPQ32/LinBPQ networking software.

As you know from 44.48.0.42, ampr-ripd and a standard linux tunnel works fine for your software and has for the past year and a half or so; but for the windows environments to be able to handle rip/ipencap this I'm sure would be a welcomed thing for those folks.

I've set up an encap entry for 44.131.56.0/27 and I receive the block of RIP44 messages every 5 minutes, and random packets addressed to 44.131.56.1, presumably from network scanners. If I ping 44.131.56.1 from a normal internet host I also see the encapsulated packets. So far so good. But if I try pinging any other address in my subnet, I don't get anything. I'd expect amprgw to send me packets for any address in my subnet.

As Brian mentioned, commercial<>amprnet requires dns entries for the IPs you want publicly routable, however if you only want to stay within the amprnet, the portal entry should be enough as 44<>44 routing is point-to-point. This excludes those announced via BGP. This may be a useful scenario for test environments on a larger scale, and sites that are RF only.

Andy.

Same story here :((

Tom - SP2L (ex sp2lob)

I have temporarily disabled the ability to edit gateways whilst I work on the code.

Chris

On 15 Nov 2014, at 15:59, Andy Brittain g0hxt@greatbrittain.co.uk wrote:

(Please trim inclusions from previous messages) _______________________________________________ Hi

Anyone else having a blank page when you try to edit your own gateway on the portal?

Andy G0HXT

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

John et al.

Checked just while ago:

sp2l@linux:/# rip44d -d -i tunl0 -vvv found local address: 44.165.2.2 found local address: 44.165.15.1 found local address: 192.168.0.101 found local address: 127.0.0.1 opening UDP socket 520... entering main loop, waiting for RIPv2 datagrams received from 44.0.0.1: 520: 124 bytes RIPv2 packet contains password <PasswordGoesHere> but we require none ... and nothing more follows... Seems that something went askew. Whereas, usually there is at least 18 lines received.

Best regards.

Summary: There is damage to the database. Chris says he's working on it. - Brian

Brian, Chris, thank you for your efforts.

I took a look at the latest sent encap info and I want to bring in discussion the way how some gateways are announced.

route addprivate 44.24.240/20 encap 44.24.221.1

Now this one is ok. The gateway (44.24.221.1) is BGP announced, but not in the encap file. Everything ok and working.

Now to the other two IMHO are wrong:

route addprivate 44.151.94.28/32 encap 44.151.94.28

So this host expects to get encapsulated traffic to a gateway which is the host itself. This leeds to a routing loop and is not possible with a regular setup. This encap entry is in fact plain and simple useless: It states 'you can reach me via me' which gives not much information.

route addprivate 44.140/16 encap 44.140.0.1

The same applies to the above, just that the whole subnet is routed to a gateway which is part of that subnet itself.

The idea is that a route can not point to a gateway for which the route is resolved by the route itself. It may be said that those are BGP routed subnets and the gateway is directly reacheable. But the routing is resolved by the route with the most specific netmask. In this case exactly the one which defines the host (or subnet) itself. Unless there is a mechanism available to mark those gateways and create a higher priority route to them so they can be reached directly, this is not functional.

Please comment on a possible sollution/approach on those setups.

73s de Marius, YO2LOJ

We think everything is ok now. Please advise if otherwise. - Brian

Sorry to push this, but I think we really need an agreed solution for this topic.

I wish to emphasize some use cases so we can find a common approach (assuming that he 44/8 route via ampr-gw is gone). All descriptions are from the point of view of the "regular" tunneled gateway.

1. 44 subnet, BGP announced, with a public IP available for tunneling This doesn't pose any problems. Has to be published in the encap file, regular route handling is OK. If direct non-tunneling access is desired, the entry has to be ignored in the encap/RIP data. Can be implemented by adding a higher priority (lower metric) route to that subnet via default gw, or add the GW address to the rip daemon ignore option. Drawback on direct access would be that ham traffic can not be identified as such (because of NAT), except when originating on other BGP announced 44 subnets. Using src-address filtering with gw data from the encap can increase security.

2. 44 subnet, BGP announced, with a public 44 tunnel gateway address, not present in the encap/RIP data This should also work without problems, as long as there is no default 44/8 route. The same issues as in (1) apply.

3. 44 subnet, BGP announced, with 44 public tunnel gateway address in the same subnet. In this case, tunnel access is prevented by a routing loop. There are solutions for this, but none of them automaticaly (for the moment). a. A specific route can be defined for the tunnel gateway via default gateway. This will allow the gateway to be direct reachable, and all the traffic for the subnet will be tunneled to it. One major drawback is the fact that the gateway itself will not be reachable via that tunnel. b. Outgoing proto 4 (ipip) traffic can be marked and handled by a separate routing table, so that it can be directed to that specific gw host. c. The route can be ignored in encap/RIP, and accessed directly, of course ham traffic from non-BGP announced hosts will not be distinguishable from regular traffic, except if src-address filtered based on encap data.

4. Single 44 host, BGP announced, accepting tunnel connections to it. Here, the only option would be to policy route the outgoing ipip traffic to the default system gateway, as described in (3).

Conclusion: The universal solution would actually be that outgoing proto 4 (ipip) traffic should be marked and handled by a separate routing table and NATed to the system's gateway address. This should not affect any routes except when using private ipip tunnels to other gateways, in which case specific routes have to be added to that routing table.

This could be implemented in the ampr-ripd daemon and done automatically using a secondary routing table, for all RIP routes which have a 44 gateway address.

I assume this could also be done in xNOS systems.

Have a nice day, Marius, YO2LOJ

However I'm discussing the publication of IRT contact data specifically tailored to AMPR sysadmins and provide the link to the IRT data within the gateway notes.

We have published an update to our gateway entry

https://portal.ampr.org/gateways_list.php?a=view&id=533

it now references a CERT contact page

http://laru.lu/working-groups/digital-data-networks-ddc/147-cert-en.html

Comments welcome.

vy 73

Hello OMs,

Following the recent outage at ampr-gw and the latest discussions, I did some modifications to the daemon.

Routing: - Ignore subnets for which the gateway is inside their own subnet

RIP forwarding: - Reconstruct forwarded RIP messages to be able to send them even on ampr-gw outages - Forwarded local RIP messages do not use authentication anymore - Forwarded local RIP messages are sent 30 seconds after a RIP update, otherwise every 29 seconds

You can get the changes from GitHub: https://github.com/yo2loj/ampr-ripd

Or the usual locations: inet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.13.tgz 44net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.13.tgz

73s Marius, YO2LOJ