* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-01-16 6:41 UTC (permalink / raw)
To: spereira; +Cc: arnd, acme, ak, linux-kernel, netdev, pereira.shaun, yoshfuji
In-Reply-To: <1137391160.5588.32.camel@spereira05.tusc.com.au>
In article <1137391160.5588.32.camel@spereira05.tusc.com.au> (at Mon, 16 Jan 2006 16:59:20 +1100), Shaun Pereira <spereira@tusc.com.au> says:
> If I understand correctly from your comments (thanks for that, they are
> helpful)
> copy_to_user acts like a memcopy for an 'array' of bytes and should not
> be used to copy the timeval struct to userspace.
> Rather put_user / __put_user macros should be used which allows transfer
> of single element values of the structure.
> +int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
> *userstamp)
> +{
> + struct compat_timeval __user *ctv
> + = (struct compat_timeval __user*) userstamp;
> + int err = -ENOENT;
> + if(!sock_flag(sk, SOCK_TIMESTAMP))
> + sock_enable_timestamp(sk);
> + if(sk->sk_stamp.tv_sec == -1)
> + return err;
> + if(sk->sk_stamp.tv_sec == 0)
> + do_gettimeofday(&sk->sk_stamp);
> + err = -EFAULT;
> + if(access_ok(VERIFTY_WRITE, ctv, sizeof(*ctv))) {
> + err = __put_user(sk->sk_stamp.tv_sec, &ctv->tv_sec);
> + err != __put_user(sk->sk_stamp.tv_usec, &ctv->tv_usec);
> + }
> + return err;
> +}
> +
Hmm, you will copy 32bit of MSB in big-endian.
You should do something like this:
strtuct compat_timeval tvtmp;
:
tvtmp.tv_sec = sk->sk_stamp.tv_sec;
tvtmp.tv_usec = sk->sk_stemp.tv_usec;
return copy_to_user(ctv, &tvtmp, sizeof(tvtmp));
Or, am I miss something?
--yoshfuji
^ permalink raw reply
* Re: Re: acxsm: migrate acx from homegrown 802.11 handling to softmac stack
From: Denis Vlasenko @ 2006-01-16 6:52 UTC (permalink / raw)
To: acx100-devel; +Cc: Carlos Martín, netdev, softmac-dev
In-Reply-To: <200601151929.43896.carlos@cmartin.tk>
On Sunday 15 January 2006 20:29, Carlos Martín wrote:
> On Sunday 15 January 2006 12:52, Denis Vlasenko wrote:
> > Hi,
> >
> > http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
>
> I've mirrored it at http://www.cmartin.tk/acx/ and will sync as with the
> 'normal' tarballs.
>
> >
> > README says:
> > ==================
> > *** Not run tested. Almost certainly won't work. Lots of things are TODO.
>
> I'll try to try it out this week. Unfortunately, my USB device is broken
> again.
It's not ready for actual usage, but code review would be appreciated.
I am trying to keep acxsm close enough to acx so that "diff -urp acx acxsm"
will give good idea about the differences.
> > P.S. It does not mean that acx driver is discontinued.
> > It will be supported as before. Let's see whether acxsm
> > will get any traction at all.
> at^^^^^^^^
> You mean it won't slip when the road is wet? :P
> This should make certain things easier to handle, won't it? From what I've
> seen you don't have to worry about fragmentation of packets. Will the stack
> also handle TKPI/WPA?
Stack is meant to eventually handle all bells and whistles.
The first important missing thing is AP mode. There is softmac'ish
AP mode implementation in Devicescape stack...
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-16 9:39 UTC (permalink / raw)
To: spereira; +Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, netdev, SP
In-Reply-To: <1137391160.5588.32.camel@spereira05.tusc.com.au>
On Monday 16 January 2006 06:59, Shaun Pereira wrote:
>
> I was wondering if this the compat_sock_get_timestamp function is
> needed? If I were to remove the SIOCGSTAMP case from the
> compat_x25_ioctl function, then a SIOCGSTAMP ioctl system call would
> return -ENOIOCTLCMD which could then be handled by do_siocgstamp
> handler in the ioctl32_hash_table? (fs/compat_ioctl.c)
> In which case I could remove this patch from the rest of the series.
Yes, that would also work, as I already mentioned (or tried to)
in one of my earlier comments. I would prefer to have this patch
though, because in the long term, I think we should migrate more
stuff away from the hash table and having the function there
means that others can use it as well.
> + err = -EFAULT;
> + if(access_ok(VERIFTY_WRITE, ctv, sizeof(*ctv))) {
> + err = __put_user(sk->sk_stamp.tv_sec, &ctv->tv_sec);
> + err != __put_user(sk->sk_stamp.tv_usec, &ctv->tv_usec);
> + }
> + return err;
> +}
This copies the correct data down to user space now, but might result
in returning an invalid error code.
In the second line you now have 'err != __put_user(...);', which is
a comparison, not an assignment!
For readability, I would simply write that as:
ret = 0;
if (put_user(sk->sk_stamp.tv_sec, &ctv->tv_sec) |
put_user(sk->sk_stamp.tv_usec, &ctv->tv_usec))
err = -EFAULT;
You can also write it like your code, but with '|' instead of '!', but
that requires the additional knowledge that __put_user can only ever
return '0' or '-EFAULT' itself and that the bitwise or of those is
therefore also one of these two.
Arnd <><
^ permalink raw reply
* [PATCH] WLAN acx100: OOPS fix, KERN_xxx, misc.
From: Andreas Mohr @ 2006-01-16 14:02 UTC (permalink / raw)
To: acx100-devel; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
Hi all (and especially Denis),
acx-20060116_misc.diff:
- fix OOPS in acx_l_rxmonitor() (wrong ndev->type setting leading to memcpy
of negative size) by reworking monitor mode type setup and adding
missing sanity checks
- rename acx1XX_ie_powermgmt_t to more correct acx1XX_ie_powersave_t
- fix format string compile warnings
- add <linux/compiler.h> include apparently required for __iomem define
around Linux 2.6.8
- rework eCPU init by replacing static msleep with faster, more intelligent
(hopefully) busy-wait
acx-20060116_KERN_xxx.diff (too large: gzipped):
- add proper KERN_xxx prefixes to printk() as requested recently
Note that both patches are based on acx-20060116 proper (rediffed from
acx-20060113), smallish conflicts may result; apply acx-20060116_KERN_xxx.diff after acx-20060116_misc.diff.
Andreas Mohr
[-- Attachment #2: acx-20060116_misc.diff --]
[-- Type: text/plain, Size: 9559 bytes --]
diff -urN acx-20060116.orig/acx_struct.h acx-20060116_misc/acx_struct.h
--- acx-20060116.orig/acx_struct.h 2006-01-15 12:03:38.000000000 +0100
+++ acx-20060116_misc/acx_struct.h 2006-01-16 14:12:04.000000000 +0100
@@ -1202,6 +1202,7 @@
u8 ap[ETH_ALEN]; /* The AP we want, FF:FF:FF:FF:FF:FF is any */
u16 aid; /* The Association ID sent from the AP / last used AID if we're an AP */
u16 mode; /* mode from iwconfig */
+ int monitor_type; /* ARPHRD_IEEE80211 or ARPHRD_IEEE80211_PRISM */
u16 status; /* 802.11 association status */
u8 essid_active; /* specific ESSID active, or select any? */
u8 essid_len; /* to avoid dozens of strlen() */
@@ -1623,7 +1624,7 @@
#define PS_OPT_TX_PSPOLL 0x02 /* send PSPoll frame to fetch waiting frames from AP (on frame with matching AID) */
#define PS_OPT_STILL_RCV_BCASTS 0x01
-typedef struct acx100_ie_powermgmt {
+typedef struct acx100_ie_powersave {
u16 type ACX_PACKED;
u16 len ACX_PACKED;
u8 wakeup_cfg ACX_PACKED;
@@ -1631,9 +1632,9 @@
u8 options ACX_PACKED;
u8 hangover_period ACX_PACKED; /* remaining wake time after Tx MPDU w/ PS bit, in values of 1/1024 seconds */
u16 enhanced_ps_transition_time ACX_PACKED; /* rem. wake time for Enh. PS */
-} acx100_ie_powermgmt_t;
+} acx100_ie_powersave_t;
-typedef struct acx111_ie_powermgmt {
+typedef struct acx111_ie_powersave {
u16 type ACX_PACKED;
u16 len ACX_PACKED;
u8 wakeup_cfg ACX_PACKED;
@@ -1642,7 +1643,7 @@
u8 hangover_period ACX_PACKED; /* remaining wake time after Tx MPDU w/ PS bit, in values of 1/1024 seconds */
u32 beacon_rx_time ACX_PACKED;
u32 enhanced_ps_transition_time ACX_PACKED; /* rem. wake time for Enh. PS */
-} acx111_ie_powermgmt_t;
+} acx111_ie_powersave_t;
/***********************************************************************
diff -urN acx-20060116.orig/common.c acx-20060116_misc/common.c
--- acx-20060116.orig/common.c 2006-01-15 12:38:43.000000000 +0100
+++ acx-20060116_misc/common.c 2006-01-16 14:22:02.000000000 +0100
@@ -183,7 +183,7 @@
diff -= adev->lock_time;
if (diff > max_lock_time) {
where = sanitize_str(where);
- printk("max lock hold time %d CPU ticks from %s "
+ printk("max lock hold time %ld CPU ticks from %s "
"to %s\n", diff, adev->last_lock, where);
max_lock_time = diff;
}
@@ -230,7 +230,7 @@
unsigned long diff = jiffies - adev->sem_time;
if (diff > max_sem_time) {
where = sanitize_str(where);
- printk("max sem hold time %d jiffies from %s "
+ printk("max sem hold time %ld jiffies from %s "
"to %s\n", diff, adev->last_sem, where);
max_sem_time = diff;
}
@@ -838,7 +838,7 @@
acx100_ie_len[] = {
0,
ACX100_IE_ACX_TIMER_LEN,
- sizeof(acx100_ie_powermgmt_t)-4, /* is that 6 or 8??? */
+ sizeof(acx100_ie_powersave_t)-4, /* is that 6 or 8??? */
ACX1xx_IE_QUEUE_CONFIG_LEN,
ACX100_IE_BLOCK_SIZE_LEN,
ACX1xx_IE_MEMORY_CONFIG_OPTIONS_LEN,
@@ -889,7 +889,7 @@
acx111_ie_len[] = {
0,
ACX100_IE_ACX_TIMER_LEN,
- sizeof(acx111_ie_powermgmt_t)-4,
+ sizeof(acx111_ie_powersave_t)-4,
ACX1xx_IE_QUEUE_CONFIG_LEN,
ACX100_IE_BLOCK_SIZE_LEN,
ACX1xx_IE_MEMORY_CONFIG_OPTIONS_LEN,
@@ -2156,6 +2156,7 @@
adev->listen_interval = 100;
adev->beacon_interval = DEFAULT_BEACON_INTERVAL;
adev->mode = ACX_MODE_2_STA;
+ adev->monitor_type = ARPHRD_IEEE80211_PRISM;
adev->dtim_interval = DEFAULT_DTIM_INTERVAL;
adev->msdu_lifetime = DEFAULT_MSDU_LIFETIME;
@@ -2347,10 +2348,11 @@
skb_put(skb, skb_len);
+ if (adev->ndev->type == ARPHRD_IEEE80211) {
/* when in raw 802.11 mode, just copy frame as-is */
- if (adev->ndev->type == ARPHRD_IEEE80211)
datap = skb->data;
- else { /* otherwise, emulate prism header */
+ } else if (adev->ndev->type == ARPHRD_IEEE80211_PRISM) {
+ /* emulate prism header */
msg = (wlansniffrm_t*)skb->data;
datap = msg + 1;
@@ -2410,8 +2412,20 @@
msg->frmlen.status = WLANITEM_STATUS_data_ok;
msg->frmlen.len = 4;
msg->frmlen.data = skb_len;
+ } else {
+ printk(KERN_ERR "unsupported netdev type %d!\n",
+ adev->ndev->type);
+ dev_kfree_skb(skb);
+ return;
}
+ /* sanity check (keep it here) */
+ if (unlikely((int)skb_len < 0))
+ {
+ printk(KERN_ERR "skb_len bug (%d)!! Aborting...\n", (int)skb_len);
+ dev_kfree_skb(skb);
+ return;
+ }
memcpy(datap, ((unsigned char*)rxbuf)+payload_offset, skb_len);
skb->dev = adev->ndev;
@@ -2425,6 +2439,7 @@
adev->stats.rx_packets++;
adev->stats.rx_bytes += skb->len;
+
end:
FN_EXIT0;
}
@@ -5816,8 +5831,8 @@
{
/* merge both structs in a union to be able to have common code */
union {
- acx111_ie_powermgmt_t acx111;
- acx100_ie_powermgmt_t acx100;
+ acx111_ie_powersave_t acx111;
+ acx100_ie_powersave_t acx100;
} pm;
/* change 802.11 power save mode settings */
@@ -6246,7 +6261,8 @@
}
if (adev->set_mask & GETSET_MODE) {
- adev->ndev->type = ARPHRD_ETHER;
+ adev->ndev->type = (adev->mode == ACX_MODE_MONITOR) ?
+ adev->monitor_type : ARPHRD_ETHER;
switch (adev->mode) {
case ACX_MODE_3_AP:
@@ -6265,9 +6281,6 @@
acx_s_cmd_join_bssid(adev, adev->bssid);
break;
case ACX_MODE_MONITOR:
- /* adev->ndev->type = ARPHRD_ETHER; */
- /* adev->ndev->type = ARPHRD_IEEE80211; */
- adev->ndev->type = ARPHRD_IEEE80211_PRISM;
acx111_s_feature_on(adev, 0, FEATURE2_NO_TXCRYPT|FEATURE2_SNIFFER);
/* this stops beacons */
acx_s_cmd_join_bssid(adev, adev->bssid);
diff -urN acx-20060116.orig/ioctl.c acx-20060116_misc/ioctl.c
--- acx-20060116.orig/ioctl.c 2006-01-15 12:02:26.000000000 +0100
+++ acx-20060116_misc/ioctl.c 2006-01-16 14:21:46.000000000 +0100
@@ -2078,13 +2078,14 @@
switch (params[0]) {
case 0:
- adev->ndev->type = ARPHRD_ETHER;
+ /* no monitor mode. hmm, should we simply ignore it
+ * or go back to enabling adev->netdev->type ARPHRD_ETHER? */
break;
case 1:
- adev->ndev->type = ARPHRD_IEEE80211_PRISM;
+ adev->monitor_type = ARPHRD_IEEE80211_PRISM;
break;
case 2:
- adev->ndev->type = ARPHRD_IEEE80211;
+ adev->monitor_type = ARPHRD_IEEE80211;
break;
}
diff -urN acx-20060116.orig/pci.c acx-20060116_misc/pci.c
--- acx-20060116.orig/pci.c 2006-01-15 12:01:41.000000000 +0100
+++ acx-20060116_misc/pci.c 2006-01-16 14:21:13.000000000 +0100
@@ -33,6 +33,7 @@
#include <linux/config.h>
#include <linux/version.h>
+#include <linux/compiler.h> /* required for Lx 2.6.8 ?? */
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
@@ -354,8 +355,9 @@
write_flush(adev);
write_reg32(adev, IO_ACX_EEPROM_CTL, 1);
+ count = 0xffff;
while (read_reg16(adev, IO_ACX_EEPROM_CTL)) {
- if (unlikely(++count > 0xffff)) {
+ if (unlikely(!--count)) {
printk("WARNING, DANGER!!! "
"Timeout waiting for EEPROM write\n");
goto end;
@@ -369,13 +371,13 @@
write_flush(adev);
/* now start a verification run */
- count = 0xffff;
for (i = 0; i < len; i++) {
write_reg32(adev, IO_ACX_EEPROM_CFG, 0);
write_reg32(adev, IO_ACX_EEPROM_ADDR, addr + i);
write_flush(adev);
write_reg32(adev, IO_ACX_EEPROM_CTL, 2);
+ count = 0xffff;
while (read_reg16(adev, IO_ACX_EEPROM_CTL)) {
if (unlikely(!--count)) {
printk("timeout waiting for EEPROM read\n");
@@ -747,18 +749,17 @@
temp = read_reg16(adev, IO_ACX_ECPU_CTRL) | 0x1;
write_reg16(adev, IO_ACX_ECPU_CTRL, temp);
- /* now do soft reset of eCPU */
+ /* now do soft reset of eCPU, set bit */
temp = read_reg16(adev, IO_ACX_SOFT_RESET) | 0x1;
log(L_DEBUG, "%s: enable soft reset...\n", __func__);
write_reg16(adev, IO_ACX_SOFT_RESET, temp);
write_flush(adev);
- /* now reset bit again */
+ /* now clear bit again: deassert eCPU reset */
log(L_DEBUG, "%s: disable soft reset and go to init mode...\n", __func__);
- /* deassert eCPU reset */
write_reg16(adev, IO_ACX_SOFT_RESET, temp & ~0x1);
- /* now start a burst read from initial flash EEPROM */
+ /* now start a burst read from initial EEPROM */
temp = read_reg16(adev, IO_ACX_EE_START) | 0x1;
write_reg16(adev, IO_ACX_EE_START, temp);
write_flush(adev);
@@ -893,6 +894,7 @@
int result = NOT_OK;
u16 hardware_info;
u16 ecpu_ctrl;
+ int count;
FN_ENTER;
@@ -927,12 +929,24 @@
acx_unlock(adev, flags);
- /* without this delay acx100 may fail to report hardware_info
- ** (see below). Most probably eCPU runs some init code */
- acx_s_msleep(10);
-
/* need to know radio type before fw load */
- hardware_info = read_reg16(adev, IO_ACX_EEPROM_INFORMATION);
+ /* Need to wait for arrival of this information in a loop,
+ * most probably since eCPU runs some init code from EEPROM
+ * (started burst read in reset_mac()) which also
+ * sets the radio type ID */
+
+ count = 0xffff;
+ do {
+ hardware_info = read_reg16(adev, IO_ACX_EEPROM_INFORMATION);
+ if (!--count)
+ {
+ msg = "eCPU didn't indicate radio type";
+ goto end_fail;
+ }
+ cpu_relax();
+ } while (!(hardware_info & 0xff00)); /* radio type still zero? */
+
+ /* printk("DEBUG: count %d\n", count); */
adev->form_factor = hardware_info & 0xff;
adev->radio_type = hardware_info >> 8;
@@ -940,11 +954,11 @@
if (OK != acxpci_s_upload_fw(adev))
goto end_fail;
- acx_s_msleep(10);
+ /* acx_s_msleep(10); this one really shouldn't be required */
/* now start eCPU by clearing bit */
- log(L_DEBUG, "booted eCPU up and waiting for completion...\n");
write_reg16(adev, IO_ACX_ECPU_CTRL, ecpu_ctrl & ~0x1);
+ log(L_DEBUG, "booted eCPU up and waiting for completion...\n");
/* wait for eCPU bootup */
if (OK != acxpci_s_verify_init(adev)) {
[-- Attachment #3: acx-20060116_KERN_xxx.diff.gz --]
[-- Type: application/x-gzip, Size: 18122 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Jiri Benc @ 2006-01-16 14:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel, John W. Linville
In-Reply-To: <1137191522.2520.63.camel@localhost>
On Fri, 13 Jan 2006 23:32:02 +0100, Johannes Berg wrote:
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinking is that
> different virtual types have different structures associated, so
> changing it needs re-creating structures anyway.
You are right. But it breaks compatibility with iwconfig unless we
emulate 'iwconfig mode' command by deleting and adding interface. This
means some events are generated, hotplug/udev gets involved etc. In the
worst case it can mean that we end up with interface with a different
name.
> And different virtual
> device types might even be provided by different kernel modules so you
> don't carry around AP mode if you don't need it.
I'm not sure about your concept of softmac modules. I wrote an e-mail
some time ago explaining why I don't think it is useful and I haven't
got any reply. Please, could you answer that e-mail first? (See
http://marc.theaimsgroup.com/?l=linux-netdev&m=113404158202233&w=2)
Could you also explain how would you implement separate module for AP
mode? How would you bind that module to the rest of ieee80211,
especially in the rx path?
Thanks,
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [PATCH] WLAN acx100: OOPS fix, KERN_xxx, misc.
From: Denis Vlasenko @ 2006-01-16 14:34 UTC (permalink / raw)
To: acx100-devel; +Cc: Andreas Mohr, netdev
In-Reply-To: <20060116140233.GA8170@rhlx01.fht-esslingen.de>
On Monday 16 January 2006 16:02, Andreas Mohr wrote:
> Hi all (and especially Denis),
>
> acx-20060116_misc.diff:
> - fix OOPS in acx_l_rxmonitor() (wrong ndev->type setting leading to memcpy
> of negative size) by reworking monitor mode type setup and adding
> missing sanity checks
> - rename acx1XX_ie_powermgmt_t to more correct acx1XX_ie_powersave_t
> - fix format string compile warnings
> - add <linux/compiler.h> include apparently required for __iomem define
> around Linux 2.6.8
> - rework eCPU init by replacing static msleep with faster, more intelligent
> (hopefully) busy-wait
>
> acx-20060116_KERN_xxx.diff (too large: gzipped):
Applied, thanks!
> - add proper KERN_xxx prefixes to printk() as requested recently
Please forward me that request.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: wireless: recap of current issues (actions)
From: Johannes Berg @ 2006-01-16 14:44 UTC (permalink / raw)
To: John W. Linville; +Cc: Jeff Garzik, netdev, linux-kernel
In-Reply-To: <20060115005614.GB32206@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
On Sat, 2006-01-14 at 19:56 -0500, John W. Linville wrote:
> Yes, someone (Johannes? Jiri?) had the beginnings of this a few days
> ago, but I seem to have lost the link. Could someone repost it?
http://johannes.sipsolutions.net/802.11_stacks/
Someone should start a new page to collect all the info we're talking
about at the moment on the netdev wiki and then also move this content
there. I don't think I'll get to it in the next few days.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-16 14:55 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, linux-kernel, John W. Linville
In-Reply-To: <20060116152312.6b9ddfd0@griffin.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]
On Mon, 2006-01-16 at 15:23 +0100, Jiri Benc wrote:
> You are right. But it breaks compatibility with iwconfig unless we
> emulate 'iwconfig mode' command by deleting and adding interface. This
> means some events are generated, hotplug/udev gets involved etc. In the
> worst case it can mean that we end up with interface with a different
> name.
Eh, right. In that case, I guess that dropping compatibility here would
be the only solution. Other iwconfig could still work though. I don't
know where to draw the line.
> I'm not sure about your concept of softmac modules. I wrote an e-mail
> some time ago explaining why I don't think it is useful and I haven't
> got any reply. Please, could you answer that e-mail first? (See
> http://marc.theaimsgroup.com/?l=linux-netdev&m=113404158202233&w=2)
I didn't really participate much in that thread. Maybe softmac was a bad
example for being a module -- it just seemed to fit the current model
that the in-kernel ieee80211 module follows.
> Could you also explain how would you implement separate module for AP
> mode? How would you bind that module to the rest of ieee80211,
> especially in the rx path?
Well, if you look at p80211 that davem wrote there are functions for
handling each type of the different receive frames. These could easily
be multiplexed into function pointers the module provides.
I really don't see why a plain STA mode card should be required to carry
around all the code required for AP operation -- handling associations
of clients, powersave management wrt. buffering, ... Sure, fragmentation
is needed for all, so it needs to be in the common code, and it might
make a lot of sense to unify WDS and STA modes, but AP mode requires
fundamentally different things and a lot of code that will never be
called in STA operation.
Putting it into the same modules and then probably into the same
structures just encourages bloat and interdependencies that I don't
think should be there.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 17:09 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.58.0601152038540.19953@irie>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> Regarding 802.11d and regulatory domains, the stack should also be able to
> stick to one regulatory domain if asked so by userspace, whatever the APs
> around tell us.
...and in doing so, violate the local regulatory constraints. :)
Although I believe 802.11d specifies that the 802.11d beacons should
trump whatever the user specifies. (of course, 802.11d doesn't say what
to do when there are APs out there that disagree...)
While I feel it should be *posisble* to do so, the default should be to
query the hardware for its factory default, and go with that. Allowing
the user to change the regulatory domain at will.. is a rather fuzzy
legal area, to say the least.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 17:28 UTC (permalink / raw)
To: Sam Leffler; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <43CAA853.8020409@errno.com>
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
> The above is a great synopsis but there is more. For example to support
> roaming (and sometimes for ap operation) you want to do background
> scanning; this ties in to power save mode if operating as a station.
Opportunistic roaming is one of those things that has many knobs to
twiddle, and depends a lot on the needs of the users.
But we're not actually in powersave mode -- the 802.11 stack can spit
out the NULL frames to tell the AP to buffer traffic for us. This is
trivial to do.
Scans should be specified as "non-distruptive" so the hardware driver
has to twiddle whatever bits are necessary to return the hardware to the
same state that it was in before the scan kicked in. Beyond that, the
scanning smarts are all in the 802.11 stack. The driver should be as
dumb as possible. :)
Background scanning, yes -- but there are all sorts of different
thresholds and types of 'scanning' to be done, depending on how
disruptive you are willing to be, and how capable the hardware is. Most
thin MACs don't filter out foreign BSSIDs on the same channel when
you're joined, which makes some things a lot easier.
> Further you want to order your channel list to hit the most likely
> channels first in case you are scanning for a specific ap--e.g. so you
> can stop the foreground scan and start to associate.
With my scenarios, the driver performs the sweep in the order it was
given -- if the hardware supports it, naturally.
> In terms of beacon miss processing some parts have a hardware beacon
> miss interrupt based on missed consecutive beacons but others require
> you to detect beacon miss in software. Other times you need s/w bmiss
> detection because you're doing something like build a repeater when
> the station virtual device can't depend on the hardware to deliver a
> bmiss interrupt.
Of course. The stack is going to need a set of timers regardless of the
hardware's capabilities, but having (sane) hardware beacon miss
detection capabilities makes it a bit more robust.
> Scanning (and roaming) is really a big can 'o worms.
Oh, I know. I've burned out many brain cells trying to build
supportable solutions for our customers.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 17:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jiri Benc, netdev, linux-kernel, John W. Linville
In-Reply-To: <1137423355.2520.112.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
> I really don't see why a plain STA mode card should be required to carry
> around all the code required for AP operation -- handling associations
> of clients, powersave management wrt. buffering, ... Sure, fragmentation
From the perspective of the hardware driver, there is little AP or
STA-specific code, especially when IBSS is thrown in. Thick MACs
excepted, there's little more than "frame tx/rx, and hardware control
twiddling".
The AP/STA smarts happen in the 802.11 stack. And, speaking from
experience, it is very hard to separate them cleanly, at least not
without incurring even more overall complexity and bloat.
It's far simpler to build them intertwined, then add a bunch of #ifdefs
if you want to disable AP or STA mode individually to save space.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-16 17:54 UTC (permalink / raw)
To: Stuffed Crust; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060116172817.GB8596@shaftnet.org>
Stuffed Crust wrote:
> On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
>
>>The above is a great synopsis but there is more. For example to support
>>roaming (and sometimes for ap operation) you want to do background
>>scanning; this ties in to power save mode if operating as a station.
>
>
> Opportunistic roaming is one of those things that has many knobs to
> twiddle, and depends a lot on the needs of the users.
>
> But we're not actually in powersave mode -- the 802.11 stack can spit
> out the NULL frames to tell the AP to buffer traffic for us. This is
> trivial to do.
The way you implement bg scanning is to notify the ap you are going into
power save mode before you leave the channel (in sta mode). Hence bg
scanning and power save operation interact.
>
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in. Beyond that, the
> scanning smarts are all in the 802.11 stack. The driver should be as
> dumb as possible. :)
See above. Doing bg scanning well is a balancing act and restoring
hardware state is the least of your worries (hopefully); e.g. what's the
right thing to do when you get a frame to transmit while off-channel
scanning, how often should you return to the bss channel?
>
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is. Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.
Er, you need to listen to at least beacons from other ap's if you're in
11g so you can detect overlapping bss and enable protection. There are
other ways to handle this but that's one.
>
>
>>Further you want to order your channel list to hit the most likely
>>channels first in case you are scanning for a specific ap--e.g. so you
>>can stop the foreground scan and start to associate.
>
>
> With my scenarios, the driver performs the sweep in the order it was
> given -- if the hardware supports it, naturally.
Channel ordering is useful no matter who specifies it. If you offload
the ordering to the upper layers then they need to be aware of the
regdomain constraints. Probably not a big deal but then you need to
synchronize info between layers or export it. And there's other
regdomain-related info that may want to be considered such as max
txpower. I'm just saying if you want to do a good job there's lots of
work here.
>
>
>>In terms of beacon miss processing some parts have a hardware beacon
>>miss interrupt based on missed consecutive beacons but others require
>>you to detect beacon miss in software. Other times you need s/w bmiss
>>detection because you're doing something like build a repeater when
>>the station virtual device can't depend on the hardware to deliver a
>>bmiss interrupt.
>
>
> Of course. The stack is going to need a set of timers regardless of the
> hardware's capabilities, but having (sane) hardware beacon miss
> detection capabilities makes it a bit more robust.
>
>
>>Scanning (and roaming) is really a big can 'o worms.
>
>
> Oh, I know. I've burned out many brain cells trying to build
> supportable solutions for our customers.
I don't recall seeing well-developed scanning code in either of the
proposed stacks.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-16 18:00 UTC (permalink / raw)
To: Stuffed Crust
Cc: Johannes Berg, Jiri Benc, netdev, linux-kernel, John W. Linville
In-Reply-To: <20060116173325.GC8596@shaftnet.org>
Stuffed Crust wrote:
> On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
>
>>I really don't see why a plain STA mode card should be required to carry
>>around all the code required for AP operation -- handling associations
>>of clients, powersave management wrt. buffering, ... Sure, fragmentation
>
>
> From the perspective of the hardware driver, there is little AP or
> STA-specific code, especially when IBSS is thrown in. Thick MACs
> excepted, there's little more than "frame tx/rx, and hardware control
> twiddling".
>
> The AP/STA smarts happen in the 802.11 stack. And, speaking from
> experience, it is very hard to separate them cleanly, at least not
> without incurring even more overall complexity and bloat.
>
> It's far simpler to build them intertwined, then add a bunch of #ifdefs
> if you want to disable AP or STA mode individually to save space.
Perhaps you haven't hit some of the more recent standards that place
more of a burden on the ap implementation? Also some vendor-specific
protocol features suck up space for ap mode only and it is nice to be
able to include them only as needed.
There are several advantages to splitting up the code such as reduced
audit complexity and real space savings but I agree that it is an open
question whethere there's a big gain to modularizing the code by
operating mode.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Dan Williams @ 2006-01-16 18:39 UTC (permalink / raw)
To: Stuffed Crust
Cc: Sam Leffler, Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060116172817.GB8596@shaftnet.org>
On Mon, 2006-01-16 at 12:28 -0500, Stuffed Crust wrote:
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in. Beyond that, the
> scanning smarts are all in the 802.11 stack. The driver should be as
> dumb as possible. :)
This is quite important... from a user perspective, it might be 2, 5, or
15 seconds before the card can actually scan all channels.
Unfortunately, background (passive) scanning by definition can't find
all access points, so you're going to need to do active scanning.
However, that active scanning should be controlled by userspace, not the
driver. Only userspace knows what policies the user him/herself has set
on powersaving mode.
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is. Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.
Scanning has the tradeoff of updated network list vs. saving power +
network disruption. The user, or programs delegated by the user, need
to make that choice, not the stack or the driver.
-------------
Furthermore, and this is also extremely important, user apps need to
know when the scan is done. From my look at drivers, _all_ cards know
when the hardware is in scanning states, and when its done. What many
don't do is communicate that information to userspace via wireless
events. The userspace app that requested scanning is then stuck
busy-waiting for the SIOCGIWSCAN to return success, which just sucks.
Much better if all drivers had the wireless event so that the userspace
app could just fire off the scan with SIOCSIWSCAN, and parse the results
when the event comes back rather than spinning.
In the netlink world, this would of course be done by multicasting the
"Scan Done" message to all interested clients, which would be just as
good.
Dan
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Samuel Ortiz @ 2006-01-16 18:51 UTC (permalink / raw)
To: ext Stuffed Crust; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060116170951.GA8596@shaftnet.org>
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > Regarding 802.11d and regulatory domains, the stack should also be able to
> > stick to one regulatory domain if asked so by userspace, whatever the APs
> > around tell us.
>
> ...and in doing so, violate the local regulatory constraints. :)
The other option is to conform to whatever the AP you associate with
advertises. In fact, this is how it should be done according to 802.11d.
Unfortunately, this doesn't ensure local regulatory constraints compliance
unless you expect each and every APs to do the Right Thing ;-)
> Allowing
> the user to change the regulatory domain at will.. is a rather fuzzy
> legal area, to say the least.
IMHO, strictly sticking to 802.11d is also somehow legally fuzzy as you're
as legal as the network you're joining.
Cheers,
Samuel.
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: John W. Linville @ 2006-01-16 19:06 UTC (permalink / raw)
To: Samuel Ortiz
Cc: ext Stuffed Crust, Jeff Garzik, Johannes Berg, netdev,
linux-kernel
In-Reply-To: <Pine.LNX.4.58.0601162020260.17348@irie>
On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
>
> > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > Regarding 802.11d and regulatory domains, the stack should also be able to
> > > stick to one regulatory domain if asked so by userspace, whatever the APs
> > > around tell us.
> >
> > ...and in doing so, violate the local regulatory constraints. :)
> The other option is to conform to whatever the AP you associate with
> advertises. In fact, this is how it should be done according to 802.11d.
> Unfortunately, this doesn't ensure local regulatory constraints compliance
> unless you expect each and every APs to do the Right Thing ;-)
If regulators come down on someone, it seems like common sense
that they would be more lenient on mobile stations complying with a
misconfigured AP than they would be with a mobile station ignoring a
properly configured AP? I know expecting common sense from government
regulators is optimistic, but still... :-)
Of course when we are the AP, the ability to adjust these parameters
could be very important. No?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Samuel Ortiz @ 2006-01-16 19:07 UTC (permalink / raw)
To: ext Stuffed Crust
Cc: Sam Leffler, Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060116172817.GB8596@shaftnet.org>
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is. Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.
That is true, thin MACs usually don't filter beacons on the same channel.
But in some cases (mainly power saving), you really want to avoid
receiving useless beacons and having the host woken up for each of them.
You may even want to not receive all the useful ones (the ones coming from
the AP you're joined with) if your softmac allows that.
This kind of beacon filtering is a big power saver, which is one of the
most important requirement for some platforms (phones, PDA, etc...).
Cheers,
Samuel.
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 19:40 UTC (permalink / raw)
To: Sam Leffler; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <43CBDDC7.9060504@errno.com>
[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
> The way you implement bg scanning is to notify the ap you are going into
> power save mode before you leave the channel (in sta mode). Hence bg
> scanning and power save operation interact.
That is not "powersave operation" -- that is telling the AP we are going
into powersave, but not actually going into powersave -- Actual
powersave operation would need to be disabled if we go into a scan, as
we need to have the rx path powered up and ready to hear anything out
there for the full channel dwell time.
> See above. Doing bg scanning well is a balancing act and restoring
> hardware state is the least of your worries (hopefully); e.g. what's the
> right thing to do when you get a frame to transmit while off-channel
> scanning, how often should you return to the bss channel?
Disallow all other transmits (either by failing them altogether, or by
buffering them up, which I think is better) while performing the scan.
If we are (continually) scanning because we don't have an association,
then we shouldn't be allowing any traffic through the stack anyway.
At the end of each scan pass, you return to the original channel, then
return "scan complete" to the stack/userspace. at this point any
pending transmits can go out, and if another scan pass is desired, it
will happen then.
> Er, you need to listen to at least beacons from other ap's if you're in
> 11g so you can detect overlapping bss and enable protection. There are
> other ways to handle this but that's one.
If you can't hear the traffic, then it doesn't count for purposes of ER
protection -- but that said, this only matters for AP operation, so APs
shouldn't filter out anyone else's becacons. STAs should respect the
"use ER Protection" bit in the AP's beacon, so can filter out traffic
that doesn't match the configured BSSID.
> >Oh, I know. I've burned out many brain cells trying to build
> >supportable solutions for our customers.
>
> I don't recall seeing well-developed scanning code in either of the
> proposed stacks.
I've only looked into the pre-2.6-merged HostAP stack, so I can't
comment on what's publically available. I'll have a look at the GPL'ed
DeviceScape stack when I have more time.
Most of what I've going on about is derived from my experience from
commercial 802.11 work I've done over the past few years.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 19:50 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Sam Leffler, Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.58.0601162056261.17348@irie>
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]
On Mon, Jan 16, 2006 at 09:07:52PM +0200, Samuel Ortiz wrote:
> That is true, thin MACs usually don't filter beacons on the same channel.
> But in some cases (mainly power saving), you really want to avoid
> receiving useless beacons and having the host woken up for each of them.
> You may even want to not receive all the useful ones (the ones coming from
> the AP you're joined with) if your softmac allows that.
BSSID filtering doesn't matter as far as 802.11 powersave is concerned
-- the power savings come from disabling the RF/BBP components. In
other words, you can't receive or transmit traffic.
If you're respecting the AP's beacon interval/DTIM settings, you only
wake up every couple of beacon intervals and listen for a beacon. IF
there's traffic waiting for you, then you wake up your transmitter, send
out a PSPOLL (or NULL/PSEnd) frame, get your traffic, then go back to
sleep again.
You may hear another beacon when the STA is awake, you may not. BSSID
filtering has nothing to do with 802.11 power save, but rather is
intented to reduce the host load (interrupts, processing overhead) and
thus the host power consumption.
> This kind of beacon filtering is a big power saver, which is one of the
> most important requirement for some platforms (phones, PDA, etc...).
You need to be clear if you're talking about 802.11 powersave, versus
"power savings stemming from reducing the load on the host system",
which is where BSSID filtering is beneficial.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Andy Gospodarek @ 2006-01-16 20:04 UTC (permalink / raw)
To: linux-kernel, netdev, davem
Printing the total number of sockets used in /proc/net/sockstat is out
of place in a file that is supposed to contain information related to
ipv4 sockets. Removed output for total socket usage.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
proc.c | 1 -
1 files changed, 1 deletion(-)
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -60,7 +60,6 @@ static int fold_prot_inuse(struct proto
*/
static int sockstat_seq_show(struct seq_file *seq, void *v)
{
- socket_seq_show(seq);
seq_printf(seq, "TCP: inuse %d orphan %d tw %d alloc %d mem %d\n",
fold_prot_inuse(&tcp_prot), atomic_read(&tcp_orphan_count),
tcp_death_row.tw_count, atomic_read(&tcp_sockets_allocated),
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Samuel Ortiz @ 2006-01-16 20:10 UTC (permalink / raw)
To: ext Stuffed Crust
Cc: Sam Leffler, Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060116195008.GB12748@shaftnet.org>
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> You may hear another beacon when the STA is awake, you may not. BSSID
> filtering has nothing to do with 802.11 power save, but rather is
> intented to reduce the host load (interrupts, processing overhead) and
> thus the host power consumption.
I know that and I know a bit about 802.11 PS as well.
I was talking about host powersaving, not 802.11. Sorry for the confusion.
What I meant is that having an 802.11 stack capable of living with less
than a beacon every couple of beacon intervals would be nice as well.
Cheers,
Samuel.
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Lee Revell @ 2006-01-16 20:14 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: linux-kernel, netdev, davem
In-Reply-To: <20060116200432.GB14060@gospo.rdu.redhat.com>
On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote:
> Printing the total number of sockets used in /proc/net/sockstat is out
> of place in a file that is supposed to contain information related to
> ipv4 sockets. Removed output for total socket usage.
>
Um, you can't do that, it will break userspace.
Lee
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-16 20:14 UTC (permalink / raw)
To: pizza, Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060116194013.GA12748@shaftnet.org>
Stuffed Crust wrote:
> On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
>> The way you implement bg scanning is to notify the ap you are going into
>> power save mode before you leave the channel (in sta mode). Hence bg
>> scanning and power save operation interact.
>
> That is not "powersave operation" -- that is telling the AP we are going
> into powersave, but not actually going into powersave -- Actual
> powersave operation would need to be disabled if we go into a scan, as
> we need to have the rx path powered up and ready to hear anything out
> there for the full channel dwell time.
Please read what I wrote again. Station mode power save work involves
communicating with the ap and managing the hardware. The first
interacts with bg scanning. We haven't even talked about how to handle
sta mode power save.
>
>> See above. Doing bg scanning well is a balancing act and restoring
>> hardware state is the least of your worries (hopefully); e.g. what's the
>> right thing to do when you get a frame to transmit while off-channel
>> scanning, how often should you return to the bss channel?
>
> Disallow all other transmits (either by failing them altogether, or by
> buffering them up, which I think is better) while performing the scan.
Not necessarily in my experience.
>
> If we are (continually) scanning because we don't have an association,
> then we shouldn't be allowing any traffic through the stack anyway.
If you do not have an association you are not doing bg scanning.
>
> At the end of each scan pass, you return to the original channel, then
> return "scan complete" to the stack/userspace. at this point any
> pending transmits can go out, and if another scan pass is desired, it
> will happen then.
If you wait until the end of the scan to return to the bss channel then
you potentially miss buffered mcast frames. You can up the station's
listen interval but that only gets you so far. As I said there are
tradeoffs in doing this.
>
>> Er, you need to listen to at least beacons from other ap's if you're in
>> 11g so you can detect overlapping bss and enable protection. There are
>> other ways to handle this but that's one.
>
> If you can't hear the traffic, then it doesn't count for purposes of ER
> protection -- but that said, this only matters for AP operation, so APs
> shouldn't filter out anyone else's becacons. STAs should respect the
> "use ER Protection" bit in the AP's beacon, so can filter out traffic
> that doesn't match the configured BSSID.
Sorry I meant this was needed for ap operation.
>
>>> Oh, I know. I've burned out many brain cells trying to build
>>> supportable solutions for our customers.
>> I don't recall seeing well-developed scanning code in either of the
>> proposed stacks.
>
> I've only looked into the pre-2.6-merged HostAP stack, so I can't
> comment on what's publically available. I'll have a look at the GPL'ed
> DeviceScape stack when I have more time.
>
> Most of what I've going on about is derived from my experience from
> commercial 802.11 work I've done over the past few years.
Ditto.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Samuel Ortiz @ 2006-01-16 20:16 UTC (permalink / raw)
To: ext John W. Linville
Cc: ext Stuffed Crust, Jeff Garzik, Johannes Berg, netdev,
linux-kernel
In-Reply-To: <20060116190629.GB5529@tuxdriver.com>
On Mon, 16 Jan 2006, ext John W. Linville wrote:
> On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> > On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> >
> > > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > > Regarding 802.11d and regulatory domains, the stack should also be able to
> > > > stick to one regulatory domain if asked so by userspace, whatever the APs
> > > > around tell us.
> > >
> > > ...and in doing so, violate the local regulatory constraints. :)
> > The other option is to conform to whatever the AP you associate with
> > advertises. In fact, this is how it should be done according to 802.11d.
> > Unfortunately, this doesn't ensure local regulatory constraints compliance
> > unless you expect each and every APs to do the Right Thing ;-)
>
> If regulators come down on someone, it seems like common sense
> that they would be more lenient on mobile stations complying with a
> misconfigured AP than they would be with a mobile station ignoring a
> properly configured AP? I know expecting common sense from government
> regulators is optimistic, but still... :-)
Well, I'd rather trust a governement regulated network than my neighbour's
AP ;-) In fact, some phones set their 802.11 regulatory domain based on
the information they received from a somehow government regulated network,
e.g. a GSM one.
Cheers,
Samuel.
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 20:16 UTC (permalink / raw)
To: Sam Leffler
Cc: Johannes Berg, Jiri Benc, netdev, linux-kernel, John W. Linville
In-Reply-To: <43CBDF32.50109@errno.com>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place
> more of a burden on the ap implementation? Also some vendor-specific
> protocol features suck up space for ap mode only and it is nice to be
> able to include them only as needed.
While there is more work to be done on the AP side, and that code may
even be easily wrapped in an #ifdef, the majority of the complexity is
shared by both the station and the AP. It's worth mentioning that the
802.11 specs do not generally differentiate between "APs vs non-APs" --
they're all "STAs" of equal capabilities.
This is at least true of 802.11d, 802.11e, 802.11i
(supplicant/authenticator notwithstanding), 802.11j, and 802.11k. The
general difference is that the AP needs to be aware of the state of its
associated STAs, and perform different actions depending on configured
policy and the STAs' states, whereas the STAs generally do what the AP
tells them to do.
> There are several advantages to splitting up the code such as reduced
> audit complexity and real space savings but I agree that it is an open
> question whethere there's a big gain to modularizing the code by
> operating mode.
I agree that there would be some space savings, but they'd be relatively
small, at least if the stack is designed to be generic. This would make
the most difference for tiny/embedded systems -- but they'd want to use
#ifdefs to disable all AP code entirely, which includes all of the "if
(ap_mode) { } else { }" clauses that would litter the whole codebase,
regardless of modularity. (then if we use function pointers... that's a
*lot* of virtual functions..)
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox