* Re: dBm cutoff at -1dBm is too low
From: Jean Tourrilhes @ 2006-05-09 18:54 UTC (permalink / raw)
To: Pavel Roskin; +Cc: NetDev
In-Reply-To: <1147150495.4453.65.camel@dv>
On Tue, May 09, 2006 at 12:54:55AM -0400, Pavel Roskin wrote:
> On Mon, 2006-05-08 at 10:17 -0700, Jean Tourrilhes wrote:
> > > But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
> > > is positive or negative?
> >
> > You can't remove the test, making the rest pointeless. Old
> > style driver never used the flags, new style driver that don't report
> > dBm will never use the flags, and there is not way to dinstinguish
> > both, apart from the 'sign' of the value.
>
> I used "new style driver" as synonymous to the driver using IW_QUAL_DBM
> and "old style driver" as the one that doesn't use IW_QUAL_DBM.
>
> I don't think any drivers need to specify both dBm and non-dBm data for
> the same device.
>
> Drivers that give non-dBm data are already well served by wireless
> tools. They don't need to change.
>
> Drivers that give dBm data had to limit the data to avoid its
> misinterpretation as non-dBm data. Now IW_QUAL_DBM is supposed to free
> drivers from such checks. But it doesn't deliver its promise, because
> the data can still be misinterpreted, just is a different way. Namely,
> a strong signal (0dBm) can be interpreted as an incredibly weak signal
> (-256dBm). That's what I want to see fixed.
I hear you 100%. But, before removing the backward
compatibility for old style drivers, we need to make sure all of them
are gone. I don't plan to keep backward compatibility forever, but
just enough to cover the transition.
Technically, we can't make backward compatibility for old
driver and this proposal to work together, because of the test on the
sign. We need to pick one.
> One tricky case would be when the driver sets the max signal e.g. to 30
> and reports 35 (i.e. a positive value within the "reasonable" dBm
> range). I would probably prefer to show it as 30/30 rather than 35dBm,
> but the driver is nuts anyway, and I'm not really concerned about it to
> write an extra line of code.
Agreed.
> Regards,
> Pavel Roskin
Jean
^ permalink raw reply
* Re: r8169+NAPI soft lockup
From: Francois Romieu @ 2006-05-09 18:53 UTC (permalink / raw)
To: Richard Gregory; +Cc: netdev
In-Reply-To: <4460DCAF.7060503@liv.ac.uk>
Richard Gregory <R.Gregory@liverpool.ac.uk> :
> Francois Romieu wrote:
[...]
> >Is netconsole enabled ?
>
> It can be. How much output do you need, a single soft lockup?
Nonononono. Keep it disabled.
--
Ueimor
^ permalink raw reply
* Re: [RFC] SECMARK 1.0
From: James Morris @ 2006-05-09 18:56 UTC (permalink / raw)
To: Karl MacMillan
Cc: Joshua Brindle, selinux, netdev, Stephen Smalley, Daniel J Walsh,
netfilter-devel
In-Reply-To: <1147194399.32719.148.camel@jackjack.columbia.tresys.com>
On Tue, 9 May 2006, Karl MacMillan wrote:
> Ok - I obviously don't have the expertise to judge how ugly the code to
> do this is. It becomes a question of whether the feature is compelling
> enough.
Atcually, I think there may be a good way to do this, will investigate.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Stephen Hemminger @ 2006-05-09 18:56 UTC (permalink / raw)
To: Chris Wright
Cc: xen-devel, Ian Pratt, netdev, linux-kernel, virtualization,
Christian Limpach
In-Reply-To: <20060509085201.446830000@sous-sol.org>
The stuff in /proc could easily just be added attributes to the class_device kobject
of the net device (and then show up in sysfs).
> +
> +#define GRANT_INVALID_REF 0
> +
> +#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
> +#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
> +
> +static inline void init_skb_shinfo(struct sk_buff *skb)
> +{
> + atomic_set(&(skb_shinfo(skb)->dataref), 1);
> + skb_shinfo(skb)->nr_frags = 0;
> + skb_shinfo(skb)->frag_list = NULL;
> +}
> +
Could you use existing sk_buff_head instead of inventing your
own skb queue?
> +struct netfront_info
> +{
> + struct list_head list;
> + struct net_device *netdev;
> +
> + struct net_device_stats stats;
> + unsigned int tx_full;
> +
> + struct netif_tx_front_ring tx;
> + struct netif_rx_front_ring rx;
> +
> + spinlock_t tx_lock;
> + spinlock_t rx_lock;
> +
> + unsigned int handle;
> + unsigned int evtchn, irq;
> +
> + /* What is the status of our connection to the remote backend? */
> +#define BEST_CLOSED 0
> +#define BEST_DISCONNECTED 1
> +#define BEST_CONNECTED 2
> + unsigned int backend_state;
> +
> + /* Is this interface open or closed (down or up)? */
> +#define UST_CLOSED 0
> +#define UST_OPEN 1
> + unsigned int user_state;
> +
> + /* Receive-ring batched refills. */
> +#define RX_MIN_TARGET 8
> +#define RX_DFL_MIN_TARGET 64
> +#define RX_MAX_TARGET NET_RX_RING_SIZE
> + int rx_min_target, rx_max_target, rx_target;
> + struct sk_buff_head rx_batch;
> +
> + struct timer_list rx_refill_timer;
> +
> + /*
> + * {tx,rx}_skbs store outstanding skbuffs. The first entry in each
> + * array is an index into a chain of free entries.
> + */
> + struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1];
> + struct sk_buff *rx_skbs[NET_RX_RING_SIZE+1];
> +
> + grant_ref_t gref_tx_head;
> + grant_ref_t grant_tx_ref[NET_TX_RING_SIZE + 1];
> + grant_ref_t gref_rx_head;
> + grant_ref_t grant_rx_ref[NET_TX_RING_SIZE + 1];
> +
> + struct xenbus_device *xbdev;
> + int tx_ring_ref;
> + int rx_ring_ref;
> + u8 mac[ETH_ALEN];
Isn't mac address already stored in dev->dev_addr and/or dev->perm_addr?
^ permalink raw reply
* Re: [RFC] netdev sysfs failure handling
From: Stephen Hemminger @ 2006-05-09 19:01 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20060506.180622.117885702.davem@davemloft.net>
Something like this would handle errors better, but introduce possible
problems for drivers that call register_netdevice with irq's disabled.
There was some comment about racing with linkwatch, but don't see how
that could happen during creation.
For 2.6.18?
--- bridge.orig/include/linux/netdevice.h 2006-05-09 11:17:08.000000000 -0700
+++ bridge/include/linux/netdevice.h 2006-05-09 11:18:52.000000000 -0700
@@ -433,8 +433,7 @@
/* register/unregister state machine */
enum { NETREG_UNINITIALIZED=0,
- NETREG_REGISTERING, /* called register_netdevice */
- NETREG_REGISTERED, /* completed register todo */
+ NETREG_REGISTERED, /* completed register_netdevice */
NETREG_UNREGISTERING, /* called unregister_netdevice */
NETREG_UNREGISTERED, /* completed unregister todo */
NETREG_RELEASED, /* called free_netdev */
--- bridge.orig/net/core/dev.c 2006-05-09 11:17:09.000000000 -0700
+++ bridge/net/core/dev.c 2006-05-09 11:37:18.000000000 -0700
@@ -2777,6 +2777,8 @@
BUG_ON(dev_boot_phase);
ASSERT_RTNL();
+ might_sleep();
+
/* When net_device's are persistent, this will be fatal. */
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
@@ -2863,6 +2865,11 @@
if (!dev->rebuild_header)
dev->rebuild_header = default_rebuild_header;
+ ret = netdev_register_sysfs(dev);
+ if (ret)
+ goto out_err;
+ dev->reg_state = NETREG_REGISTERED;
+
/*
* Default initial state at registry is that the
* device is present.
@@ -2878,14 +2885,11 @@
hlist_add_head(&dev->name_hlist, head);
hlist_add_head(&dev->index_hlist, dev_index_hash(dev->ifindex));
dev_hold(dev);
- dev->reg_state = NETREG_REGISTERING;
write_unlock_bh(&dev_base_lock);
/* Notify protocols, that a new device appeared. */
blocking_notifier_call_chain(&netdev_chain, NETDEV_REGISTER, dev);
- /* Finish registration after unlock */
- net_set_todo(dev);
ret = 0;
out:
@@ -3008,7 +3012,7 @@
*
* We are invoked by rtnl_unlock() after it drops the semaphore.
* This allows us to deal with problems:
- * 1) We can create/delete sysfs objects which invoke hotplug
+ * 1) We can delete sysfs objects which invoke hotplug
* without deadlocking with linkwatch via keventd.
* 2) Since we run with the RTNL semaphore not held, we can sleep
* safely in order to wait for the netdev refcnt to drop to zero.
@@ -3017,8 +3021,6 @@
void netdev_run_todo(void)
{
struct list_head list = LIST_HEAD_INIT(list);
- int err;
-
/* Need to guard against multiple cpu's getting out of order. */
mutex_lock(&net_todo_run_mutex);
@@ -3041,40 +3043,29 @@
= list_entry(list.next, struct net_device, todo_list);
list_del(&dev->todo_list);
- switch(dev->reg_state) {
- case NETREG_REGISTERING:
- err = netdev_register_sysfs(dev);
- if (err)
- printk(KERN_ERR "%s: failed sysfs registration (%d)\n",
- dev->name, err);
- dev->reg_state = NETREG_REGISTERED;
- break;
-
- case NETREG_UNREGISTERING:
- netdev_unregister_sysfs(dev);
- dev->reg_state = NETREG_UNREGISTERED;
-
- netdev_wait_allrefs(dev);
-
- /* paranoia */
- BUG_ON(atomic_read(&dev->refcnt));
- BUG_TRAP(!dev->ip_ptr);
- BUG_TRAP(!dev->ip6_ptr);
- BUG_TRAP(!dev->dn_ptr);
-
-
- /* It must be the very last action,
- * after this 'dev' may point to freed up memory.
- */
- if (dev->destructor)
- dev->destructor(dev);
- break;
-
- default:
+ if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
printk(KERN_ERR "network todo '%s' but state %d\n",
dev->name, dev->reg_state);
- break;
+ dump_stack();
+ continue;
}
+
+ netdev_unregister_sysfs(dev);
+ dev->reg_state = NETREG_UNREGISTERED;
+
+ netdev_wait_allrefs(dev);
+
+ /* paranoia */
+ BUG_ON(atomic_read(&dev->refcnt));
+ BUG_TRAP(!dev->ip_ptr);
+ BUG_TRAP(!dev->ip6_ptr);
+ BUG_TRAP(!dev->dn_ptr);
+
+ /* It must be the very last action,
+ * after this 'dev' may point to freed up memory.
+ */
+ if (dev->destructor)
+ dev->destructor(dev);
}
out:
^ permalink raw reply
* Re: r8169: only works in 10mbit/half duplex
From: Francois Romieu @ 2006-05-09 19:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1147137144.16487.61.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> :
[...]
> I'm thinking this is a hardware failure, is there any reason to believe
> otherwise?
It's hard to tell without data. It could be any of the usual suspects
or a genuine bug.
Can you send the complete dmesg from boot + lspci -vvx + /proc/interrupts
of the computer ?
What does ethtool report if you do not force it to 10Mbps with the media=1
option and what hardware is it connected to ? Any URL for the motherboard ?
--
Ueimor
^ permalink raw reply
* Re: r8169: only works in 10mbit/half duplex
From: Johannes Berg @ 2006-05-09 19:12 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20060509190110.GB3215@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
Hi,
> It's hard to tell without data. It could be any of the usual suspects
> or a genuine bug.
Yeah, I realise that. I've tried booting windows which behaves exactly
the same, with the latest realtek driver. I've sent back the machine
today because I need to have this box up fairly soon. Sorry :/
> Can you send the complete dmesg from boot + lspci -vvx + /proc/interrupts
> of the computer ?
I don't have a dmesg any more, lspci is at
http://johannes.sipsolutions.net/files/lspci-minipc, /proc/interrupts
looked normal as far as I can remember. dmesg didn't say much about
r8169, and other than that I didn't see any problems. I tried booting
with pci=routeirq and some options but none of that helped, and
interrupts were definitely counted in all cases.
> What does ethtool report if you do not force it to 10Mbps with the media=1
> option and what hardware is it connected to ? Any URL for the motherboard ?
Here's the weirdest thing:
If I connected it to 100mbit/full duplex hardware, it worked only if I
forced it to 10mbit (half or full), otherwise the tx/rx led would blink
frantically and the card didn't receive any packets (sending was fine).
If I connected it to gbit hardware it worked in gibt mode, but only got
transfer speeds of about 10mb/sec. Same behaviour with windows.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Stephen Hemminger @ 2006-05-09 20:25 UTC (permalink / raw)
To: Chris Wright
Cc: xen-devel, Ian Pratt, netdev, linux-kernel, virtualization,
Christian Limpach
In-Reply-To: <20060509085201.446830000@sous-sol.org>
> +static int setup_device(struct xenbus_device *dev, struct
> netfront_info *info) +{
> + struct netif_tx_sring *txs;
> + struct netif_rx_sring *rxs;
> + int err;
> + struct net_device *netdev = info->netdev;
> +
> + info->tx_ring_ref = GRANT_INVALID_REF;
> + info->rx_ring_ref = GRANT_INVALID_REF;
> + info->rx.sring = NULL;
> + info->tx.sring = NULL;
> + info->irq = 0;
> +
> + txs = (struct netif_tx_sring *)get_zeroed_page(GFP_KERNEL);
> + if (!txs) {
> + err = -ENOMEM;
> + xenbus_dev_fatal(dev, err, "allocating tx ring
> page");
> + goto fail;
> + }
> + rxs = (struct netif_rx_sring *)get_zeroed_page(GFP_KERNEL);
> + if (!rxs) {
> + err = -ENOMEM;
> + xenbus_dev_fatal(dev, err, "allocating rx ring
> page");
> + free_page((unsigned long)txs);
> + goto fail;
> + }
> + info->backend_state = BEST_DISCONNECTED;
> +
> + SHARED_RING_INIT(txs);
> + FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> +
> + SHARED_RING_INIT(rxs);
> + FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> +
> + err = xenbus_grant_ring(dev, virt_to_mfn(txs));
> + if (err < 0)
> + goto fail;
> + info->tx_ring_ref = err;
> +
> + err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
> + if (err < 0)
> + goto fail;
> + info->rx_ring_ref = err;
> +
> + err = xenbus_alloc_evtchn(dev, &info->evtchn);
> + if (err)
> + goto fail;
> +
> + memcpy(netdev->dev_addr, info->mac, ETH_ALEN);
> + network_connect(netdev);
> + info->irq = bind_evtchn_to_irqhandler(
> + info->evtchn, netif_int, SA_SAMPLE_RANDOM,
> netdev->name,
>
This doesn't look like a real random entropy source. packets
arriving from another domain are easily timed.
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Keir Fraser @ 2006-05-09 20:26 UTC (permalink / raw)
To: Stephen Hemminger
Cc: xen-devel, Ian Pratt, netdev, linux-kernel, Chris Wright,
virtualization
In-Reply-To: <20060509132556.76deaa91@localhost.localdomain>
On 9 May 2006, at 21:25, Stephen Hemminger wrote:
>> + memcpy(netdev->dev_addr, info->mac, ETH_ALEN);
>> + network_connect(netdev);
>> + info->irq = bind_evtchn_to_irqhandler(
>> + info->evtchn, netif_int, SA_SAMPLE_RANDOM,
>> netdev->name,
>>
>
> This doesn't look like a real random entropy source. packets
> arriving from another domain are easily timed.
Where should we get our entropy from in a VM environment? Leaving the
pool empty can cause processes to hang.
-- Keir
^ permalink raw reply
* Re: r8169+NAPI soft lockup
From: Francois Romieu @ 2006-05-09 20:26 UTC (permalink / raw)
To: Richard Gregory; +Cc: netdev
In-Reply-To: <4460B8DC.9080105@liv.ac.uk>
Richard Gregory <R.Gregory@liverpool.ac.uk> :
[...]
Can you send me your drivers/ide/ide-io.o ?
--
Ueimor
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Chris Wright @ 2006-05-09 20:32 UTC (permalink / raw)
To: Stephen Hemminger
Cc: xen-devel, Ian Pratt, netdev, linux-kernel, Chris Wright,
virtualization, Christian Limpach
In-Reply-To: <20060509132556.76deaa91@localhost.localdomain>
* Stephen Hemminger (shemminger@osdl.org) wrote:
> > + info->irq = bind_evtchn_to_irqhandler(
> > + info->evtchn, netif_int, SA_SAMPLE_RANDOM,
> > netdev->name,
>
> This doesn't look like a real random entropy source. packets
> arriving from another domain are easily timed.
Heh, given the path they take, that sadly may not be the case ;-)
But point well-taken, that's easy to drop.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Roland Dreier @ 2006-05-09 20:46 UTC (permalink / raw)
To: Keir Fraser
Cc: Stephen Hemminger, virtualization, Ian Pratt, xen-devel,
linux-kernel, Chris Wright, netdev
In-Reply-To: <6a1855ab01a195ac2a28a97c5f966f67@cl.cam.ac.uk>
Keir> Where should we get our entropy from in a VM environment?
Keir> Leaving the pool empty can cause processes to hang.
You could have something like a virtual HW RNG driver (with a frontend
and backend), which steals from the dom0 /dev/random pool.
- R.
^ permalink raw reply
* Re: [RFC] netdev sysfs failure handling
From: David S. Miller @ 2006-05-09 21:05 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20060509120107.0a999f38@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Tue, 9 May 2006 12:01:07 -0700
> Something like this would handle errors better, but introduce possible
> problems for drivers that call register_netdevice with irq's disabled.
> There was some comment about racing with linkwatch, but don't see how
> that could happen during creation.
>
> For 2.6.18?
I've been thinking about this a bit more.
How can anyone be using this with IRQ's disabled if we have
an ASSERT_RTNL() there?
^ permalink raw reply
* Re: [RFC] netdev sysfs failure handling
From: Stephen Hemminger @ 2006-05-09 21:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20060509.140501.18000999.davem@davemloft.net>
On Tue, 09 May 2006 14:05:01 -0700 (PDT)
"David S. Miller" <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Tue, 9 May 2006 12:01:07 -0700
>
> > Something like this would handle errors better, but introduce possible
> > problems for drivers that call register_netdevice with irq's disabled.
> > There was some comment about racing with linkwatch, but don't see how
> > that could happen during creation.
> >
> > For 2.6.18?
>
> I've been thinking about this a bit more.
>
> How can anyone be using this with IRQ's disabled if we have
> an ASSERT_RTNL() there?
Agreed, especially since rtnl is now a real mutex. The case, that
I was worried about:
rtnl_lock()
spin_lock_irq(&mylock);
x = register_netdevice();
...
Doesn't show up in any current code, even for the pseudo devices
and funny virtualized interfaces.
^ permalink raw reply
* [PATCH] sky2: ifdown kills irq mask
From: Stephen Hemminger @ 2006-05-09 21:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Bringing down a port also masks off the status and other IRQ's
needed for device to function due to missing paren's.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- sky2.orig/drivers/net/sky2.c
+++ sky2/drivers/net/sky2.c
@@ -128,6 +128,7 @@ MODULE_DEVICE_TABLE(pci, sky2_id_table);
/* Avoid conditionals by using array */
static const unsigned txqaddr[] = { Q_XA1, Q_XA2 };
static const unsigned rxqaddr[] = { Q_R1, Q_R2 };
+static const u32 portirq_msk[] = { Y2_IS_PORT_1, Y2_IS_PORT_2 };
/* This driver supports yukon2 chipset only */
static const char *yukon2_name[] = {
@@ -1084,7 +1085,7 @@ static int sky2_up(struct net_device *de
/* Enable interrupts from phy/mac for port */
imask = sky2_read32(hw, B0_IMSK);
- imask |= (port == 0) ? Y2_IS_PORT_1 : Y2_IS_PORT_2;
+ imask |= portirq_msk[port];
sky2_write32(hw, B0_IMSK, imask);
return 0;
@@ -1435,7 +1436,7 @@ static int sky2_down(struct net_device *
/* Disable port IRQ */
imask = sky2_read32(hw, B0_IMSK);
- imask &= ~(sky2->port == 0) ? Y2_IS_PORT_1 : Y2_IS_PORT_2;
+ imask &= ~portirq_msk[port];
sky2_write32(hw, B0_IMSK, imask);
/* turn off LED's */
^ permalink raw reply
* Re: Dscape ieee80211: enabling/disabling the radio
From: Ivo van Doorn @ 2006-05-09 22:01 UTC (permalink / raw)
To: netdev, Olivier; +Cc: Jiri Benc
In-Reply-To: <200605061401.01795.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]
> While working on the rt2x00 driver, I keep hitting against some problems with scanning.
> Basicly the dscape stack handles scanning in 2 ways, through the
> passive_scan() handler in the ieee80211_hw structure, and by calling
> the config() handler in the ieee80211_hw stucture.
>
> The usage of the first handler, does not give any problems at this time.
> The main source of problems during scanning in rt2x00 seems to come
> when the config() handler is used.
>
> In rt2x00 the config() handler schedules all configuration changes by using a workqueue,
> this is required since several configuration changes in rt2x00 need sleeping and for
> USB devices all register access requires sleeping. And the config() handler is often
> called from interrupt context so it complains a lot when the workqueue is not used.
>
> This seemed fine, untill the radio_enabled field was introduced to the configuration structure.
> When the radio_enable field is set, the radio must be enabled, but enabling
> the radio is something that can (at least in rt2x00) fail. So scheduling the enabling of the radio
> to the workqueue is not something that is desired since the stack can not be notified that the
> device is not able to enable the radio.
>
> Moving the enabling of the radio outside the workqueue function and into the config()
> handler results in scheduling while atomic issues since the enabling of the radio requires
> sleeping for both PCI and USB devices.
>
> Instead of using a config field radio_enabled, wouldn't it be better to add 2 handlers
> to the ieee80211_hw structure, something like enable_radio() and disable_radio()?
> If these functions are called from normal context the dscape stack can still enable
> and disable the radio whenever it is desired, and it is able to check the return value
> to see if the request has actually succeeded.
>
> What I am wondering about afterwards is what exactly should happen when the open()
> and stop() handlers are being called? Because those are basicly intented to enable
> and stop the radio as well. I checked bcm43xx to see what they do, and they don't seem
> to check the radio_enabled field, so I don't know what they do besides enabling the radio.
>
> Well this was just some stuff I have been trying to figure out while trying to solve several
> rt2x00 bugs... ;)
A user on the forums Olivier Cornu (added to the CC list) has done some investigation into the
scanning behaviour of the dscape stack.
Basicly the dscape stack is performing active scanning while the device is down,
but during the active scan it is sending packets out, or at least attempting to do so.
Besides the question if active scanning is preferred over passive scanning while interface is down,
active scanning fails because the packets that should be send are being send through the regular
xmit routines of the interface. (IFF_UP is not set for the interface)
This means that besides enabling the radio which should be done in the driver, the stack should either bring
up the interface when doing an active scan, or resort to passive scanning while interface is down.
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add missing operstates.txt
From: David S. Miller @ 2006-05-09 22:16 UTC (permalink / raw)
To: stefan; +Cc: netdev
In-Reply-To: <200605071218.59537.stefan@loplof.de>
From: Stefan Rompf <stefan@loplof.de>
Date: Sun, 7 May 2006 12:18:59 +0200
> seems documentation got lost when the RFC2863-patch was applied. Having
> documentation is good, so I resend it ;-)
>
> Signed-off-by: Stefan Rompf <stefan@loplof.de>
Applied, thanks Stefan.
^ permalink raw reply
* Re: [PATCH]ip_options_fragment() has no effect on fragmentation
From: David S. Miller @ 2006-05-09 22:20 UTC (permalink / raw)
To: weiyj; +Cc: netdev
In-Reply-To: <1146875774.3659.22.camel@LINE>
From: Wei Yongjun <weiyj@soft.fujitsu.com>
Date: Fri, 05 May 2006 20:36:14 -0400
> I had tested the patch under linux system, maybe this mail is correct.
>
> Fix error point to options in ip_options_fragment(). optptr get a error
> pointer to the ipv4 header, correct is pointer to ipv4 options.
>
> Signed-off-by: Wei Yongjun <weiyj@soft.fujitsu.com>
Patch applied, thank you very much.
^ permalink raw reply
* Re: [PATCH 1/4] New IrDA maintainer
From: David S. Miller @ 2006-05-09 22:24 UTC (permalink / raw)
To: samuel.ortiz; +Cc: jt, irda-users, netdev
In-Reply-To: <20060508212333.GB20933@irie>
From: Samuel Ortiz <samuel.ortiz@nokia.com>
Date: Tue, 9 May 2006 00:23:33 +0300
> As agreed with Jean Tourrilhes, I am taking over IrDA
> maintainership.
>
> Signed-off-by: Samuel Ortiz <samuel.ortiz@nokia.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/4] IrDA: Removing unused EXPORT_SYMBOLs
From: David S. Miller @ 2006-05-09 22:25 UTC (permalink / raw)
To: samuel.ortiz; +Cc: jt, irda-users, netdev
In-Reply-To: <20060508212343.GC20933@irie>
From: Samuel Ortiz <samuel.ortiz@nokia.com>
Date: Tue, 9 May 2006 00:23:44 +0300
> This patch removes the following unused EXPORT_SYMBOL's:
> - irias_find_attrib
> - irias_new_string_value
> - irias_new_octseq_value
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> Signed-off-by: Samuel Ortiz <samuel.ortiz@nokia.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] IrDA: smsc-ircc: Minimal hotplug support.
From: David S. Miller @ 2006-05-09 22:26 UTC (permalink / raw)
To: samuel.ortiz; +Cc: jt, irda-users, netdev, dbrownell, akpm
In-Reply-To: <20060508212359.GD20933@irie>
From: Samuel Ortiz <samuel.ortiz@nokia.com>
Date: Tue, 9 May 2006 00:23:59 +0300
> Minimal PNP hotplug support for the smsc-ircc2 driver. A modular driver
> will be modprobed via hotplug, but still bypasses driver model probing.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> Signed-off-by: Samuel Ortiz <samuel.ortiz@nokia.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 4/4] IrDA: Switching to a workqueue for the SIR work
From: David S. Miller @ 2006-05-09 22:27 UTC (permalink / raw)
To: samuel.ortiz; +Cc: jt, irda-users, netdev, hch
In-Reply-To: <20060508212410.GE20933@irie>
From: Samuel Ortiz <samuel.ortiz@nokia.com>
Date: Tue, 9 May 2006 00:24:10 +0300
> Since sir_kthread.c pretty much duplicates the workqueue functionality,
> we'd better switch.
> The SIR fsm has been merged into sir_dev.c and thus sir_kthread.c is
> deleted.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Samuel Ortiz <samuel.ortiz@nokia.com>
Applied, thanks.
^ permalink raw reply
* Re: Scanning in ieee80211 softmac layer and setting essid (newbie)
From: Uli Kunitz @ 2006-05-09 22:27 UTC (permalink / raw)
To: Ian Brown; +Cc: netdev
In-Reply-To: <d0383f90605090638u3ca7a5c0je1a4ce8bc3dc696e@mail.gmail.com>
Ian Brown wrote:
> My question is : why is this scanning needed when set essid is called?
> and why is the repeatition?
ESSID doesn't tell you the channel nummber, so you have to scan
for a beacon containing the ESSID in passive scanning. Even if you
do active scanning you need to check all channels because your
ESSID could be on anyone of the channels.
Uli
--
Uli Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: [NET] linkwatch: Handle jiffies wrap-around
From: David S. Miller @ 2006-05-09 22:28 UTC (permalink / raw)
To: stefan; +Cc: herbert, netdev
In-Reply-To: <200605091851.49775.stefan@loplof.de>
From: Stefan Rompf <stefan@loplof.de>
Date: Tue, 9 May 2006 18:51:49 +0200
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Acked-by: Stefan Rompf <stefan@loplof.de>
Applied, thanks everyone.
^ permalink raw reply
* Re: Dscape ieee80211: enabling/disabling the radio
From: Michael Wu @ 2006-05-09 22:36 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev, Olivier, Jiri Benc
In-Reply-To: <200605100001.20180.IvDoorn@gmail.com>
On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote:
> A user on the forums Olivier Cornu (added to the CC list) has done some
> investigation into the scanning behaviour of the dscape stack.
> Basicly the dscape stack is performing active scanning while the device is
> down, but during the active scan it is sending packets out, or at least
> attempting to do so. Besides the question if active scanning is preferred
> over passive scanning while interface is down, active scanning fails
> because the packets that should be send are being send through the regular
> xmit routines of the interface. (IFF_UP is not set for the interface)
>
> This means that besides enabling the radio which should be done in the
> driver, the stack should either bring up the interface when doing an active
> scan, or resort to passive scanning while interface is down.
>
If you can passive scan while the interface is down, I don't think it's really
down. In adm8211, nothing can be sent or received when the interface is down.
The radio is always off when the interface is down. Taking the interface up
just for a scan and then taking it back down doesn't sound too good either. I
think scans should be prohibited while the interface is down, since leaving
the interface on isn't gonna do anything bad unless you put in the info to
associate.
-Michael Wu
^ 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