Same problem for me on mint 12 and mint 13...no luck at all and I've spent

6 hours trying..I do know that most commercial routers don't pass rip packets but i've put my system direct in the dmz still to no avail, however it works right away in jnos2...

John

Routers have to pass IPIP traffic (proto 4), the RIP annoncements arrive via tunnel interface from amprgw, not directly.

Marius

This has nothing to do with port 520. The rip packages are encapsulated in proto 4 ip frames. They pass right through and are decapsulated in the tunnel driver on the machine which hosts your tunnel endpoint. So from the routers point of view, there are only IP proto 4 frames which have to pass through, no port 520 RIP traffic. They emerge only at the tunnel interface from where rip44d has to process them, where they are indeed port 520 UDP frames. Not before that.

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of JJ Sent: Saturday, August 25, 2012 09:41 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] rip44d fedora 4

(Please trim inclusions from previous messages) _______________________________________________ On 08/25/2012 01:54 AM, Marius Petrescu wrote:

(Please trim inclusions from previous messages) _______________________________________________

...

Same problem for me on mint 12 and mint 13...no luck at all and I've spent

6 hours trying..I do know that most commercial routers don't pass rip packets but i've put my system direct in the dmz still to no avail, however it works right away in jnos2...

...

John

Routers have to pass IPIP traffic (proto 4), the RIP annoncements arrive via tunnel interface from amprgw, not directly.

Marius

---

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

yes, but do the routers understand ipip port 520 udp?

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

Sugestion: RIP messages sent by amprgw are multicast. You should check your firewall rules so they don't block multicast traffic.

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of JJ Sent: Saturday, August 25, 2012 16:30 To: AMPRNet working group Subject: Re: [44net] rip44d fedora 4

(Please trim inclusions from previous messages) _______________________________________________ yes true, I knew that actually, just referencing port 520 as some op's might not know which port to try to forward from the router, hi, I should have been clearer...what I'm refering to is the fact that protocol 4 is not understood by most routers - I've read that cisco- based routers do however, but I can't verify that...I'm running dd-wrt on mine and it still stubbornly won't pass rip packets to my internal ip that it has assigned to me..so now I'm using an ip within the routers subnet assigned as dmz and using jnos2 which parses the ripv2 packets just fine on my persistant linux tun0. However, if I drop jnos, and run rip44d pointed at the same tun0, linux rip44d does not see any rip packets...(had to edit rip44 to change tunl0 to tun0)...so still "dead in the water", yes, waited more than 5 minutes, hi, waited 1 hour...not sure how to proceed after that... Cheers, Bald John

I will describe my setup, which is working, maybe you'll get some ideas.

So I have a DSL modem followed by a router and then my server on which the tunnel endpoint resides. The DSL modem is set to bridge mode and I do the PPPoE authentication on the router (I don't think this is relevant). Now, on the WAN port I got my public IP and have a firewall route forwarding protocol 4 to my server. Your DMZ essentially does the same in a more general way, ensuring the proper NAT. Now to the tunnel. My internal IP on the router is 10.10.74.2, the server ip is 10.10.74.1. My tunnel interface: address 44.182.21.1 netmask 255.0.0.0 Startup command sequence: ip tun add ampr0 mode ipip local 10.10.74.1 (<-- this is the local interface address) ip route add default via 169.228.66.251 dev ampr0 onlink table default (<-- this is the amprgw peer which goes into table "default") ip rule add from 44.182.21.1 table default (<-- anything coming to my server from this interface will use the "default" routing table) ip rule add from 44.182.21.1 to 44.0.0.0/8 table main (<-- anything going to other 44 addresses will use table "main") ip route del 44.0.0.0/8 (<-- delete the route created automatically for this interface so that connections to 44 addresses not in the routing table go via regular internet and not via tunnel)

After this I start the rip44d daemon: rip44d -I ampr0 -p HereComesThePassword -a 89.x.x.x (All routes from rip broadcasts will go into the table "main" and your local public infos IP will be discarded)

This setup ensures that any connection request arriving via tunnel will go back the way they came in, the rest will be routed according to the "main" routing table.

Now, if I run some tracing program like wireshark, I see ripv2 packets on the ampr0 interface, which is my tunnel interface.

Maybe this helps.

Marius, YO2LOJ

oh yes, have tun0 working fine and I'm getting the ripv2 broadcasts just fine on it(FINALLY!), then I've created a userspace tun1 for jnos to use to talk to the linux stack using tuncreate (create a tun device WITHOUT root permissions), and jnos is talking fine thru it...so now I have a couple of axip links working, the odd thing is, some links are working, some are not, and from the linux console 44-net isn't working (yet) but from jnos 44-net (at least some of it) IS working another odd thing is terribly slow domain lookups from jnos, but domain lookups from linux itself are working fine, ha... still working on it.. Cheers, John