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 con
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 deve
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
>
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. Sa
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
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
i
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
> >>> i
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 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
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
> --
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
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
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 sy
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 pro
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 r
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 ide
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 ide
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 mess
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
-
To
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 d
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
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 you
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
> a
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 transmissi
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 sa
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 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 i
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 ieee80211_
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
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 e
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 i
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 rig
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 PROTECT
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 [mai
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
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
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 kno
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
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 <[EMAI
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
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
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 14:
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 deve
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 fullm
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 whi
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 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 lik
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...
Ju
* 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 in
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
<[EMAI
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
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 implemen
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
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 fixin
> 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:
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
I'd b
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 PROTECTE
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 opa
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
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 02 Nov 2006 13:02:29 -0800
> [TG3]: Fix 2nd ifup failure on 5752M.
>
> This fixes a bug reported in:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7438
>
> tg3_close() turns off the PHY if WoL and ASF are both disabled. On
> the next tg3_ope
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
> > linux
On Thu, Nov 02, 2006 at 11:40:43AM -0800, Nate Diller ([EMAIL PROTECTED]) wrote:
> Are you saying that the *only* reason we choose not to be
> source-compatible with BSD is the 32 bit userland on 64 bit arch
> problem? I've followed every thread that gmail 'kqueue' search
I.e. do you want that ge
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 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 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 y
66 matches
Mail list logo
