lkml.org 
[lkml]   [2019]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx_status frames
    From
    Date
    > 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 192.168.254.1 # 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:

    Documentation/networking/can.rst:

    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.

    johannes

    \
     
     \ /
      Last update: 2019-03-01 09:33    [W:8.821 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site