Date: Thu, 15 Jul 1999 01:19:04 -0700 (PDT) From: kbracey@acorn.co.uk To: freebsd-gnats-submit@freebsd.org Subject: kern/12646: IGMP reports not sent if no multicast route Message-ID: <19990715081904.BE4C5154FC@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 12646
>Category: kern
>Synopsis: IGMP reports not sent if no multicast route
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jul 15 01:20:00 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator: Kevin Bracey
>Release: A mixture from 1996 to -current.
>Organization:
Pace Micro Technology
>Environment:
The software is an Internet module in an embedded system, based on
the network code from FreeBSD. The various components are of differing
vintages - each source file is generally a 1996 version with somewhere between
25% and 100% of the changes to -current applied.
>Description:
I've just stumbled across a bug in ip_output() while testing a multicast
TFTP client on a system with a FreeBSD-derived network stack.
The system has no default route or route for 224.0.0.0 set up. It is not
sending any multicasts, except for the IGMP reports generated by its group
joins, so it shouldn't need one.
The problem is that ip_output() will not output multicast packets if
it can't find a route for the destination IP address, even if the caller
has provided an interface in the multicast options, as igmp_sendpkt() does.
The same problem would arise a user process wanted to multicast on an
interface specified by IP_MULTICAST_IF.
And when you do have a route, various stats to do with that route
end up being incremented and examined, even though that route
ends up not being used!
I realise that in a normal FreeBSD system one would have a multicast
or default route set up, so the IGMP messages would get out, but it
strikes me that this is just covering up a kernel problem. You shouldn't
need a route to multicast on a manually named interface.
>How-To-Repeat:
Remove any default route and any route for 224.0.0.0/4. Check
that this has worked by pinging 224.0.0.1 - you should get a
"No route to host" error. Run a program that joins a multicast group.
No IGMP report will be sent (check with tcpdump). netstat will say
that the report was sent, but in reality it will have fallen foul of
"output packets discarded due to no route".
>Fix:
A quick fix would appear to be the following. Not terribly elegant, but
I think it works.
line 214 or so of ip_output.c:
ifp = ia->ia_ifp;
ip->ip_ttl = 1;
isbroadcast = in_broadcast(dst->sin_addr, ifp);
! } else {
/*
* If this is the case, we probably don't want to allocate
* a protocol-cloned route since we didn't get one from the
change to:
ifp = ia->ia_ifp;
ip->ip_ttl = 1;
isbroadcast = in_broadcast(dst->sin_addr, ifp);
! } else if (!(imo && imo->imo_multicast_ifp &&
! IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) {
/*
* If this is the case, we probably don't want to allocate
* a protocol-cloned route since we didn't get one from the
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990715081904.BE4C5154FC>