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

From: Johannes Berg
Date: Fri Mar 01 2019 - 03:32:45 EST

> 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
> txpower 30.00 dBm
> 1 $ iw phy phy0 interface add mon0 type monitor
> 1 $ iw phy phy0 interface add mon1 type monitor
> When we send (raw) packets on mon0 using packetspammer [1] and listen on
> the _other_ monitor mode interface mon1, we receive frames that were sent
> on the first one:
> 1 $ packetspammer mon0
> 2 $ tcpdump -i mon1 'wlan addr2 13:22:33:44:55:66'
> This is due to the fact that frames sent on mon0 are echoed back as TX
> status frames, because REQ_TX_STATUS is always set for frames sent from
> monitor mode interfaces.

Yes, I understand :-)

> But when we replace mon0 with an interface in managed mode (wlp1s0), the
> receipt of frames stops, because in managed mode REQ_TX_STATUS is cleared
> in most frames:
> 1 $ ifup wlp1s0
> 1 $ ping -I wlp1s0 # this address is not assigned to any host
> 2 $ tcpdump -i mon1 âwlan addr2 4c:5e:0c:11:43:acâ

Yes, also understand.

> > 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.
> What we propose is to use IFF_ECHO to force REQ_TX_STATUS being set for all
> frames sent on the interface. But you are right: The goal is that frames
> transmitted through the other interface show up on the monitor interface
> (but only after passing the driver). However, this is exactly how we
> understand the semantics of IFF_ECHO in the kernel documentation.

I disagree.

First of all, IFF_ECHO is only documented/used *inside* the kernel, and
cannot be set by userspace today. It's documented by CAN as such:


Local Loopback of Sent Frames

As described in :ref:`socketcan-local-loopback1` the CAN network
device driver should
support a local loopback functionality similar to the local echo
e.g. of tty devices. In this case the driver flag IFF_ECHO has to be
set to prevent the PF_CAN core from locally echoing sent frames
(aka loopback) as fallback solution::

dev->flags = (IFF_NOARP | IFF_ECHO);

Note that everything here is specific to a single interface.

Also note that it's a signal from the *driver* to the *stack* to not do
the loopback itself, because the driver will do it.

I think in the case of all other sockets/interfaces, the stack will do
the echo anyway, for tcpdump etc. purposes.

The documentation in the uapi just states:
@IFF_ECHO: echo sent packets. Volatile.
and makes no representation about which interface, but I'd argue that
all the flags are specific to a single interface and thus you'd expect
this to also be.

Thus, I don't think this was ever intended for any cross-interface
behaviour, even if it may be on the same physical NIC.

> As far as we know, drivers must return a TX status frame, if REQ_TX_STATUS
> is set, but can do whatever they want, if it is clear.

Not all drivers can and do this, I believe. Some things don't work very
well if they don't do it, but I _think_ you've just been lucky and used
hardware that does in fact support it.

Also note that for some hardware that does support this, there's
sometimes significant overhead - not just the performance overhead of
actually reporting the frames, but sometimes also overhead in how the
hardware is programmed and used, and how TX status is extracted.

> This is no problem for our
> functionality, because we force the delivery of TX status frames by
> permanently setting REQ_TX_STATUS. As long as the semantics of
> REQ_TX_STATUS remains like it is now, the functionality will always be
> as expected from our API.

Sure, for now, for your specific case of ath9k :-)

> We could also achieve the functionality by modifying the drivers but this
> would mean that we had to add this functionality to every driver.
> Moreover, the feature of TX status frames, how it is implemented currently
> for monitor mode interfaces, is part of the mac80211 implementation. The
> decision to force TX status frames for monitor mode interfaces is made in
> the common mac80211 implementation.

I suppose it could be in mac80211 (perhaps debugfs?) too. I just really
don't think IFF_ECHO is the right approach.