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
