This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Why does sending multicast UDP require a gateway?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]