public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "Jakub Kicinski" <kuba@kernel.org>,
	"Markus Blöchl" <markus.bloechl@ipetronik.com>,
	"Ido Schimmel" <idosch@idosch.org>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Alexander Duyck" <alexander.duyck@gmail.com>,
	"Woojung Huh" <woojung.huh@microchip.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Microchip Linux Driver Support" <UNGLinuxDriver@microchip.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net] net: lan78xx: Disable hardware vlan filtering in promiscuous mode
Date: Wed, 11 Nov 2020 19:14:16 +0200	[thread overview]
Message-ID: <20201111171416.ns4lysezemurdipo@skbuf> (raw)
In-Reply-To: <20201111164727.pqecvbnhk4qgantt@skbuf>

On Wed, Nov 11, 2020 at 06:47:27PM +0200, Vladimir Oltean wrote:
> On Wed, Nov 11, 2020 at 07:56:58AM -0800, Florian Fainelli wrote:
> > The semantics of promiscuous are pretty clear though, and if you have a
> > NIC with VLAN filtering capability which could prevent the stack from
> > seeing *all* packets, that would be considered a bug. I suppose that you
> > could not disable VLAN filtering but instead install all 4096 - N VLANs
> > (N being currently used) into the filter to guarantee receiving those
> > VLAN tagged frames?
> 
> Are they?
> 
> IEEE 802.3 clause 30.3.1.1.16 aPromiscuousStatus says:
> 
> APPROPRIATE SYNTAX:
> BOOLEAN
> 
> BEHAVIOUR DEFINED AS:
> A GET operation returns the value “true” for promiscuous mode enabled, and “false” otherwise.
> 
> Frames without errors received solely because this attribute has the value “true” are counted as
> frames received correctly; frames received in this mode that do contain errors update the
> appropriate error counters.
> 
> A SET operation to the value “true” provides a means to cause the LayerMgmtRecognizeAddress
> function to accept frames regardless of their destination address.
> 
> A SET operation to the value “false” causes the MAC sublayer to return to the normal operation
> of carrying out address recognition procedures for station, broadcast, and multicast group
> addresses (LayerMgmtRecognizeAddress function).;
> 
> 
> As for IEEE 802.1Q, there's nothing about promiscuity in the context of
> VLAN there.
> 
> Sadly, I think promiscuity refers only to address recognition for the
> purpose of packet termination. I cannot find any reference to VLAN in
> the context of promiscuity, or, for that matter, I cannot find any
> reference coming from a standards body that promiscuity would mean
> "accept all packets".

I realize I did not tell you what the LayerMgmtRecognizeAddress function
does.

function LayerMgmtRecognizeAddress(address: AddressValue): Boolean;
begin
	if {promiscuous receive enabled} then LayerMgmtRecognizeAddress := true;
	if address = ... {MAC station address} then LayerMgmtRecognizeAddress := true;
	if address = ... {Broadcast address} then LayerMgmtRecognizeAddress := true;
	if address = ... {One of the addresses on the multicast list and multicast reception is enabled} then LayerMgmtRecognizeAddress := true;
	LayerMgmtRecognizeAddress := false
end; {LayerMgmtRecognizeAddress}

Markus complained about the tcpdump program in particular. Well, tcpdump
is a complex beast, and far too often, people seem to conflate tcpdump
with promiscuity, even though:
- promiscuity is not what enables tcpdump to see "all packets" being
  sent/received by the network stack on that interface, but ETH_P_ALL
  sockets are what do the magic there
- tcpdump also has a --no-promiscuous-mode option.

I would expect that tcpdump could gain a feature to disable (even if
temporarily) the rx-vlan-filter offload, through an ethtool netlink
message. Then users could get what they expect.

  reply	other threads:[~2020-11-11 17:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 15:39 [PATCH net] net: lan78xx: Disable hardware vlan filtering in promiscuous mode Markus Blöchl
2020-11-11  3:13 ` Jakub Kicinski
2020-11-11 15:43 ` Jakub Kicinski
2020-11-11 15:56   ` Florian Fainelli
2020-11-11 16:47     ` Vladimir Oltean
2020-11-11 17:14       ` Vladimir Oltean [this message]
2020-11-12 10:53       ` Markus Blöchl
2020-11-14 18:11         ` Vladimir Oltean
2020-11-19 15:37           ` Markus Blöchl
2020-11-19 16:28             ` Vladimir Oltean
2020-11-19 17:31             ` Jakub Kicinski
2020-11-11 18:02   ` Ido Schimmel
2020-11-12 22:52   ` Alexander Duyck
2020-11-13  0:44   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201111171416.ns4lysezemurdipo@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexander.duyck@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=markus.bloechl@ipetronik.com \
    --cc=netdev@vger.kernel.org \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox