Not all that long ago I installed the new rip44d on a CentOS install. It did receive the broadcasts as I saw them in debug mode. However it didn't seem to install these routes to the local routing table.
I assume that has to with networking working slightly different on the various flavor of Linux.
So now I am trying with Ubuntu 10.04 server, but I can't even seem to receive the broadcasts. It just sits there in the main loop waiting for broadcasts. Yet when I watch with tcpdump, there are things going on. But I am mostly concerned by the udp port unreachable that I am responding with:
(For now) I have the Linux firewall completely disabled (as far as I know... more of a RedHat guy) and connected directly to the outside world.
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 13:30:00.337401 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.38700: RIPv2, Response, length: 504 13:30:00.337442 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 38700 unreachable, length 540 13:30:00.337454 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 13:30:00.337606 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.38700: RIPv2, Response, length: 504 13:30:00.337624 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 38700 unreachable, length 540 13:30:00.337632 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 13:30:00.337976 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.38700: RIPv2, Response, length: 504 13:30:00.338000 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 38700 unreachable, length 540 13:30:00.338008 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 13:30:00.338015 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.38700: RIPv2, Response, length: 504 13:30:00.338026 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 38700 unreachable, length 540 13:30:00.339133 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504
I am looking for tips on what I am doing wrong, or what distribution and steps those who are doing this had success with.
Thanks, Steve, KB9MWR
Hi,
On Tue, 2 Oct 2012, kb9mwr@gmail.com wrote:
So now I am trying with Ubuntu 10.04 server, but I can't even seem to receive the broadcasts. It just sits there in the main loop waiting for broadcasts. Yet when I watch with tcpdump, there are things going on. But I am mostly concerned by the udp port unreachable that I am responding with:
That would probably mean that your ipip tunneling is not set up, or that rip44d is not running like it should (as root, listening on the rip UDP port).
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 13:30:00.337401 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.38700: RIPv2, Response, length: 504 13:30:00.337442 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 38700 unreachable, length 540
Fun, RIP is on port 520. Could you run this:
tcpdump -i eth0 -vvv host amprgw.sysnet.ucsd.edu or ip proto \icmp
The -v flags give more information on the packet contents. This is what I get in the incoming frames:
22:00:01.176444 IP (tos 0x0, ttl 41, id 30103, offset 0, flags [none], proto UDP (17), length 292) amprgw.sysnet.ucsd.edu.route > ampr-gw.oh2ch.org.33324: RIPv2, Response, length: 264, routes: 13 .. and then the password and route information
I wrote rip44d, and I'm happily running it on Ubuntu 10.04. Works fine for me.
You could also post the output of the /sbin/ifconfig command (to see if tunneling is set up right).
- Hessu