On Thu, 2006-11-02 at 23:15 -0500, John W. Linville wrote:
403 Forbidden (shouldn't that be Verboten? :-)
Nah, that's ok, that particular Apache instance is running in London,
UK :)
Fixed, sorry about that, I don't usually allow directory listing in that
hierarchy and forgot to enable it (so
On Thu, 2006-11-02 at 21:28 -0500, Michael Wu wrote:
That's because TX might fail for reasons other than not getting an ACK. I
can't say I've actually seen this happen, so it might just be something left
over from tulip that doesn't need to be there now. (or perhaps it only
happens when
On Fri, 2006-11-03 at 01:42 -0500, Michael Wu wrote:
This is with cfg80211 turned off.
wext-old.c shouldn't be compiled then. Must be some Makefile bug, I'll
look into it.
johannes
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
On Thu, 2006-11-02 at 23:30 -0500, John W. Linville wrote:
I've also added a 'pending' branch, with similar policies to the
'pending' branch in wireless-2.6 (i.e it means I've got the patch,
but I'm waiting on some feedback or changes, etc).
Note that the d80211: change the cookie to be
YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 15:16:23 +0200), Ville
Nuorvala [EMAIL PROTECTED] says:
On 11/02/06 14:59, YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:39:19 +0200), Ville
Nuorvala [EMAIL PROTECTED] says:
On Fri, 2006-11-03 at 01:46 +0100, Johannes Berg wrote:
d80211-reduce-mdev.patch
d80211-ethtool.patch
d80211-cookie.patch
G, whitespace damaged. I swear I'm going to submit a s/ {8}/\t/
patch some of these days. wiggle should handle that just fine, and
personally, I have reached a point
Hi!
returns, which thread are you referring to? Nicholas Miell, in The
Proposed Linux kevent API thread, seems to think that there are no
advantages over kqueue to justify the incompatibility, an argument you
made no effort to refute. I've also read the Kevent wiki at
From: Pavel Machek [EMAIL PROTECTED]
Date: Fri, 3 Nov 2006 09:57:12 +0100
Not sure what you are smoking, but there's unsigned long in *bsd
version, lets rewrite it from scratch sounds like very bad idea. What
about fixing that one bit you don't like?
I disagree, it's more like since we have
On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
So, kqueue API and structures can not be usd in Linux.
Not sure what you are smoking, but there's unsigned long in *bsd
version, lets rewrite it from scratch sounds like very bad idea. What
about fixing that
On Fri, Nov 03, 2006 at 10:42:04AM +0800, zhou drangon ([EMAIL PROTECTED])
wrote:
As for the VFS system, when we introduce the AIO machinism, we add aio_read,
aio_write, etc... to file ops, and then we make the read, write op to
call aio_read,
aio_write, so that we only remain one implement
zze-Ganesh KERDONCUFF G ext RD-MAPS-REN wrote:
The algorithm now applies NAT to the complete IP address (and not only
the first byte)
It also recomputes the UDP checksum accordingly.
I'm not too familiar with SNMP NAT, please send this to
[EMAIL PROTECTED] so other netfilter
developers get a
Ville Nuorvala wrote:
YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 15:16:23 +0200), Ville Nuorvala
[EMAIL PROTECTED] says:
On 11/02/06 14:59, YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:39:19 +0200), Ville Nuorvala
[EMAIL
* Alexey Dobriyan | 2006-11-03 03:09:05 [+0300]:
On Wed, Nov 01, 2006 at 03:06:24PM +0100, Florian Westphal wrote:
convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const.
Ahhh, I missed the start of threads.
Patch is useless because it changes one unbounded string function into
Ben Greear writes:
I'd be thrilled to have the receive logic go into pktgen, even if it was #if
0 with a comment
showing how to patch dev.c to get it working. It would make my out-of-tree
patch smaller
and should help others who are doing research and driver development...
Just
On Fri, 2006-11-03 at 10:06 +0100, Johannes Berg wrote:
It doesn't seem to compile on my system:
net/built-in.o: In function `iw_send_thrspy_event':
wext-old.c:(.text+0x67672): undefined reference to `wireless_send_event'
Uh, common is missing. Adjust net/wireless/Makefile like this:
If inet6_init() fails later than ndisc_init() call, or IPv6 module is
unloaded, ndisc_netdev_notifier call remains in the list and will follows in
oops later.
Signed-off-by: Dmitry Mishin [EMAIL PROTECTED]
---
ndisc.c |1 +
1 file changed, 1 insertion(+)
---
diff --git a/net/ipv6/ndisc.c
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
On 10/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
This patch completes WPA/RSN with TKIP support for all fullmac prism54
cards.
I removed all parts which are not
On 11/3/06, Dan Williams [EMAIL PROTECTED] wrote:
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
On 10/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
This patch completes WPA/RSN with TKIP support for all fullmac
Robert Olsson wrote:
Ben Greear writes:
I'd be thrilled to have the receive logic go into pktgen, even if it was #if
0 with a comment
showing how to patch dev.c to get it working. It would make my out-of-tree
patch smaller
and should help others who are doing research and driver
Removed define H_CB_ALIGNMENT which is already defined in
include/asm-powerpc/hvcall.h
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
diff -Nurp git.netdev-2.6.base/drivers/net/ehea/ehea.h
git.netdev-2.6/drivers/net/ehea/ehea.h
--- git.netdev-2.6.base/drivers/net/ehea/ehea.h 2006-11-03
Fix: Must check for nullpointer before dereferencing it - not afterwards.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
diff -Nurp git.netdev-2.6.base/drivers/net/ehea/ehea_qmr.c
git.netdev-2.6/drivers/net/ehea/ehea_qmr.c
--- git.netdev-2.6.base/drivers/net/ehea/ehea_qmr.c 2006-11-03
This patch fixes 64k page support by using PAGE_MASK and appropriate pagesize
defines in several places.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
drivers/net/ehea/ehea_ethtool.c |2 +-
drivers/net/ehea/ehea_main.c| 26 +-
drivers/net/ehea/ehea_phyp.c
On Thu, Nov 02, 2006 at 09:45:46AM +0100, Johannes Berg wrote:
On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote:
Has anyone used this patch, particularly with WPA encryption? When I try
it, wpa_supplicant
immediately uses 90+% of the cpu and never actually authenticates with my
You might find this thread useful if it is just a case
of messed up firmware:
http://sourceforge.net/mailarchive/message.php?msg_id=2970511
The gist of it is that sometimes DOS utilities work
when all else fails.
ben
--- Ivan Matveich [EMAIL PROTECTED] wrote:
On 11/2/06, Dan Williams [EMAIL
On 11/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Am Freitag, 3. November 2006 17:06 schrieben Sie:
On 11/3/06, Dan Williams [EMAIL PROTECTED] wrote:
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
On 10/29/06,
On Thursday 02 November 2006 17:38, Johannes Berg wrote:
I'm sorry I didn't manage to update these drivers. As for out-of-tree
drivers, I obviously haven't updated them either. It *shouldn't*
be too hard as the net_dev shouldn't be used in many places.
So uh, what am I going to prefix all my
Michael Wu wrote:
So uh, what am I going to prefix all my printk messages with now that I
can't
access dev-name? It seems like the other d80211 drivers have a habit of
prefixing their messages with the driver name (wrong thing to do, IMHO),
which is different from pretty much all other
I'm not sure why we don't use the master device for packet capture - I
can't think of any good reason for requiring a separate device. I would
think the master device is the perfect place to do packet capture, and
raw packet transmission.
Simon
-Original Message-
From: Johannes Berg
I should elaborate - if 802.11 is made into a real protocol - then raw
packet capture works correctly on the master device. (raw sockets opened
on the device see all frames before they are passed to the protocol).
This is the right way to go.
Simon
-Original Message-
From: [EMAIL
On Fri, Nov 03, 2006 at 11:29:33AM -0800, Simon Barber wrote:
I should elaborate - if 802.11 is made into a real protocol - then raw
packet capture works correctly on the master device. (raw sockets opened
on the device see all frames before they are passed to the protocol).
This is the right
Ben Greear writes:
It requires a hook in dev.c, or at least that is the only way I can
think to implement it.
Well the hook be placed along the packet path even in drivers. In tulip I
didn't
even take packet of the ring in some experiments.
And there plenty of existing hooks already
Robert Olsson wrote:
Ben Greear writes:
It requires a hook in dev.c, or at least that is the only way I can
think to implement it.
Well the hook be placed along the packet path even in drivers. In tulip I didn't
even take packet of the ring in some experiments.
And there plenty of
Please pull from tag 'jg-20061103-00' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git jg-20061103-00
to get the changes below.
Distance from 'upstream-fixes'
-
17fddc34b36fc26aa8b5f130fe32b446d9d88fa2
Diffstat
drivers/net/r8169.c
On Thursday 02 November 2006 17:38, Johannes Berg wrote:
After removing knowledge of the master net_dev from drivers,
they'll still need a way to tell us which MAC address they have.
This is that way, the perm_addr is initially used for all devices.
Shouldn't you add something to
On Friday 03 November 2006 14:08, Johannes Berg wrote:
Yeah, I thought about that and added that function to get the wiphy index.
cfg80211 makes the wiphy index an actual identifier that you can use to
enumerate all devices it has attached etc, so that makes sense. and d80211
also puts it into
On Wed, Nov 01, 2006 at 09:57:46PM +0300, Evgeniy Polyakov wrote:
On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED])
wrote:
[]
Where's real-life application to do configure make make install?
Your real life or mine as developer?
I fortunately do not know anything
On Thursday 02 November 2006 17:38, Johannes Berg wrote:
+ /* hardware device */
+ struct device *dev;
+
Can we just pass this in as an argument instead? No one is gonna look at it
ever again after ieee80211_register_hw, so I don't think it's worth putting
in struct ieee80211_hw.
+
On Thursday 02 November 2006 17:39, Johannes Berg wrote:
After removing knowledge of the master net_dev from drivers,
some will still want to have ethtool ops assigned (rt2x00 uses
it). This is that way.
But bcm43xx sets ethtool ops through bcm43xx_netdev_setup. Why not have rt2x00
do the
On Fri, 2006-11-03 at 11:23 -0800, Simon Barber wrote:
I would
think the master device is the perfect place to do packet capture,
Sort of. Since it'll be an 802.11 protocol thing, you won't be getting
any signal strength information etc. You really do need that.
and
raw packet transmission.
On Fri, 2006-11-03 at 17:14 -0500, Michael Wu wrote:
I still prefer obtaining the name of the master interface because well.. all
other network drivers prefix their messages with the name of their interface.
The master interface name should be as good as the wiphy index to enumerate
On Fri, 2006-11-03 at 16:49 -0500, Michael Wu wrote:
Shouldn't you add something to ieee80211_set_mac_address so the driver/d80211
can find out what MAC address the user actually wants?
Hmm? d80211 already handles the case of the user changing a net_dev's
mac address fine. And it'll tell your
On Fri, 2006-11-03 at 17:43 -0500, Michael Wu wrote:
But bcm43xx sets ethtool ops through bcm43xx_netdev_setup. Why not have
rt2x00
do the same?
Actually, look closer. I removed bcm43xx_netdev_setup as well as the
setup() callback for the hw as well as the bcm43xx ethtool ops which
were
On Fri, 2006-11-03 at 17:27 -0500, Michael Wu wrote:
On Thursday 02 November 2006 17:38, Johannes Berg wrote:
+ /* hardware device */
+ struct device *dev;
+
Can we just pass this in as an argument instead? No one is gonna look at it
ever again after ieee80211_register_hw, so I don't
I am working on getting WOL to work on sky2 (and then skge). But in the process
I
noticed that the semantics of WOL seems to be device dependent. I assume that
WOL
should work when device is suspended. But some drivers also support WOL when
the device is down (or even removed).
Now I know some
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not seem a
good idea to wake up a machine that was shutdown (and thus the interface `downed`) ?
Auke
-
On Sat, 2006-11-04 at 00:21 +0100, Johannes Berg wrote:
Actually, it is used for all new devices as well. Yeah, we could pull it
out of the mdev again,
Oh, in fact, we do. I still think it feels stupid and will change it.
johannes
signature.asc
Description: This is a digitally signed
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not
seem a
good idea to wake
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not
seem a
good idea to wake
Stephen Hemminger wrote:
I am working on getting WOL to work on sky2 (and then skge). But in the process
I
noticed that the semantics of WOL seems to be device dependent. I assume that
WOL
should work when device is suspended. But some drivers also support WOL when
the device is down (or even
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 03 Nov 2006 18:51:25 -0500
The purpose of WOL is being able to turn on a system remotely, if it is
in a power-off or sleep state.
So, if the system is -on- and the interface is down and/or driver is
unloaded, are you saying WOL is a problem
On Fri, 03 Nov 2006 16:02:30 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 03 Nov 2006 18:51:25 -0500
The purpose of WOL is being able to turn on a system remotely, if it is
in a power-off or sleep state.
So, if the system is -on-
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 03 Nov 2006 18:51:25 -0500
The purpose of WOL is being able to turn on a system remotely, if it is
in a power-off or sleep state.
So, if the system is -on- and the interface is down and/or driver is
unloaded, are you saying
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 03 Nov 2006 19:42:49 -0500
David Miller wrote:
I guess you can argue that, like IP addresses, this WoL thing is an
attribute of the system.
Yeah, it's definitely a system state. When the magic packet arrives,
the WOL wire on the
Gaurav wrote:
Hi All,
I am seeing a crash in rt_check_expire. Below is the Oops info.
Does any one has an idea about the cause of this?
Thanks in advance.
Regards,
Gaurav
---
CPU 0
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not seem a
On Fri, 03 Nov 2006 17:36:45 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not seem a
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 17:36:45 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 16:02:30 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 03 Nov 2006 18:51:25 -0500
The purpose of WOL is being able to turn on a system remotely, if it is
in a power-off or sleep state.
So, if
I guess right now when you transmit on the master device frames are only
accepted with a cookie and all that info in the CB. It would work just
as well to move that info from the CB and into a protocol header. It
would also make it easier to expand the info without the size constraint
of the CB.
Hi,
I wanted to understand the code of d80211 (thanks to James Ketrenos
for the info he provided) and also work in it.
I found that I can get the latest patches regarding the same from :
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
Also, in the main kernel tree the
Udayan Singh wrote:
Hi,
I wanted to understand the code of d80211 (thanks to James Ketrenos
for the info he provided) and also work in it.
I found that I can get the latest patches regarding the same from :
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
Wireless-2.6
On Thu, Nov 02, 2006 at 06:47:15PM -0800, David Brownell wrote:
On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
It seems to lack the select MII at the USB_RTL8150 option that was in
Randy's first patch?
I was just addressing the usbnet issues ... that driver doesn't
use the
63 matches
Mail list logo
