RE: d80211: How does TX flow control work?
Scratches head -- this is from memory when I was thinking about this problem a long time ago... I think we can return an error in the qdisc destructor function - making sure legitimate interface removal is not the cause of the qdisc deletion first of course. Simon -Original Message- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 6:20 PM To: Jan Kiszka Cc: netdev@vger.kernel.org; Ivo Van Doorn; [EMAIL PROTECTED]; Jouni Malinen; Simon Barber Subject: Re: d80211: How does TX flow control work? On Mon, 08 Jan 2007 21:18:48 +0100, Jan Kiszka wrote: The actual problem was meanwhile identified: shorewall happened to overwrite the queueing discipline of wmaster0 with pfifo_fast. I found the magic knob to tell shorewall to no longer do this (at least until I want to manage traffic control that way...), but I still wonder if it is an acceptable situation. Currently, the user can intentionally or accidentally screw up the stack this way. Hm, we probably need a way to tell the kernel not to remove 802.11 qdisc. Jouni, Simon, is that possible or do we need to patch NET_SCHED code? Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/6] d80211: add IEEE802.11e/WMM MLMEs, Status Code and Reason Code
None of this should be in the kernel. See wpa_supplicant.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Zhu Yi
Sent: Wednesday, December 13, 2006 8:02 PM
To: netdev@vger.kernel.org
Subject: [PATCH 1/6] d80211: add IEEE802.11e/WMM MLMEs, Status Code and
Reason Code
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
---
include/net/d80211_mgmt.h | 148
+
1 files changed, 148 insertions(+), 0 deletions(-)
d83f6236e756f5f0bb1484d99188f06704de
diff --git a/include/net/d80211_mgmt.h b/include/net/d80211_mgmt.h index
87141d4..450c0a2 100644
--- a/include/net/d80211_mgmt.h
+++ b/include/net/d80211_mgmt.h
@@ -14,6 +14,39 @@
#include linux/types.h
+struct ieee802_11_ts_info {
+ __le16 traffic_type:1;
+ __le16 tsid:4;
+ __le16 direction:2;
+ __le16 access_policy:2;
+ __le16 aggregation:1;
+ __le16 apsd:1;
+ __le16 up:3;
+ __le16 ack_policy:2;
+ u8 schedule:1;
+ u8 reserved:7;
+} __attribute__ ((packed));
+
+struct ieee802_11_elem_tspec {
+ struct ieee802_11_ts_info ts_info;
+ __le16 nominal_msdu_size;
+ __le16 max_msdu_size;
+ __le32 min_service_interval;
+ __le32 max_service_interval;
+ __le32 inactivity_interval;
+ __le32 suspension_interval;
+ __le32 service_start_time;
+ __le32 min_data_rate;
+ __le32 mean_data_rate;
+ __le32 peak_data_rate;
+ __le32 burst_size;
+ __le32 delay_bound;
+ __le32 min_phy_rate;
+ __le16 surplus_band_allow;
+ __le16 medium_time;
+} __attribute__ ((packed));
+
+
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
@@ -81,9 +114,51 @@ struct ieee80211_mgmt {
struct {
u8 action_code;
u8 dialog_token;
+ u8 variable[0];
+ } __attribute__ ((packed)) addts_req;
+ struct {
+ u8 action_code;
+ u8 dialog_token;
+ __le16 status_code;
+ u8 variable[0];
+ } __attribute__ ((packed)) addts_resp;
+ struct {
+ u8 action_code;
+ struct ieee802_11_ts_info
ts_info;
+ __le16 reason_code;
+ } __attribute__ ((packed)) delts;
+ struct {
+ u8 action_code;
+ u8 dialog_token;
u8 status_code;
u8 variable[0];
} __attribute__ ((packed)) wme_action;
+ struct {
+ u8 action_code;
+ u8 dest[6];
+ u8 src[6];
+ __le16 capab_info;
+ __le16 timeout;
+ /* Followed by Supported Rates
and
+* Extended Supported Rates */
+ u8 variable[0];
+ } __attribute__ ((packed)) dls_req;
+ struct {
+ u8 action_code;
+ __le16 status_code;
+ u8 dest[6];
+ u8 src[6];
+ /* Followed by Capability
Information,
+* Supported Rates and Extended
+* Supported Rates */
+ u8 variable[0];
+ } __attribute__ ((packed)) dls_resp;
+ struct {
+ u8 action_code;
+ u8 dest[6];
+ u8 src[6];
+ __le16 reason_code;
+ } __attribute__ ((packed)) dls_teardown;
struct{
u8 action_code;
u8 element_id;
@@ -150,6 +225,18 @@ enum ieee80211_statuscode {
WLAN_STATUS_UNSUPP_RSN_VERSION = 44,
WLAN_STATUS_INVALID_RSN_IE_CAP = 45,
WLAN_STATUS_CIPHER_SUITE_REJECTED = 46,
+ /* 802.11e */
+ WLAN_STATUS_UNSPECIFIED_QOS = 32,
+
RE: [PATCH 4/6] d80211: add IEEE802.11e/WMM Traffic Stream (TS) Management support
This policing of media time must be done in the qdisc - and made to work
per DA (Destination Address) - in order that AP mode will work as well
as STA mode. In addition the count of used time should be updated AFTER
the frame has been sent, not before, since the number of retries done
cannot be taken into account before. These MUST be counted.
The API to the qdisc should be via TC - not cfg80211 or other.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Zhu Yi
Sent: Wednesday, December 13, 2006 8:03 PM
To: netdev@vger.kernel.org
Subject: [PATCH 4/6] d80211: add IEEE802.11e/WMM Traffic Stream (TS)
Management support
The d80211 now maintains a sta_ts_data structure for every TSID and
direction combination of all the Taffic Streams. For those admission
control enabled Acesss Categories (AC), STA can initiatively request a
traffic stream. The stack also maintains two variables to record the
admitted time and used time for each TS. In every
dot11EDCAAveragingPeriod, a timer is used to track how much time (in
usec) has been used (vs the admitted time). If it finds the used time is
less than the admitted time in current dot11EDCAAveragingPeriod period,
the STA will continue to fulfil the admitted time in the next period.
Otherwise the stack will reduce the admitted time until the TS has been
throttled. Finally both the AP and STA are able to delete the TS by
sending a DELTS MLME.
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
---
net/d80211/ieee80211.c |4
net/d80211/ieee80211_i.h | 49 -
net/d80211/ieee80211_iface.c |5 +
net/d80211/ieee80211_sta.c | 403
++
net/d80211/wme.c | 34 +++-
5 files changed, 480 insertions(+), 15 deletions(-)
d4a326b8493fb465480a68696315c05558c03b2c
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c index
6e10db5..4eba18f 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4599,6 +4599,10 @@ int ieee80211_register_hw(struct ieee802
goto fail_wep;
}
+ /* Initialize QoS Params */
+ local-dot11EDCAAveragingPeriod = 5;
+ local-MPDUExchangeTime = 0;
+
/* TODO: add rtnl locking around device creation and qdisc
install */
ieee80211_install_qdisc(local-mdev);
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h index
ef303da..e8929d3 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -56,6 +56,10 @@ struct ieee80211_local;
* increased memory use (about 2 kB of RAM per entry). */ #define
IEEE80211_FRAGMENT_MAX 4
+/* Minimum and Maximum TSID used by EDCA. HCCA uses 0~7; EDCA uses 8~15
+*/ #define EDCA_TSID_MIN 8 #define EDCA_TSID_MAX 15
+
struct ieee80211_fragment_entry {
unsigned long first_frag_time;
unsigned int seq;
@@ -241,6 +245,7 @@ struct ieee80211_if_sta {
IEEE80211_IBSS_SEARCH, IEEE80211_IBSS_JOINED
} state;
struct work_struct work;
+ struct timer_list admit_timer; /* Recompute EDCA admitted time
*/
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 ssid[IEEE80211_MAX_SSID_LEN];
size_t ssid_len;
@@ -328,6 +333,19 @@ struct ieee80211_sub_if_data {
#define IEEE80211_DEV_TO_SUB_IF(dev) netdev_priv(dev)
+struct sta_ts_data {
+ enum {
+ TS_STATUS_UNUSED= 0,
+ TS_STATUS_ACTIVE= 1,
+ TS_STATUS_INACTIVE = 2,
+ TS_STATUS_THROTTLING= 3,
+ } status;
+ u8 dialog_token;
+ u8 up;
+ u32 admitted_time_usec;
+ u32 used_time_usec;
+};
+
struct ieee80211_local {
/* embed the driver visible part.
* don't cast (use the static inlines below), but we keep @@
-449,18 +467,19 @@ struct ieee80211_local { #ifdef
CONFIG_HOSTAPD_WPA_TESTING
u32 wpa_trigger;
#endif /* CONFIG_HOSTAPD_WPA_TESTING */
-/* SNMP counters */
-/* dot11CountersTable */
-u32 dot11TransmittedFragmentCount;
-u32 dot11MulticastTransmittedFrameCount;
-u32 dot11FailedCount;
+ /* SNMP counters */
+ /* dot11CountersTable */
+ u32 dot11TransmittedFragmentCount;
+ u32 dot11MulticastTransmittedFrameCount;
+ u32 dot11FailedCount;
u32 dot11RetryCount;
u32 dot11MultipleRetryCount;
u32 dot11FrameDuplicateCount;
-u32 dot11ReceivedFragmentCount;
-u32 dot11MulticastReceivedFrameCount;
-u32 dot11TransmittedFrameCount;
-u32 dot11WEPUndecryptableCount;
+ u32 dot11ReceivedFragmentCount;
+ u32 dot11MulticastReceivedFrameCount;
+ u32 dot11TransmittedFrameCount;
+ u32 dot11WEPUndecryptableCount;
+ u32 dot11EDCAAveragingPeriod;
#ifdef CONFIG_D80211_LEDS
int tx_led_counter, rx_led_counter;
@@ -533,6 +552,17 @@ struct ieee80211_local {
* (1 MODE_*) */
int user_space_mlme;
+
+ u32
RE: [PATCH 6/6] d80211: add sysfs interface for QoS functions
This is all part of the client MLME - it would be much better to add
this functionality to wpa_supplicant, rather than adding it to the
kernel. Nothing here needs to be in the kernel for any reason.
The client MLME functions that are in the kernel were put in there for
test and debugging convenience only - the right client MLME to use is
the one in wpa_supplicant. Especially with all the new and very complex
MLME functions that are being added to 802.11 we do not want this huge
amount of code in the kernel when it does not need to be there.
The client MLME in the kernel should be #ifdefed out and made a kernel
option - off by default.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Zhu Yi
Sent: Wednesday, December 13, 2006 8:03 PM
To: netdev@vger.kernel.org
Subject: [PATCH 6/6] d80211: add sysfs interface for QoS functions
The sysfs interface here is only a proof of concept. It provides a way
for the userspace applications to use the advanced QoS features
supported by
d80211 stack. The finial solution should be switched to cfg80211.
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
---
net/d80211/ieee80211_i.h | 13 ++
net/d80211/ieee80211_sysfs.c | 245
++
2 files changed, 258 insertions(+), 0 deletions(-)
83d49f70af1f38c152d8bd3abd69756ec087622e
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h index
d09f65e..7904033 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -20,6 +20,7 @@
#include linux/workqueue.h
#include linux/types.h
#include linux/spinlock.h
+#include net/d80211_mgmt.h
#include ieee80211_key.h
#include sta_info.h
@@ -329,6 +330,7 @@ struct ieee80211_sub_if_data {
int channel_use_raw;
struct attribute_group *sysfs_group;
+ struct attribute_group *sysfs_qos_group;
};
#define IEEE80211_DEV_TO_SUB_IF(dev) netdev_priv(dev) @@ -702,6 +704,17
@@ struct sta_info * ieee80211_ibss_add_sta
u8 *addr);
int ieee80211_sta_deauthenticate(struct net_device *dev, u16 reason);
int ieee80211_sta_disassociate(struct net_device *dev, u16 reason);
+void ieee80211_send_addts(struct net_device *dev,
+ struct ieee802_11_elem_tspec *tspec); void
wmm_send_addts(struct
+net_device *dev,
+ struct ieee802_11_elem_tspec *tspec); void
+ieee80211_send_delts(struct net_device *dev, u8 tsid, u8 direction,
+ u32 medium_time);
+void wmm_send_delts(struct net_device *dev, u8 tsid, u8 direction,
+ u32 medium_time);
+void ieee80211_send_dls_req(struct net_device *dev, struct dls_info
+*dls); void ieee80211_send_dls_teardown(struct net_device *dev, u8
+*mac, u16 reason); void dls_info_add(struct ieee80211_local *local,
+struct dls_info *dls);
void dls_info_stop(struct ieee80211_local *local); int
dls_link_status(struct ieee80211_local *local, u8 *addr);
diff --git a/net/d80211/ieee80211_sysfs.c b/net/d80211/ieee80211_sysfs.c
index 6a60077..31dc1f4 100644
--- a/net/d80211/ieee80211_sysfs.c
+++ b/net/d80211/ieee80211_sysfs.c
@@ -13,6 +13,7 @@
#include linux/netdevice.h
#include linux/rtnetlink.h
#include net/d80211.h
+#include net/d80211_mgmt.h
#include ieee80211_i.h
#include ieee80211_rate.h
@@ -21,6 +22,15 @@
#define to_net_dev(class) \
container_of(class, struct net_device, class_dev)
+/* For sysfs and debug only */
+static struct ieee802_11_elem_tspec _tspec; static u8
+_dls_mac[ETH_ALEN];
+
+#define TSID _tspec.ts_info.tsid
+#define TSDIR _tspec.ts_info.direction
+#define TSUP _tspec.ts_info.up
+
+
static inline int rtnl_lock_local(struct ieee80211_local *local) {
rtnl_lock();
@@ -657,6 +667,230 @@ static struct class ieee80211_class = { #endif
};
+
+/* QoS sysfs entries */
+static ssize_t show_ts_info(struct class_device *dev, char *buf) {
+ /* TSID, Direction, UP */
+ return sprintf(buf, %u %u %u\n, TSID, TSDIR, TSUP); }
+
+static ssize_t store_ts_info(struct class_device *dev, const char *buf,
+size_t len)
+{
+ unsigned int id, index, up;
+
+ if (sscanf(buf, %u, %u, %u, id, index, up) != 3) {
+ printk(KERN_ERR %s: sscanf error\n, __FUNCTION__);
+ return -EINVAL;
+ }
+ if (id 8 || id 15) {
+ printk(KERN_ERR invalid tsid %d\n, id);
+ return -EINVAL;
+ }
+ if ((index != 0) (index != 1) (index != 3)) {
+ printk(KERN_ERR invalid direction %d\n, index);
+ return -EINVAL;
+ }
+ if (up 0 || up 7) {
+ printk(KERN_ERR invalid UP %d\n, up);
+ return -EINVAL;
+ }
+ TSID = id;
+ TSDIR = index;
+ TSUP = up;
+ return len;
+}
+
+static CLASS_DEVICE_ATTR(ts_info, S_IWUSR|S_IRUGO, show_ts_info,
+store_ts_info);
+
+static ssize_t show_tspec(struct class_device *dev, char *buf) {
+
RE: [PATCH 5/6] d80211: add IEEE 802.11e Direct Link Setup (DLS) support
Again - this DLS management frame processing code should not be in the
kernel - it should be in wpa_supplicant.
Only the frame processing code should be in the kernel.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Zhu Yi
Sent: Wednesday, December 13, 2006 8:03 PM
To: netdev@vger.kernel.org
Subject: [PATCH 5/6] d80211: add IEEE 802.11e Direct Link Setup (DLS)
support
Struct dls_info is declared to store the peer's MAC address, timeout
value, supported rates, etc information for the DLS link. The stack also
maintains a hash table to store the dls_info for all the DLS peers for
local interface. The peer's MAC address is used as the hash table key.
The DLS MLMEs handling functions for DLS Setup Request, DLS Response and
DLS teardown are added.
During packet TX, the stack compares the destination MAC address against
the dls_info hash table and see whether a Direct Link should be used for
the packet transmission. If so, it modifiess the IEEE 802.11 MAC header
DA, SA and BSS fields to reflect the direct link setup.
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
---
net/d80211/ieee80211.c | 19 +-
net/d80211/ieee80211_i.h | 17 ++
net/d80211/ieee80211_sta.c | 450
3 files changed, 481 insertions(+), 5 deletions(-)
077c391798f72f356c0a5cb50f307b50143a5dcc
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c index
4eba18f..b25d00e 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -1472,11 +1472,18 @@ static int ieee80211_subif_start_xmit(st
memcpy(hdr.addr4, skb-data + ETH_ALEN, ETH_ALEN);
hdrlen = 30;
} else if (sdata-type == IEEE80211_IF_TYPE_STA) {
- fc |= IEEE80211_FCTL_TODS;
- /* BSSID SA DA */
- memcpy(hdr.addr1, sdata-u.sta.bssid, ETH_ALEN);
- memcpy(hdr.addr2, skb-data + ETH_ALEN, ETH_ALEN);
- memcpy(hdr.addr3, skb-data, ETH_ALEN);
+ if (dls_link_status(local, hdr.addr1) == DLS_STATUS_OK)
{
+ /* DA SA BSSID */
+ memcpy(hdr.addr1, skb-data, ETH_ALEN);
+ memcpy(hdr.addr2, skb-data + ETH_ALEN,
ETH_ALEN);
+ memcpy(hdr.addr3, sdata-u.sta.bssid, ETH_ALEN);
+ } else {
+ fc |= IEEE80211_FCTL_TODS;
+ /* BSSID SA DA */
+ memcpy(hdr.addr1, sdata-u.sta.bssid, ETH_ALEN);
+ memcpy(hdr.addr2, skb-data + ETH_ALEN,
ETH_ALEN);
+ memcpy(hdr.addr3, skb-data, ETH_ALEN);
+ }
hdrlen = 24;
} else if (sdata-type == IEEE80211_IF_TYPE_IBSS) {
/* DA SA BSSID */
@@ -4602,6 +4609,7 @@ int ieee80211_register_hw(struct ieee802
/* Initialize QoS Params */
local-dot11EDCAAveragingPeriod = 5;
local-MPDUExchangeTime = 0;
+ spin_lock_init(local-dls_lock);
/* TODO: add rtnl locking around device creation and qdisc
install */
ieee80211_install_qdisc(local-mdev);
@@ -4702,6 +4710,7 @@ void ieee80211_unregister_hw(struct ieee
ieee80211_rx_bss_list_deinit(local-mdev);
ieee80211_clear_tx_pending(local);
+ dls_info_stop(local);
sta_info_stop(local);
rate_control_deinitialize(local);
ieee80211_dev_sysfs_del(local);
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h index
e8929d3..d09f65e 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -346,6 +346,18 @@ struct sta_ts_data {
u32 used_time_usec;
};
+#define DLS_STATUS_OK 0
+#define DLS_STATUS_NOLINK 1
+#define DLS_STATUS_SETUP 2
+struct dls_info {
+ atomic_t refcnt;
+ int status;
+ u8 addr[ETH_ALEN];
+ struct dls_info *hnext; /* next entry in hash table list */
+ u32 timeout;
+ u32 supp_rates;
+};
+
struct ieee80211_local {
/* embed the driver visible part.
* don't cast (use the static inlines below), but we keep @@
-558,6 +570,9 @@ struct ieee80211_local {
#define STA_TSDIR_NUM 2
/* HCCA: 0~7, EDCA: 8~15 */
struct sta_ts_data ts_data[STA_TSID_NUM][STA_TSDIR_NUM];
+
+ struct dls_info *dls_hash[STA_HASH_SIZE];
+ spinlock_t dls_lock;
};
enum sta_link_direction {
@@ -687,6 +702,8 @@ struct sta_info * ieee80211_ibss_add_sta
u8 *addr);
int ieee80211_sta_deauthenticate(struct net_device *dev, u16 reason);
int ieee80211_sta_disassociate(struct net_device *dev, u16 reason);
+void dls_info_stop(struct ieee80211_local *local); int
+dls_link_status(struct ieee80211_local *local, u8 *addr);
/* ieee80211_dev.c */
int ieee80211_dev_alloc_index(struct ieee80211_local *local); diff
--git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c index
81b2ded..393a294 100644
--- a/net/d80211/ieee80211_sta.c
RE: d80211-drivers pull request (week-48)
Devicescape does understant that the hardware can do retries - but it adds software retries on top. This allows higher reliability, as well as correct handling of the powersave state machine. (PS bit from a STA is supposed to stop APs transmission immediately). Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Tuesday, December 12, 2006 1:35 AM To: Daniel Drake Cc: Michael Wu; John Linville; netdev@vger.kernel.org; Ulrich Kunitz Subject: Re: d80211-drivers pull request (week-48) On Tuesday 12 December 2006 02:07, Daniel Drake wrote: Michael Wu wrote: zd1211rw-d80211: Use ieee80211_tx_status I've thought some more about this and I'm not so sure that this is the right approach. Can't devicescape be taught that the ZD1211 handles retries in hardware and the stack doesn't need to worry about it? What does devicescape do in response to not getting an ack? It does ratecontrol based on that. Basically: No ACK == failed packet. If too many failures, lower the rate. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless notes / pre d80211 merge
Hi Jiri, I disagree that the master device is a hack - I also disagree that we should use 802.11 format frames anywhere but internally inside the 802.11 stack. The 802.11 specification does not use 802.11 format frames to communicate with the upper layers - it uses almost exactly the same interface as 802.3 ethernet does. This is a 2 address interface. I believe that using the standard 2 address format to talk with upper layers matches well with the spec and is the right way to do things. If you put 802.11 frame format directly into the L3 protocols then you make all these protocols depend on the MAC - since they will now implement part of the MAC inside the L3 protocol. I don't think this is the right thing to do. I believe that the mapping of 3 and 4 address frames to a particular virtual 2 address port is the right way to do this mapping. It is normal to have a single interface to represent the physical hardware network interface. This is exactly the pattern that many other physical network devices use. Things like sniffing should go on on this physical interface - and the changes that johannes proposes are exactly the right things to enable this. I would go further - and perhaps move some of the meta-data that is in the skb-cb into a d80211 specific hardware header. This would allow sniffers to directly attach to the master device and both send and receive frames complete with the meta data. It would also reduce the amount of cb space we need. Virtual devices could be created in order to use sniffers that use a different hardware header format (with a small performance penalty when using those). Simon -Original Message- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 6:11 PM To: Johannes Berg Cc: netdev; Jeff Garzik; John W. Linville; Simon Barber; Michael Buesch; Ivo van Doorn; Michael Wu; Jouni Malinen; Daniel Drake; Hong Liu; Luis R. Rodriguez; James Ketrenos; David Kimdon; Udayan Singh Subject: Re: wireless notes / pre d80211 merge On Tue, 14 Nov 2006 23:19:57 +0100, Johannes Berg wrote: 1. master netdev Currently, we have the 'master' netdev wmasterN which is created as native 802.11 device but is essentially useless. It is exported to userspace but only supports wireless extensions and, depending on what the drivers do, ethtool ops. It isn't really useful for network functionality although outgoing frames can be seen on it. See section (3) for why. I wouldn't say useless. It's actually a hack (and you yourself described in (7) why it is currently necessary). We'll need to live with it or cripple the stack to support only very basic features or rewrite the Linux networking core. Choose your own favorite solution :-) [1] why we didn't make a static inline ieee80211_rx() that calls an exported __ieee80211_rx() until we get rid of the other ieee80211 is beyond me. Would have been good but I guess we can also just convert all the drivers when we change the name again. Yes, it's just temporary and it doesn't matter. 3. skb path during tx This is more complicated. When a frame is created in one of the virtual interfaces, it first goes through through conversion from 802.3 into 802.11, some tx control is added on and the frame is queued to the master netdev. This is why we see outgoing frames in tcpdump. After getting queued to the master netdev, the frame goes through the qdiscs and some more info is tacked on into skb-cb by the 802.11 qdisc. Afterwards, if the frame is not dropped, it shows up in ieee80211_master_start_xmit where skb-cb is copied onto the stack and cleared afterwards. Then, the frame goes through all the tx handlers including fragmentation and encryption and is finally given to the lowlevel driver via the hardware description's tx() call. During the tx handlers phase that copy of skb-cb is extended quite a lot with other information determined in the tx handlers. The result is a structure that doesn't fit into cb anymore. This is a reason for not using cb to pass tx information to drivers. 4. wiphy concept Straying a bit from the discussion of frames and similar, let me describe the wiphy concept we currently have. Currently, in sysfs we have class/ieee80211/phy%d/ and below that a wealth of information not only about various hardware related things but also, for example, a list of all stations associated to any virtual access points intermixed with those 'stations' that we are associated to on any virtual interface. Also, we here find 'add_iface' and 'remove_iface', knobs to create and destroy virtual interfaces. The second wiphy concept is currently present in cfg80211 which currently requires this concept in the userspace interface and should effectively replace the 'add_iface' and 'remove_iface' hooks and make them more generically available for non-d80211 drivers. I was thinking of ipw2200 when I wrote it which allows adding a monitor device (currently
RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc
I'm not sure why we don't use the master device for packet capture - I can't think of any good reason for requiring a separate device. I would think the master device is the perfect place to do packet capture, and raw packet transmission. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 2:57 PM To: Stephen Hemminger Cc: Simon Barber; Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc On Thu, 2006-11-02 at 14:34 -0800, Stephen Hemminger wrote: It makes 802.11 packet capture easier as well. Please don't invent yet another network access object for the master device. Oh, but the master device doesn't get any packets you could capture. For that, you need to add a monitor interface. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc
I should elaborate - if 802.11 is made into a real protocol - then raw packet capture works correctly on the master device. (raw sockets opened on the device see all frames before they are passed to the protocol). This is the right way to go. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Barber Sent: Friday, November 03, 2006 11:24 AM To: Johannes Berg; Stephen Hemminger Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc I'm not sure why we don't use the master device for packet capture - I can't think of any good reason for requiring a separate device. I would think the master device is the perfect place to do packet capture, and raw packet transmission. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 2:57 PM To: Stephen Hemminger Cc: Simon Barber; Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specificqdisc On Thu, 2006-11-02 at 14:34 -0800, Stephen Hemminger wrote: It makes 802.11 packet capture easier as well. Please don't invent yet another network access object for the master device. Oh, but the master device doesn't get any packets you could capture. For that, you need to add a monitor interface. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops ratherthand80211-specificqdisc
I guess right now when you transmit on the master device frames are only accepted with a cookie and all that info in the CB. It would work just as well to move that info from the CB and into a protocol header. It would also make it easier to expand the info without the size constraint of the CB. Same could apply on receive. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 3:07 PM To: Simon Barber Cc: Stephen Hemminger; Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: RE: [patch] d80211: use pfifo_qdisc_ops ratherthand80211-specificqdisc On Fri, 2006-11-03 at 11:23 -0800, Simon Barber wrote: I would think the master device is the perfect place to do packet capture, Sort of. Since it'll be an 802.11 protocol thing, you won't be getting any signal strength information etc. You really do need that. and raw packet transmission. Same here, you really do want to be able to submit a frame with the bitrate to use etc. All not part of 802.11. All the meta info you want from RX or need for proper TX cannot be transported over that master netdev since it'll have a proper 802.11 protocol, so it's pretty much useless. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc
There are many reasons to have the master device - and many reasons not to get rid of it. The only excpetion is when using a limited fullmac card. Some fullmac cards only support a single ethernet interface, so for these cards a single device may be OK, if we want to allow multiple different appearences for different types of card (a bad thing in my book). (Note - older prism 54g fullmac cards support WDS, hence need multiple interfaces). The master interface represents the physical networking device that works using native 802.11 frames. The qdisc works on 802.11 frames - not ethernet, and it can change how 802.11 management frames are queued. It can only be got rid of in the case of a fullmac card with only a single interface, where all management frames are processed in the card. In addition as we move to make 802.11 devices native (i.e. create an 802.11 protocol) the 802.11 master interface will be essential. I don't see the problem with 802.11 master devices - they are not ethernet devices, and should not confuse any user space. Any user space that gets confused by netdevices with arp-hdr types that they do not recognise is broken, and needs to be fixed. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 6:23 AM To: Christoph Hellwig Cc: James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc On Thu, 2006-11-02 at 15:05 +0100, Jiri Benc wrote: - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. Actually, just as a note to all the others (talked to Jiri about it already), I think it's easier than thought since the code is so convoluted. The only purpose of the wmaster device appears to be to have an outgoing frame queue through the qdisc. Since we require the 802.11 qdisc to be installed at the root for all netdevices anyway, we could just as well hand the frame to it right away. I'll look into that later today. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
I don't believe it makes sense to change the frame type except for the master interface. The interface to an 802.11 MAC (the MAC-SAP) is very similar to the interface to an 802.3 MAC. It is a 2 address format - not 3 or 4. The master interface is an internal part of the MAC, and here 802.11 frames are essential. Simon -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 6:46 AM To: Johannes Berg Cc: Christoph Hellwig; Jiri Benc; James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, Nov 02, 2006 at 03:32:34PM +0100, Johannes Berg wrote: On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. [1] I really hate config options affecting the abi, but this is a tough problem as we can't have a etdevice with different frametypes for the same piece of hardware. maybewe could at least make it a module option.. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Perhaps the solution is to allow the prefix to be a kernel configuration item? Simon -Original Message- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 10:39 AM To: Sven-Haegar Koch Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
Getting people to use wpa_supplicant almost exclusivly as the interface for wireless will improve a lot of things. One thing that might help here is to do some work on the wpa_cli - to make it easier for the startup scripts to do what they need, and also to make the command syntax easier for command line users to do what they need. Simon -Original Message- From: Dan Williams [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 8:33 AM To: Luis R. Rodriguez Cc: Johannes Berg; Michael Wu; Simon Barber; David Kimdon; netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean Tourrilhes; Hong Liu; Jouni Malinen Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 On Thu, 2006-10-26 at 11:04 -0400, Luis R. Rodriguez wrote: On 10/26/06, Dan Williams [EMAIL PROTECTED] wrote: While wpa_supplicant is certainly the main client for stuff directly related to setting up a connection, there are quite a few other users of general WE calls to pull information out of the card, or to receive scan events. How about we just ditch iwconfig completely and move on to wpa_supplicant/wpa_cli as our next userspace application with nl80211/cg80211 as our new API for usersapce--kernel communication? As you point out, wpa_supplicant already does a lot for us -- and several distributions already rely on it. Some work is required but I think its worth it. If we do a complete move from WE to nl80211 it would be transparent to the users too. The one blocker I can think of here is startup scripts on various distributions. Most of those are shell, and they usually rely on iwconfig quite heavily. Getting those converted to wpa_supplicant wouldn't be a trivial amount of work, but it wouldn't be a ton either. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: about 802.11i IBSS support
One area that needs work is the 802.11 qdisc - there is no provision in the current implementation for queueing certain frames because the 802.11 link is not ready to traqnsmit them yet, while letting other frames through. E.G. for normal client mode links it would be nice for the qdisc to allow management frames and EAPOL frames to an AP through while mid roam to another AP - but to queue other data frames until EAPOL has sucessfully completed. In the IBSS case a similar mechanism could queue data frames sent to a particular destination, until a key has been negociated with that destination. Indeed if the mechanism is generic the client mode case should be a subset of the IBSS case. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Wednesday, October 25, 2006 8:48 AM To: Hong Liu Cc: Jiri Benc; netdev Subject: Re: about 802.11i IBSS support On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. In addition, there will likely be need for some new kernel-to-userspace events to notify supplicant/authenticator that communication with a new target is needed. I don't think the standard has strict requirements on how this is done and there may be different preferences based on the application, so adding a generic mechanism for this would be nice. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? This is on my to-do list for wpa_supplicant/hostapd 0.6 branch where it will be possible to link in part of wpa_supplicant and hostapd together into a single program. In other words, the authenticator code (both IEEE 802.1X/EAPOL and WPA/WPA2) will be available from hostapd. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Patrick McHardy
Sent: Wednesday, October 25, 2006 4:29 PM
To: David Kimdon
Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than
d80211-specific qdisc
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This
allows removal of net/d80211/fifo_qdisc.c which isn't particularily
tied to IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc) {
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev,
CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev,
pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation
failed, dev-name,
i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe thats a
better choice to avoid unnecessary bloat.
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
The Wi-Fi alliance's test plans for their WMM specification are written assuming you use certain specific DSCP values. Since WMM is the only QoS mechanism that is widely used with 802.11 I followed the WMM values in the default 802.11 qdisc implementation. Most windows 802.11 drivers do the same thing. Simon -Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 6:50 PM To: Simon Barber Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. It wouldn't really hurt though since all frames queued to a band already have the same priority, so pfifo_fast behaves similar to fifo. BTW, is there a specific reason for using DSCP? Normally Linux uses rt_tos2priority and prio2band for determining a priority for IP packets. I don't want to argue that one is better than the other, but there is some value in keeping things consistent .. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: about 802.11i IBSS support
It's not possible to 'negotiate keys at the beginning' - since there is no indication of a new station joining an IBSS. The first you ever know about a station joining an IBSS is when you receive a frame from that station. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hong Liu Sent: Wednesday, October 25, 2006 7:47 PM To: Jouni Malinen Cc: Jiri Benc; netdev Subject: Re: about 802.11i IBSS support On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote: On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. This may add complexity to the implementation. If the STA wants to send broadcast data, it must distribute its group key to all other STAs, and then it can send out the packet. For RX, if it receives data from other STA it needs to find out whether it has finished key negotiation with that STA. And it can not decrypt the data until key negotiation is finished. If we negotiate keys at the beginning, things will be simple. But the cost is we may negotiating keys with STAs we may not communicate with. Thanks, Hong - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik Sent: Wednesday, October 25, 2006 7:39 PM To: Patrick McHardy Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote: Considering that it is possibly and may be desirable to attach a different qdisc than the built-in multiband qdisc, it might also make sense to split the 80211 specific classification in a seperate classifier module to allow simple classification of management traffic with other qdiscs. I've been telling the wireless people this for ages... Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) I would also like to see: Drivers to use register_netdev - not special ieee80211 register to register themselves Drivers to use a normal hard_start_xmit function - need to move 802.11 pre xmit frame processing into the qdisc dequeue function Get rid of gunky beacon multicast buffered frame handling - make them into normal queues like everything else (so same hard_start_xmit can be used). Simon -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 10:04 PM To: Simon Barber Cc: Patrick McHardy; David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote: Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. First do it right, then tune performance. If you aren't doing it right, then who cares about VxWorks. We also need 802.11 to register as a real protocol, rather than faking ethernet. David Miller did an example stub: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/dave m-p80211.tar.bz2 Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
The Client MLME code in the kernel was only ever written to be used for quick testing. It does not have good roaming performance, and was never intended to be a complete client. The right place for the Client MLME is in userspace, where it can be closely coupled with the supplicant, and better scanning and roaming decisions can be made. If the Client MLME is removed from the kernel, then a userspace part is always required in order for 802.11 to be used at all. (It's already required in order to use any of the recent security modes, or have automatic network selection, or decent roaming). In this case the regulatory constraints can be set in a privileged userspace deamon. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Kimdon Sent: Tuesday, October 24, 2006 7:02 AM To: Luis R. Rodriguez Cc: netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean Tourrilhes Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 Hi, The following patches extend 802.11 regulatory domain support of the d80211 wireless stack through two modules: 1. ieee80211_regdomains 2. iso3166-1 I am glad to see this work, this is something that we need a solution for. I do wonder if we can push most of this out of the kernel and into userspace. We could hard code a single set of constraints in the kernel which may be used world wide (802.11b channels 1-11, is that allowed everywhere?). Then we have a userspace tool which passes updated regulatory information into the kernel based on the user's country input. -David - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
Hi Luis, The CVS version of wpa_supplicant implements a user space Client MLME. Are there any FullMAC clients that do not also do regulatory in the hardware? (Intel 2100/2200?) Simon -Original Message- From: Luis R. Rodriguez [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 3:03 PM To: Simon Barber Cc: David Kimdon; netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean Tourrilhes Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 On 10/24/06, Simon Barber [EMAIL PROTECTED] wrote: The Client MLME code in the kernel was only ever written to be used for quick testing. It does not have good roaming performance, and was never intended to be a complete client. The right place for the Client MLME is in userspace, where it can be closely coupled with the supplicant, and better scanning and roaming decisions can be made. If the Client MLME is removed from the kernel, then a userspace part is always required in order for 802.11 to be used at all. (It's already required in order to use any of the recent security modes, or have automatic network selection, or decent roaming). In this case the regulatory constraints can be set in a privileged userspace deamon. We also have to take into consideration FullMAC devices where we don't need an MLME implemented in kernel/userspace and how regulatory domain control will dictate their behaviour. My approach here was to support a map between stack regulatory domain values and device regulatory domain values. This is currently provided by ieee80211_regdomains. We can add to ieee80211_conf a ieee80211_regulatory_map and if defined d80211 will simply call the the stack's set regdomain which the device implements and sets the regdomain internally to whatever the device should have. Mind you I realize most new devices are taking the SoftMAC design approach and while these vary ultimately I do agree with your point. All that said though: 1. Anyone working on completing FullMAC support on d80211? 2. Who's working on a userspace MLME replacement for d80211 and where are we with that? 3. Who's doing the endianness/smp testing of d80211 and how far are we with that? Lastly, as I have said in previous e-mails -- I agree with a userspace daemon but where is it and how long before its ready.. also it may be difficult to introduce as a requirement for distributions and for this reason I am suggesting going with in-kernel regulatory domain control and now perhaps in-kernel MLME for a first stable push of d80211, specially since only... 3 in-kernel drivers currently use d80211! Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 1/5] d80211: remove bitfields from ieee80211_tx_control
Removing the bitfields makes the code much harder to read and maintain. Here we are working around a problem with the compiler by making the code ugly - rather than fixing the compiler. The compilers are getting better and better (GCC 4 has much better handling of this type of optimization) but the code will remain ugly for ever. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Monday, October 16, 2006 9:07 AM To: David Kimdon Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch 1/5] d80211: remove bitfields from ieee80211_tx_control On Friday 13 October 2006 21:20, David Kimdon wrote: All one-bit bitfields have been subsumed into the new 'flags' structure member and the new IEEE80211_TXCTL_* definitions. The multiple bit members were converted to u8, s8 or u16 as appropriate. And, eh, did this increase or decrease the struct size? Does this generate better or worse code? -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [d80211] connecting to B-mode AP
The extended rates element is only needed if there are more than 8 rates to report - which is normal for G operation, but not necessary. It only exists because a particularly popular old 11b MAC codebase crashed when the normal rate element had more than 8 elements, and this hurt interoperability with early G AP implementations - so the spec was changed. Simon -Original Message- From: Michael Wu [mailto:[EMAIL PROTECTED] Sent: Saturday, September 16, 2006 10:05 AM To: mabbas Cc: Simon Barber; netdev@vger.kernel.org Subject: Re: [d80211] connecting to B-mode AP On Friday 15 September 2006 19:50, mabbas wrote: I see your point here, although some one will file some bugs against the driver about showing G while associating with B-mode AP. By the way how can you figure if the AP is B/G other than the rates? IIRC, only 802.11g APs will send the extended rate information element, though I don't know if forcing 802.11b on the AP will cause it to stop sending that. (but it might still be okay if it doesn't - it's still a 802.11g AP, with the faster speeds turned off..) -Michael Wu - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [d80211] connecting to B-mode AP
But it's not the AP connection type that determines what rates are available - it's the available rate set - this is independent of whether the card is B or G. A G AP may only advertise B rates, even though it's a G AP. I still don't see any need to change the phytype. Simon -Original Message- From: mabbas [mailto:[EMAIL PROTECTED] Sent: Friday, September 15, 2006 10:19 AM To: Simon Barber Cc: netdev@vger.kernel.org Subject: Re: [d80211] connecting to B-mode AP Simon Barber wrote: Why is it necessary to set phymode to B? - a G client can connect perfectly well to a B AP. We need this information for rate scaling and we need to send the NIC different command depends on the AP connection type. Mohamed Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mabbas Sent: Thursday, September 14, 2006 4:25 PM To: netdev@vger.kernel.org Subject: [d80211] connecting to B-mode AP When I connect to b-mode only AP and then run iwconf it shows it as a G-mode AP. I guess when we set frequency it look through all the modes and set the mode to the first channel it founds. since B and G share the same frequencies it will set phymode to G. How can we force it to set phymode to the AP we are associating with. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 2/3] make d80211 use cfg80211
Hi Johannes,
Does the packet injection allow hostapd to use nl80211 instead of the
wlan0ap interface to send management frames? Important features for this
include requesting a transmit status - i.e. the ability for
hostapd/wpa_supplicant to know if the frame got acked or not.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Johannes Berg
Sent: Thursday, September 14, 2006 3:50 AM
To: netdev@vger.kernel.org
Cc: John W. Linville; Michael Buesch; Jean Tourrilhes; Jiri Benc; James
P. Ketrenos; Mohamed Abbas; Ulrich Kunitz; Daniel Drake
Subject: [RFC 2/3] make d80211 use cfg80211
This patch makes d80211 partially configurable using the infrastructure
that nl80211 provides. So far, it allows packet injection and
adding/removing virtual interfaces.
Also identical to previous patches except for the file and Kconfig
renames that nl80211/cfg80211 went through.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/net/d80211/Kconfig2006-09-13
22:06:09.209647141 +0200
+++ wireless-dev/net/d80211/Kconfig 2006-09-13 22:06:12.559647141
+0200
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select CFG80211
---help---
This option enables the hardware independent IEEE 802.11
networking stack.
--- wireless-dev.orig/net/d80211/Makefile 2006-09-13
22:06:09.219647141 +0200
+++ wireless-dev/net/d80211/Makefile2006-09-13 22:06:12.559647141
+0200
@@ -8,6 +8,7 @@ obj-$(CONFIG_D80211) += 80211.o rate_con
sta_info.o \
wep.o \
wpa.o \
+ ieee80211_cfg.o \
ieee80211_scan.o \
ieee80211_sta.o \
ieee80211_dev.o \
--- wireless-dev.orig/net/d80211/ieee80211.c2006-09-13
22:06:09.209647141 +0200
+++ wireless-dev/net/d80211/ieee80211.c 2006-09-13 22:06:12.569647141
+0200
@@ -20,6 +20,7 @@
#include net/iw_handler.h
#include linux/compiler.h
#include linux/bitmap.h
+#include linux/nl80211.h
#include net/d80211.h
#include net/d80211_common.h
@@ -32,6 +33,7 @@
#include wme.h
#include aes_ccm.h
#include ieee80211_led.h
+#include ieee80211_cfg.h
/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ @@ -354,6
+356,16 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021 {
struct rate_control_extra extra;
+ /* FIXME
+ if (tx-dev == tx-local-mdev
+ (inject rate set)) {
+ a
+ tx-u.tx.rate = ...
+ etc etc
+ return TXRX_CONTINUE;
+ }
+ */
+
memset(extra, 0, sizeof(extra));
extra.mgmt_data = tx-sdata
tx-sdata-type == IEEE80211_IF_TYPE_MGMT; @@ -759,6
+771,13 @@ ieee80211_tx_h_misc(struct ieee80211_txr
u16 dur;
struct ieee80211_tx_control *control = tx-u.tx.control;
+ /* FIXME
+ if (tx-dev == tx-local-mdev) {
+ set up retry limit, ...
+ based on injection parameters
+ }
+ */
+
if (!is_multicast_ether_addr(hdr-addr1)) {
if (tx-skb-len + FCS_LEN tx-local-rts_threshold
tx-local-rts_threshold
IEEE80211_MAX_RTS_THRESHOLD) { @@ -884,6 +903,9 @@
ieee80211_tx_h_check_assoc(struct ieee80 #endif /*
CONFIG_D80211_VERBOSE_DEBUG */
u32 sta_flags;
+ if (unlikely(tx-dev == tx-local-mdev))
+ return TXRX_CONTINUE;
+
if (unlikely(tx-local-sta_scanning != 0)
((tx-fc IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT ||
(tx-fc IEEE80211_FCTL_STYPE) !=
IEEE80211_STYPE_PROBE_REQ)) @@ -987,6 +1009,12 @@ static void
purge_old_ps_buffers(struct static inline ieee80211_txrx_result
ieee80211_tx_h_multicast_ps_buf(struct ieee80211_txrx_data *tx) {
+ /* FIXME
+ if (unlikely(tx-dev == tx-local-mdev
+ (inject flags) NL80211_FLAG_NOBUFFER))
+ return TXRX_CONTINUE;
+ */
+
/* broadcast/multicast frame */
/* If any of the associated stations is in power save mode,
* the frame is buffered to be sent after DTIM beacon frame */
@@ -1414,11 +1442,12 @@ static int ieee80211_master_start_xmit(s
control.ifindex = odev-ifindex;
control.type = osdata-type;
- control.req_tx_status = pkt_data-req_tx_status;
- control.do_not_encrypt = pkt_data-do_not_encrypt;
+ control.req_tx_status = !!(pkt_data-flags
NL80211_FLAG_TXSTATUS);
+ control.do_not_encrypt = !(pkt_data-flags
NL80211_FLAG_ENCRYPT);
control.pkt_type =
- pkt_data-pkt_probe_resp ? PKT_PROBE_RESP : PKT_NORMAL;
- control.requeue = pkt_data-requeue;
+ (pkt_data-internal_flags TX_FLAG_PROBERESP) ?
+ PKT_PROBE_RESP : PKT_NORMAL;
+ control.requeue = !!(pkt_data-internal_flags
TX_FLAG_REQUEUE);
control.queue = pkt_data-queue;
ret =
RE: [d80211] connecting to B-mode AP
Why is it necessary to set phymode to B? - a G client can connect perfectly well to a B AP. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mabbas Sent: Thursday, September 14, 2006 4:25 PM To: netdev@vger.kernel.org Subject: [d80211] connecting to B-mode AP When I connect to b-mode only AP and then run iwconf it shows it as a G-mode AP. I guess when we set frequency it look through all the modes and set the mode to the first channel it founds. since B and G share the same frequencies it will set phymode to G. How can we force it to set phymode to the AP we are associating with. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] Try 2: Add wireless statistics to d80211
Why have both signal and rssi measures?
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Larry Finger
Sent: Wednesday, August 23, 2006 8:02 PM
To: Jiri Benc
Cc: John Linville; netdev@vger.kernel.org
Subject: [PATCH 1/4] Try 2: Add wireless statistics to d80211
This patch modifies d80211 to add wireless statistics.
Signed-Off-By: Larry [EMAIL PROTECTED]
==
diff --git a/include/net/d80211.h b/include/net/d80211.h index
42fdbf7..70655dc 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -205,6 +205,8 @@ struct ieee80211_rx_status {
int channel;
int phymode;
int ssi;
+ int signal;
+ int noise;
int antenna;
int rate;
int flag;
@@ -499,6 +501,9 @@ struct ieee80211_hw {
/* This is the time in us to change channels
*/
int channel_change_time;
+ /* This is maximum value of rssi reported by this interface
+*/
+ int maxssi;
int num_modes;
struct ieee80211_hw_modes *modes;
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c index
e72721f..2549484 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -3175,6 +3175,8 @@ ieee80211_rx_h_sta_process(struct ieee80
sta-rx_fragments++;
sta-rx_bytes += rx-skb-len;
sta-last_rssi = rx-u.rx.status-ssi;
+ sta-last_signal = rx-u.rx.status-signal;
+ sta-last_noise = rx-u.rx.status-noise;
if (!(rx-fc IEEE80211_FCTL_MOREFRAGS)) {
/* Change STA power saving mode only in the end of a
frame diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 0d2d79d..1271513 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -336,6 +336,7 @@ struct ieee80211_local {
struct net_device *apdev; /* wlan#ap - management frames
(hostapd) */
int open_count;
int monitors;
+ struct iw_statistics wstats;
struct ieee80211_conf conf;
int dev_index;
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 89a58e3..b121302 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1581,6 +1581,16 @@ static int ieee80211_ioctl_giwrange(stru
range-min_frag = 256;
range-max_frag = 2346;
+ range-max_qual.qual = 100;
+ range-max_qual.level = 146; /* set floor at -110 dBm (146 -
256) */
+ range-max_qual.noise = 146;
+ range-max_qual.updated = IW_QUAL_ALL_UPDATED;
+
+ range-avg_qual.qual = 50;
+ range-avg_qual.level = 0;
+ range-avg_qual.noise = 0;
+ range-avg_qual.updated = IW_QUAL_ALL_UPDATED;
+
return 0;
}
@@ -2996,6 +3006,39 @@ static int ieee80211_ioctl_siwauth(struc
return ret;
}
+/* Get wireless statistics. Called by /proc/net/wireless and by
+SIOCGIWSTATS */ static struct iw_statistics
+*ieee80211_get_wireless_stats(struct net_device *net_dev) {
+ struct ieee80211_local *local = net_dev-ieee80211_ptr;
+ struct iw_statistics * wstats = local-wstats;
+ struct ieee80211_sub_if_data *sdata =
IEEE80211_DEV_TO_SUB_IF(net_dev);
+ struct sta_info *sta;
+ static int tmp_level = 0;
+ static int tmp_qual = 0;
+
+ sta = sta_info_get(local, sdata-u.sta.bssid);
+ if (!sta) {
+ wstats-discard.fragment = 0;
+ wstats-discard.misc = 0;
+ wstats-qual.qual = 0;
+ wstats-qual.level = 0;
+ wstats-qual.noise = 0;
+ wstats-qual.updated = IW_QUAL_ALL_INVALID;
+ } else {
+ if (!tmp_level) { /* get initial values */
+ tmp_level = sta-last_signal;
+ tmp_qual = sta-last_rssi;
+ } else {/* smooth results */
+ tmp_level = (15 * tmp_level +
sta-last_signal)/16;
+ tmp_qual = (15 * tmp_qual + sta-last_rssi)/16;
+ }
+ wstats-qual.level = tmp_level;
+ wstats-qual.qual = 100*tmp_qual/local-hw-maxssi;
+ wstats-qual.noise = sta-last_noise;
+ wstats-qual.updated = IW_QUAL_ALL_UPDATED |
IW_QUAL_DBM;
+ }
+ return wstats;
+}
static int ieee80211_ioctl_giwauth(struct net_device *dev,
struct iw_request_info *info,
@@ -3019,7 +3062,6 @@ static int ieee80211_ioctl_giwauth(struc
return ret;
}
-
static int ieee80211_ioctl_siwencodeext(struct net_device *dev,
struct iw_request_info *info,
struct iw_point *erq, char
*extra) @@ -3184,6 +3226,7 @@ const struct iw_handler_def ieee80211_iw
.standard = (iw_handler *) ieee80211_handler,
.private= (iw_handler *) ieee80211_private_handler,
.private_args =
RE: [patch 5/5] d80211: add ioctl to stop data frame tx
David - how long does the data flow need to be stopped when radar is
detected? If it's a short time it would be better to buffer the data
frames, if the connection can be disabled for a long time then dropping
them might be better.
There is one other application where data frames should be buffered - in
a client while roaming between 2 APs. The best way to implement this
will be to extend the 802.11 qdisc. Currently there are 4 queues,
representing the 4 EDCA access categories. Only the top AC (AC_VO) is
used for sending management frames. I would recommend we split the
qdisc, so that there are 2 software queues attached to this AC - one for
management frames and 802.1x, and another for data frames. This way if
we want to stop data (either for radar, or because we are mid BSS
transition) we can simply stop all the queues except the AC_VO
management queue.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Johannes Berg
Sent: Wednesday, August 23, 2006 12:25 AM
To: David Kimdon
Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch 5/5] d80211: add ioctl to stop data frame tx
On Tue, 2006-08-22 at 10:34 -0700, David Kimdon wrote:
This ioctl is used when radar is delected on a channel. Data frames
must stop but management frames must be allowed to continue for some
time to communicate the channel switch to stations.
Which does lead to the question: How are you detecting radar in
userspace in the first place??
+ if (unlikely(local-stop_data_frame_tx)) {
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)
skb-data;
+ u16 fc = le16_to_cpu(hdr-frame_control);
+ if ((fc IEEE80211_FCTL_FTYPE) ==
IEEE80211_FTYPE_DATA) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
Should that really drop dataframes dead on the floor? And wouldn't it
make sense stop the networking layer from injecting more data into the
stack when stop_data_frame_tx is enabled?
+static int ieee80211_ioctl_set_stop_data_frame_tx(struct net_device
*dev,
+ int val) {
+ struct ieee80211_local *local = dev-ieee80211_ptr;
+local-stop_data_frame_tx = val;
+return 0;
+}
Again, whitespace damaged. Yes, I know it's hard to code in there with
any smart editor that thinks it knows what to do based on the
surroundings because those may also contain whitespace...
+ret = ieee80211_ioctl_set_stop_data_frame_tx(dev,
+ value);
Ditto.
johannes
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] d80211: add ieee80211_stop_queues()
One question - in most hardware implementations today the queues are DMA
rings. In this case the right length of the queue is determined by the
interrupt/tx_softirq latency required to keep the queue from becoming
empty. With 802.11 there are large differences in the time it takes to
transmit different frames - a full size 1Mbit frame vs. a short 54Mbit
frame. Would it be worth optimizing the DMA queue length to be a
function of the amount of time rather than number of frames?
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Buesch
Sent: Wednesday, August 23, 2006 4:44 AM
To: Jiri Benc
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: [PATCH] d80211: add ieee80211_stop_queues()
Add ieee80211_stop_queues() to stop all queues with a single call.
I will submit a patch for bcm43xx to use this function as soon as this
got merged.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h 2006-08-19
18:26:05.0 +0200
+++ wireless-dev/include/net/d80211.h 2006-08-23 13:38:41.0
+0200
@@ -826,6 +826,15 @@
void ieee80211_start_queues(struct net_device *dev);
/**
+ * ieee80211_stop_queues - stop all queues
+ * @dev: pointer to $struct net_device as obtained from
+ * ieee80211_alloc_hw().
+ *
+ * Drivers should use this function instead of netif_stop_queue.
+ */
+void ieee80211_stop_queues(struct net_device *dev);
+
+/**
* ieee80211_get_mc_list_item - iteration over items in multicast list
* @dev: pointer to struct net_device as obtained from
* ieee80211_alloc_hw().
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c2006-08-19
18:26:05.0 +0200
+++ wireless-dev/net/d80211/ieee80211.c 2006-08-23 13:41:34.0
+0200
@@ -4690,6 +4690,15 @@
clear_bit(IEEE80211_LINK_STATE_XOFF, local-state[i]);
}
+void ieee80211_stop_queues(struct net_device *dev) {
+ struct ieee80211_local *local = dev-ieee80211_ptr;
+ int i;
+
+ for (i = 0; i local-hw-queues; i++)
+ ieee80211_stop_queue(dev, i);
+}
+
void * ieee80211_dev_hw_data(struct net_device *dev) {
struct ieee80211_local *local = dev-ieee80211_ptr; @@ -4819,6
+4828,7 @@ EXPORT_SYMBOL(ieee80211_wake_queue);
EXPORT_SYMBOL(ieee80211_stop_queue);
EXPORT_SYMBOL(ieee80211_start_queues);
+EXPORT_SYMBOL(ieee80211_stop_queues);
EXPORT_SYMBOL(ieee80211_dev_hw_data);
EXPORT_SYMBOL(ieee80211_dev_stats);
EXPORT_SYMBOL(ieee80211_get_hw_conf);
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] d80211: add ieee80211_stop_queues()
I'd agree the memory benefit is not worth the work and complexity. The additional benefit is tighter queue control - reducing the latency between the software qdisc (and whatever scheduling/rate controlling/etc work they are doing) and the frames coming out of the hardware. A 100 frame DMA queue can be 1.2 seconds of transmit time, or it can be 30ms of transmit time depending on frame size and transmission rate. This disparity will only get larger as rates go up with 11n. A further benefit in reducing this latency - is to keep the latency between the software rate control algorithm (which sees frames before they hit the DMA queue) and the hardware tx down. This allows the software rate control to be more responsive. Simon -Original Message- From: Michael Buesch [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 12:45 PM To: Simon Barber Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: [PATCH] d80211: add ieee80211_stop_queues() On Wednesday 23 August 2006 21:30, Simon Barber wrote: One question - in most hardware implementations today the queues are DMA rings. In this case the right length of the queue is determined by the interrupt/tx_softirq latency required to keep the queue from becoming empty. With 802.11 there are large differences in the time it takes to transmit different frames - a full size 1Mbit frame vs. a short 54Mbit frame. Would it be worth optimizing the DMA queue length to be a function of the amount of time rather than number of frames? I doubt that the added complexity would do any good. We should look at what a ring actually is. A ring is an allocated memory space with dma descriptors in it. The ring size if the number of dma descriptors. So theoretically the number of descriptors adds up to the size to allocate. In practice we have alignment issues (at least for bcm43xx). For a ring we always allocate one page of memory. Regardless of how much of it is actually used by descriptors. One wireless-specific thing remains, though. We store meta data for each descriptor (The ieee80211_tx_control at least). So basically only the memory consumption of the meta data could be optimized. We used to have 512 TX descriptors for each ring until I recently submitted a patch to lower it to 128. I did this because after doing stress tests the maximum amount of used descriptors did not go over about 80 on my machines. I think it basically comes down to the question: Do we want to save 1 kb of memory[*] but pay the price of additional code complexity? [*] 1kb is a random value invented by me. I did not calculate it, but it should be somewhere around that value. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] d80211: add ieee80211_stop_queues()
The DMA ring forms a queue of frames. Frames live in that queue for some time before they are transmitted. This is a source of latency between the software process that puts the frames in the queue and the point in time when they are actually transmitted. Simon -Original Message- From: Michael Buesch [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 1:05 PM To: Simon Barber Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: [PATCH] d80211: add ieee80211_stop_queues() On Wednesday 23 August 2006 21:54, Simon Barber wrote: I'd agree the memory benefit is not worth the work and complexity. The additional benefit is tighter queue control - reducing the latency between the software qdisc (and whatever scheduling/rate controlling/etc work they are doing) and the frames coming out of the hardware. A 100 frame DMA queue can be 1.2 seconds of transmit time, or it can be 30ms of transmit time depending on frame size and transmission rate. This disparity will only get larger as rates go up with 11n. A further benefit in reducing this latency - is to keep the latency between the software rate control algorithm (which sees frames before they hit the DMA queue) and the hardware tx down. This allows the software rate control to be more responsive. Hm, I don't really see how a larger DMA ring adds latency. A DMA ring is endless. From the device and driver point of view it only goes forward. If we reach the physical end while going forward, we simply start at the beginning again. Both, device and driver maintain very simple pointers into the ring that are simply incremented. TX notification latency is only controlled by a flag in the descriptor control. We currently request an IRQ for each frame, so latency is as low as possible here. Maybe I don't understand what you are trying to explain, but I don't see a benefit other than lower memory usage by reducing DMA ring length. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] d80211: add ieee80211_stop_queues()
Right - and what I'm proposing is that we don't just count the number of frames in the ring - but also count the amount of frame time the ring takes too. This way if there are a number of large, slow frames we can stop adding more frames into the ring well before we reach the limit on the number of frames. Simon -Original Message- From: Michael Buesch [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 1:20 PM To: Simon Barber Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: [PATCH] d80211: add ieee80211_stop_queues() On Wednesday 23 August 2006 22:10, Simon Barber wrote: The DMA ring forms a queue of frames. Frames live in that queue for some time before they are transmitted. This is a source of latency between the software process that puts the frames in the queue and the point in time when they are actually transmitted. Yes, sure. But I don't see how shortening that queue reduces the time. Frames are always processed by the device as fast as possible to a given end-pointer. That end-pointer is updated on the fly as packets come in. So if enough packets come in the device keeps circling the ring. No matter how large it is. The issue that we must prevent is a ring overflow by providing a sufficiently _large_ (not small) ring. The larger the ring the better. Theoretically an infinite ring size would be perfect, but we don't want that for obvious memory issues. ;) So we try to keep ring size down to a sane amount, where it's damn unlikely to ever overflow, to reduce memory usage (and only memory usage). -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] d80211: add ieee80211_stop_queues()
We already do have intelligent qdiscs - via TC. Anyone using htb for rate pacing, will achieve better control (less jitter) if the DMA queue latency is kept down. One very important issue for 802.11 is the software rate control. At a certain point in time the rate control algorithm may determine it's time to start transmitting frames at a much lower rate - now all the frames already in the DMA queue will be transmitted at the old higher rate - and hence will suffer a lower probability of being received correctly. If the number of frames in the DMA queue can be kept down then the rate change happens faster. Obviously the limiting factor is keeping the DMA queue full enough that the hardware is not starved in the worst case of softirq latency. This is a time based limit. Simon -Original Message- From: Michael Buesch [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 1:57 PM To: Simon Barber Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: [PATCH] d80211: add ieee80211_stop_queues() On Wednesday 23 August 2006 22:32, Simon Barber wrote: Right - and what I'm proposing is that we don't just count the number of frames in the ring - but also count the amount of frame time the ring takes too. This way if there are a number of large, slow frames we can stop adding more frames into the ring well before we reach the limit on the number of frames. Ah, now I understand what you are trying to explain. :) But why do we actually _want_ to stop a DMA ring, if it's not full (has free descriptors)? I can't see any benefit on it. Adding frames to the ring is done on the fly without stopping or otherwise interferring with any running transmissions queued earlier. I would say we don't care about the time it takes for the ring to go into idle on the d80211 level. I think the only thing we care at d80211 level is: Can we queue another frame? We have that logic. If a queue is not stopped, we can queue another frame. Or do you want to make the qdisc intelligent? Say, it drops a few beacons, if there are already packets queued for the next 300ms, for example. Do you want to optimize latency of payload data by dropping low-priority packets while the queue is heavily loaded? I can't see another usage for time based DMA ring accounting in d80211, yet. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [clarification request] ieee80211_tx_control.pkt_type
It might be appropriate to change it from pkt_type to a flag indicating that a timestamp should be added at TX time add_timestamp. This may well also end up being used for beacons too on hardware where the beacons are completely software generated. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 7:51 AM To: Jouni Malinen Cc: netdev@vger.kernel.org; Simon Barber; Jiri Benc Subject: Re: [clarification request] ieee80211_tx_control.pkt_type On Fri, 2006-08-18 at 07:33 -0700, Jouni Malinen wrote: Some hardware designs require this configuration for TX frames. It is used to select whether some of the fields are being filled in hardware (e.g., timestamp for Probe Response). Ah ok, timestamp makes sense. This would only be needed for AP mode and IBSS (adhoc), so it is possible that not all low-level dirvers have yet been implemented to support such operation. Right. This pkt_type was added at generic 802.11 layer in order to avoid forcing the low-level driver to even look at the 802.11 header when queuing the frame for transmission. Taken into account how simple operation it is to get the type and subtype from the frame control field, this tx ctrl pkt_type could be removed, if desired. However, it was added there for a reason. No, that's ok, I was just wondering why it is there at all. Thanks for clarifying, johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
I did mean RSSI - just about anything that when interpreted as an 8 bit unsigned int and goes up with increasing signal fits the bill as an RSSI measure. RCPI requires a certain minimum accuracy and linearity (the accuracy required is not very high). Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 12:02 AM To: Simon Barber Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes Subject: RE: proposal for new wireless configuration API On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote: The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Yeah, if you knew at least linearity it'd be more useful. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a did you mean to write RCPI there? more tightly specified signal strength measure. Ah, ok. Yes, I think we almost know how to make the bcm card report dBm instead. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a more tightly specified signal strength measure. Just saying that a RSSI value is not very useful. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 12:20 AM To: Simon Barber Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes Subject: RE: proposal for new wireless configuration API On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote: I'd suggest that the new signal strength measure should be defined as 'RCPI' - the 'Received Channel Power Indicator' - which is defined in IEEE 802.11k (the Radio Measurements amendment to 802.11). Except that we unfortunately have no way of getting this with all the reverse engineered devices :) Hence, I guess we should then have multiple different possibilities. A device reporting RCPI would be better than just reporting RSSI, but that's still better than nothing... johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
I'd suggest that the new signal strength measure should be defined as
'RCPI' - the 'Received Channel Power Indicator' - which is defined in
IEEE 802.11k (the Radio Measurements amendment to 802.11). Here is the
full text of the definition from 802.11k draft 5.0:
received channel power indicator (RCPI): An indication of the total
channel power (signal, noise, and interference) of a received IEEE
802.11 frame measured on a single channel and at the antenna connector
used to receive the frame.
The RCPI indicator is a measure of the received RF power in the selected
channel for a received frame. This parameter shall be a measure by the
PHY sublayer of the received RF power in the channel measured over the
entire received frame or by other equivalent means which meet the
specified accuracy. RCPI shall be a monotonically increasing,
logarithmic function of the received power level defined in dBm. The
allowed values for the Received Channel Power Indicator (RCPI) parameter
shall be an 8 bit value in the range from 0 through 220, with indicated
values rounded to the nearest 0.5 dB as follows:
0: Power -110 dBm
1: Power = -109.5 dBm
2: Power = -109.0 dBm
and so on where
RCPI = int{(Power in dBm +110)*2} for 0dbm Power -110dBm
220: Power -0 dBm
221-254: reserved
255: Measurement not available
RCPI shall equal the received RF power within an accuracy of +/-5 dB
(95% confidence interval) within the specified dynamic range of the
receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by
1.1.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Johannes Berg
Sent: Tuesday, August 15, 2006 11:51 PM
To: Dan Williams
Cc: netdev@vger.kernel.org; Jean Tourrilhes
Subject: Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote:
We might want to take the time to fix up a few of the ambiguities of
WEXT that we've encountered over the past few years:
Yes, I definitely agree.
o Separate attributes for signal strength units; signed integer type
for dBm, unsigned integer type for RSSI. One 8-bit var to represent
both is just too confusing for people, evidently (which is true...)
Yes, agreed, they should be separated. In general, I think that one
attribute should always have a single meaning and unit attached, except
for explicitly unit-less attributes (number of frames or whatever), or
attributes that explicitly have no stable unit (raw rssi).
o Merge functionality ENCODE and ENCODEEXT handlers into one
Good one. I'm still not sure whether we should have an attribute for
this, or a command. The whole key business seems rather complex and it
might be good to have a command 'set key' with say a possible attribute
for the mac address of a pairwise key, a key material attribute and an
IV attribute or something. Otherwise we'll end up parsing the contents
of an attribute again, which rather sucks...
On the other hand, having it as a command won't allow the user to
optimize setting the key and other things at once. I'm not too sure we
should pay all that much attention to this problem though, it can't take
forever and typically a user with such a card won't be changing the key
or parameters all the time, hence it's usually probably done only at boo
or association time.
johannes
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
A further complication happens in Japan with 802.11j, and now in the USA too - with 802.11y in the 3.65Ghz band - here there are some new channel widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter rate, giving a 5Mhz wide channel. Hence same frequency, different channel spec. Using a channel number is the way to go. If we need something to convert between the 2 it should probably be a library in user space (in hostapd or wpa_supplicant) - hostapd does have this today. It might be nice if other applications could access this data too - but I don't think it needs to be inside the kernel. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Tuesday, August 15, 2006 12:13 PM To: Dan Williams Cc: netdev@vger.kernel.org; Jean Tourrilhes; Johannes Berg Subject: Re: proposal for new wireless configuration API On Tuesday 15 August 2006 20:14, Dan Williams wrote: On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. Right, I don't have a problem with only using one or the other; but we _HAVE_ to provide a function in the driver that allows userspace programs to convert channel - frequency both ways, like you suggest below. Obviously the channel/frequency mapping isn't the same everywhere. [ or is it? I'd be very uncomfortable using the same channel #s everywhere unless some IEEE spec states exactly what the channel #s are for every frequency range that wireless stuff operates in ] The channel-freq mapping is stable. What is unstable is the allowed channels map. For APHY there are even many gaps in the map. For example channels 6, 40 and 55 may be the only ones allowed (6, 40, 55 are generated by my /brain/random device ;) ) The frequency range you mention is selected differently by another config option. In d80211 we call it the PHYMODE. Switching the PHYMODE changes the meaning of channel values and changes the output of the two functions below. So if I want to switch to channel 4 in the 2.4Ghz band, I would do: select PHYMODE B or G, select channel 4. That would lead to the card tuning to 2427 MHz. The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. No argument here; as long as we provide the mapping function in the driver for each card. Hm, I don't know if I understand this correctly. You want to implement the mapping function in every driver or in the d80211 stack? It belongs into a central place in the 80211 stack. There where regulatory domain stuff is managed, too. We need functions like: u32 ieee80211_channel_to_freq(struct ieee80211 *ieee, u8 channel); u8 ieee80211_freq_to_channel(struct ieee80211 *ieee, u32 channel); These would be used in drivers to convert values. The validity of the channel value passed from userspace would be checked in the _stack_. If the user passes an illegal value for his country, it would never reach the driver. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wlan#ap seems bogus
The purpose of the wlap0ap or wlap0mgmt interface is to communicate between hostapd/wpa_supplicant and the kernel. What travels over this interface is not quite pure 802.11 management frames - there is some meta-data with each frame, and a few special case messages. E.G. transmitted frames are returned back to user space to indicate successful transmission (required so that the MLME state machine can be correctly implemented in user space). I believe these messages form a special management protocol between the kernel and user space, and that netlink would be the best solution for this link. Switching to netlink would allow these bogus 'network' interfaces to be removed alltogether. Unfortunately I don't currently have the time to put together a patch to do this. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Berg Sent: Monday, August 14, 2006 7:04 AM To: netdev@vger.kernel.org Cc: Jouni Malinen; Jiri Benc Subject: Re: wlan#ap seems bogus Johannes Berg wrote: Hence, I think it ought to be named 'wlan#mgmt' instead. I see it's actually called wmgmt# now. Sorry. The rest of this mail still holds though. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 3945 driver using d80211
There are many different functions in a complete 802.11 implementation - and different implementations put these functions in different places. In general, I would consider the primary difference between a full-mac card and others to be the location of the MLME function. All full-mac cards perform the MLME in the card. They typically also do the conversion of data frames between 802.3 and 802.11 format in the card as well, and the inter-BSS transitions are handled in the card too. This key difference make it very unlikely that full-mac cards will implement various advanced 802.11 features - such as WDS, virtual APs, multiple clients, simultaneous client/AP modes etc etc. (Of course, by adding a large number of APIs all this can theoretically be achieved - it's just a lot more work this way). Because the full-mac cards have functions in the card that other cards do not the API for these cards will necessarily be quite different from the API for non-full-mac cards. Typically the full mac cards will only ever expose a single 802.3 interface - and hence they may not need to have an 802.11 master interface at all. They will require a user space API that includes control of MLME functions - because the MLME is in the card. A non full-mac card does not require this user space API - with the MLME built in to hostapd since year dot, and in new versions of wpa_supplicant there is little need for the kernel to have a MLME API from user space - unless you are using a full-mac card. This is a great thing - goodbye to much of the awkward parts of the legacy kernel wireless APIs. In short - full-mac and non full-mac cards have very different kernel and API requirements. I'd be very careful in looking at how much their kernel support should be fully merged. It would be very interesting to do a taxonomy of the different cards, and look at where different functions are performed. One question for intel - will intel ever release a firmware for the 2100/2200 that makes the card into a non-full-mac card? (This would make unified support so much easier, as well as giving the cards much more capability and flexability.) Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams Sent: Wednesday, August 09, 2006 12:23 PM To: Michael Wu Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org Subject: Re: 3945 driver using d80211 On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote: On Wednesday 09 August 2006 00:57, Johannes Berg wrote: Please not, for now. We need someone pushing for fullmac features in d80211, we need those anyway for embedded systems that can't afford running all of it on the main CPU. While obviously Intel would benefit from doing this since a lot more d80211 features would come available, the greater good would be having a main-stream card that someone cares about and helps making d80211 full-mac capable. It's not that hard to generate probe, authentication, and association frames, and it isn't done frequently enough to stress any embedded system that can run linux. Doing this would let 3945 take advantage of all the d80211 features, so why not? What level of fullmac support are we talking about? True fullmac cards (as I define them) do not need to use d80211. WE19 is all they need, to add WPA/WPA2 support. The IPW cards have a particularly unique split between firmware and host 802.11 duties which I haven't seen in any other cards. They aren't quite fullmac enough to interface with WE directly, yet they only need probe response handling to complete the picture. What other half-fullmac, half-softmac card besides the other IPW cards splits card/host 802.11 duties along those lines? What other splits between card and host are out there? I would be very reluctant to make changes to the 802.11 stack to support fullmac without evidence that other drivers need the change. The atmel driver is somewhat of a hybrid. For fullmac cards like airo, you just set the connection info up, let the card go, and you get back a link event. But the atmel driver controls authentication and association stuff; that's not done in firmware. Look at: send_authentication_request() send_association_request() atmel_transmit_management_frame() atmel_management_frame() authenticate() associate() The driver has an auth/assoc state machine, receives management frames, and sends out the next appropriate management frame based on the current state. I think this is the reverse of ipw2100, where the firmware handles assoc/auth but not much else, but it's still less fullmac than airo, and more fullmac than softmac. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at
RE: 3945 driver using d80211
One thing driving many silicon vendors away from putting the MLME in the card - is that in order to support the advanced wireless features of MS Vista you have to leave the MLME to the host! (this is to enable Vista's advanced wireless features - like simultaneous client/ad-hoc mode). This is forcing more and more vendors to do things the right way. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Barber Sent: Wednesday, August 09, 2006 2:33 PM To: Dan Williams; Michael Wu Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org Subject: RE: 3945 driver using d80211 There are many different functions in a complete 802.11 implementation - and different implementations put these functions in different places. In general, I would consider the primary difference between a full-mac card and others to be the location of the MLME function. All full-mac cards perform the MLME in the card. They typically also do the conversion of data frames between 802.3 and 802.11 format in the card as well, and the inter-BSS transitions are handled in the card too. This key difference make it very unlikely that full-mac cards will implement various advanced 802.11 features - such as WDS, virtual APs, multiple clients, simultaneous client/AP modes etc etc. (Of course, by adding a large number of APIs all this can theoretically be achieved - it's just a lot more work this way). Because the full-mac cards have functions in the card that other cards do not the API for these cards will necessarily be quite different from the API for non-full-mac cards. Typically the full mac cards will only ever expose a single 802.3 interface - and hence they may not need to have an 802.11 master interface at all. They will require a user space API that includes control of MLME functions - because the MLME is in the card. A non full-mac card does not require this user space API - with the MLME built in to hostapd since year dot, and in new versions of wpa_supplicant there is little need for the kernel to have a MLME API from user space - unless you are using a full-mac card. This is a great thing - goodbye to much of the awkward parts of the legacy kernel wireless APIs. In short - full-mac and non full-mac cards have very different kernel and API requirements. I'd be very careful in looking at how much their kernel support should be fully merged. It would be very interesting to do a taxonomy of the different cards, and look at where different functions are performed. One question for intel - will intel ever release a firmware for the 2100/2200 that makes the card into a non-full-mac card? (This would make unified support so much easier, as well as giving the cards much more capability and flexability.) Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams Sent: Wednesday, August 09, 2006 12:23 PM To: Michael Wu Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org Subject: Re: 3945 driver using d80211 On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote: On Wednesday 09 August 2006 00:57, Johannes Berg wrote: Please not, for now. We need someone pushing for fullmac features in d80211, we need those anyway for embedded systems that can't afford running all of it on the main CPU. While obviously Intel would benefit from doing this since a lot more d80211 features would come available, the greater good would be having a main-stream card that someone cares about and helps making d80211 full-mac capable. It's not that hard to generate probe, authentication, and association frames, and it isn't done frequently enough to stress any embedded system that can run linux. Doing this would let 3945 take advantage of all the d80211 features, so why not? What level of fullmac support are we talking about? True fullmac cards (as I define them) do not need to use d80211. WE19 is all they need, to add WPA/WPA2 support. The IPW cards have a particularly unique split between firmware and host 802.11 duties which I haven't seen in any other cards. They aren't quite fullmac enough to interface with WE directly, yet they only need probe response handling to complete the picture. What other half-fullmac, half-softmac card besides the other IPW cards splits card/host 802.11 duties along those lines? What other splits between card and host are out there? I would be very reluctant to make changes to the 802.11 stack to support fullmac without evidence that other drivers need the change. The atmel driver is somewhat of a hybrid. For fullmac cards like airo, you just set the connection info up, let the card go, and you get back a link event. But the atmel driver controls authentication and association stuff; that's not done in firmware. Look at: send_authentication_request() send_association_request() atmel_transmit_management_frame() atmel_management_frame() authenticate() associate() The driver has
RE: RX processing order for packet sockets and bridge
The generic solution here is to use ebtables - the broute chain is there to perform exactly this kind of filtering. Set a rule in the broute chain to route these EAPOL frames, rather than bridging them. Then open the packet socket on the original interface. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Wednesday, March 29, 2006 11:14 AM To: netdev@vger.kernel.org Subject: RX processing order for packet sockets and bridge The current netif_receive_skb() implementation is delivering packets to all ptype_all handlers before calling handle_bridge() and to all ptype_base[type] handlers after calling handle_bridge(). This causes somewhat unfortunate difference in how packet sockets work based on whether they are bound to a specific sll_protocol or not for the case of special frames that bridge (stp) code processes internally. This does not probably matter much for most cases, but this breaks some applications. I'm looking at an issue where IEEE 802.1X authentication is used on an Ethernet device. In such a case, EAPOL frames are sent to special PAE group address (01:80:c2:00:00:03) with ethertype=EAPOL. At least for me, the most logical way of receiving these frames is to use a packet socket bound to the selected sll_ifndex and sll_protocol=EAPOL. This works fine whenever the network device is not part of a bridge. However, this gets difficult when the interface is added to a bridge. With STP disabled it is still possible to use the same type of packet socket to receive EAPOL frames. However, the frames will now end up being received from the bridge interface (e.g., br0), not Ethernet (eth0). In other words, the supplicant will need to know that it needs to bind to another interface. With STP enabled, the EAPOL frames to 01:80:c2:00:00:03 are not received anymore, so IEEE 802.1X authentication does not work with this kind of packet socket use. br_handle_frame() (called via br_handle_frame_hook) has code that processes all 01:80:c2:00:00:0? frames differently. 01:80:c2:00:00:00 will be delivered to NF_BR_LOCAL_IN and consumed internally (I would assume). Packets to other 01:80:c2:00:00:0? addresses get dropped. This is understandable since these are special addresses that bridges are not supposed to forward. However, IEEE 802.1X uses one of these addresses and those frames should be made available to user space programs (but without forwarding them to other ports). What could be done to make this work better? If the supplicant would not bind to a specific sll_protocol, the packets are received at eth0 and this works. However, lots of other packets would also be received and user space filtering for these is not really a good idea. One could probably use Linux socket filters to do filtering in kernel (if those are processed before packet sockets; I did not yet verify this), but even that is somewhat complex solution compared to binding a packet socket to sll_protocol=EAPOL. One option would be to move packet socket handlers to be called before handle_bridge() call for both the cases where they are bound to a specific protocol and where they are not. This would allow EAPOL frames to be received from eth0 regardless of whether the device is in a bridge or not. This sounds like the cleanest solution from the user space viewpoint. Would this be feasible? Can all protocol (ptype_base[type]) handlers be called before handle_bridge() or would there need to be special case for packet sockets? Another option would be to teach bridge code about this special-special case and make br_handle_frame() return 0 if destination address is 01:80:c2:00:00:03. Doing this for the stp_enabled case seemed to resolve the problem I was seeing with wpa_supplicant not receiving the frames when STP was enabled. However, since this was only for stp_enabled, the frames in STP disabled case were received from br0, not eth0. It would be possible to return 0 from br_handle_frame() for both cases with some extra CPU use (i.e., one new memcmp() regardless of whether STP is enabled or not). This should allow EAPOL frames to be received from eth0 in all cases using packet socket with sll_protocol bound to EAPOL, so user space side would be as clean as the first option I mentioned above. However, this would be a specific solution for this particular issue with IEEE 802.1X. Would this be acceptable, if moving packet socket handlers in netif_receive_skb() is consider too expensive? Is anyone aware of a better solution for this issue? -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 6/13] d80211: remove obsolete stuff
Yes, fully agreed - and the hardware's pre-beacon interrupt would cause the beacon function to create a beacon frame and put it into the queue (dev_queue_xmit on the master device). The beacon frame would the be passed to the hardware through the normal run_queue that follows. Simon -Original Message- From: Jouni Malinen Sent: Wednesday, March 15, 2006 4:48 PM To: Simon Barber Cc: Jiri Benc; netdev@vger.kernel.org Subject: Re: [RFC/PATCH 6/13] d80211: remove obsolete stuff On Wed, Mar 15, 2006 at 04:41:56PM -0800, Simon Barber wrote: The more natural way for beacons to flow from the 80211.o to the low level driver would be for beacons to be passed down just like any other 802.11 frame is passed down - rather than having a special case for beacons and buffered MC data, where they are pulled. I would suggest making the qdisc aware of beacons, and then there is no special interface for passing beacons down - they are passed down just like other frames, with a special queue ID reserved for beacons and buffered multicast. This would simplify the 80211.o/low level interface. Sure, but it would also require good synchronization for sending the beacons just before they are needed for transmission.. If the wlan hardware implementation provides support for interrupts that request beacons at proper times, being able to use them for this is quite convenient. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 6/13] d80211: remove obsolete stuff
The more natural way for beacons to flow from the 80211.o to the low
level driver would be for beacons to be passed down just like any other
802.11 frame is passed down - rather than having a special case for
beacons and buffered MC data, where they are pulled. I would suggest
making the qdisc aware of beacons, and then there is no special
interface for passing beacons down - they are passed down just like
other frames, with a special queue ID reserved for beacons and buffered
multicast.
This would simplify the 80211.o/low level interface.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jouni Malinen
Sent: Wednesday, March 15, 2006 4:36 PM
To: Jiri Benc
Cc: netdev@vger.kernel.org
Subject: Re: [RFC/PATCH 6/13] d80211: remove obsolete stuff
On Mon, Mar 06, 2006 at 04:44:26PM +0100, Jiri Benc wrote:
Because any number of interfaces may be added, bss_devs and sta_devs
arrays cannot be fixed-size arrays. We can make them linked lists, but
they are needed for optimalization only (and even that is questionable
with subsequent patches). Let's remove them; we will probably want
something similar later to speed up packet receiving, but let's not
bother ourselves now.
@@ -277,9 +277,6 @@ struct ieee80211_conf {
int antenna_def;
int antenna_mode;
- u8 bssid_mask[ETH_ALEN];/* ff:ff:ff:ff:ff:ff = 1 BSSID
*/
- int bss_count;
In theory, the low-level driver can determine the needed mask itself.
However, it would need to be somehow notified of allowed BSSID values.
By removing this entry, this information would need to fetched from
somewhere else before interfaces are added.
Most hardware implementations have storage for a single MAC address in
EEPROM (or something similar) and in some cases, no addresses are stored
with the card and some external store is needed for this. We have been
using this mechanism of passing the information from user space to avoid
problems in figuring out board specific mechanisms for storing extra
data. Do you have any ideas on what would be the best of getting this
information configured after this change?
--- dscape.orig/net/d80211/ieee80211.c2006-03-06
14:10:18.0 +0100
+++ dscape/net/d80211/ieee80211.c 2006-03-06 14:10:22.0
+0100
@@ -1569,17 +1569,14 @@ struct sk_buff * ieee80211_beacon_get(st
u8 *b_head, *b_tail;
int bh_len, bt_len;
- spin_lock_bh(local-sub_if_lock);
- if (bss_idx 0 || bss_idx = local-bss_dev_count)
- bdev = NULL;
- else {
- bdev = local-bss_devs[bss_idx];
+ bdev = dev_get_by_index(bss_idx);
This and similar change for ieee80211_get_buffered_bc() add more
requirements for the low-level driver. It used to be enough to just know
that the low-level code should ask for up to N beacon frames. However,
with this change, the low-level driver would need to maintain a list of
ifindexes for the virtual interfaces. This is somewhat against the
original design of hiding all the virtual interfaces from low-level
code.
I think the ifindex values could be made available from add/remove
interface calls that you added. Was that what you had in mind or is
there another mechanism for getting the needed ifindexes down? I need to
understand this bit better in order to be able to modify the low-level
driver to handle this kind of change. At the moment, this change does
not look very good to me because of the extra requirement added for the
low-level code as far as virtual interfaces are concerned.
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 7/13] d80211: remove adm_status
Overloading configuration parameters with extra meanings like this makes it harder to configure the system - I think it's useful to keep an on/off function separate from the power setting. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Monday, March 06, 2006 4:23 PM To: Jean Tourrilhes Cc: netdev@vger.kernel.org; Jiri Benc Subject: Re: [RFC/PATCH 7/13] d80211: remove adm_status On Mon, Mar 06, 2006 at 02:25:52PM -0800, Jean Tourrilhes wrote: Jouni Malinen wrote : This is used to implement radio on/off without having to change other parts of the configuration (e.g., set interfaces down). The airo driver use 'txpower' for that. txpower has a 'off' option, and with the airo driver this disable the whole MAC, leaving the interface up (and 'on' revert back). This is somewhat confusing parameter for disabling both transmit and receive (or the whole MAC for that matter). Other than that, I don't really have anything against using this for what the adm_status was used as long as the 'on' option returns the previously used TX level without user space program having to set it again. I haven't looked at what the current drivers are doing in this case. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ANNOUNCE: new DHCP client for linux 2.6.x
A quick suggestion for a feature improvement... In 802.11 networks when connecting to a new AP on the same networks (same SSID security settings) you typically don't have to do DHCP again - but with some networks setups you do. In order to detect this, when connecting to a new AP always issue an ARP request for the default gateway - if you don't get a response, then kick off a dhcp request. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Rompf Sent: Friday, February 17, 2006 6:37 AM To: netdev@vger.kernel.org; linux-kernel@vger.kernel.org Subject: ANNOUNCE: new DHCP client for linux 2.6.x dhcpclient A DHCP client for linux 2.6, using modern kernel features, (c) 2006 Stefan Rompf. Motivation Using a notebook, I'm often traveling between different networks. After replugging, I always needed to issue a ifdown/ifup sequence because the DHCP client did not realize the temporary disconnection. This is an unneeded limitation because since 2.6, the kernel notifies userspace of these disconnection/reconnection events. Actually is was me who implemented this feature. Beginning with 2.6.17, the linux kernel will allow userspace to influence this signalling, so that for example a wpa supplicant can tell the dhcpclient that an association has finished and the client should try to get an IP address. Of course, you need software that support this feature. Unfortunately, most existing DHCP clients implemented their statemachine using siglongjmp() or one huge function, so there was no easy way extending them. So I wrote a new one. Features * RFC2131 compatible DHCP client, tested with ISC dhcpd directly and via a Cisco IOS relay agent, Cisco IOS DHCP server and dnsmasq. * uses netlink for interface configuration * does act on link state messages * calls a script on every state change to allow updating resolv.conf etc * small, compiles with [1]uclibc Status Currently, this is alpha software. It shouldn't be used in production environment, but I'm looking forward for people who like to test it in different environments and for (reasonable ;-) feature suggestions! Support The webpage is at [2]http://www.flamewarmaster.de/software/dhcpclient/ There is a mailing list available on [3]http://www.flamewarmaster.de/mailman/listinfo/dhcpclient/ References 1. http://www.uclibc.org/ 2. http://www.flamewarmaster.de/software/dhcpclient/ 3. http://www.flamewarmaster.de/mailman/listinfo/dhcpclient/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SNAP headers, RFC1042
Currently many wireless drivers handle SNAP-Ethernet header processing - this is an obvious candidate for factoring out - and might possibly be something that should be moved out of the wireless code completely. Would it make sense to add the code to eth_trans_type or create a ieee80211_trans_type? Advantages: 1) Better code reuse 2) Frame data is no longer moved or touched unless bridging. Disadvantage: 1) things like dhcpd need to understand SNAP header format (unless frames going to a raw socket have the header re-written) 2) bridge code needs to rewrite frames according to the output port's needed header type Comments? Suggestions? Simon - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: SNAP headers, RFC1042
The main reason is bridging - the header format needs to be different for different ports. Ideally I'd like to see a single snap processor used in both cases (local receive bridging). One problem with the current processor is the in the bridge the skb-protocol is set to 802_2_LLC, not to the real protocol type. This prevents ebtables rules and tc from working correctly. Simon -Original Message- From: Stephen Hemminger [mailto:[EMAIL PROTECTED] Sent: Friday, February 03, 2006 1:19 PM To: Simon Barber Cc: netdev@vger.kernel.org; Jouni Malinen Subject: Re: SNAP headers, RFC1042 On Fri, 3 Feb 2006 13:08:17 -0800 Simon Barber [EMAIL PROTECTED] wrote: Currently many wireless drivers handle SNAP-Ethernet header processing - this is an obvious candidate for factoring out - and might possibly be something that should be moved out of the wireless code completely. Would it make sense to add the code to eth_trans_type or create a ieee80211_trans_type? Advantages: 1) Better code reuse 2) Frame data is no longer moved or touched unless bridging. Disadvantage: 1) things like dhcpd need to understand SNAP header format (unless frames going to a raw socket have the header re-written) 2) bridge code needs to rewrite frames according to the output port's needed header type Comments? Suggestions? Simon We already have a snap processor, so why not just do a netif_receive_skb on the frame. You need to select LLC in the kernel config with that driver. -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless-2.6 status (25 January 2006)
In order to get FCC certification the manufacturer must ensure there is no easy way for the user to tune to illegal frequencies. Broadcom has done their job - it was not easy to reverse engineer their driver. Now the cat is out of the bag. The open source driver is not illegal - although it may be illegal to use it - since the chipset and driver were likely certified together. I'm no expert in FCC regulation, so take all of this with a pinch of salt. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Thursday, January 26, 2006 3:46 PM To: Ben Greear Cc: David Hollis; John W. Linville; Samuel Ortiz; netdev@vger.kernel.org Subject: Re: wireless-2.6 status (25 January 2006) On Friday 27 January 2006 00:10, you wrote: Michael Buesch wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: If someone has a reverse-engineered HAL that might could be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: State of the Union: Wireless
To do qos properly there needs to be a single net_device that a single qdisc can be installed on - this alone is a good reason for a master net_device. (there must be a single 802.11 qdisc for a single physical piece of hardware). Here is another reason (for hardware devices that do not include a MLME in hardware): In the Devicescape stack the hardware driver (called the low level driver) uses an internal interface to the rest of the stack. The master net_device is created by the rest of the stack (80211.o module). I would like to change this, so that the hardware driver itself creates a net_device, with an 802.11 ARP_HDR. This would be the master device, and the interface between the kernel 802.11 code and a hardware 802.11 device that does not implement the MLME in hardware. The 80211.o module in the kernel would hook itself into this device by watching for the broadcast message when a new device is registered, and automatically installing the 802.11 qdisc on the new device. When the hadware receives 802.11 frames the hardware device driver would set the protocol type to 802.11 before calling netif_rx, and the 80211.o module would register itself as a protocol handler for 802.11. This change would remove the current special internal interface in the Devicescape stack between the hardware driver and the core of the stack - and would make the stack better integrated with the kernel. The design here is similar to the VLAN code for the RX direction, but using the qdisc for both queueing and part of the stack implementation is a new direction for the TX. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Benc Sent: Tuesday, January 17, 2006 2:05 AM To: Jouni Malinen Cc: Krzysztof Halasa; Mike Kershaw; netdev@vger.kernel.org; Stefan Rompf; John W.Linville Subject: Re: State of the Union: Wireless On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. You can add a new soft monitor interface and use it instead. There is no need for separate master device. -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless: recap of current issues (other issues)
To fake ethernet or not? There is a similar problem in the VLAN code - do you expect the rest of the network stack to be able to interpret VLAN tagged frames? This was the original state of the VLAN code - this caused problems since many apps and modules did not understand VLAN tags (e.g. dhcp). The VLAN code was extended to offer both options - the VLAN virtual device can be switched to ethernet (non tagged) or tagged. I would suggest that for compatibility the default for WLAN code be ethernet format frames, and if somebody wants it to also have an option for 802.11 format frames - then that be alowed too. If you really want to build a kernel without ethernet support this is theoretically possible. The 802.11 format question is related to the 'virtual devices' question. Most 802.11 implementations split into 2 categories. 1. Those where the MLME runs on the chip and 2. those where the MLME runs in the host. The MLME implementations that run on the chip to date that I know about do not support multiple virtual networks, or other advanced features that require multiple virtual devices. For these devices frames are typically exchanged with the hardware in ethernet format, and a single ethernet format net_device is likely all that will be needed in linux. For devices that leave the MLME to the host, a much wider range of advanced features is possible - and here a raw 802.11 net_device and multiple virtual devices is likely required. A single physical device is required to implement a qdisc and do priority queueing properly. Multiple virtual devices to support advanced stack features could be either 802.11 format or ethernet format depending on the feature and configuration. Channels/Frequencies For chips with firmware that runs on the chip oftentimes the setting of channel and power limits is done on the chip, in order to meet the FCC restriction of making it difficult for the end user to set illegal values. In cases of chips without firmware these functions may be done by the stack, or in some cases by a binary code block. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik Sent: Saturday, January 14, 2006 2:09 PM To: John W. Linville Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: wireless: recap of current issues (other issues) John W. Linville wrote: Other Issues A big open issue: should you fake ethernet, or represent 802.11 natively throughout the rest of the net stack? The former causes various and sundry hacks, and the latter requires that you touch a bunch of non-802.11 code to make it aware of a new frame class. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: netif_stop_queue() and multiple hardware queues
Hi Jeremy, I implemented this functionality in Devicescape's 802.11 stack. The approach I took was for the driver to install a device specific qdisc as the root qdisc on the device. This root qdisc's purpose is to expose the hardware queues directly, so other qdiscs can be attached as leaf qdiscs. This hardware specific root qdisc cannot be deleted or changed. This makes it possible to use tc to inspect/set/modify per hardware queue statistics and parameters. In order for this to work my device driver never calls netif_stop. Instead the qdisc dequeue function for the root qdisc looks to see which hardware queues can accept a frame, and if none then it returns no data. The driver's frame completion function calls __netif_schedule appropriately too to ensure the queue runs when it should. This allows Devicescape's 802.11 stack to properly integrate with the Linux tc framework. I don't think any other 802.11 drivers achieve this. In the future I plan to extend Devicescape's 802.11 root qdisc to further expose the 802.11 MAC's internal queues, in cases where this is useful (e.g. the scheduled access implementation). The same principle could apply to Intel's e1000. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Jackson Sent: Wednesday, December 14, 2005 2:31 PM To: netdev@vger.kernel.org Subject: netif_stop_queue() and multiple hardware queues Hi, I posted this briefly on linux-net, before being redirected here. Two pieces of hardware now have Linux driver support for multiple hardware queues: Intel's e1000 (two queues from what I can see in the code) and Atheros's 5212 and up, in support of 802.11e and WME (four hardware queues). In the GigE case, this just reduces latency due to hardware queueing. In the WiFi case, the queues actually have significance in access to the shared medium. (ACKs can be disabled as well) It is also worthy of note that ADSL2, VDSL, and ADSL2+ have 4 different latency queues. These last two are significant; real-time applications suffer the most from low speed, shared, and/or non-deterministic media. I wonder where DOCSIS 2 is in this regard. Anyone? Beuler? So my question is, what's it going to take to get dev-hard_start_xmit() to hook up tc queues directly to hardware/driver queues? Right now, it seems no matter how elaborate a tc setup you have, everything funnels through one queue, where the only thing that survives from the classifying/queueing is skb- priority (ie nothing). The hardware driver can then try to reclassify packets. I suppose you could hack up an iptables classifyer to set skb-priority... The Atheros driver tries to do it's own classifying by first wiping out skb-priority, then hard-coding a mapping (tsk - policy is for the sysadmin!) between VLAN tag priority, IP TOS/DSCP, and skb-priority, then to one of the 4 queues and ACK states, blithely ignoring any fine work done by tc. It's be sweet to head this nonsense off at the pass, before others discover the rabbit trail and make it into a trade route. -- Jeremy Jackson Coplanar Networks W:(519)489-4903 MSN: [EMAIL PROTECTED] ICQ: 43937409 http://www.coplanar.net - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: netif_stop_queue() and multiple hardware queues
Oh - and re: policy - my 802.11 qdisc first calls out to the tc classify function - allowing the sysadmin to do what he wants, then if no class is selected it has a default implementation that reflects the appropriate 802.11 and WiFi specs for classification. Of course another implementation would be to implement an 802.11 classifier, and install this by default on the 802.11 qdisc. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Barber Sent: Wednesday, December 14, 2005 3:07 PM To: Jeremy Jackson; netdev@vger.kernel.org Subject: RE: netif_stop_queue() and multiple hardware queues Hi Jeremy, I implemented this functionality in Devicescape's 802.11 stack. The approach I took was for the driver to install a device specific qdisc as the root qdisc on the device. This root qdisc's purpose is to expose the hardware queues directly, so other qdiscs can be attached as leaf qdiscs. This hardware specific root qdisc cannot be deleted or changed. This makes it possible to use tc to inspect/set/modify per hardware queue statistics and parameters. In order for this to work my device driver never calls netif_stop. Instead the qdisc dequeue function for the root qdisc looks to see which hardware queues can accept a frame, and if none then it returns no data. The driver's frame completion function calls __netif_schedule appropriately too to ensure the queue runs when it should. This allows Devicescape's 802.11 stack to properly integrate with the Linux tc framework. I don't think any other 802.11 drivers achieve this. In the future I plan to extend Devicescape's 802.11 root qdisc to further expose the 802.11 MAC's internal queues, in cases where this is useful (e.g. the scheduled access implementation). The same principle could apply to Intel's e1000. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Jackson Sent: Wednesday, December 14, 2005 2:31 PM To: netdev@vger.kernel.org Subject: netif_stop_queue() and multiple hardware queues Hi, I posted this briefly on linux-net, before being redirected here. Two pieces of hardware now have Linux driver support for multiple hardware queues: Intel's e1000 (two queues from what I can see in the code) and Atheros's 5212 and up, in support of 802.11e and WME (four hardware queues). In the GigE case, this just reduces latency due to hardware queueing. In the WiFi case, the queues actually have significance in access to the shared medium. (ACKs can be disabled as well) It is also worthy of note that ADSL2, VDSL, and ADSL2+ have 4 different latency queues. These last two are significant; real-time applications suffer the most from low speed, shared, and/or non-deterministic media. I wonder where DOCSIS 2 is in this regard. Anyone? Beuler? So my question is, what's it going to take to get dev-hard_start_xmit() to hook up tc queues directly to hardware/driver queues? Right now, it seems no matter how elaborate a tc setup you have, everything funnels through one queue, where the only thing that survives from the classifying/queueing is skb- priority (ie nothing). The hardware driver can then try to reclassify packets. I suppose you could hack up an iptables classifyer to set skb-priority... The Atheros driver tries to do it's own classifying by first wiping out skb-priority, then hard-coding a mapping (tsk - policy is for the sysadmin!) between VLAN tag priority, IP TOS/DSCP, and skb-priority, then to one of the 4 queues and ACK states, blithely ignoring any fine work done by tc. It's be sweet to head this nonsense off at the pass, before others discover the rabbit trail and make it into a trade route. -- Jeremy Jackson Coplanar Networks W:(519)489-4903 MSN: [EMAIL PROTECTED] ICQ: 43937409 http://www.coplanar.net - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
