> On 01.03.2019 09:32, Johannes Berg wrote:
>
> Thus, I don't think this was ever intended for any cross-interface
> behaviour, even if it may be on the same physical NIC.
Now we got your point. We are sorry for the confusion - it seems we
understood that wrong.
> Not all drivers can and do t
> Let us briefly describe our test setup to ensure everyone on this mailing
> list is one the same page.
>
> Our general setup looks like this:
> 1 $ iw wlp1s0 info
> Interface wlp1s0
> ifindex 5
> wdev 0x1
> addr 4c:5e:0c:11:43:ac
> type managed
> wiphy 0
> txp
> On 26.02.2019 14:33 Johannes Berg wrote
>
> 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 r
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 pac
Hi Oliver,
> On 26.02.2019 12:04, Oliver Hartkopp wrote:
>
> Hi Julius,
>
(..)
>
> The reason for IFF_ECHO was, that the data frame which is sent onto the wire
> (by one application) is not visible to all the other applications on the same
> (local) host. Therefore a successful transmission o
Hi Julius,
On 26.02.19 10:40, Julius Niedworok wrote:
In order to force delivery of TX status frames for research and debugging
purposes, implement the IFF_ECHO flag for ieee80211 devices. When this flag
is set for a specific interface, IEEE80211_TX_CTL_REQ_TX_STATUS is enabled
in all packets s
At Technical University of Munich we use MAC 802.11 TX status frames to
perform several measurements in MAC 802.11 setups.
With ath based drivers this was possible until commit d94a461d7a7df6
("ath9k: use ieee80211_tx_status_noskb where possible") as the driver
ignored the IEEE80211_TX_CTL_REQ_TX_
