Subject: mrouted and mbone apps on same linux machine

From: Nathan Kidd <[email-masked]>
Date: Tue, 30 Jul 1996 16:39:34 -0400 (EDT)

I am having a problem, similar to one mentioned by Dave Price earlier when
setting up a tunnel between two linux machines.  

One machine is running Slackware 3.0 kernal 2.0.9 and the other is running
Redhat kernal 2.0.8.  

The tunnel is established using mrouted 3.8, and is up, however only data
packets originating from machines other then the two running mrouted are
passed through the tunnel.  

I do not, however, get the "data field too short" messages when running an
mtrace between the systems.

Does anyone have any experience/information concerning this?  It would be
greatly appreciated.  Please cc any replys directly to me, as I do not
reliably recieve the mailing list.

Thank you.

Nathan Kidd

---

From: Rafal Maszkowski <[email-masked]>
Date: Wed, 31 Jul 1996 10:16:43 +0200 (MET DST)

> passed through the tunnel.  

I'm not experimenting currently with mbone on Linux but I'm reading the
patches. Maybe 2.0.10 would help:

diff -u --recursive --new-file v2.0.9/linux/net/ipv4/igmp.c linux/net/ipv4/igmp.c
--- v2.0.9/linux/net/ipv4/igmp.c        Mon May 13 12:15:24 1996
+++ linux/net/ipv4/igmp.c       Sat Jul 27 11:25:24 1996
@@ -56,6 +56,11 @@
  *             Christian Daudt :       igmp_heard_report now only calls
  *                                     igmp_timer_expire if tm->running is
  *                                     true (960216).
+ *             Malcolm Beattie :       ttl comparison wrong in igmp_rcv made
+ *                                     igmp_heard_query never trigger. Expiry
+ *                                     miscalculation fixed in igmp_heard_query
+ *                                     and random() made to return unsigned to
+ *                                     prevent negative expiry times.

I'm not playing with multicasting now because just running mrouted
seems to saturate my 56k link. Does is really have to be so or it is
some configuration or Linux implementatin bug? What's the typical
volume of mbone mrouted-mrouted communication?

R.
-- 
Rafal Maszkowski [email-masked]           http://www.torun.pdi.net/~rzm
Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec

---

From: Malcolm Beattie <[email-masked]>
Date: Wed, 31 Jul 1996 10:57:01 +0100 (BST)

> +++ linux/net/ipv4/igmp.c       Sat Jul 27 11:25:24 1996

The patches from 2.0.9 -> 2.0.10 don't affect mrouted (which already
works, as I'll go into in a minute); they fix mbone applications
which used to timeout after 5 minutes. Linux didn't used to respond
to IGMP_HOST_MEMBERSHIP_QUERY requests properly so the nearest mrouted
would prune back each joined multicast group after 5 minutes.

Back to mrouted: I have it working happily now and I'm willing to help
others set it up. You need at least kernel 2.0.8 since there *were*
bugs with multicast routing before that. When you configure the kernel,
make sure that you answer "yes" to CONFIG_EXPERIMENTAL: that will
ensure that you're offered the other multicast routing questions.
Multicast routing was experimental in 2.0.0 but I hope that now it
seems to be stable, it'll be offered even without CONFIG_EXPERIMENTAL.
You also need to turn on the following
    CONFIG_IP_FORWARD
    CONFIG_IP_MULTICAST
    CONFIG_IP_MROUTE
and have CONFIG_IP_IP either linked into the kernel or as a module.

Once you are running such a kernel, you need to do
    # route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
(assuming eth0 is your primary interface).
If you compiled ipip as a module (CONFIG_IP_IP=m) then you also need
    # insmod ipip
Apart from that, it should just be a case of setting up
/etc/mrouted.conf and running mrouted, as usual.

The version of mrouted that I'm running is mrouted-3.8.1-linux.
I'm afraid I can't remember where I got it but I've made it
available at
    ftp://ftp.ox.ac.uk/pub/linux/mrouted-3.8.1-linux.tar.gz 
You'll need to rebuild it from scratch: it contains pre-built
old object files and binaries for a.out so do a thorough
"make clean" and remove the binaries from the bin directory.
You can either ignore or get rid of the special include-linux
directory and its include files and remove the
    MCAST_INCLUDE=        -Iinclude-linux
line from the Makefile. Linux 2.x has the de facto "standard"
multicast include files now and the only difference from the
include-linux ones is guard lines at top and bottom. If anyone
can point me at a newer source (I've heard 3.8.2 mentioned),
I'll build that and put together an RPM to simplify installation
for people.

> volume of mbone mrouted-mrouted communication?

I'd doubt that traffic over the tunnel has much to do with the
underlying kernel and the only Linux-specific parts of mrouted
are (1) because Linux raw IP packets are really raw and not the
partially chewed ones that BSD kernels give you and (2) Linux does
IGMP control requests on an IGMP socket instead of on a UDP socket
like BSD does.

--Malcolm

-- 
Malcolm Beattie <[email-masked]>
Unix Systems Programmer
Oxford University Computing Services

---

From: Bill Fenner <[email-masked]>
Date: Wed, 31 Jul 1996 07:51:58 PDT

In message <[email-masked]> yo
u write:
>only data

I glanced at the code for Linux 2.0.10, and it looks like packets getting
sent by the mrouter don't get sent to ipmr_forward().  The only calls to
ipmr_forward() are in ip_rcv(), which doesn't normally get called when
transmitting packets.

It's likely that ip_output.c needs to gain a call to ipmr_forward().

Just for kicks, add the following lines to your .vat.tcl and see if data
then starts getting forwarded.

proc user_hook {} {
        global V

	$V(net) loopback 1
	$V(ctrl-net) loopback 1
}

This will cause vat to set the IP_MULTICAST_LOOP option on both its sockets,
which will at least get the data to ipmr_forward().  I don't think it'll
help but there's probably some subtlety to the code that I'm missing.

  Bill

---

From: Nathan Kidd <[email-masked]>
Date: Thu, 1 Aug 1996 10:39:58 -0400 (EDT)

> then starts getting forwarded.

This does not appear to have any effect on multicast packets entering the
tunnel from the machine running the tunnel.  

Although both ends of the tunnel will indicate that a particular group is
joined, no data or user information is passed through the tunnel from that
machines running mrouted.  Other machines on the local net still pass
everything through the tunnel as expected.

> It's likely that ip_output.c needs to gain a call to ipmr_forward().

Has anyone worked on this problem, or can anyone give more specific
information as to where this call may need to be added?

Thanks.

Nathan Kidd