[ECOS] Re: Why does sending multicast UDP require a gateway?

Gary Thomas gary@mlbassoc.com
Wed Mar 30 14:24:00 GMT 2011


On 03/29/2011 05:09 PM, Grant Edwards wrote:
> On 2011-03-29, Grant Edwards<grant.b.edwards@gmail.com>  wrote:
>
>> Somebody I work with has spent the last three days trying to send UDP
>> multicast packets using eCos and the FreeBSD network stack.
>
> AFAICT, the FreeBSD stack will refuse to send a UDP multicast packet
> unless it can find a valid route to the multicast destination IP
> address with that IP _treated_as_a_unicast_address_.
>
> The broken code is in sys/netinet/ip_output.c, and the error is
> asserted at line 269:
>
>     123	ip_output(m0, opt, ro, flags, imo)
> [...]
>     239	        /*
>     240	         * If routing to interface only,
>     241	         * short circuit routing lookup.
>     242	         */
>     243	#define ifatoia(ifa)    ((struct in_ifaddr *)(ifa))
>     244	#define sintosa(sin)    ((struct sockaddr *)(sin))
>     245	        if (flags&  IP_ROUTETOIF) {
>     246	                if ((ia = ifatoia(ifa_ifwithdstaddr(sintosa(dst)))) == 0&&
>     247	                    (ia = ifatoia(ifa_ifwithnet(sintosa(dst)))) == 0) {
>     248	                        ipstat.ips_noroute++;
>     249	                        error = ENETUNREACH;
>     250	                        goto bad;
>     251	                }
>     252	                ifp = ia->ia_ifp;
>     253	                ip->ip_ttl = 1;
>     254	                isbroadcast = in_broadcast(dst->sin_addr, ifp);
>     255	        } else {
>     256	                /*
>     257	                 * If this is the case, we probably don't want to allocate
>     258	                 * a protocol-cloned route since we didn't get one from the
>     259	                 * ULP.  This lets TCP do its thing, while not burdening
>     260	                 * forwarding or ICMP with the overhead of cloning a route.
>     261	                 * Of course, we still want to do any cloning requested by
>     262	                 * the link layer, as this is probably required in all cases
>     263	                 * for correct operation (as it is for ARP).
>     264	                 */
>     265	                if (ro->ro_rt == 0)
>     266	                        rtalloc_ign(ro, RTF_PRCLONING);
>     267	                if (ro->ro_rt == 0) {
>     268	                        ipstat.ips_noroute++;
>     269	                        error = EHOSTUNREACH;
>     270	                        goto bad;
>     271	                }
>     272	                ia = ifatoia(ro->ro_rt->rt_ifa);
>     273	                ifp = ro->ro_rt->rt_ifp;
>     274	                ro->ro_rt->rt_use++;
>     275	                if (ro->ro_rt->rt_flags&  RTF_GATEWAY)
>     276	                        dst = (struct sockaddr_in *)ro->ro_rt->rt_gateway;
>     277	                if (ro->ro_rt->rt_flags&  RTF_HOST)
>     278	                        isbroadcast = (ro->ro_rt->rt_flags&  RTF_BROADCAST);
>     279	                else
>     280	                        isbroadcast = in_broadcast(dst->sin_addr, ifp);
>     281	        }
>     282	        if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) {
>     283	                struct in_multi *inm;
>     284	
>     285	                m->m_flags |= M_MCAST;
>     286	                /*
>     287	                 * IP destination address is multicast.  Make sure "dst"
>     288	                 * still points to the address in "ro".  (It may have been
>     289	                 * changed to point to a gateway address, above.)
>     290	                 */
>
> As you can see, the output code rejects the packet for lack of a valid
> route to the destination IP address before it checks to see if it's a
> multicast IP address.
>
> That doesn't look right to me...
>
> If it's a multicast destination, shouldn't that short-circuit the
> route-checking stuff?
>
> The docs I can find are pretty clear: if it's a multicast IP
> destination you ship it out to the corresponding multicast MAC
> address. Period. No messing about with routes and gateway addresses.

I agree that this doesn't seem right.  You might try looking at the
current BSD networking code to see if this has changed since I merged
the stack last - some *ten* years ago :-)

If you find a fix/work-around, send a patch!

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list