linux-kernel - Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx

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: <550ff2ac45c891a3fcf3dd8a454f9732d8aa1b70.camel@sipsolutions.net>
Date:   Tue, 26 Feb 2019 14:33:07 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Julius Niedworok <julius.n@....net>,
        Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     linux-wireless@...r.kernel.org, ga58taw@...um.de,
        David Hildenbrand <david@...hat.com>, nc@....in.tum.de,
        "David S. Miller" <davem@...emloft.net>,
        Edward Cree <ecree@...arflare.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Petr Machata <petrm@...lanox.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Amritha Nambiar <amritha.nambiar@...el.com>,
        Li RongQing <lirongqing@...du.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of
 tx_status frames

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