Re: Missing IPv6 ICMPv6 Neighbor Solicitation with

[Guy Harris <guy () alum mit edu>]

On Feb 23, 2012, at 5:58 PM, Michael Richardson wrote:

> > > > > > "Paul" == Paul Sheer <paulsheer () gmail com> writes:
>    Paul> Actually I found the answer to this, as below.
>
>    Paul> Would anyone consider adding this support to libpcap: i.e. a
>    Paul> new member within pcap_opt ?
>
> I think that it should probably just be on.
> Principal of least surprise.

Here's why PACKET_MR_ALLMULTI is currently *not* turned on:

        https://sourceforge.net/tracker/?func=detail&aid=599857&group_id=53067&atid=469577

> On Redhat Linux 7.3 with:
> kernel-2.4.18-10
> ethereal-0.9.4-0.7.3.0
> tcpdump-3.6.2-12
> libpcap-0.6.2-12
> (and the same behavior observed also with
> tcpdump-3.7.1/libpcap-0.7.1).
> The interface in question, eth1, is a Linksys WMP11 wireless PCI card, using the orinoco_pci driver.
> The default route is to a Cisco 340 wireless access point.
>
> I have two problems:
> (1) While tracing using tcpdump or ethereal (regardless of whether in promiscuous mode or not), pings through the 
> router fail with ICMP "Destination Host Unreachable" (apperently from the local host, not the router)
> (2) After the trace is finished, if the trace did *not* use promiscuous mode, pings through the router still fail.
>
> To get the interface out of the bad state of (2), I do either of the following:
> ifconfig eth1 promisc; ifconfig eth1 -promisc
> or:
> tcpdump -n -i eth1 (and then end it, with ^C)
> (note that starting and ending "tcpdump -p -n -i eth1" does *not* fix it).
>
> Running the debugger on tcpdump, I found out that the call in libpcap which causes the pings through the router to 
> stop working is:
> setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP, &{ mr_ifindex = device_id, mr_type = promisc ? 
> PACKET_MR_PROMISC : PACKET_MR_ALLMULTI })

My followup comment was

> To quote the comment in "__orinoco_set_multicast_list()" in the 0.13c version of the Orinoco driver at
>
> http://ozlabs.org/people/dgibson/dldwd/
>
> "The Hermes doesn't seem to have an allmulti mode, so we go into promiscuous mode and let the upper levels deal."
>
> Bleah.
>
> I'm inclined to just yank out the PACKET_MR_ALLMULTI, given that, as far as I know, doing non-promiscuous captures on 
> a networking device doesn't muck with the set of multicast packets it receives.

So maybe it *does* muck with that set.

The section of code in question in the 0.13c driver is

        /* The Hermes doesn't seem to have an allmulti mode, so we go
         * into promiscuous mode and let the upper levels deal. */
        if ( (dev->flags & IFF_PROMISC) || (dev->flags & IFF_ALLMULTI) ||
             (dev->mc_count > MAX_MULTICAST(priv)) ) {
                promisc = 1;
                mc_count = 0;
        } else {
                promisc = 0;
                mc_count = dev->mc_count;
        }

        if (promisc != priv->promiscuous) {
                err = hermes_write_wordrec(hw, USER_BAP,
                                           HERMES_RID_CNFPROMISCUOUSMODE,
                                           promisc);
                if (err) {
                        printk(KERN_ERR "%s: Error %d setting PROMISCUOUSMODE to 1.\n",
                               dev->name, err);
                } else 
                        priv->promiscuous = promisc;
        }

At one point while searching around on the Intertubes I thought I'd found a version of the driver that actually treated 
allmulti differently by turning some allmulti mode on, but I can't find it any more.

So perhaps the right thing to do here is to just say "if you have a wireless adapter with the Hermes chipset and the 
firmware in question, you will get our sympathy, but you won't get our support", and go back to turning 
PACKET_MR_ALLMULTI on in non-promiscuous mode (and hope that either the behavior Don Hatch found was the result of a 
bug somewhere in Linux that has subsequently been fixed or that this is a quirk with some older network cards and 
doesn't show up with newer network cards).

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.