netdev - Re: r8169 driver fails to see IGMPv2 SAP announcements

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OF47F0798E.811EA708-ON88257412.0070C381-88257412.00724DBB@us.ibm.com>
Date:	Thu, 20 Mar 2008 13:48:33 -0700
From:	David Stevens <dlstevens@...ibm.com>
To:	Glen Gray <glen.gray@...cor.com>
Cc:	netdev@...r.kernel.org, netdev-owner@...r.kernel.org,
	Francois Romieu <romieu@...zoreil.com>
Subject: Re: r8169 driver fails to see IGMPv2 SAP announcements

Hi, Glen,
        From your detailed description, and particularly the fact
that the problem seems to be tied to the driver & device, I think
I'd recommend looking at the multicast address filter code in the
driver. IGMP is not device dependent, so I doubt that is the
source of the problem.
        If you can reproduce the problem, then while it's
happening:

1) catch the group memberships by saving /proc/net/igmp
2) catch the hardware group memberships by saving
        /proc/net/dev_mcast
[I expect from the symptoms that 1) is ok, 2) may or may not be...]
and...
3) run tcpdump or wireshark in promiscuous mode
        - if the device address filter is the problem, when you
        put the device in promiscuous mode, everything will
        start working again, until you exit tcpdump. You will
        also see the packets you aren't receiving are being
        sent, if that's the problem.

I understand you probably can't directly reproduce it, and
the visual artifacts you mentioned in that one test may or
may not be the same issue as the other one.

Another possibility that comes to mind is a memory leak,
if the response problems are related to a low memory
condition. So, that might be something else to look for.
Compare memory usage with ordinary usage, check
for log messages of allocation failures and check "netstat -s"
output for any indication of drops.

If you can set a program or script to monitor the system
and detect when you hit the problem, then you could use
that to trigger running a script that captures the data you
need when it happens.

                                        +-DLS

--
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