From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Lunn <andrew@lunn.ch>
Subject: Re: [Query]: DSA Understanding
Date: Thu, 9 Aug 2018 17:35:43 +0200
Message-ID: <20180809153543.GD20006@lunn.ch>
References: <20180726153906.GA10686@lunn.ch>
 <CA+V-a8uiaO3Z9fLeXvkfrm0Fvp=h7eBu3d9kQEuOQY7xwzAZHg@mail.gmail.com>
 <20180802144550.GE7462@lunn.ch>
 <CA+V-a8t=nMh19Ti4_m+otj8n3S5aFUMS=Xn7DLU6oJuPXFgpQQ@mail.gmail.com>
 <20180802160539.GL19257@lunn.ch>
 <CA+V-a8u0W4JA_HrorXZApFbAOBHiWdVpVK0DvSmcKftr5NrC8w@mail.gmail.com>
 <20180809120159.GA16359@lunn.ch>
 <CA+V-a8vAuigs9GTUa7AwRY8YR6ti9N90-RsChoDdRPxYMGWoWg@mail.gmail.com>
 <20180809125637.GC1813@lunn.ch>
 <CA+V-a8sEKfe+vRkxM7EKwH9h3HwLcW_k1Ygso2K3h5jY3TtaiA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: netdev <netdev@vger.kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from vps0.lunn.ch ([185.16.172.187]:60006 "EHLO vps0.lunn.ch"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1731065AbeHISBL (ORCPT <rfc822;netdev@vger.kernel.org>);
        Thu, 9 Aug 2018 14:01:11 -0400
Content-Disposition: inline
In-Reply-To: <CA+V-a8sEKfe+vRkxM7EKwH9h3HwLcW_k1Ygso2K3h5jY3TtaiA@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

> > > The received packets captured on the PC are MDNS and DHPC, these MDNS
> > > are causing the rx
> > > packet counter go up:
> >
> > And where are these packets coming from? The target device? Or some
> > other device on your network?
> >
> AFIK, MDNS is also kind of a bcast its sending MDNS requests and
> receiving itself,
> that’s the reason rx packets are incrementing (correct me if I am wrong)

Your Ethernet device should not be receiving its own
transmissions. Looping back for broadcast and multicast packets
happens higher up in the network stack.

Look at the source MAC address for these packets. Where are the coming
from?

> ~$ ethtool -S lan4
> NIC statistics:
...
>      tx_hi: 0
>      tx_late_col: 0
>      tx_pause: 0
>      tx_bcast: 749
>      tx_mcast: 212

This suggest the switch is putting packets onto the wire.

> Only weird thing I notice on target, when its replying for ping
> requests ( (oui Unknown) is that something which is causing issues ?

These are not ping requests. These are ARP requests/replies.

> 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28

c4:f3:12 is the OUI. It is actually registers to TI:

https://aruljohn.com/mac/C4F312

But tcpdump probably does not know this, or the build you have has the
oui table removed to keep the binary small.

    Andrew