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] [day] [month] [year] [list]
Date:	Tue, 6 Feb 2007 17:21:57 -0600
From:	David Young <dyoung@...ox.com>
To:	Marcelo Tosatti <marcelo@...ck.org>
Cc:	Michael Wu <flamingice@...rmilk.net>,
	netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
	Dan Williams <dcbw@...hat.com>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	"John W. Linville" <linville@...hat.com>, sam@...no.com
Subject: Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver

On Mon, Dec 18, 2006 at 05:57:23PM -0200, Marcelo Tosatti wrote:
> 
> > > > /* Channel flags. */
> > > Did you send this part to netbsd also? We really don't want to fork 
> > > radiotap. ;) Also, this should be in a separate patch, but I'm guessing it's 
> > > all rolled together for convenience.
> > 
> > No, especially since NetBSD is where I keep the authoritative definitions.
> > 
> > How have you defined RX_FLAGS and TX_FLAGS?
> 
> Oh yes, missed that part of the patch. Sorry.

Sorry for the delayed response, it's been a busy couple of months.

There is now a mailing list for discussing radiotap.  Subscribe at
<http://mail.ojctech.com/mailman/listinfo/radiotap>.  I ask that you
send proposals for new fields to the mailing list for discussion.  I am
interested to see proposals for 802.11n.  A couple of people have already
promised me proposals, but they never sent them.

A couple words about the fields you mention:

> --- a/include/net/ieee80211_radiotap.h
> +++ b/include/net/ieee80211_radiotap.h
> @@ -168,6 +168,23 @@ struct ieee80211_radiotap_header {
>   *      Unitless indication of the Rx/Tx antenna for this packet.
>   *      The first antenna is antenna 0.
>   *
> + * IEEE80211_RADIOTAP_RX_FLAGS          u_int16_t       bitmap
> + *
> + *     Properties of received frames. See flags defined below.
> + *
> + * IEEE80211_RADIOTAP_TX_FLAGS          u_int16_t       bitmap
> + *
> + *     Properties of transmitted frames. See flags defined below.
> + *
> + * IEEE80211_RADIOTAP_RTS_RETRIES       u_int8_t        data
> + *
> + *     Number of rts retries a transmitted frame used.
> + *
> + * IEEE80211_RADIOTAP_DATA_RETRIES      u_int8_t        data
> + *
> + *     Number of unicast retries a transmitted frame used.
> + *
> + *
>   * IEEE80211_RADIOTAP_FCS           	u32       data
>   *
>   *	FCS from frame in network byte order.
> @@ -187,7 +204,11 @@ enum ieee80211_radiotap_type {
>  	IEEE80211_RADIOTAP_ANTENNA = 11,
>  	IEEE80211_RADIOTAP_DB_ANTSIGNAL = 12,
>  	IEEE80211_RADIOTAP_DB_ANTNOISE = 13,
> -	IEEE80211_RADIOTAP_EXT = 31,
> +	IEEE80211_RADIOTAP_RX_FLAGS = 14,
> +	IEEE80211_RADIOTAP_TX_FLAGS = 15,
> +	IEEE80211_RADIOTAP_RTS_RETRIES = 16,
> +	IEEE80211_RADIOTAP_DATA_RETRIES = 17,
> +	IEEE80211_RADIOTAP_EXT = 31
>  };

I remember discussing these fields, but they were for somebody's
experimental use.  All of the fields are acceptable to me, but this flag
is questionable; it duplicates the function of another flag:

> +#define IEEE80211_RADIOTAP_F_RX_BADFCS	0x0001	/* frame failed crc check */

If it is important to people that I add this flag, let's discuss on the
mailing list.

Dave

-- 
David Young             OJC Technologies
dyoung@...tech.com      Urbana, IL * (217) 278-3933
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ