Skip site navigation (1)Skip section navigation (2)
Date:      Fri,  1 Sep 2000 10:11:50 -0700 (PDT)
From:      Martin.Karsten@KOM.tu-darmstadt.de
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/20984: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON
Message-ID:  <20000901171150.8FC4D37B43C@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         20984
>Category:       kern
>Synopsis:       conflict between IP_RSVP_ON and IP_RSVP_VIF_ON
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 01 10:20:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Martin Karsten
>Release:        4.1
>Organization:
TU Darmstadt, Germany
>Environment:
FreeBSD m3i05.m3i.kom.e-technik.tu-darmstadt.de 4.1-RELEASE FreeBSD 4.1-RELEASE #2: Fri Sep  1 17:14:09 CEST 2000     root@m3i05.m3i.kom.e-technik.tu-darmstadt.de:/usr/src/sys/compile/KOM  i386
>Description:
When MROUTING is turned on, the code in function 'rsvp_input' in file
netinet/ip_mroute.c currently works as follows:
1) If an old-style global RSVP socket exists (IP_RSVP_ON), it is used to
deliver all RSVP packets to the user-level.
2) Only if such a socket doesn't exist, it is tested whether an
interface-specific socket (IP_RSVP_VIF_ON) exists for the incoming interface
and the packet is delivered.

I believe that this order is wrong in principle. If mrouted is running,
but only a subset of all interfaces are enabled as vifs, it is impossible
to use the new socket option (IP_RSVP_VIF_ON) on these interfaces, because
all packets are delivered to the old-style global socket.

Depending on the setting of IP_MULTICAST_LOOP, this leads to duplicate
RSVP packet receptions or, if IP_MULTICAST_LOOP is turned off, any socket
with IP_RSVP_VIF_ON is useless.

Realizing this, ISI's rsvpd closes the global RSVP socket (IP_RSVP_ON) as
soon as any multicast-vifs are detected through RSRR. However, this is an
error, because if an interface is disabled for mrouted, no (not even
unicast) RSVP packets can be received through that interface. The Fix below
does not affect this (however unsatisfying) behaviour of the ISI rsvpd.

>How-To-Repeat:
The current code is not an apparent bug, but the change is needed in order
to create an appropriately designed RSVP userland daemon. Ie, the daemon can
then open IP_RSVP_VIF_ON sockets for all vifs and a single IP_RSVP_ON socket
to receive packets from all other interfaces. This is beneficial, e.g. when
designing a multi-threaded RSVP daemon.

>Fix:
This problem can be solved by exchanging the order in which both steps are
executed. The following patch can be used for ip_mroute.c, although the code
(e.g. the log messages) should probably be cleaned up:

2147,2156d2146
<     /* If the old-style non-vif-associated socket is set, then use
<      * it and ignore the new ones.
<      */
<     if (ip_rsvpd != NULL) {
<       if (rsvpdebug)
<           printf("rsvp_input: Sending packet up old-style socket\n");
<       rip_input(m, off, proto);  /* xxx */
<       return;
<     }
<
2178,2180c2168
<       m_freem(m);
<       splx(s);
<       return;
---
>       goto try_generic_socket;
2191,2193c2179
<           m_freem(m);
<           splx(s);
<           return;
---
>           goto try_generic_socket;
2208a2195,2207
>     goto end;
>
> try_generic_socket:
>     /* If the old-style non-vif-associated socket is set, then use it */
>     if (ip_rsvpd != NULL) {
>       if (rsvpdebug)
>           printf("rsvp_input: Sending packet up old-style socket\n");
>       rip_input(m, off, proto);  /* xxx */
>     } else {
>       m_freem(m);
>     }
>
> end:


>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?20000901171150.8FC4D37B43C>