netdev - Re: Packet capture and Bonding asymmetries

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: <20100610121012.GB11110@cel.leo>
Date:	Thu, 10 Jun 2010 13:10:12 +0100
From:	Paul LeoNerd Evans <leonerd@...nerd.org.uk>
To:	Jay Vosburgh <fubar@...ibm.com>, netdev@...r.kernel.org
Subject: Re: Packet capture and Bonding asymmetries

On Wed, Jun 09, 2010 at 03:52:31PM -0700, Jay Vosburgh wrote:
> >I believe this should be fixable with a one-line patch; just adding a
> >call to netif_nit_deliver(skb) from within the bonding driver... though
> >just offhand I'm unable to find exactly the line where packets received
> >on slaves gets passed up to the master. :)
> 
> 	This won't work, because bonding does not have a receive
> function in the usual sense.  Instead, the slaves do their normal
> receive logic, and then in __netif_receive_skb, packets are assigned to
> the bonding master if the device is a slave.

Ah; that would explain why I'm having trouble finding it then :)

> 	For your own private testing, you could add a call to
> __netif_nit_deliver in netif_receive_skb prior to this part:
<snip>

Rather than put it -before- that part, why not inside the if (master)
arm?

-----

diff -urp linux-2.6.33.2.orig/net/core/dev.c linux-2.6.33.2/net/core/dev.c
--- linux-2.6.33.2.orig/net/core/dev.c  2010-04-02 00:02:33.000000000 +0100
+++ linux-2.6.33.2/net/core/dev.c       2010-06-10 12:58:24.000000000 +0100
@@ -2443,6 +2443,7 @@ int netif_receive_skb(struct sk_buff *sk
        orig_dev = skb->dev;
        master = ACCESS_ONCE(orig_dev->master);
        if (master) {
+               netif_nit_deliver(skb);
                if (skb_bond_should_drop(skb, master))
                        null_or_orig = orig_dev; /* deliver only exact match */
                else

-----

(This patch doesn't quite apply cleanly to latest source but if that
approach seems OK I'll rebuild it and submit properly)

> 	This will give you multiple captures of the same packet, as is
> seen for transmit (i.e., one on the slave, one on the bond).  For
> non-bonding devices, tcpdump will see each packet twice on the same
> device, so it's not really suitable for general use.

I was hoping for a proper permanent solution - often it would have been
useful to me, that eth0 appears to receive traffic properly to tcpdump
et.al., as well as transmitting.

> 	If merely knowing the traffic counts is sufficient, the slaves
> do count their received packets individually, so, e.g., ifconfig will
> show how many packets a particular slave has received, regardless of
> what bonding does with them.  The packet counts for the bonding device
> itself are merely a sum of all of its slaves.

I had noticed the counters, yes. That has been useful on occasions. But
at other times we've really wanted to be able to see the actual traffic.

> 	Also, generally speaking, IP protocol traffic that arrives on an
> inactive bonding slave is not delivered.  If you're using active-backup
> mode, and your traffic makes it through, it likely arrived on the active
> slave.

Useful though that is, sometimes it's the fact that traffic appears on a
non-active slave, which is interesting, and we'd like to see what
traffic that was.

-- 
Paul "LeoNerd" Evans

leonerd@...nerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)