lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <91bdcedb0903181851v2b3190bekb832df227910e844@mail.gmail.com>
Date:	Wed, 18 Mar 2009 20:51:03 -0500
From:	Dave Boutcher <daveboutcher@...il.com>
To:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
Cc:	Eric Dumazet <dada1@...mosbay.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	e1000-devel@...ts.sourceforge.net
Subject: Re: IGMP Join dropping multicast packets

On Wed, Mar 18, 2009 at 12:24 PM, Brandeburg, Jesse
<jesse.brandeburg@...el.com> wrote:
>
> On Tue, 17 Mar 2009, Dave Boutcher wrote:
> > Eric, based on your inability to recreate this, I tried on some other
> > hardware I had lying around that has an AMD chipset built-in NIC.
> > I could not recreate the problem on that hardware.  I'm starting to
> > think this is an e1000 problem.  In both the e1000 and e1000e
> > drivers they do the following logic:
> >
> >       /* clear the old settings from the multicast hash table */
> >
> >        for (i = 0; i < mta_reg_count; i++) {
> >                E1000_WRITE_REG_ARRAY(hw, MTA, i, 0);
> >                E1000_WRITE_FLUSH();
> >        }
> >
> >        /* load any remaining addresses into the hash table */
> >
> >        for (; mc_ptr; mc_ptr = mc_ptr->next) {
> >                hash_value = e1000_hash_mc_addr(hw, mc_ptr->da_addr);
> >                e1000_mta_set(hw, hash_value);
> >        }
> >
> > There's clearly a window where the NIC doesn't have the multicast
> > addresses loaded.  This may just be broken-as-designed.  If anyone
> > else happens to have some e1000 hardware and wants to see if you
> > can recreate this, I'd be curious.
> >
> > Some other notes just FYI...
> >
> > - RcvbufErrors in /proc/net/snmp doesn't get incremented when this happens
> > - there are no messages in dmesg
> > - frames get dropped when the program calls exit() and all the sockets
> > get closed
> >   (and multicast joins dropped) as well as when the ADD_MEMBERSHIPs happen
> > - The problem happens even when adding a sleep(1) in between each of the
> >   ADD_MEMBERSHIP calls.
>
> Interesting, this code has been there for eons (and probably this
> behavior) but that doesn't mean its not a problem.

Hi Jesse, thanks for the response...

If you go back in this thread I had a dead easy unprivileged user-land testcase
that causes frame loss.  We ran into this in a production environment
(and I kind
of glossed over how long it took to figure out why the hell we were dropping
frames...you can only increase rmem_max so many times ;-)  OTOH not that many
people use multicast, and even fewer notice a few dropped frames, so the
priority is probably lowish.

On the other other hand, I'm working in the financial trading space these days,
where Linux is pretty much king....and they're all about multicast.

--
Dave B
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ