Date: Thu, 20 May 2004 21:00:52 +0800 From: Eugene Grosbein <eugen@grosbein.pp.ru> To: Ruslan Ermilov <ru@freebsd.org> Cc: net@freebsd.org Subject: [ANALISYS] Re: multicast arp entry Message-ID: <20040520130052.GA442@grosbein.pp.ru> In-Reply-To: <20040518105134.GC70919@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 18, 2004 at 01:51:34PM +0300, Ruslan Ermilov wrote:
> > got message of size 236 on Tue May 18 16:42:26 2004
> > RTM_ADD: Add Route: len 236, pid: 0, seq 0, errno 0,
> > flags:<UP,HOST,DONE,LLINFO,WASCLONED,MULTICAST>
> > locks: inits:
> > sockaddrs: <DST,GATEWAY,IFP,IFA>
> > 224.0.0.9 1.0.5e.0.0.9 em3:0.7.e9.1f.f1.de 172.20.2.75
> >
> > After that arp -an shows:
> > (224.0.0.9) at 01:00:5e:00:00:09 on em3 permanent [ethernet]
> >
> > Then tcpdump shows that multicast packets with source IP of interface em1
> > (those must be directed via em1) go out through em3. I run quagga/ripd
> > (same effect for zebra) on FreeBSD 4.9-STABLE.
> >
> > How do I find who installs this route?
> >
> The short answer is: the kernel adds it for you, automatically,
> just as it does this for you for normal unicast destinations.
>
> The long answer could be: you could join to a single multicast
> group on multiple interfaces, and you will be able to receive
> multicast on all of them, but if you don't have multicast
> forwarding enabled, only one interface will be used for sending.
> Which one gets used will be determined by a normal routing
> lookup, i.e., ``route -vn get -host 224.0.0.9'' where no entry
> yet exists. Then, when the actual packet gets delivered, the
> kernel will insert the corresponding ARP entry, mapping the
> multicast group address to a MAC address.
I've found that divert machanics is guilty in broken multicasts.
Here is the scenario.
1. ripd assignes an outgoing interface for the mulicast socket using
setsockopt (sock, IPPROTO_IP, IP_MULTICAST_IF, (void *)&m, sizeof(m));
2. ripd runs:
memset (&mreq, 0, sizeof(mreq));
mreq.imr_multiaddr.s_addr = mcast_addr;
mreq.imr_interface = if_addr; /* (1) */
setsockopt (sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *)&mreq,
sizeof(mreq));
This leads to
igmp_joingroup(inm) and igmp_sendpkt(inm, inm->inm_rti->rti_type, 0),
here inm->inm_ifp is filled with the contents of imo.imo_multicast_ifp,
that is if_addr from (1). Still good.
3. Now we enter ip_output() keeping imo as one of arguments.
There we run the following code:
else if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) &&
imo != NULL && imo->imo_multicast_ifp != NULL) {
/*
* Bypass the normal routing lookup for multicast
* packets if the interface is specified.
*/
ifp = imo->imo_multicast_ifp;
IFP_TO_IA(ifp, ia);
isbroadcast = 0; /* fool gcc */
}
It's allright still.
4. When ipfw diverts our packet, we call
/* Deliver packet to divert input routine */
divert_packet(m, 0, off & 0xffff, args.divert_rule);
Ops, imo is not passed by! So our imo->imo_multicast_ifp is lost
and diverted packet will not be sent through it but routing lookup
will be performed.
Should I fill the PR?
Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040520130052.GA442>