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.

quoted

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