Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx_status frames

From: Johannes Berg <johannes@sipsolutions.net>
To: Julius Niedworok <julius.n@gmx.net>,
	Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-wireless@vger.kernel.org, ga58taw@mytum.de,
	David Hildenbrand <david@redhat.com>,
	nc@net.in.tum.de, "David S. Miller" <davem@davemloft.net>,
	Edward Cree <ecree@solarflare.com>,
	Jiri Pirko <jiri@mellanox.com>,
	Ido Schimmel <idosch@mellanox.com>,
	Petr Machata <petrm@mellanox.com>,
	Kirill Tkhai <ktkhai@virtuozzo.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Amritha Nambiar <amritha.nambiar@intel.com>,
	Li RongQing <lirongqing@baidu.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx_status frames
Date: Tue, 26 Feb 2019 14:33:07 +0100	[thread overview]
Message-ID: <550ff2ac45c891a3fcf3dd8a454f9732d8aa1b70.camel@sipsolutions.net> (raw)
In-Reply-To: <6A213CBE-0B6A-466A-B721-E6A728D4888D@gmx.net> (sfid-20190226_141427_875178_50C975AD)

On Tue, 2019-02-26 at 14:13 +0100, Julius Niedworok wrote:
> 
> Thank you for the explanation - I can adjust the comment, if you like to.
> 
> > So what are you getting back after you enabled IFF_ECHO on your mac80211 device?
> > 
> > Is it just a 'status' about a sent packet, or is it the packet ('full content') itself?
> 
> We are actually getting back the full content of the packet. So it
> matches the behaviour of the 'echo' in CAN.

I don't think it does, really.

In CAN, if I understand correctly, this is used for regular operation
interfaces, where you might want to run 'tcpdump', on wifi the
equivalent would be 'tcpdump -i wlan0'. This *already* implements full
visibility of outgoing and incoming frames.

Not sure how CAN even manages *not to*, but I don't really need to care
:-)

You're proposing to add this to the *monitor* interfaces and you really
should have made the flag conditional on that to make that clear.

However, even on monitor interfaces, you typically *already* see the
frames you transmitted there (as raw frames, which is the only thing you
can do).

What you're proposing is to use IFF_ECHO to show frames transmitted
through *other* interfaces on the monitor interface.

I don't think the IFF_ECHO semantics really match this.

Additionally, drivers are sort of free to ignore the REQ_TX_STATUS, or
we could in the future add ways of using the _noskb to feed back TX
status to the state machines where needed, so I'm not really sure I even
_want_ this to be set in stone in such an API.

Now, I can also see how this can be useful for debugging, but it feels
to me like this should be a driver (debug) option?

johannes