Subject: Re: bin/1316: excessive mrouted syslogs on duplex promisc ifaces
To: None <fenner@parc.xerox.com>
From: John Hawkinson <jhawk@mit.edu>
List: netbsd-bugs
Date: 08/06/1995 20:53:01
> > 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