netdev - Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <6A213CBE-0B6A-466A-B721-E6A728D4888D@gmx.net>
Date:   Tue, 26 Feb 2019 14:13:51 +0100
From:   Julius Niedworok <julius.n@....net>
To:     Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     linux-wireless@...r.kernel.org, ga58taw@...um.de,
        David Hildenbrand <david@...hat.com>, nc@....in.tum.de,
        "David S. Miller" <davem@...emloft.net>,
        Johannes Berg <johannes@...solutions.net>,
        Edward Cree <ecree@...arflare.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Petr Machata <petrm@...lanox.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Amritha Nambiar <amritha.nambiar@...el.com>,
        Li RongQing <lirongqing@...du.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] mac80211: Use IFF_ECHO to force delivery of tx_status
 frames

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 on the wire triggers the 'echo' of the sent content into the local host.
> 

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.

> 
> Regards,
> Oliver
> 


Many thanks,
Julius