Menu
▾
▴
ieee80211-devel — List for discussing development of ieee80211 subsystem
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(46) |
Sep
(117) |
Oct
(24) |
Nov
(10) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(3) |
Apr
(3) |
May
(1) |
Jun
(5) |
Jul
(7) |
Aug
(1) |
Sep
(8) |
Oct
(2) |
Nov
(27) |
Dec
(33) |
| 2009 |
Jan
(11) |
Feb
(10) |
Mar
(10) |
Apr
(16) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael Wu <fla...@so...> - 2005-09-21 03:28:55
|
Fix time calculation. Use jiffies_to_msec. Signed-off-by: Michael Wu <fla...@so...> --- net/ieee80211/ieee80211_wx.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) 43b558f8357e9de7a7d33fb259d16c569d837699 diff --git a/net/ieee80211/ieee80211_wx.c b/net/ieee80211/ieee80211_wx.c --- a/net/ieee80211/ieee80211_wx.c +++ b/net/ieee80211/ieee80211_wx.c @@ -32,6 +32,7 @@ #include <linux/kmod.h> #include <linux/module.h> +#include <linux/jiffies.h> #include <net/ieee80211.h> #include <linux/wireless.h> @@ -218,7 +219,7 @@ static inline char *ipw2100_translate_sc p = custom; p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), " Last beacon: %lums ago", - (jiffies - network->last_scanned) / (HZ / 100)); + jiffies_to_msecs(jiffies - network->last_scanned)); iwe.u.data.length = p - custom; if (iwe.u.data.length) start = iwe_stream_add_point(start, stop, &iwe, custom); @@ -252,9 +253,8 @@ int ieee80211_wx_get_scan(struct ieee802 escape_essid(network->ssid, network->ssid_len), MAC_ARG(network->bssid), - (jiffies - - network->last_scanned) / (HZ / - 100)); + jiffies_to_msecs(jiffies - + network->last_scanned)); } spin_unlock_irqrestore(&ieee->lock, flags); |
|
From: Michael Wu <fla...@so...> - 2005-09-21 03:28:55
|
On Monday 19 September 2005 01:41, Jeff Garzik wrote: > Patience. We've got to balance kernel hackers' insatiable desire for > cleanups, with the desire of users and driver developers to move forward > with Linux wireless support. > > Since Intel has useful stuff, stuff which affects a wide range of > hardware owned by Linux users, it's worth waiting a bit to let them > catch up. Of course, if it takes forever to merge their stuff, someone > else will inevitably come along and speed up the process. Open source > at work. > I don't have the patience to wait forever. Mind if I speed up the process? The following patch series contains all the unapplied patches up to #17 from James Ketrenos' patch series with fixes for all the issues raised last time. I will finish the rest of the patch series if this is applied. Some patches were consolidated. This patch series is against the netdev upstream branch. Thanks, -Michael Wu |
|
From: Matt D. <Mat...@de...> - 2005-09-19 22:01:11
|
On Mon, Sep 19, 2005 at 01:41:14AM -0400, Jeff Garzik wrote: > Michael Wu wrote: > >If it has a version, then only the maintainer can submit patches - > > False. Presence of an optional label in source code files does not > change the fundamental rules of open source, or the processes > surrounding patch merging in the Linux kernel. Anybody who feels the > version number should be changed is welcome to submit a patch. And a > reviewer along the line is welcome to reject such a patch, if they think > it is unwarranted. > > >otherwise the > >version is useless for identifying what code you're running. (unless other > > False. We have plenty of examples of slower-moving drivers where > community consensus often dictates a version number change. This is also the reason for the 'srcversion' field available in modinfo. This is a CRC across the source code for a given module (not counting #include<*>, but counting #include "*"). The version field may not change, but if anything really cares about a particular source code copy, and that it hasn't been patched, but the version field not updated, they can see that. Thanks to Rusty for implementing this. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com |
|
From: Jeff G. <jg...@po...> - 2005-09-19 05:41:31
|
Michael Wu wrote: > If it has a version, then only the maintainer can submit patches - False. Presence of an optional label in source code files does not change the fundamental rules of open source, or the processes surrounding patch merging in the Linux kernel. Anybody who feels the version number should be changed is welcome to submit a patch. And a reviewer along the line is welcome to reject such a patch, if they think it is unwarranted. > otherwise the > version is useless for identifying what code you're running. (unless other False. We have plenty of examples of slower-moving drivers where community consensus often dictates a version number change. > submitters decide to alter the version too, which is probably not a good > idea) For any given driver/subsystem/whatever version number in the kernel, ultimately a submittor changes the version and one or more reviewers approve this, by pulling the change into their tree. Your "probably not a good idea" is the 100% case here, including the master version number in ./Makefile. >>> That early and often thing is true for drivers aswell, the intel >>> wireless >>> driver are so hopelessly out of date in mainline just after >>> submission that >>> it's not funny anymore. Hopefully we'll have a mainline maintainer for >>> them soon that imports everything important from intel and other >>> contributors. >> >> >> Patience: We still have over 20 patches to merge, before even getting >> to the ipw updates. >> > I wish those patches were submitted and merged quickly when they were > created > instead of piling up. Other people can't get patches merged because it Agreed. > Other people can't get patches merged because it > would > break the chain of patches. Patches are being sent too late and > and infrequently.. Patience. We've got to balance kernel hackers' insatiable desire for cleanups, with the desire of users and driver developers to move forward with Linux wireless support. Since Intel has useful stuff, stuff which affects a wide range of hardware owned by Linux users, it's worth waiting a bit to let them catch up. Of course, if it takes forever to merge their stuff, someone else will inevitably come along and speed up the process. Open source at work. Currently, it has rather been like a clock algorithm: merge initial ieee80211 code from Intel. Accept months worth of cleanups from community. Accept unifying updates from Jouni. Begin merging work from Jiri and SuSE. Now the clock hand points at Intel again, and they've been waiting a while to send useful stuff. People are slowly converging at a decent solution, while at the same moving wireless hardware support forward. The need to improve the wireless API is balanced with the need to keep wireless hardware working (and/or enable new wireless hardware). This convergence will be attained more rapidly once the community starts WORKING TOGETHER, rather than sending me competing patches. Person A breaks Person B's work. And then back again. Jeff |
|
From: Michael Wu <fla...@so...> - 2005-09-19 04:45:08
|
Quoting Jeff Garzik <jg...@po...>: > Christoph Hellwig wrote: >> I mean not having versioning at all. The kernel version should uniqueuely >> identify major subsystems, not a version of it's own. Development will >> happen in the kernel tree anyway, and you should better start submitting >> patches often and early or you will get ouf of sync with all the development >> going on in mainline. > > Maintainer's choice. > > If it has a version, then only the maintainer can submit patches - otherwise the version is useless for identifying what code you're running. (unless other submitters decide to alter the version too, which is probably not a good idea) >> That early and often thing is true for drivers aswell, the intel wireless >> driver are so hopelessly out of date in mainline just after submission that >> it's not funny anymore. Hopefully we'll have a mainline maintainer for >> them soon that imports everything important from intel and other >> contributors. > > Patience: We still have over 20 patches to merge, before even getting > to the ipw updates. > I wish those patches were submitted and merged quickly when they were created instead of piling up. Other people can't get patches merged because it would break the chain of patches. Patches are being sent too late and infrequently.. -Michael Wu |
|
From: Jeff G. <jg...@po...> - 2005-09-19 01:13:19
|
Christoph Hellwig wrote: > I mean not having versioning at all. The kernel version should uniqueuely > identify major subsystems, not a version of it's own. Development will > happen in the kernel tree anyway, and you should better start submitting > patches often and early or you will get ouf of sync with all the development > going on in mainline. Maintainer's choice. > That early and often thing is true for drivers aswell, the intel wireless > driver are so hopelessly out of date in mainline just after submission that > it's not funny anymore. Hopefully we'll have a mainline maintainer for > them soon that imports everything important from intel and other contributors. Patience: We still have over 20 patches to merge, before even getting to the ipw updates. Jeff |
|
From: Christoph H. <hc...@in...> - 2005-09-17 09:28:55
|
On Wed, Sep 14, 2005 at 12:16:15PM -0500, James Ketrenos wrote: > Christoph Hellwig wrote: > > >On Tue, Sep 13, 2005 at 06:35:57PM -0500, James Ketrenos wrote: > > > > > >>Updated misc. copyright dates. > >>Added version reporting to syslog during ieee80211 subsystem load. > >> > >> > > > >version reporting for subsystems doesn't make sense - they evolve too much > >and should evolve with the kernel tree, not separately. > > > > > Do you have issue with reporting the version via printk, or just > -having- versioning? > > If the former, its a useful debug and troubleshooting tool, and the > overhead is minimal. There are other ways to get at the info (modinfo) > but displaying the version information via printk it is used by other > components in the kernel. I mean not having versioning at all. The kernel version should uniqueuely identify major subsystems, not a version of it's own. Development will happen in the kernel tree anyway, and you should better start submitting patches often and early or you will get ouf of sync with all the development going on in mainline. That early and often thing is true for drivers aswell, the intel wireless driver are so hopelessly out of date in mainline just after submission that it's not funny anymore. Hopefully we'll have a mainline maintainer for them soon that imports everything important from intel and other contributors. |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:17:52
|
James Ketrenos wrote: > Added WE-18 support to default wireless extension handler in ieee80211 > subsystem. > > Signed-off-by: James Ketrenos <jke...@li...> Stopped applying patches at this stage, since previous ones were NAK'd, and dependencies are causing attrition. I'll let you take a look at the result in 'upstream' branch of netdev-2.6.git, and resend a new series from here. We're getting there... slowly but surely... Thanks for your patience, Jeff |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:16:14
|
applied |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:14:50
|
patch OK, but does not apply |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:14:32
|
James Ketrenos wrote: > Allow drivers to fix an issue when using wpa_supplicant with WEP. > > The problem is introduced by the hwcrypto patch. We changed indicator of patch skipped, since hwcrypto patch not applied. otherwise OK. |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:13:30
|
James Ketrenos wrote: > Fix time calculation. HZ is 1000 on 2.6 i386 kernel, but we don't > calculate time bases on this. We calculate time bases on (jiffies == > 1/HZ). > > Signed-off-by: James Ketrenos <jke...@li...> NAK: use jiffies_to_msecs() helper |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:12:13
|
applied patches 8-9 |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:11:53
|
James Ketrenos wrote: > Hardware crypto and fragmentation offload support added (Zhu Yi) > > Signed-off-by: James Ketrenos <jke...@li...> OK, but patch does not apply, probably due to previously-NAK'd patches not being applied. Applying 'Hardware crypto and fragmentation offload support added' error: patch failed: include/net/ieee80211.h:436 error: include/net/ieee80211.h: patch does not apply |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:11:21
|
applied patches 5-6 |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:08:18
|
James Ketrenos wrote: > diff --git a/include/net/ieee80211_crypt.h b/include/net/ieee80211_crypt.h > --- a/include/net/ieee80211_crypt.h > +++ b/include/net/ieee80211_crypt.h > @@ -25,6 +25,24 @@ > > #include <linux/skbuff.h> > > +#ifdef CONFIG_IEEE80211_WPA_MODULE > +#ifndef CONFIG_IEEE80211_WPA > +#define CONFIG_IEEE80211_WPA > +#endif > +#endif > + > +#ifdef CONFIG_IEEE80211_CRYPT_CCMP_MODULE > +#ifndef CONFIG_IEEE80211_CRYPT_CCMP > +#define CONFIG_IEEE80211_CRYPT_CCMP > +#endif > +#endif > + > +#ifdef CONFIG_IEEE80211_CRYPT_TKIP_MODULE > +#ifndef CONFIG_IEEE80211_CRYPT_TKIP > +#define CONFIG_IEEE80211_CRYPT_TKIP > +#endif > +#endif NAK: Kernel code should -never- mess with CONFIG_xxx symbols, except to test them. Jeff |
|
From: Jeff G. <jg...@po...> - 2005-09-16 07:07:12
|
applied patches 1-3. Note that I applied the _first_ patch #3, the one with the Lindent stuff included. |
|
From: James K. <jke...@li...> - 2005-09-14 18:10:45
|
James Ketrenos wrote:
>Type-o, capbility definition for QoS, and ERP parsing
>
>Added WLAN_CAPABILITY_QOS
>Fixed type-o WLAN_CAPABILITY_OSSS_OFDM -> WLAN_CAPABILITY_DSSS_OFDM
>Added ERP IE parsing to ieee80211_rx
>Added handle_probe_request callback.
>
>Signed-off-by: James Ketrenos <jke...@li...>
>
>---
>
>
This patch lost the ieee80211_rx.c changes. Below is the corrected patch.
include/net/ieee80211.h | 7 ++++++-
net/ieee80211/ieee80211_rx.c | 24 +++++++++++++++++++++++-
2 files changed, 29 insertions(+), 2 deletions(-)
---
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -231,8 +231,9 @@ struct ieee80211_snap_hdr {
#define WLAN_CAPABILITY_PBCC (1<<6)
#define WLAN_CAPABILITY_CHANNEL_AGILITY (1<<7)
#define WLAN_CAPABILITY_SPECTRUM_MGMT (1<<8)
+#define WLAN_CAPABILITY_QOS (1<<9)
#define WLAN_CAPABILITY_SHORT_SLOT_TIME (1<<10)
-#define WLAN_CAPABILITY_OSSS_OFDM (1<<13)
+#define WLAN_CAPABILITY_DSSS_OFDM (1<<13)
/* Status codes */
enum ieee80211_statuscode {
@@ -762,6 +763,7 @@ struct ieee80211_network {
u16 beacon_interval;
u16 listen_interval;
u16 atim_window;
+ u8 erp_value;
u8 wpa_ie[MAX_WPA_IE_LEN];
size_t wpa_ie_len;
u8 rsn_ie[MAX_WPA_IE_LEN];
@@ -912,6 +914,9 @@ struct ieee80211_device {
int (*handle_probe_response) (struct net_device * dev,
struct ieee80211_probe_response * resp,
struct ieee80211_network * network);
+ int (*handle_probe_request) (struct net_device * dev,
+ struct ieee80211_probe_request * req,
+ struct ieee80211_rx_stats * stats);
int (*handle_assoc_response) (struct net_device * dev,
struct ieee80211_assoc_response * resp,
struct ieee80211_network * network);
diff --git a/net/ieee80211/ieee80211_rx.c b/net/ieee80211/ieee80211_rx.c
--- a/net/ieee80211/ieee80211_rx.c
+++ b/net/ieee80211/ieee80211_rx.c
@@ -1076,6 +1076,7 @@ static inline int ieee80211_network_init
network->ssid_len = 0;
network->flags = 0;
network->atim_window = 0;
+ network->erp_value = 0x3;
if (stats->freq == IEEE80211_52GHZ_BAND) {
/* for A band (No DS info) */
@@ -1189,8 +1190,16 @@ static inline int ieee80211_network_init
IEEE80211_DEBUG_SCAN("MFIE_TYPE_TIM: ignored\n");
break;
+ case MFIE_TYPE_ERP_INFO:
+ network->erp_value = info_element->data[0];
+ IEEE80211_DEBUG_SCAN("MFIE_TYPE_ERP_SET: %d\n",
+ network->erp_value);
+ break;
+
case MFIE_TYPE_IBSS_SET:
- IEEE80211_DEBUG_SCAN("MFIE_TYPE_IBSS_SET: ignored\n");
+ network->atim_window = info_element->data[0];
+ IEEE80211_DEBUG_SCAN("MFIE_TYPE_IBSS_SET: %d\n",
+ network->atim_window);
break;
case MFIE_TYPE_CHALLENGE:
@@ -1301,6 +1310,7 @@ static inline void update_network(struct
dst->beacon_interval = src->beacon_interval;
dst->listen_interval = src->listen_interval;
dst->atim_window = src->atim_window;
+ dst->erp_value = src->erp_value;
memcpy(dst->wpa_ie, src->wpa_ie, src->wpa_ie_len);
dst->wpa_ie_len = src->wpa_ie_len;
@@ -1482,6 +1492,18 @@ void ieee80211_rx_mgt(struct ieee80211_d
(header->frame_ctl)));
break;
+ case IEEE80211_STYPE_PROBE_REQ:
+ IEEE80211_DEBUG_MGMT("recieved auth (%d)\n",
+ WLAN_FC_GET_STYPE(le16_to_cpu
+ (header->frame_ctl)));
+
+ if (ieee->handle_probe_request != NULL)
+ ieee->handle_probe_request(ieee->dev,
+ (struct
+ ieee80211_probe_request *)
+ header, stats);
+ break;
+
case IEEE80211_STYPE_PROBE_RESP:
IEEE80211_DEBUG_MGMT("received PROBE RESPONSE (%d)\n",
WLAN_FC_GET_STYPE(le16_to_cpu
|
|
From: James K. <jke...@li...> - 2005-09-14 18:08:06
|
Jiri Benc wrote: >>Could you please send the patch without those formatting changes? >> >> I rebased the series (again)... after applying Lindent to all the ieee80211 files before I started the series. You can grab the latest rebase at rsync://bughost.org/repos/ieee80211-delta/.git/ Below is the cleaned [patch 3/29]. James include/net/ieee80211.h | 1 + net/ieee80211/ieee80211_rx.c | 34 ++++++++++++++++++++++++---------- 2 files changed, 25 insertions(+), 10 deletions(-) --- diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h --- a/include/net/ieee80211.h +++ b/include/net/ieee80211.h @@ -653,6 +653,7 @@ struct ieee80211_device { int scan_age; int iw_mode; /* operating mode (IW_MODE_*) */ + struct iw_spy_data spy_data; /* iwspy support */ spinlock_t lock; diff --git a/net/ieee80211/ieee80211_rx.c b/net/ieee80211/ieee80211_rx.c --- a/net/ieee80211/ieee80211_rx.c +++ b/net/ieee80211/ieee80211_rx.c @@ -378,33 +378,47 @@ int ieee80211_rx(struct ieee80211_device frag = WLAN_GET_SEQ_FRAG(sc); hdrlen = ieee80211_get_hdrlen(fc); -#ifdef NOT_YET -#if WIRELESS_EXT > 15 /* Put this code here so that we avoid duplicating it in all * Rx paths. - Jean II */ #ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */ /* If spy monitoring on */ - if (iface->spy_data.spy_number > 0) { + if (ieee->spy_data.spy_number > 0) { struct iw_quality wstats; - wstats.level = rx_stats->signal; - wstats.noise = rx_stats->noise; - wstats.updated = 6; /* No qual value */ + + wstats.updated = 0; + if (rx_stats->mask & IEEE80211_STATMASK_RSSI) { + wstats.level = rx_stats->rssi; + wstats.updated |= IW_QUAL_LEVEL_UPDATED; + } else + wstats.updated |= IW_QUAL_LEVEL_INVALID; + + if (rx_stats->mask & IEEE80211_STATMASK_NOISE) { + wstats.noise = rx_stats->noise; + wstats.updated |= IW_QUAL_NOISE_UPDATED; + } else + wstats.updated |= IW_QUAL_NOISE_INVALID; + + if (rx_stats->mask & IEEE80211_STATMASK_SIGNAL) { + wstats.qual = rx_stats->signal; + wstats.updated |= IW_QUAL_QUAL_UPDATED; + } else + wstats.updated |= IW_QUAL_QUAL_INVALID; + /* Update spy records */ - wireless_spy_update(dev, hdr->addr2, &wstats); + wireless_spy_update(ieee->dev, hdr->addr2, &wstats); } #endif /* IW_WIRELESS_SPY */ -#endif /* WIRELESS_EXT > 15 */ + +#ifdef NOT_YET hostap_update_rx_stats(local->ap, hdr, rx_stats); #endif -#if WIRELESS_EXT > 15 if (ieee->iw_mode == IW_MODE_MONITOR) { ieee80211_monitor_rx(ieee, skb, rx_stats); stats->rx_packets++; stats->rx_bytes += skb->len; return 1; } -#endif if (ieee->host_decrypt) { int idx = 0; |
|
From: James K. <jke...@li...> - 2005-09-14 17:16:20
|
Christoph Hellwig wrote: >On Tue, Sep 13, 2005 at 06:35:57PM -0500, James Ketrenos wrote: > > >>Updated misc. copyright dates. >>Added version reporting to syslog during ieee80211 subsystem load. >> >> > >version reporting for subsystems doesn't make sense - they evolve too much >and should evolve with the kernel tree, not separately. > > Do you have issue with reporting the version via printk, or just -having- versioning? If the former, its a useful debug and troubleshooting tool, and the overhead is minimal. There are other ways to get at the info (modinfo) but displaying the version information via printk it is used by other components in the kernel. James |
|
From: James K. <jke...@li...> - 2005-09-14 14:01:25
|
Christoph Hellwig wrote:
>On Tue, Sep 13, 2005 at 06:35:13PM -0500, James Ketrenos wrote:
>
>
>>+ * are met:
>>+ * 1. Redistributions of source code must retain the above copyright
>>+ * notice, this list of conditions and the following disclaimer.
>>+ * 2. Redistributions in binary form must reproduce the above copyright
>>+ * notice, this list of conditions and the following disclaimer in the
>>+ * documentation and/or other materials provided with the distribution.
>>+ * 3. The name of David Young may not be used to endorse or promote
>>+ * products derived from this software without specific prior
>>+ * written permission.
>>
>>
>
>Is this actually GPL-compatible?
>
>
Per FSF[1], the modified BSD license is compatible with the GPL. Its
used throughout other files in the kernel tree (grep for 'may not be
used' or 'redistributions of source code must').
>>+#include <linux/version.h>
>>
>>
>
>shouldn;t be beeded,
>
>
Removed.
>>+/* Kluge the radiotap linktype for now if we don't have it */
>>+#ifndef ARPHRD_IEEE80211_RADIOTAP
>>+#define ARPHRD_IEEE80211_RADIOTAP 803
>>+#endif
>>
>>
>
>please get that right.
>
>
This should go into include/linux/if_arp.h anyway, correct?
>>+ u_int8_t it_version; /* Version 0. Only increases
>>
>>
>please use u8/etc types as in the rest of the kernel, or SuS
>uint8_t/etc types if you really want to.
>
>
A quick sed script now has them set to uN vs. u_intN_t.
Patch covering the above changes follows.
Thanks,
James
---
include/linux/if_arp.h | 1 +
include/net/ieee80211_radiotap.h | 38 ++++++++++++++++----------------------
2 files changed, 17 insertions(+), 22 deletions(-)
---
diff --git a/include/linux/if_arp.h b/include/linux/if_arp.h
--- a/include/linux/if_arp.h
+++ b/include/linux/if_arp.h
@@ -84,6 +84,7 @@
#define ARPHRD_IEEE802_TR 800 /* Magic type ident for TR */
#define ARPHRD_IEEE80211 801 /* IEEE 802.11 */
#define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */
+#define ARPHRD_IEEE80211_RADIOTAP 803 /* IEEE 802.11 + Radiotap header */
#define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */
#define ARPHRD_NONE 0xFFFE /* zero header length */
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -38,15 +38,9 @@
#ifndef IEEE80211RADIOTAP_H
#define IEEE80211RADIOTAP_H
-#include <linux/version.h>
#include <linux/if_ether.h>
#include <linux/kernel.h>
-/* Kluge the radiotap linktype for now if we don't have it */
-#ifndef ARPHRD_IEEE80211_RADIOTAP
-#define ARPHRD_IEEE80211_RADIOTAP 803
-#endif
-
/* Radiotap header version (from official NetBSD feed) */
#define IEEE80211RADIOTAP_VERSION "1.5"
/* Base version of the radiotap packet header data */
@@ -74,18 +68,18 @@
/* The radio capture header precedes the 802.11 header. */
struct ieee80211_radiotap_header {
- u_int8_t it_version; /* Version 0. Only increases
+ u8 it_version; /* Version 0. Only increases
* for drastic changes,
* introduction of compatible
* new fields does not count.
*/
- u_int8_t it_pad;
- u_int16_t it_len; /* length of the whole
+ u8 it_pad;
+ u16 it_len; /* length of the whole
* header in bytes, including
* it_version, it_pad,
* it_len, and data fields.
*/
- u_int32_t it_present; /* A bitmap telling which
+ u32 it_present; /* A bitmap telling which
* fields are present. Set bit 31
* (0x80000000) to extend the
* bitmap by another 32 bits.
@@ -97,22 +91,22 @@ struct ieee80211_radiotap_header {
/* Name Data type Units
* ---- --------- -----
*
- * IEEE80211_RADIOTAP_TSFT u_int64_t microseconds
+ * IEEE80211_RADIOTAP_TSFT u64 microseconds
*
* Value in microseconds of the MAC's 64-bit 802.11 Time
* Synchronization Function timer when the first bit of the
* MPDU arrived at the MAC. For received frames, only.
*
- * IEEE80211_RADIOTAP_CHANNEL 2 x u_int16_t MHz, bitmap
+ * IEEE80211_RADIOTAP_CHANNEL 2 x u16 MHz, bitmap
*
* Tx/Rx frequency in MHz, followed by flags (see below).
*
- * IEEE80211_RADIOTAP_FHSS u_int16_t see below
+ * IEEE80211_RADIOTAP_FHSS u16 see below
*
* For frequency-hopping radios, the hop set (first byte)
* and pattern (second byte).
*
- * IEEE80211_RADIOTAP_RATE u_int8_t 500kb/s
+ * IEEE80211_RADIOTAP_RATE u8 500kb/s
*
* Tx/Rx data rate
*
@@ -128,30 +122,30 @@ struct ieee80211_radiotap_header {
* RF noise power at the antenna, decibel difference from one
* milliwatt.
*
- * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_t decibel (dB)
+ * IEEE80211_RADIOTAP_DB_ANTSIGNAL u8 decibel (dB)
*
* RF signal power at the antenna, decibel difference from an
* arbitrary, fixed reference.
*
- * IEEE80211_RADIOTAP_DB_ANTNOISE u_int8_t decibel (dB)
+ * IEEE80211_RADIOTAP_DB_ANTNOISE u8 decibel (dB)
*
* RF noise power at the antenna, decibel difference from an
* arbitrary, fixed reference point.
*
- * IEEE80211_RADIOTAP_LOCK_QUALITY u_int16_t unitless
+ * IEEE80211_RADIOTAP_LOCK_QUALITY u16 unitless
*
* Quality of Barker code lock. Unitless. Monotonically
* nondecreasing with "better" lock strength. Called "Signal
* Quality" in datasheets. (Is there a standard way to measure
* this?)
*
- * IEEE80211_RADIOTAP_TX_ATTENUATION u_int16_t unitless
+ * IEEE80211_RADIOTAP_TX_ATTENUATION u16 unitless
*
* Transmit power expressed as unitless distance from max
* power set at factory calibration. 0 is max power.
* Monotonically nondecreasing with lower power levels.
*
- * IEEE80211_RADIOTAP_DB_TX_ATTENUATION u_int16_t decibels (dB)
+ * IEEE80211_RADIOTAP_DB_TX_ATTENUATION u16 decibels (dB)
*
* Transmit power expressed as decibel distance from max power
* set at factory calibration. 0 is max power. Monotonically
@@ -164,17 +158,17 @@ struct ieee80211_radiotap_header {
* reference). This is the absolute power level measured at
* the antenna port.
*
- * IEEE80211_RADIOTAP_FLAGS u_int8_t bitmap
+ * IEEE80211_RADIOTAP_FLAGS u8 bitmap
*
* Properties of transmitted and received frames. See flags
* defined below.
*
- * IEEE80211_RADIOTAP_ANTENNA u_int8_t antenna index
+ * IEEE80211_RADIOTAP_ANTENNA u8 antenna index
*
* Unitless indication of the Rx/Tx antenna for this packet.
* The first antenna is antenna 0.
*
- * IEEE80211_RADIOTAP_FCS u_int32_t data
+ * IEEE80211_RADIOTAP_FCS u32 data
*
* FCS from frame in network byte order.
*/
---
[1]http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
|
|
From: Christoph H. <hc...@in...> - 2005-09-14 10:54:23
|
On Tue, Sep 13, 2005 at 06:35:57PM -0500, James Ketrenos wrote: > Updated misc. copyright dates. > Added version reporting to syslog during ieee80211 subsystem load. version reporting for subsystems doesn't make sense - they evolve too much and should evolve with the kernel tree, not separately. |
|
From: Christoph H. <hc...@in...> - 2005-09-14 10:53:21
|
On Tue, Sep 13, 2005 at 06:35:13PM -0500, James Ketrenos wrote:
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + * 3. The name of David Young may not be used to endorse or promote
> + * products derived from this software without specific prior
> + * written permission.
Is this actually GPL-compatible?
> +#include <linux/version.h>
shouldn;t be beeded,
> +#include <linux/if_ether.h>
> +#include <linux/kernel.h>
> +
> +/* Kluge the radiotap linktype for now if we don't have it */
> +#ifndef ARPHRD_IEEE80211_RADIOTAP
> +#define ARPHRD_IEEE80211_RADIOTAP 803
> +#endif
please get that right.
> +/* The radio capture header precedes the 802.11 header. */
> +struct ieee80211_radiotap_header {
> + u_int8_t it_version; /* Version 0. Only increases
> + * for drastic changes,
> + * introduction of compatible
> + * new fields does not count.
> + */
> + u_int8_t it_pad;
please use u8/etc types as in the rest of the kernel, or SuS
uint8_t/etc types if you really want to.
|
|
From: Michael Wu <fla...@so...> - 2005-09-14 03:13:34
|
On Tuesday 13 September 2005 22:44, Mike Kershaw wrote: > > I would prefer either that or giving drivers access to the generic > > monitor mode path so frames can be passed to userspace ASAP. > > I'm of 2 minds here... For a driver to implement radiotap, all it takes > is a struct that the driver fills in that LOOKS like a radiotap dynamic > header to userspace, but is really just a static struct fill. For the > ieee80211 layer to do the same, it will have to actually dynamically > contstruct the header, per frame, based on what the driver gives us. > It's quicker to do per-driver header construction. > > I don't mind implementing both, and including a field that ieee80211 > layer can pick to do headers dynamically or not. > > Maybe this is too weird an idea, and we should just pick "80211" or > "driver". I'm willing to write the code for either use case. I suppose > that rfmon is a fairly special case and won't be as much of a cpu drain > as a wired ethernet NIC or normal mode would be. > I'm currently leaning towards taking the monitor mode stuff out of the ieee80211 rx path and letting the driver decide when to hook in the monitor mode stuff. Then the radiotap headers would be constructed in the driver. > > Also, we probably want an ioctl or some way to switch between raw > > ieee80211 frames and radiotap headers. > > Sure, *as long as every driver uses the same ioctl* :) PLEASE PLEASE > PLEASE lets pick a constant ioctl name for this. I assume we'll want it > as an iwpriv ioctl, thats where the other behavior of this ilk lives. > If we're going to implement an iwpriv control for it, shall we plan > forward and make it an integer not a boolean, so we can have different > headers if we need them? > By ioctl, I mean Wireless Extensions, so hopefully some future version of WE will have it. I somehow doubt that we will need much more than extensions of radiotap headers in the future.. it looks like it can cover everything. However, an int is easy, so why not.. -Michael Wu |
|
From: Mike K. <dr...@ki...> - 2005-09-14 02:44:32
|
> A bunch of information that is put into the radiotap header is put inside=
=20
> struct ieee80211_rx_stats when the driver passes the frame to the ieee802=
11=20
> layer. I think it is a better idea to expand ieee80211_rx_stats to includ=
e=20
> all information necessary for filling in a radiotap header, and let the=
=20
> ieee80211 tack on the header.
Yeah, we talked about this, I was just waiting for things to settle in
the tree before I tackled it.
> I would prefer either that or giving drivers access to the generic monito=
r=20
> mode path so frames can be passed to userspace ASAP.
I'm of 2 minds here... For a driver to implement radiotap, all it takes
is a struct that the driver fills in that LOOKS like a radiotap dynamic
header to userspace, but is really just a static struct fill. For the
ieee80211 layer to do the same, it will have to actually dynamically
contstruct the header, per frame, based on what the driver gives us.
It's quicker to do per-driver header construction.
I don't mind implementing both, and including a field that ieee80211
layer can pick to do headers dynamically or not.
Maybe this is too weird an idea, and we should just pick "80211" or
"driver". I'm willing to write the code for either use case. I suppose
that rfmon is a fairly special case and won't be as much of a cpu drain
as a wired ethernet NIC or normal mode would be.
> Also, we probably want an ioctl or some way to switch between raw ieee802=
11=20
> frames and radiotap headers.
Sure, *as long as every driver uses the same ioctl* :) PLEASE PLEASE
PLEASE lets pick a constant ioctl name for this. I assume we'll want it
as an iwpriv ioctl, thats where the other behavior of this ilk lives.
If we're going to implement an iwpriv control for it, shall we plan
forward and make it an integer not a boolean, so we can have different
headers if we need them?
The ioctl is pretty trivial in any case, but you're right, we should
have it.
-m
--=20
Mike Kershaw/Dragorn <dr...@ki...>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"Dear Die-ary,
Today I stuffed some dolls with dead rats I put in a blender.
I'm beginning to wonder if, maybe, I really am screwed up."
-- Johnny C. (JtHM)
|
116 messages has been excluded from this view by a project administrator.
