> >       if that interface happens to be in promiscuous mode (running
> >       tcpdump, or...), multicasts sent by mrouted will be heard by
> >       mrouted, even though IP_MULTICAST_LOOP is disabled.

> This is a violation of RFC1112; section 7.3 says
>  
>    The local network module must not deliver up any multicast packets
>    that were transmitted from that module; loopback of multicasts is
>    handled at the IP layer or higher.

Hmm. That seems clear enough.

> It seems odd that this happens only in promiscuous mode.  Does this
> mean that *all* packets that the card transmits are recieved by it
> when in promiscuous mode?  Just multicasts/broadcasts?  If you put
> the card in promiscuous mode, does tcpdump print every packet this
> host sources twice?

I must admit to being somewhat confused by its behavior.

In non-promiscuous mode I see no duplicates, pinging either multicast
or broadcast or any such things.

In promiscuous mode (confirmed by ifconfig and caused by running tcpdump),
using ping as a test application:

unicast:			one copy of each (normal)
broadcast:			lots of answers, still only one copy. No
				reply from self.
random multicast group (ttl 1):	One copy of request, no response
joined multicast group (ttl 1):	One copy of request, 2 copies of response,
				both ostensibly from self:

In the last case, I joined the group with mtest, and then:

[lola-granola!jhawk] ~> ping 224.1.2.3
PING 224.1.2.3 (224.1.2.3): 56 data bytes
64 bytes from 18.70.0.26: icmp_seq=0 ttl=255 time=1.056 ms
64 bytes from 18.70.0.26: icmp_seq=0 ttl=255 time=2.296 ms (DUP!)
64 bytes from 18.70.0.26: icmp_seq=1 ttl=255 time=0.908 ms
64 bytes from 18.70.0.26: icmp_seq=1 ttl=255 time=7.430 ms (DUP!)

tcpdump on the ethernet interface showed only the requests:

[lola-granola!jhawk] /var/tmp> tcpdump -v -n -i fe0 icmp and host 18.70.0.26
tcpdump: listening on fe0
20:24:45.763594 18.70.0.26 > 224.1.2.3: icmp: echo request [ttl 1] (id 26936)
20:24:46.756880 18.70.0.26 > 224.1.2.3: icmp: echo request [ttl 1] (id 26938)

tcpdump on the loopback (lo0) showed nothing at all.

I'm not sure what this means...

> Why does the card recieve its own multicasts when in promiscuous
> mode but not normally?  The packet should pass the multicast filter
> even when not in promiscuous mode, so if the card simply receives
> all traffic that it sends, this behaviour should be apparent in both
> promiscuous and normal operation.

> Could this be a driver oddity, or is this very strange hardware?

I'm not sure if I'm qualified to comment. In fe_setmode() (called by
ioctl() for either SIOCIFFLAGS, SIOCADDMULTI or SIOCDELMULTI), the
following fragment exists:

        /*
         * Promiscuous mode is handled separately.
         */
        if ((flags & IFF_PROMISC) != 0) {
                /*
                 * Program 86960 to receive all packets on the segment
                 * including those directed to other stations.
                 * Multicast filter stored in MARs are ignored
                 * under this setting, so we don't need to update it.
                 *
                 * Promiscuous mode in FreeBSD 2 is used solely by
                 * BPF, and BPF only listens to valid (no error) packets.
                 * So, we ignore errornous ones even in this mode.
                 * (Older versions of fe driver mistook the point.)
                 */
                outb(sc->sc_iobase + FE_DLCR5,
                    sc->proto_dlcr5 | FE_D5_AFM0 | FE_D5_AFM1);
                sc->filter_change = 0;

AFM0 and 1 are just defined as:

/* DLCR5 -- receiver operation mode */
#define FE_D5_AFM0      0x01    /* Receive packets for other stations   */
#define FE_D5_AFM1      0x02    /* Receive packets for this station     */

There does seem to be:

/* Buffer Memory Port Registers.  On register back #2.  */
#define FE_BMPR14       14
/* BMPR14 -- More receiver control and more transmission interrupts */
#define FE_B14_FILTER   0x01    /* Filter out self-originated packets   */


I'm not sure of the wisdom of turning it on, but I guess I'll give
it a shot and see what happens.

--jhawk@mit.edu.
  John Hawkinson