* 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: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: 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 (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: [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 (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
* [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: 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
* 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: 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: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-16 5:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, netdev, SP
In-Reply-To: <200601131146.48128.arnd@arndb.de>
Hi Arnd
I have made the changes suggested, and attached it below. I think it
should be good now.
Just a couple of questions if I may.
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.
Does that also mean that copy_to_user should not be used in ioctl
calls?
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.
/Shaun
Index: linux-2.6.15/include/net/compat.h
===================================================================
--- linux-2.6.15.orig/include/net/compat.h
+++ linux-2.6.15/include/net/compat.h
@@ -23,6 +23,8 @@ struct compat_cmsghdr {
compat_int_t cmsg_type;
};
+extern int compat_sock_get_timestamp(struct sock *, struct timeval
__user *);
+
#else /* defined(CONFIG_COMPAT) */
#define compat_msghdr msghdr /* to avoid compiler warnings */
#endif /* defined(CONFIG_COMPAT) */
Index: linux-2.6.15/net/compat.c
===================================================================
--- linux-2.6.15.orig/net/compat.c
+++ linux-2.6.15/net/compat.c
@@ -503,6 +503,25 @@ static int do_get_sock_timeout(int fd, i
return err;
}
+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;
+}
+
asmlinkage long compat_sys_getsockopt(int fd, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -602,3 +621,5 @@ asmlinkage long compat_sys_socketcall(in
}
return ret;
}
+
+EXPORT_SYMBOL(compat_sock_get_timestamp);
On Fri, 2006-01-13 at 11:46 +0000, Arnd Bergmann wrote:
> On Friday 13 January 2006 03:14, Shaun Pereira wrote:
> > Thank you for reviewing that bit of code.
> > I had a look at compat_sys_gettimeofday and sys32_gettimeofday codes.
> > They seem to work in a similar way, casting a pointer to the structure
> > from user space to a compat_timeval type.
>
> The part with the case is ok, except that you don't have to write
>
> struct compat_timeval __user *ctv;
> ctv = (struct compat_timeval __user*) userstamp;
>
> Instead,
>
> struct compat_timeval __user *ctv = userstamp;
>
> is the more common way to write it. The result is the same, since
> userstamp is a 'void __user *'.
>
> > But to make sure I have tested the routine by forcing the sk-
> > >sk_stamp.tv_sec value to 0 in the x25_module ( for testing purposes
> > only, as it is initialised to -1). Now when
> > I make a 32 bit userspace SIOCGSTAMP ioctl to the 64 bit kernel I should
> > get the current time back in user space. This seems to work, the ioctl
> > returns the system time (just after TEST6:)
> >
> > So I have left the patch as is for now. However if necessary to use
> > the element-by-element __put_user routine as in put_tv32, then I can
> > make the change, just let me know.
>
> You need to to exactly that, yes. I'm not sure what exactly you have
> tested, but the expected result of your code would be that you see
> the sk_stamp.tv_sec value in the output, but not the tv_usec value.
>
> On little-endian system like x86_64, that is not much of a difference
> (less than a second) that you might miss in a test case, but on
> big-endian, it would be fatal.
>
> The layout of the structures on most systems is
>
> 64 bit LE 64 bit BE 32 bit
>
> bytes 0-3 tv_sec low tv_sec high tv_sec low
> bytes 4-7 tv_sec high tv_sec low tv_usec low
> bytes 8-11 tv_usec low tv_usec high
> bytes 12-15 tv_usec high tv_usec low
>
> You code copies the first eight bytes of the 64 bit data structure
> into the 32 bit data structure.
>
> Arnd <><
^ permalink raw reply
* RE: wireless: recap of current issues (other issues)
From: Simon Barber @ 2006-01-16 5:32 UTC (permalink / raw)
To: Jeff Garzik, John W. Linville; +Cc: netdev, linux-kernel
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: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
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 majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux 2.6.15.1 ppp_async panic on x86-64.
From: Diego Calleja @ 2006-01-16 3:03 UTC (permalink / raw)
To: Serge Belyshev; +Cc: linux-kernel, vitalyb, netdev
In-Reply-To: <56slrpz0j7.fsf@depni.sinp.msu.ru>
This should have been forwaded to netdev I think (forwading there)
El Sun, 15 Jan 2006 23:41:48 +0300,
Serge Belyshev <belyshev@depni.sinp.msu.ru> escribió:
Diego Calleja <diegocg@gmail.com> writes:
> > El Sun, 15 Jan 2006 21:48:38 +0200,
> > "Vitaly V. Bursov" <vitalyb@telenet.dn.ua> escribió:
> ...
> >> PPP doesn't work for me on a x86-64 kernel. Kernel panics with a message
> ...
> >> Jan 15 20:24:12 vb skb_over_panic: text:ffffffff886700d9 len:1 put:1
> >> head:ffff81002b7ed000 data:ffff81012b7ed000 tail:ffff81012b7ed001
> >> end:ffff81002b7ed600 dev:<NULL>
> ...
> > Just for the record, there're more people hitting this
> > http://bugzilla.kernel.org/show_bug.cgi?id=5857
>
> I can confirm this with a similar oops:
>
> [ 273.950666] skb_over_panic: text:ffffffff882d8c19 len:54 put:54 head:ffff81001cfecd60 data:ffff81011cfecd63 tail:ffff81011cfecd99 end:ffff81001cfed360 dev:<NULL>
> [ 273.950681] ----------- [cut here ] --------- [please bite here ] ---------
> [ 273.950684] Kernel BUG at net/core/skbuff.c:94
> [ 273.950686] invalid operand: 0000 [1] PREEMPT
> [ 273.950689] CPU 0
> [ 273.950691] Modules linked in: ppp_deflate bsd_comp ppp_async ppp_generic slhc pl2303 usbserial radeon drm af_packet ipv6 pcmcia firmware_class bridge deflate zlib_deflate zlib_inflate twofish serpent aes blowfish des sha256 sha1 af_key binfmt_misc dm_mod asus_acpi button thermal processor battery evdev eth1394 snd_intel8x0 snd_intel8x0m snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm irtty_sir snd_timer ohci1394 snd sir_dev irda 8250_pci ide_cd yenta_socket rsrc_nonstatic pcmcia_core amd64_agp ehci_hcd psmouse pcspkr parport_pc parport 8250 serial_core ieee1394 cdrom ohci_hcd usbcore crc_ccitt i2c_nforce2 i2c_core soundcore snd_page_alloc rtc agpgart unix
> [ 273.950728] Pid: 4, comm: events/0 Not tainted 2.6.15-ssb1dbg #3
> [ 273.950731] RIP: 0010:[skb_over_panic+96/112] <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950739] RSP: 0018:ffff81001fe19d78 EFLAGS: 00010096
> [ 273.950742] RAX: 00000000000000ab RBX: 0000000000000036 RCX: ffffffff803b5d58
> [ 273.950745] RDX: ffff81001ff38080 RSI: 0000000000000082 RDI: 0000000000000001
> [ 273.950749] RBP: ffff81001fe19d98 R08: 0000000000000005 R09: 0000000000000000
> [ 273.950752] R10: 0000000000000000 R11: 0000000000000000 R12: ffff81000c4c18e8
> [ 273.950755] R13: 000000000000003f R14: ffff8100164a8801 R15: ffff81011cfecd63
> [ 273.950759] FS: 00002aaaab3a96d0(0000) GS:ffffffff80575800(0000) knlGS:0000000000000000
> [ 273.950763] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 273.950766] CR2: 0000000000c55000 CR3: 0000000019e81000 CR4: 00000000000006e0
> [ 273.950770] Process events/0 (pid: 4, threadinfo ffff81001fe18000, task ffff81001ff38080)
> [ 273.950772] Stack: ffff81011cfecd99 ffff81001cfed360 ffffffff80323edb ffff81000c4c18e8
> [ 273.950779] ffff81001fe19df8 ffffffff882d8c23 ffff81000c4c19a0 ffff81000c4c1918
> [ 273.950785] ffff8100164a8401 ffff8100164a8000
> [ 273.950789] Call Trace:<ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
> [ 273.950800] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
> [ 273.950816] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
> [ 273.950827] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
> [ 273.950839] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
> [ 273.950848] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
> [ 273.950858] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
> [ 273.950871]
> [ 273.950874]
> [ 273.950875] Code: 0f 0b 68 fe fe 32 80 c2 5e 00 c9 c3 66 66 66 90 55 49 89 d2
> [ 273.950885] RIP <ffffffff8027c160>{skb_over_panic+96} RSP <ffff81001fe19d78>
> [ 273.950891] <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
> [ 273.950895] in_atomic():1, irqs_disabled():1
> [ 273.950897]
> [ 273.950898] Call Trace:<ffffffff8012c9eb>{__might_sleep+187} <ffffffff801328ed>{profile_task_exit+29}
> [ 273.950907] <ffffffff801339e5>{do_exit+37} <ffffffff802fc7fd>{_spin_unlock_irqrestore+29}
> [ 273.950917] <ffffffff80110654>{die+84} <ffffffff802fce4d>{do_trap+269}
> [ 273.950929] <ffffffff80110e6d>{do_invalid_op+157} <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950941] <ffffffff8010f621>{error_exit+0} <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950962] <ffffffff8027c160>{skb_over_panic+96} <ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
> [ 273.950975] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
> [ 273.950990] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
> [ 273.950999] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
> [ 273.951011] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
> [ 273.951020] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
> [ 273.951029] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
> [ 273.951042]
> [ 273.951046] note: events/0[4] exited with preempt_count 1
>
> (this is 2.6.15-ck2 + few local hacks with debugging config)
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Adrian Bunk @ 2006-01-16 0:08 UTC (permalink / raw)
To: Vitaly Bordug
Cc: jgarzik, saw, linux-kernel, netdev, john.ronciak,
ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <20060115161958.07e3c7f1@vitb.dev.rtsoft.ru>
On Sun, Jan 15, 2006 at 04:19:58PM +0300, Vitaly Bordug wrote:
> On Thu, 5 Jan 2006 19:18:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the obsolete drivers/net/eepro100.c driver.
> >
> > Is there any known problem in e100 still preventing us from removing
> > this driver (it seems noone was able anymore to verify the ARM problem)?
> >
> I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
> and eepro100 worked just fine.
>
> Even if the patch below will be scheduled for application, we need to set up enough time
> for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
How/When can you/someone else test this?
Do the e100 maintainers (Cc'ed) know about such problems and their
status?
> Sincerely,
> Vitaly
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Mike Kershaw @ 2006-01-16 0:06 UTC (permalink / raw)
To: Sam Leffler; +Cc: Stefan Rompf, Johannes Berg, netdev, linux-kernel
In-Reply-To: <43CAA4FD.5070605@errno.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
On Sun, Jan 15, 2006 at 11:39:41AM -0800, Sam Leffler wrote:
> The big stumbling block I found to going with virtual devices is that it
> affects user apps. I looked at doing things like auto-create a station
> device for backwards compatibility but decided against it. If you
> really want this behaviour it can be done by user code.
Right, no reason not to just put this into a hotplug script, is there?
Is it, when it comes down to it, significantly different than automating
firmware loads for the user?
-m
--
Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Experts in ancient Greek culture say that people back then didn't see their
thoughts as belonging to them. When they had a thought, it occured to them
as a god or goddess giving them an order. Apollo was telling them to be
brave. Athena was telling them to fall in love.
Now people hear a commercial for sour cream potato chips and rush out to buy.
-- Chuck Palahniuk
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Stephen Hemminger @ 2006-01-16 0:03 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Adrian Bunk, jgarzik, saw, linux-kernel, netdev
In-Reply-To: <20060115161958.07e3c7f1@vitb.dev.rtsoft.ru>
On Sun, 15 Jan 2006 16:19:58 +0300
Vitaly Bordug <vbordug@ru.mvista.com> wrote:
> On Thu, 5 Jan 2006 19:18:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the obsolete drivers/net/eepro100.c driver.
> >
> > Is there any known problem in e100 still preventing us from removing
> > this driver (it seems noone was able anymore to verify the ARM problem)?
> >
> I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
> and eepro100 worked just fine.
>
> Even if the patch below will be scheduled for application, we need to set up enough time
> for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
>
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> >
How about doing what was done with devfs removal, and remove it
from the config menu system for a couple of releases.
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-15 20:11 UTC (permalink / raw)
To: Sam Leffler; +Cc: Stefan Rompf, netdev, linux-kernel
In-Reply-To: <43CAABD4.3070004@errno.com>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Sun, 2006-01-15 at 12:08 -0800, Sam Leffler wrote:
> To do what you describe I would create a monitor mode device, switch
> channel, then destroy it. All the time you leave the station device
> unchanged, though you probably need to disable it. This may not be
> possible with all devices--i.e. for those that require different
> firmware to do monitoring you will be restricted to a single virtual
> device and/or operating mode.
Yeah, I agree with this, it is much cleaner to handle in the kernel.
Think about the issues if you have a struct net_device that has 250
bytes of "payload" for the struct virtual_sta_device in it and you want
to switch that to a struct virtual_monitor_device. Icky.
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: Sam Leffler @ 2006-01-15 20:08 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <200601151853.31710.stefan@loplof.de>
Stefan Rompf wrote:
> Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
>
>> Isn't that rather a question of having good user-space tools that make
>> deactivating one type of interface and activating another seamless?
>
> Well, it's always easy to point to userspace. However, unregister_netdev()
> initiates a lot of actions. IPv4 addresses and routes are removed, same for
> IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered
> (even though I have not tried yet if it works when I create VLANs over 802.3
> emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be
> restored by the nifty new configuration utility, possibly including ifindex
> and future protocols.
>
> This is from my usage pattern that I want to go into monitor mode on current
> channel, look at some packets and return to the association without losing
> layer 3 configuration.
>
> So after all, it is IMHO way less painful to handle a mode change in the
> kernel.
To do what you describe I would create a monitor mode device, switch
channel, then destroy it. All the time you leave the station device
unchanged, though you probably need to disable it. This may not be
possible with all devices--i.e. for those that require different
firmware to do monitoring you will be restricted to a single virtual
device and/or operating mode.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-15 19:53 UTC (permalink / raw)
To: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060115152034.GA1722@shaftnet.org>
Stuffed Crust wrote:
> On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
>>> This can be accomplished by passing a static table to the
>>> register_wiphy_device() call (or perhaps via a struct wiphy_dev
>>> parameter) or through a more explicit, dynamic interface like:
>>>
>>> wiphy_register_supported_frequency(hw, 2412).
>> For completely programmable hardware, the stack should interact with a
>> module like ieee80211_geo, to help ensure the hardware stays within
>> legal limits.
>
> While there is much to debate about where to draw the functionality
> line, completely programmable hardware is the norm these days.
>
> ... and said code would be responsible for driving the scanning state
> machines, and also for more esoteric functions like handling RADAR
> traps, automatic channel switching, etc.
>
> Handling scans is quite interesting -- I've seen hardware which requires
> manual channel changing (including full RF parameter specification),
> host timing for the channel dwell time, and manual probe request
> issuance.. and on the other end of the spectrum, a simple "issue scan"
> command that takes few, if any, parameters.
>
> And unfortunately, many things in between.
>
> This leads me to belive that the internal scan workflow should work
> something like this:
>
> * Userspace app issues scan request (aka "refresh AP list")
>
> * Knowing the hardware frequency capabilities, the 802.11 stack applies
> 802.11d and regdomain rules to the available frequency set, and
> issues multiple internal "scan request" commands to the hardware
> driver. (eg "perform an initial passive sweep across the entire
> 2.4G band", "perform an active scan on frequencies 2412->2437
> looking for ssid "HandTossed", "perform an active scan on
> frequencies 5200-5400 looking for ssid "HandTossed", etc)
>
> (note that ideally, userspace apps/libs would be at least partially
> aware of 802.11d rules, but the kernel must do the RightThing if
> told to "scan all available channels for any access points")
>
> * The hardware driver takes this scan request, and maps it into the
> capabilities of the hardware:
>
> Hardware A: (very thin MAC)
> - Using library code, generates an appropriate probe request frame,
> translates it into a format the hardware expects/needs,
> and schedules it appropriately.
> - Loops through the frequency set specified, and for each:
> - Issues a channel change command
> - Immediately transmits the probe request (for active scans)
> - Dwells for an appropriate time
> - RX'ed beacon/probe response frames come down as regular 802.11
> frames into the stack
> - Moves to the next channel
>
> Hardware B: (thinner MAC)
> - Using library code, generates an appropriate probe request frame,
> and translate it into a format the hardware expects.
> - Program the probe request frame into the hardware as a probe
> template.
> - Loops through the frequency set specified, and for each:
> - Issues a channel change command
> - Wait for a scan complete signal
> - RX'ed beacon/probe response frames come down as regular 802.11
> frames into the stack
> - Moves to the next channel
>
> Hardware C: (thick MAC, ala prism2 or prism54)
> - Issues a hardware "scan request"
> - Waits for the hardware to signal "scan complete"
> - Requests hardware scan results
> - For each scan result, the hardware returns:
> - Translate result into an 802.11 probe response frame and
> pass down the regular RX path.
>
> So as you can see, I think the channel iteration, dwell, etc should
> be performed by the hardware driver itself, as the variation at the
> logical "tell the hardware perform a scan" step is so extreme.
>
> * Meanwhile, the 802.11 stack is receiving the beacons/probe responses
> from the hardware via the regular rx path. It diverts these (and
> other 802.11 management/control) frames, decodes them, and then adds
> them to the stack's internal list of available stations, updating any
> internal states/counters as necessary. (These frames could also be
> echoed to a special netdev interface if desired)
>
> (stuff like detecting an AP going away depends on us noticing a lack
> of beacons arriving, for example. Most hardware does not
> notify us of this event. Likewise, we should expire other
> APs from our list if they go away.. etc. For AP operation we need
> to maintain this STA list, period -- so why not use it across the
> board? But this is another discussion for another time..)
>
> * The 802.11 stack issues a MLME-Scan-Complete notification to
> userspace.
>
> * Interested userspace apps see this event, then query the
> scan results and presents them to the user in some pretty format, or
> alternatively perform automatic roaming based on scan results.
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.
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. 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.
Then of course there's whole issue of interacting with firmware-based
cards that have limited and/or funkiness in their scanning support.
Scanning (and roaming) is really a big can 'o worms.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-15 19:39 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <200601151340.10730.stefan@loplof.de>
Stefan Rompf wrote:
> Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
>
>> [Changing mode of virtual devices]
>>
>> 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. 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.
>
> Even though it is a bit more work on kernel side, we should allow changing the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow it and virtual interfaces are
> limited to one channel anyway. These users rightfully expect to have one
> interface and be able to do all configurations on it.
My experience is that once you can create+destroy virtual devices you'll
never want mode changing. From a usability standpoint when you switch
modes you typically have to reconfigure lots of settings and doing
destroy old followed by create new is easier. Depending on how things
tie into hotplug you may also find things getting complicated.
Within the kernel having the operating mode of a virtual device not
change is very good. First it lets you isolate the rules for mix+match
of different virtual devices at create. Second you can partition code
so, for example, only code required to support an ap is loaded when an
ap mode virtual device exists. There are other less obvious reasons
such as firmware-based devices can load firmware based on the operating
mode at create time but if you allow mode switching then you need to
unload+load on the fly. All these things can be handled with switching
modes but the complexity is significant and the gain is minimal.
The big stumbling block I found to going with virtual devices is that it
affects user apps. I looked at doing things like auto-create a station
device for backwards compatibility but decided against it. If you
really want this behaviour it can be done by user code.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Samuel Ortiz @ 2006-01-15 19:05 UTC (permalink / raw)
To: ext Stuffed Crust; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060115152034.GA1722@shaftnet.org>
On Sun, 15 Jan 2006, ext Stuffed Crust wrote:
> * Knowing the hardware frequency capabilities, the 802.11 stack applies
> 802.11d and regdomain rules to the available frequency set, and
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.
Cheers,
Samuel.
^ permalink raw reply
* Re: acxsm: migrate acx from homegrown 802.11 handling to softmac stack
From: Carlos Martín @ 2006-01-15 18:29 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: netdev, softmac-dev, acx100-devel
In-Reply-To: <200601151352.44548.vda@ilport.com.ua>
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.
> 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?
cmn
--
Carlos Martín http://www.cmartin.tk
"Erdbeben? Sicherlich etwas, das mit Erdberen zu tun hat." -- me, paraphrased
-------------------------------------------------------
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: wireless: recap of current issues (configuration)
From: Stefan Rompf @ 2006-01-15 17:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel
In-Reply-To: <56187.84.135.205.30.1137340292.squirrel@secure.sipsolutions.net>
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
> Isn't that rather a question of having good user-space tools that make
> deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
initiates a lot of actions. IPv4 addresses and routes are removed, same for
IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered
(even though I have not tried yet if it works when I create VLANs over 802.3
emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be
restored by the nifty new configuration utility, possibly including ifindex
and future protocols.
This is from my usage pattern that I want to go into monitor mode on current
channel, look at some packets and return to the association without losing
layer 3 configuration.
So after all, it is IMHO way less painful to handle a mode change in the
kernel.
Stefan
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-15 16:18 UTC (permalink / raw)
To: Dan Williams; +Cc: John W. Linville, netdev, linux-kernel
In-Reply-To: <1137282117.27849.11.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote:
> One other thing: capability. It's not enough to be able to configure
> the device, user-space tools also have to know what the device is
> capable of before they try touching it. Ie, which ciphers, protocols,
> channels, etc. Similar to the IWRANGE ioctl that there is now. Half
> the problem now is that you can't reliably tell what drivers support
> which features, or how much they support a particular feature.
This is an absolute requirement, especially when talking about
encryption.
You'd need, for example:
CAP_WEP_64
CAP_WEP_128
CAP_WEP_256 (non-standard, but often supported)
CAP_TKIP
CAP_MICHAELMIC
CAP_AES_CCMP
Then, to make things more complicated:
CAP_KEYMAPPING (can the hardware do keymapping?)
CAP_CAN_DISABLE_HWCRYPT (so if the hardware can't do TKIP, can we
perform it on the host?)
And to make things even more complicated, I've seen hardware that
supports disabling of hardware crypto, but not toggling it on the fly,
thanks to never-fixed hardware bugs. (you have to perform a full
reset/firmware load cycle. this means you end up disabling host crypto
altogether, at least if any of the networks you want to support include
CCMP...
Other quirks -- hardware that requires host MICHAEL on transmits, but
handles it on reception, unless if the received frames are fragmented.
Other hardware that does keymapping on rx frames, but for transmits
takes the raw keydata in the tx descriptor. (but still requires host
MICHAEL)
The list goes on and on..
- 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: Johannes Berg @ 2006-01-15 15:51 UTC (permalink / raw)
To: Stefan Rompf; +Cc: netdev, linux-kernel
In-Reply-To: <200601151340.10730.stefan@loplof.de>
Stefan Rompf wrote:
> Even though it is a bit more work on kernel side, we should allow changing
> the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow it and virtual interfaces are
> limited to one channel anyway. These users rightfully expect to have one
> interface and be able to do all configurations on it.
Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?
johannes
^ 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