From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: Radiotap header for S1G captures and associated changes and other definitions Date: Tue, 09 Apr 2019 10:58:58 +0200 Message-ID: <6141d4a8b8422b0e7e06b1457bd9a46fae37a5c2.camel@sipsolutions.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org List-Unsubscribe: To: Richard Sharpe , radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org, Ray Wang , Tasheng Lin , "Aaron J. Lee" List-Id: radiotap@radiotap.org Archived-At: List-Archive: List-Post: On Mon, 2019-03-04 at 19:18 -0800, Richard Sharpe wrote: > This is a third attempt at a RADIOTAP header for S1G captures. What's the status of this, were you going to resend? Not sure I mentioned it before, but I think you shouldn't use bit 16 for S1G, see below. I just resent my proposal for TLV fields, and I also think we should get that in before we add the S1G field, because ... we've run out of bits in the first presence bitmap! We're using all the bits 0-27 (other than 15 and 16 which are awkwardly used for different things in different OSes). Only bit 28 is free, bit 29 is the special "new radiotap namespace", bit 30 is the special "new vendor namespace", and bit 31 of course is the extension. Thus I think we should use bit 28 for the TLV switch so we won't always have to generate an extension presence bitmap when we generate a TLV type header. What do you think? johannes