* Re: Please pull upstream-fixes branch of wireless-2.6
From: Jeff Garzik @ 2006-04-20 9:00 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, netdev, akpm, torvalds
In-Reply-To: <200604201051.03881.mb@bu3sch.de>
Michael Buesch wrote:
> On Thursday 20 April 2006 03:12, John W. Linville wrote:
>> bcm43xx: fix dyn tssi2dbm memleak
>> bcm43xx: fix pctl slowclock limit calculation
>> bcm43xx: sysfs code cleanup
>
> These are already in -mm and on their way into linus's tree.
> Is it possible to cause problems?
> If not, fine. If yes, we need some clearly defined rules where
> to put patches and a clearly defined statement of how often
> patches are pushed upstream.
Ideally, patches should be sent to John, who will send me -> Linus. If
they are bug fixes, the turnaround can be same once I get them from John
(and Linus is taking patches).
That's always been the standard route: wireless patches -> wireless
maintainer.
Jeff
^ permalink raw reply
* Re: Please pull upstream-fixes branch of wireless-2.6
From: Michael Buesch @ 2006-04-20 9:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linville, jeff, netdev, torvalds
In-Reply-To: <20060420015752.01d36087.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]
On Thursday 20 April 2006 10:57, you wrote:
> Michael Buesch <mb@bu3sch.de> wrote:
> >
> > On Thursday 20 April 2006 03:12, John W. Linville wrote:
> > > bcm43xx: fix dyn tssi2dbm memleak
> > > bcm43xx: fix pctl slowclock limit calculation
> > > bcm43xx: sysfs code cleanup
> >
> > These are already in -mm and on their way into linus's tree.
>
> I don't send netdev patches to Linus except under unusual circumstances.
> I'd expect these patches to go upstream via John or Jeff.
>
> > Is it possible to cause problems?
>
> Nope, I'll just drop then when they appear in a git tree.
>
> And I really need to find a way of getting git-wireless into -mm. Problem
> is, it's based off git-netdev-all and when John's tree is synced to a later
> version of Linus's tree than Jeff's tree, all hell breaks loose at my end.
> Junio and I weren't able to work out a way of extracting the jeff->john
> diffs so I gave up.
>
> Probably, I'll need to actually do a git merge, generate the diff then
> throw away the resulting git tree. Or something. I've avoided doing git
> merges because I'm dealing with 58 trees and I suspect I'd go insane.
>
> > If not, fine. If yes, we need some clearly defined rules where
> > to put patches and a clearly defined statement of how often
> > patches are pushed upstream.
>
> Because I don't carry git-wireless I don't have visibility of when John has
> merged something. Ordinarily you'd have seen me drop the patches again
> when they popped up in John's tree.
Ok, that is perfectly fine and it will work.
Thanks for the clarification.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [XFRM Doc]: aevent description
From: jamal @ 2006-04-20 10:58 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, hidden, herbert
In-Reply-To: <20060414.150536.04415810.davem@davemloft.net>
On Fri, 2006-14-04 at 15:05 -0700, David S. Miller wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Thu, 13 Apr 2006 09:00:08 -0400
>
> > There is dependency on the previous patch i sent since the issue that
> > patch fixes is assumed in this text description. It would be a good
> > idea to apply at the same time as the other.
>
> Applied, after fixing 28 lines containing trailing whitespace :-)
yikes ;->
Ok, so how do i avoid this in the future? Note, this was a _brand new_
file, so it is a little bizarre.
cheers,
jamal
^ permalink raw reply
* Re: Please pull upstream-fixes branch of wireless-2.6
From: John W. Linville @ 2006-04-20 12:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michael Buesch, jeff, netdev, torvalds
In-Reply-To: <20060420015752.01d36087.akpm@osdl.org>
On Thu, Apr 20, 2006 at 01:57:52AM -0700, Andrew Morton wrote:
> And I really need to find a way of getting git-wireless into -mm. Problem
> is, it's based off git-netdev-all and when John's tree is synced to a later
> version of Linus's tree than Jeff's tree, all hell breaks loose at my end.
FWIW, I think this issue should be gone (hopefully never to return).
For a while I was pulling from Jeff's netdev tree as a way to fix-up
a git administration error I had inflicted upon myself... That need
has disappeared since 2.6.17 opened and Jeff pushed his upstream
branch to Linus.
At present, all the branches in wireless-2.6 only pull from linux-2.6.
I am still pushing (i.e. requesting Jeff's pull) to netdev-2.6,
if that matters.
Maybe the current wireless-2.6 tree fits into your system better?
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [patch] ipv4: initialize arp_tbl rw lock
From: Heiko Carstens @ 2006-04-20 13:11 UTC (permalink / raw)
To: David S. Miller
Cc: borntrae, akpm, shemminger, jgarzik, netdev, linux-kernel,
fpavlic, davem
In-Reply-To: <20060419.131237.49371772.davem@davemloft.net>
> > As spinlock debugging still does not work with the qeth driver I
> > want to pick up the discussion.
>
> Does something like the patch below work?
>
> But this all begs the question, what happens if you want to
> dig into the internals of a protocol which is built modular and
> hasn't been loaded yet?
>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 93dcbe1..8169f25 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -95,8 +95,9 @@ #define postcore_initcall(fn) __define_
> #define arch_initcall(fn) __define_initcall("3",fn)
> #define subsys_initcall(fn) __define_initcall("4",fn)
> #define fs_initcall(fn) __define_initcall("5",fn)
> -#define device_initcall(fn) __define_initcall("6",fn)
> -#define late_initcall(fn) __define_initcall("7",fn)
> +#define net_initcall(fn) __define_initcall("6",fn)
> +#define device_initcall(fn) __define_initcall("7",fn)
> +#define late_initcall(fn) __define_initcall("8",fn)
>
> #define __initcall(fn) device_initcall(fn)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index dc206f1..9803a57 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1257,7 +1257,7 @@ out_unregister_udp_proto:
> goto out;
> }
>
> -module_init(inet_init);
> +net_initcall(inet_init);
That's exactly the same thing that I tried to. It didn't work for me since I
saw "sometimes" the described rcu_update latencies.
Today I was able to boot the machine 30 times and just saw it once... Not very
helpful for debugging this :(
Btw.: I guess the linker scripts need an update too, so that the new
.initcall8.init section doesn't get discarded.
^ permalink raw reply
* SIOCGIWSCAN wireless event behaviour
From: Daniel Drake @ 2006-04-20 14:15 UTC (permalink / raw)
To: jt; +Cc: softmac-dev, netdev
Hi Jean,
A query regarding wireless events: under which circumstances should a
driver/stack send a SIOCGIWSCAN event to userspace?
Should it be sent whenever a driver has new scan results available, or
only when the user requested a scan a short time beforehand (via
SIOCSIWSCAN)?
I ask this because softmac is sending the SIOCGIWSCAN event even when
the user did not explicitly ask for it.
For example, the user sets an essid. softmac starts a scan in order to
find the requested network. The network is found, the scan completes,
and softmac sends SIOCGIWSCAN. softmac then authenticates to that
network, associates, and then sends SIOCGIWAP.
I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant
(but have not confirmed that yet).
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: James Smart @ 2006-04-20 14:33 UTC (permalink / raw)
To: Mike Christie; +Cc: linux-scsi, netdev, linux-kernel
In-Reply-To: <4446AC80.6040604@cs.wisc.edu>
Mike Christie wrote:
> For the tasks you want to do for the fc class is performance critical?
No, it should not be.
> If not, you could do what the iscsi class (for the netdev people this is
> drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
> copies. For iscsi we do this in userspace to send down a login pdu:
>
> /*
> * xmitbuf is a buffer that is large enough for the iscsi_event,
> * iscsi pdu (hdr_size) and iscsi pdu data (data_size)
> */
Well, the real difference is that the payload of the "message" is actually
the payload of the SCSI command or ELS/CT Request. Thus, the payload may
range in size from a few hundred bytes to several kbytes (> 1 page) to
Mbyte's in size. Rather than buffer all of this, and push it over the socket,
thus the extra copies - it would best to have the LLDD simply DMA the
payload like on a typical SCSI command. Additionally, there will be
response data that can be several kbytes in length.
> ... I think there may be issues with packing structs or 32 bit
> userspace and 64 bit kernels and other fun things like this so the iscsi
> pdu and iscsi event have to be defined correctly and I guess we are back
> to some of the problems with ioctls :(
Agreed. In this use of netlink, there's not a lot of wins for netlink over
ioctls. It all comes down to 2 things: a) proper portable message definition;
and b) what do you do with that non-portable user space buffer pointer ?
-- james s
^ permalink raw reply
* Re: SIOCGIWSCAN wireless event behaviour
From: Dan Williams @ 2006-04-20 14:37 UTC (permalink / raw)
To: Daniel Drake; +Cc: jt, softmac-dev, netdev
In-Reply-To: <4447979F.4050603@gentoo.org>
On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote:
> Hi Jean,
>
> A query regarding wireless events: under which circumstances should a
> driver/stack send a SIOCGIWSCAN event to userspace?
>
> Should it be sent whenever a driver has new scan results available, or
> only when the user requested a scan a short time beforehand (via
> SIOCSIWSCAN)?
Similar situation: when wpa_supplicant requests a scan, the driver
scans and pushes the GIWSCAN at completion. _Every_ process (like
NetworkManager) listening for netlink WE messages gets the GIWSCAN event
even though only wpa_supplicant requested the original scan.
So what I'm saying is that applications that process GIWSCAN netlink
messages today should _already_ be able to handle random GIWSCAN events
at any time even when they have not explicitly requested a scan with
SIWSCAN. The events are broadcast and the driver shouldn't really care
which user app initiated any particular request. Multiple apps can
theoretically request scans at any time, though this isn't so good in
practice.
> I ask this because softmac is sending the SIOCGIWSCAN event even when
> the user did not explicitly ask for it.
Given the above, I think this behavior is fine and even desirable.
> I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant
> (but have not confirmed that yet).
If this is the case, wpa_supplicant should not be getting confused by
GIWSCAN events happening at random times, and should be fixed. However,
in my experience with 0.4.8, this isn't a problem and wpa_supplicant
handles random scan events correctly. Not sure about the 0.5.x branch
though.
Dan
^ permalink raw reply
* Re: I/OAT: Call for discussion
From: Jack Vogel @ 2006-04-20 15:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: John Ronciak, Stephen Hemminger, Grover, Andrew, netdev
In-Reply-To: <20060419214417.GA25815@infradead.org>
On 4/19/06, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Apr 19, 2006 at 10:28:41AM -0700, John Ronciak wrote:
> > The hardware is going to generally available in June. There are also
> > lots of OEMs, OSVs and hardware vendors that have the system to test
> > on today. The early rollout of hardware has been very large.
>
> As a start to get people actually interested you should stop talking
> like a jerk and kill all these silly three-letter acronyms from your language.
??? For a community absolutely FILLED with everyday use of acronyms
it boggles the mind why you would call someone names for using them.
So if they were 4 letter ones it would make him a savant instead??
Jack
^ permalink raw reply
* Re: I/OAT: Call for discussion
From: Arnaldo Carvalho de Melo @ 2006-04-20 15:26 UTC (permalink / raw)
To: Jack Vogel
Cc: Christoph Hellwig, John Ronciak, Stephen Hemminger,
Grover, Andrew, netdev
In-Reply-To: <2a41acea0604200817g48265b32y87d4d332d1690604@mail.gmail.com>
On 4/20/06, Jack Vogel <jfvogel@gmail.com> wrote:
> On 4/19/06, Christoph Hellwig <hch@infradead.org> wrote:
> > On Wed, Apr 19, 2006 at 10:28:41AM -0700, John Ronciak wrote:
> > > The hardware is going to generally available in June. There are also
> > > lots of OEMs, OSVs and hardware vendors that have the system to test
> > > on today. The early rollout of hardware has been very large.
> >
> > As a start to get people actually interested you should stop talking
> > like a jerk and kill all these silly three-letter acronyms from your language.
>
> ??? For a community absolutely FILLED with everyday use of acronyms
> it boggles the mind why you would call someone names for using them.
>
> So if they were 4 letter ones it would make him a savant instead??
hch is not complaining about TLA usage, he is complaining about _silly_ TLAs
usage, as in to justify new feature acceptance in mainline.
- Arnaldo
^ permalink raw reply
* Re: SIOCGIWSCAN wireless event behaviour
From: Jouni Malinen @ 2006-04-20 16:39 UTC (permalink / raw)
To: Daniel Drake; +Cc: jt, softmac-dev, netdev
In-Reply-To: <4447979F.4050603@gentoo.org>
On Thu, Apr 20, 2006 at 03:15:59PM +0100, Daniel Drake wrote:
> I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant
> (but have not confirmed that yet).
No, they don't. madwifi-ng is already doing this with background
scanning and as was pointed out, there can be multiple programs asking
for scans, so user space must be prepared for multiple events anyway.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: SIOCGIWSCAN wireless event behaviour
From: Jean Tourrilhes @ 2006-04-20 16:43 UTC (permalink / raw)
To: Dan Williams, Jouni Malinen; +Cc: Daniel Drake, softmac-dev, netdev, hostap
In-Reply-To: <1145543852.2654.11.camel@localhost.localdomain>
On Thu, Apr 20, 2006 at 10:37:32AM -0400, Dan Williams wrote:
> On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote:
> > Hi Jean,
> >
> > A query regarding wireless events: under which circumstances should a
> > driver/stack send a SIOCGIWSCAN event to userspace?
> >
> > Should it be sent whenever a driver has new scan results available, or
> > only when the user requested a scan a short time beforehand (via
> > SIOCSIWSCAN)?
The original behaviour was that the event was sent only when a
user did request a scan. At that time, cards did not do background
scanning, so new scan results would be produced only as a result of a
user scan.
After a short discussion we Dan, we agree that to change that,
the driver should send a scan whenever a new scan result is available,
regardless of how it happens (background scan or user scan). This
allow smart application to synchronise on background scans and avoid
them generating useless user scans. Minimising the number of user scan
is actually good.
> Similar situation: when wpa_supplicant requests a scan, the driver
> scans and pushes the GIWSCAN at completion. _Every_ process (like
> NetworkManager) listening for netlink WE messages gets the GIWSCAN event
> even though only wpa_supplicant requested the original scan.
>
> So what I'm saying is that applications that process GIWSCAN netlink
> messages today should _already_ be able to handle random GIWSCAN events
> at any time even when they have not explicitly requested a scan with
> SIWSCAN. The events are broadcast and the driver shouldn't really care
> which user app initiated any particular request. Multiple apps can
> theoretically request scans at any time, though this isn't so good in
> practice.
100% correct.
> > I ask this because softmac is sending the SIOCGIWSCAN event even when
> > the user did not explicitly ask for it.
>
> Given the above, I think this behavior is fine and even desirable.
Yes.
> > I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant
> > (but have not confirmed that yet).
>
> If this is the case, wpa_supplicant should not be getting confused by
> GIWSCAN events happening at random times, and should be fixed. However,
> in my experience with 0.4.8, this isn't a problem and wpa_supplicant
> handles random scan events correctly. Not sure about the 0.5.x branch
> though.
After we changed to behaviour of ipw, various users reported
that wpa_supplicant was confused. I particularly trust the report of
Bill Moss, who has been hacking ipw for a long time :
http://sourceforge.net/mailarchive/forum.php?thread_id=10091113&forum_id=38938
Jouni was notified, but did not really answer to that bug report.
Then, the ipw maintainers commited the following patch to ipw
that fix or workaround that issue :
http://marc.theaimsgroup.com/?l=linux-netdev&m=114492056522667&w=2
I would still like Jouni to have a look at the issue to tell
us where the problem is. Two driver having issue is not coincidence. I
would hate driver starting to implement various workaround if the
problem is really in wpa_supplicant.
Have fun...
Jean
^ permalink raw reply
* ÆóÒµ¹©Ó¦Á´,ÖúÄãÔÚÍøÂçʱ´ú²½²½ÎªÓ®
From: ZqZew0X @ 2006-04-20 16:59 UTC (permalink / raw)
To: u8JQ7
ÔÚÏß²âÊÔµØÖ· http://starterp.oicp.net/scm/ ÕʺÅ:admin ÃÜÂë:admin
×Éѯµç»°:0 7 5 5 - 6 1 2 8 7 3 1 1 ²ÜÏÈÉú E-mail: caoshan@starterp.net
Start¹©Ó¦Á´ÊÇÀûÓû¥ÁªÍø¼¼ÊõºÍÏÖ´ú¿Æ¼¼¹ÜÀíÊֶν¨Á¢ÆðÀ´µÄÒ»Ì×ÍêÕûµÄÉÌÆ·»¯µÄÆóÒµ¹ÜÀíÈí¼þ£¬
ÊÇרÃÅÓÃÀ´¹ÜÀí¹©Ó¦ÉÌ¡¢ÁãÊÛÉÌ¡¢Åú·¢ÉÌÒÔ¼°×îÖÕ¿Í»§µÄ×ÛºÏÓ¦ÓÃϵͳ¡£
¡¡¡¡Start¹©Ó¦Á´½è¼øÁ˹úÄÚÍâÓÅÐ㹩ӦÁ´Èí¼þµÄÌص㣬²ÉÓÃÁËȫеÄÏÖ´ú¹ÜÀí˼ÏëºÍÏȽøµÄ¼¼ÊõÊֶΣ¬
Ëü¿ÉÒÔÓÐЧµØ½«ÆóÒµºÍºÏ×÷»ï°é½ôÃܵØÁªÏµÆðÀ´£¬¿ÉÒÔ³ÖÐø¿É¿¿µØÂú×ã¸÷Àà¿Í»§µÄÐèÇ󣬿ÉÒÔ×î´óÏÞ¶È
µØ½µµÍÆóÒµµÄ·çÏÕ£¬×îÖÕʵÏÖÒÔ×îµÍµÄ³É±¾ºÍ·ÑÓÃÌṩ×î´óµÄ¼ÛÖµºÍ×îºÃµÄ·þÎñ¡£ÈçͼËùʾ¡£
Start¹©Ó¦Á´ÌṩÁËÍêÕûµÄ¹©Ó¦Á´¹ÜÀí£¬Ê¹µÃ²É¹ºÔ²ÄÁÏ£¬µ½ÖÐÐÄ¿â´æ¹ÜÀí£¬µ½Õû¸öÏúÊÛͨ·ÉϵÄÎï
Á÷¹ÜÀí±äµÃÇáÇáËÉËÉ¡£ÏµÍ³ÖÐÉæ¼°µ½µÄËùÓÐÒµÎñ¶¼Äܹ»×Ô¶¯Éú³ÉÏàÓ¦µÄ»á¼Æƾ֤£¬´ó´ó·½±ãÁËÆóÒµµÄ»á¼Æ
ºËËãºÍ²ÆÎñ¹ÜÀí¹¤×÷¡£Ö÷Òª°üÀ¨£ºÏúÊÛ¡¢¿â´æ¡¢²É¹º¡¢ÆÚÄ©¡¢±¨±í¡¢×ÊÁÏ¡¢ÏµÍ³ÅäÖá£ÈçͼһËùʾ¡£
¡¡¡¡£¨Ò»£©ÏúÊÛ
¡¡¡¡ÏúÊÛ¸²¸ÇÆóÒµÏúÊ۵ĸ÷¸ö»·½Ú¡£Í¨¹ýÏúÊÛ¶©µ¥Â¼ÈëÓë±ä¸ü£¬¸ú×Ù¹ÜÀíÏúÊÛÇé¿ö£»¸ù¾Ý»õÆ·±¨¼ÛºÍÏúÊÛ
ÊýÁ¿×Ô¶¯¿ª³öÏúÊÛ·¢Æ±£¬¸ù¾Ý·¢»õµ¥²úÉú½áËãƾ֤ºÍÊÕ»õµ¥£»Ìṩʵ¼ÊÏúÊÛÉÌÆ·½ð¶îÓëÕÊÃæ½ð¶îºË¶Ô¹¦ÄÜ
£»ÌṩÁË¿Í»§ÐÅÓöî¶È¿ØÖƹ¦ÄÜ£¬¿ÉÒÔ´ïµ½½µµÍÏúÊÛ·çÏÕ£¬¼õÉÙÓ¦ÊÕ´ôÕ˵ÄÄ¿µÄ£¬»¹¿ÉÒÔʵÏÖÒµÎñÔ±ÏúÊÛ
Òµ¼¨¡¢ÏúÊÛÖ¸±êÍê³ÉÇé¿öµÄ¿¼ºË¹¦ÄÜ¡£
ÏúÊÛ¶©µ¥
ÏúÊÛ·¢»õµ¥
ÏúÊÛ·¢Æ±
ÏúÊÛÊÕ¿î
ÏúÊÛÍË»õ
ÏúÊÛÍË»õ·¢Æ±
ÏúÊÛÍË»õ¸¶¿î
ÏúÊÛÒµÎñÉóºË
ÏúÊÛÒµÎñ²éÕÒ
£¨¶þ£©²É¹º
²É¹º¸²¸ÇÆóÒµ²É¹ºµÄ¸÷¸ö»·½Ú¡£Æóҵͨ¹ýÐéÄâµÄÔÚÏß»õƷĿ¼£¬Ñ¸ËÙ¶øʵʱµÄ·ÃÎÊ»õÆ·ÐÅÏ¢£»Í¨¹ý¼Û¸ñºÍÆ·
ÖʵıȽϣ¬Ñ¡¶¨²úÆ·¹©Ó¦ÉÌ£»²É¹ºÈËԱͨ¹ýϵͳ¶Ô¿â´æ×´¿öµÄ·ÖÎöÆÀ¹À¹©Ó¦É̵ÄʵÁ¦£»ÊµÊ±¶øѸËÙµØÁ˽⹩
Ó¦É̵ÄÐÅÏ¢£¬±ÜÃ⴫ͳ½»Ò×ÖеÄÖÖÖÖÕÏ°¡£
²É¹º¶©µ¥
²É¹ºÊÕ»õ
²É¹º·¢Æ±
²É¹º¸¶¿î
²É¹ºÍË»õ
²É¹ºÍË»õ·¢Æ±
²É¹ºÍË»õÊÕ¿î
²É¹ºÒµÎñÉóºË
²É¹ºÒµÎñ²éÕÒ
£¨Èý£©´æ»õ
¸ù¾Ý²É¹ºµ¥½øÐÐÈë¿âµÇ¼Ç£»¿ÉÒÔʵÏÖ»õÆ·Å̵㡢ËðºÄµÇ¼Ç¡¢¿â´æµ÷²¦µÈ¹¦ÄÜ£»¶Ô½ø³ö²Ö»õÆ·Êý¾Ý½øÐк˶ԡ£
½ø¿âµ¥
³ö¿âµ¥
ÆäËûÊÕ»õµ¥
ÆäËû·¢»õµ¥
²Ö¿âµ÷²¦
´æ»õÒµÎñÉóºË
´æ»õÒµÎñ²éÕÒ
£¨ËÄ£©ÆÚÄ©
ÆÚÄ©ÌṩÁË»õÆ·Å̵㡢»õÆ·µ÷¼ÛÒÔ¼°ÒµÎñÉóºËµÈÆÚÄ©ÒµÎñ´¦Àí¹¦ÄÜ£¬ÒµÎñÆÚÄ©½áËãΪ²ÆÎñÆÚÄ©½áËã×öÁ˱ØÒª
µÄÆ̵æ×÷Óá£
»õÆ·Å̵ã
»õÆ·µ÷¼Û
ÆÚÄ©ÒµÎñÉóºË
£¨Î壩±¨±í
¸ù¾Ý²»Í¬µÄÒµÎñÐèÇó£¬ÌṩÁ˲»Í¬µÄ±¨±í¡£Ã¿Ò»À౨±í¶¼¿ÉÒÔ¸ù¾ÝÆóÒµµÄÐèÒª½øÐлã×Üͳ¼ÆÓйصÄÏîÄ¿¡£±¨
±í¿ÉÒÔ°ïÖúÆóÒµÁìµ¼ÊÊʱ¼à¶½ÒµÎñ¼Æ»®£¬Á˽ⶩµ¥µÄÖ´ÐÐÇé¿ö£¬½øÐÐÏà¹ØÊý¾Ý·ÖÎö£¬½øÒ»²½½øÐоӪ¾ö²ß¡£
£¨Áù£©×ÊÁÏ
Óû§¿ÉÒÔ¿ìËÙ¡¢Ö±¹ÛµØ²éѯËùÐèÒªµÄÊý¾Ý×ÊÁÏ¡£
¿Í»§ºÍ¹©Ó¦ÉÌ×ÊÁÏ
»õÆ·ºÍ²Ö¿â×ÊÁÏ
ÒµÎñ×ÊÁÏ
¹«Ë¾ÐÅÏ¢
µ¥¾ÝÄ£°å
£¨Æߣ©ÏµÍ³¹ÜÀí
ϵͳ¹ÜÀíÊÇÕû¸öϵͳµÄÃÅ»§£¬ÔÚϵͳµÄ°²È«ÐÔÉÏÆðµ½Á˲»¿É¹ÀÁ¿µÄ×÷Ó᣸÷ÖÖÐÅÏ¢ÒªÇó¾¡Á¿È«ÃæÏêϸ£¬Ê¹¹ÜÀí
±äµÃ¸üÇáËɸüÓÐЧ¡£
Óû§¹ÜÀí
Óû§×é¹ÜÀí
Óû§×éȨÏÞ¶¨Òå
Óû§È¨ÏÞ¶¨Òå
ΪÓû§×é·ÖÅäÓû§
Start¹©Ó¦Á´Ö÷ÒªÊÇΪÖÐСÐÍÆóҵʵÏÖÈ«Ãæ¹ÜÀí¶øÑз¢µÄ£¬·ûºÏÎÒ¹úÏÖ´úÆóÒµµÄ·ÖÏúģʽ£¬Ö§³Ö¶àÖÖ·ÖÏú
ÒµÎñÌØÓеÄÏúÊÛ½±Àø·½Ê½¡£Start¹©Ó¦Á´°ïÖúÆóÒµ·½±ãµØÕûºÏÇþµÀ×ÊÔ´£¬Í³³ïÐÅÏ¢¡¢»õÆ·Óë×ʽð¹ÜÀí£¬¼õÉÙÆóÒµ
µÄÔËÓª³É±¾£¬Ìá¸ßÁ˹¤×÷ЧÂÊ¡£Ö÷ÒªÌصãÓУº
ÏȽøµÄWebģʽ£ºÏµÍ³ÍêÈ«»ùÓÚWebģʽ£¬²ÉÓÃÏȽøµÄä¯ÀÀÆ÷/·þÎñÆ÷£¨B/S£©µÄ½á¹¹£¬ÍêÈ«Í»ÆÆÁË´«Í³ÍøÂçʱ
¿ÕÏÞÖƵĸÅÄî¡£ÄúÖ»ÒªÁ¬½ÓÉÏInternet£¬¾Í¿ÉÒÔÔÚÈκÎʱ¼ä¡¢Èκεص㡢ÒÔÈκνÓÈ뷽ʽµÇ¼ϵͳ£¬ÇáËÉ×ÔÈçµØ
¹¤×÷¡£ÏµÍ³Êý¾Ý¼¯³É¶È¸ß£ºStart¹©Ó¦Á´Í»ÆÆÁË´«Í³µÄÊý¾Ý´«µÝ·½Ê½£¬²ÉÓÃÁË"ÎÞ·ìÁ´½Ó"µÄ¸ÅÄ¸÷Ä£¿éÖ®¼äµÄÊý
¾ÝתÒÆ¿É×Ô¶¯Íê³É£¬±ÜÃâÁËÖظ´ÊäÈ룬±£Ö¤ÁËÊý¾ÝµÄÒ»ÖÂÐÔ¡¢Á¬¹áÐÔ£¬´Ó¶ø´ó´ó¼õÇáÁ˹¤×÷Á¿£¬Ìá¸ßÁ˹¤×÷ЧÂÊ¡£
¸ß¶ÈµÄ°²È«ÐÔ¡¢¿É¿¿ÐÔ£ºStart¹©Ó¦Á´Îª±£Ö¤ÆóÒµÄÚ²¿µÄÐͬ¹¤×÷£¬¶ÔËùÓÐÓû§½øÐÐÁËÑϸñµÄ·Ö×é¹ÜÀí£¬²¢¶Ôÿ¸ö
Óû§×é½øÐÐÑÏÃܵÄȨÏÞ·ÖÅ䣬³¹µ×½â¾öÁ˳¤ÆÚÀ§ÈÅÆóÒµÐÅÏ¢»¯µÄ°²È«ÐÔÎÊÌâ¡£
ÍêÈ«µÄÍøÂ绯²Ù×÷£ºStart¹©Ó¦Á´»ùÓÚÏȽøµÄä¯ÀÀÆ÷/·þÎñÆ÷£¨B/S£©Ìåϵ½á¹¹¿ª·¢¶ø³É£¬ÊÇÕæÕýµÄÍøÂ绯ÐÅÏ¢
¹ÜÀíÈí¼þ¡£Êý¾Ý´«ÊäËٶȸü¼Ó¿ì½Ý¡¢×¼È·£¬ÆóÒµ¹ÜÀíЧÂʽ«µÃµ½´ó·ùÌá¸ß¡£
µ¼º½Ê½µÄ²Ù×÷½çÃ棺Start¹©Ó¦Á´²ÉÓÃÁ˵¼º½Ê½²Ù×÷½çÃ棬¸Ã½çÃ漯ºÏÁËËùÓеÄÒµÎñ²Ù×÷¹¦ÄÜ£¬Ö±¹ÛÐÎÏóµØÒý
µ¼Óû§½øÐÐÒµÎñ²Ù×÷¡£µ¼º½Ê½µÄ½çÃæʹ¸÷ÏîÒµÎñ²Ù×÷±äµÃÇáËÉ×ÔÈç¡£
È«ÄܵÄÐÅÏ¢²éѯ£ºStart¹©Ó¦Á´ÌṩÁËÇ¿´óµÄ×ÊÁÏÖÐÐÄ£¬°üÀ¨²É¹º¡¢ÏúÊÛ¡¢¿â´æ¡¢ÆÚÄ©¡¢±¨±íµÈһϵÁж¯Ì¬Êý
¾Ý×ÊÁÏ£¬¸²¸ÇÃæ¹ã£¬Í³¼Æ·½·¨¿Æѧ£¬Êý¾Ý׼ȷ¡£Óû§¿ÉÒÔ°´ÕÕÏà¹ØÌõ¼þ¶Ô¶©µ¥¡¢ÊÕ»õ¡¢ÍË»õ¡¢¸¶¿î¡¢¿â´æ¡¢ÏúÊÛµÈ
½øÐÐ×éºÏ²éѯ¡£
·½±ãµÄÓ¦Óö¨Öƹ¦ÄÜ£ºStart¹©Ó¦Á´²ÉÓõ±½ñÁ÷Ðеı¨±íÉè¼ÆÆ÷½øÐе¥¾Ý¡¢Õ˱íµÄÉè¼Æ£¬²¢ÎªÓû§ÌṩÁË×ÔÓɶ¨
ÖƸ÷ÀàÔʼµ¥¾Ý¡¢Õ˱í¸ñʽµÄ¹¦ÄÜ£»Óû§²»½ö¿ÉÒÔ¶Ôµ¥¾Ý¡¢Õ˱íÍâ¹Û½øÐÐÉè¼Æ£¨°üÀ¨¶Ô¸ñʽ¡¢×ÖÌå¡¢±ß¿ò¡¢±³¾°µÈµÄ
Éè¼Æ£©£¬¶øÇÒ¿ÉÒÔÉ趨±¨±íÄÚ²¿Êý¾ÝµÄ¼ÆËã·½·¨£¨°üÀ¨¶ÔÊý¾ÝÀ´Ô´µÄÉ趨¡¢Êý¾ÝËã·¨µÄÉ趨µÈ£©£¬Í¬Ê±¼æ¾ßWORDºÍ
EXCELµÄÇ¿´ó¹¦ÄÜ¡£
^ permalink raw reply
* Re: SIOCGIWSCAN wireless event behaviour
From: Jouni Malinen @ 2006-04-20 17:26 UTC (permalink / raw)
To: Jean Tourrilhes
Cc: Dan Williams, Daniel Drake, softmac-dev, netdev, hostap, jkmaline
In-Reply-To: <20060420164354.GA32409@bougret.hpl.hp.com>
On Thu, Apr 20, 2006 at 09:43:54AM -0700, Jean Tourrilhes wrote:
> After we changed to behaviour of ipw, various users reported
> that wpa_supplicant was confused. I particularly trust the report of
> Bill Moss, who has been hacking ipw for a long time :
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=10091113&forum_id=38938
Hmm.. Can someone please describe what was changed? Just sending
SIOCGIWSCAN events more frequently? I have not seen any problems with
this in my tests (though, mainly with madwifi-ng). Is the broken case
available in one of the kernel trees? 2.6.16? wireless-2.6? (i.e., where
can I get the exact version of ipw2200 driver that is expected to show
incorrect behavior)?
> Jouni was notified, but did not really answer to that bug report.
> Then, the ipw maintainers commited the following patch to ipw
> that fix or workaround that issue :
>
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114492056522667&w=2
Hmm.. I don't remember having seen that report from Bill Moss.. How was
I notified? ;-) The patch here seems to be moving ipw_disassociate()
call, so it is not obviously clear from that what the impact on behavior
is. I can try to reproduce this, but I would like to know what version
to test with in order to avoid any possible workarounds from hiding the
issue.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: Mike Christie @ 2006-04-20 17:45 UTC (permalink / raw)
To: James.Smart; +Cc: linux-scsi, netdev, linux-kernel
In-Reply-To: <44479BA8.1000405@emulex.com>
James Smart wrote:
>
> Mike Christie wrote:
>> For the tasks you want to do for the fc class is performance critical?
>
> No, it should not be.
>
>> If not, you could do what the iscsi class (for the netdev people this is
>> drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
>> copies. For iscsi we do this in userspace to send down a login pdu:
>>
>> /*
>> * xmitbuf is a buffer that is large enough for the iscsi_event,
>> * iscsi pdu (hdr_size) and iscsi pdu data (data_size)
>> */
>
> Well, the real difference is that the payload of the "message" is actually
> the payload of the SCSI command or ELS/CT Request. Thus, the payload may
I am not sure I follow. For iscsi, everything after the iscsi_event
struct can be the iscsi request that is to be transmitted. The payload
will not normally be Mbytes but it is not a couple if bytes.
> range in size from a few hundred bytes to several kbytes (> 1 page) to
> Mbyte's in size. Rather than buffer all of this, and push it over the
> socket,
> thus the extra copies - it would best to have the LLDD simply DMA the
> payload like on a typical SCSI command. Additionally, there will be
> response data that can be several kbytes in length.
>
Once you have got the buffer to the class, the class can create a
scatterlist to DMA from for the LLD. I thought. iscsi does not do this
just because it is software right now. For qla4xxx we do not need
something like what you are talking about (see below for what I was
thinking about for the initiators). If you are saying the extra step of
the copy is plain dumb, I agree, but this happens (you have to suffer
some copy and cannot do dio) for sg io as well in some cases. I think
for the sg driver the copy_*_user is the default.
Instead of netlink for scsi commands and transport requests....
For scsi commands could we just use sg io, or is there something special
about the command you want to send? If you can use sg io for scsi
commands, maybe for transport level requests (in my example iscsi pdu)
we could modify something like sg/bsg/block layer scsi_ioctl.c to send
down transport requests to the classes and encapsulate them in some new
struct transport_requests or use the existing struct request but do that
thing people keep taling about using the request/request_queue for
message passing.
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: Mike Christie @ 2006-04-20 17:52 UTC (permalink / raw)
To: James.Smart; +Cc: linux-scsi, netdev, linux-kernel
In-Reply-To: <4447C8C2.30909@cs.wisc.edu>
Mike Christie wrote:
> James Smart wrote:
>> Mike Christie wrote:
>>> For the tasks you want to do for the fc class is performance critical?
>> No, it should not be.
>>
>>> If not, you could do what the iscsi class (for the netdev people this is
>>> drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
>>> copies. For iscsi we do this in userspace to send down a login pdu:
>>>
>>> /*
>>> * xmitbuf is a buffer that is large enough for the iscsi_event,
>>> * iscsi pdu (hdr_size) and iscsi pdu data (data_size)
>>> */
>> Well, the real difference is that the payload of the "message" is actually
>> the payload of the SCSI command or ELS/CT Request. Thus, the payload may
>
> I am not sure I follow. For iscsi, everything after the iscsi_event
> struct can be the iscsi request that is to be transmitted. The payload
> will not normally be Mbytes but it is not a couple if bytes.
>
>> range in size from a few hundred bytes to several kbytes (> 1 page) to
>> Mbyte's in size. Rather than buffer all of this, and push it over the
>> socket,
>> thus the extra copies - it would best to have the LLDD simply DMA the
>> payload like on a typical SCSI command. Additionally, there will be
>> response data that can be several kbytes in length.
>>
>
> Once you have got the buffer to the class, the class can create a
> scatterlist to DMA from for the LLD. I thought. iscsi does not do this
> just because it is software right now. For qla4xxx we do not need
That should be, we do need.
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: Mike Christie @ 2006-04-20 17:58 UTC (permalink / raw)
To: James.Smart; +Cc: linux-scsi, netdev, linux-kernel
In-Reply-To: <4447C8C2.30909@cs.wisc.edu>
Mike Christie wrote:
> James Smart wrote:
>> Mike Christie wrote:
>>> For the tasks you want to do for the fc class is performance critical?
>> No, it should not be.
>>
>>> If not, you could do what the iscsi class (for the netdev people this is
>>> drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
>>> copies. For iscsi we do this in userspace to send down a login pdu:
>>>
>>> /*
>>> * xmitbuf is a buffer that is large enough for the iscsi_event,
>>> * iscsi pdu (hdr_size) and iscsi pdu data (data_size)
>>> */
>> Well, the real difference is that the payload of the "message" is actually
>> the payload of the SCSI command or ELS/CT Request. Thus, the payload may
>
> I am not sure I follow. For iscsi, everything after the iscsi_event
> struct can be the iscsi request that is to be transmitted. The payload
> will not normally be Mbytes but it is not a couple if bytes.
>
>> range in size from a few hundred bytes to several kbytes (> 1 page) to
>> Mbyte's in size. Rather than buffer all of this, and push it over the
>> socket,
>> thus the extra copies - it would best to have the LLDD simply DMA the
>> payload like on a typical SCSI command. Additionally, there will be
>> response data that can be several kbytes in length.
>>
>
> Once you have got the buffer to the class, the class can create a
> scatterlist to DMA from for the LLD. I thought. iscsi does not do this
> just because it is software right now. For qla4xxx we do not need
> something like what you are talking about (see below for what I was
> thinking about for the initiators). If you are saying the extra step of
> the copy is plain dumb, I agree, but this happens (you have to suffer
> some copy and cannot do dio) for sg io as well in some cases. I think
> for the sg driver the copy_*_user is the default.
>
> Instead of netlink for scsi commands and transport requests....
>
> For scsi commands could we just use sg io, or is there something special
> about the command you want to send? If you can use sg io for scsi
> commands, maybe for transport level requests (in my example iscsi pdu)
> we could modify something like sg/bsg/block layer scsi_ioctl.c to send
> down transport requests to the classes and encapsulate them in some new
> struct transport_requests or use the existing struct request but do that
> thing people keep taling about using the request/request_queue for
> message passing.
And just to be complete, the problem with this is that it is tied to the
request queue and so you cannot just send a transport level request
unless it is tied to the device. But for the target stuff we added a
request queue to the host so we could inject requests (the idea was to
send down those magic message requests) at a higher level. To be able
to use that for sg io though it would require some more code and magic
as you know.
^ permalink raw reply
* [patch 3/3] softmac: clean up event handling code
From: Johannes Berg @ 2006-04-20 18:02 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, softmac-dev
In-Reply-To: <20060420180201.092857000@sipsolutions.net>
[-- Attachment #1: fix-event-code.patch --]
[-- Type: text/plain, Size: 2263 bytes --]
This patch cleans up the event handling code in ieee80211softmac_event.c and
makes the module slightly smaller by removing some strings that are not used
any more and consolidating some code.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_event.c 2006-04-20 18:51:24.190142823 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_event.c 2006-04-20 18:54:07.540142823 +0200
@@ -38,7 +38,8 @@
* The event context is private and can only be used from
* within this module. Its meaning varies with the event
* type:
- * SCAN_FINISHED: no special meaning
+ * SCAN_FINISHED,
+ * DISASSOCIATED: NULL
* ASSOCIATED,
* ASSOCIATE_FAILED,
* ASSOCIATE_TIMEOUT,
@@ -59,15 +60,15 @@
*/
static char *event_descriptions[IEEE80211SOFTMAC_EVENT_LAST+1] = {
- "scan finished",
- "associated",
+ NULL, /* scan finished */
+ NULL, /* associated */
"associating failed",
"associating timed out",
"authenticated",
"authenticating failed",
"authenticating timed out",
"associating failed because no suitable network was found",
- "disassociated",
+ NULL, /* disassociated */
};
@@ -136,30 +137,24 @@ ieee80211softmac_call_events_locked(stru
int we_event;
char *msg = NULL;
+ memset(&wrqu, '\0', sizeof (union iwreq_data));
+
switch(event) {
case IEEE80211SOFTMAC_EVENT_ASSOCIATED:
network = (struct ieee80211softmac_network *)event_ctx;
- wrqu.data.length = 0;
- wrqu.data.flags = 0;
memcpy(wrqu.ap_addr.sa_data, &network->bssid[0], ETH_ALEN);
- wrqu.ap_addr.sa_family = ARPHRD_ETHER;
- we_event = SIOCGIWAP;
- break;
+ /* fall through */
case IEEE80211SOFTMAC_EVENT_DISASSOCIATED:
- wrqu.data.length = 0;
- wrqu.data.flags = 0;
- memset(&wrqu, '\0', sizeof (union iwreq_data));
wrqu.ap_addr.sa_family = ARPHRD_ETHER;
we_event = SIOCGIWAP;
break;
case IEEE80211SOFTMAC_EVENT_SCAN_FINISHED:
- wrqu.data.length = 0;
- wrqu.data.flags = 0;
- memset(&wrqu, '\0', sizeof (union iwreq_data));
we_event = SIOCGIWSCAN;
break;
default:
msg = event_descriptions[event];
+ if (!msg)
+ msg = "SOFTMAC EVENT BUG";
wrqu.data.length = strlen(msg);
we_event = IWEVCUSTOM;
break;
--
^ permalink raw reply
* [patch 0/3] softmac: more fixes
From: Johannes Berg @ 2006-04-20 18:02 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, softmac-dev
This patchset fixes more things in softmac, the first patch implements
the SIOCSIWMLME wext, the second fixes the SIOCSIWAP wext and the third
cleans up the event code.
The second is a fairly important fix for wpa_supplicant and should probably
still go to 2.6.17, the others can go in too of course but aren't that
important I think.
johannes
^ permalink raw reply
* [patch 2/3] softmac: fix SIOCSIWAP
From: Johannes Berg @ 2006-04-20 18:02 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, softmac-dev
In-Reply-To: <20060420180201.092857000@sipsolutions.net>
[-- Attachment #1: fix-SIOCSIWAP.patch --]
[-- Type: text/plain, Size: 6292 bytes --]
There are some bugs in the current implementation of the SIOCSIWAP wext,
for example that when you do it twice and it fails, it may still try
another access point for some reason. This patch fixes this by introducing
a new flag that tells the association code that the bssid that is in use
was fixed by the user and shouldn't be deviated from.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- wireless-2.6.orig/include/net/ieee80211softmac.h 2006-04-13 15:48:12.000000000 +0200
+++ wireless-2.6/include/net/ieee80211softmac.h 2006-04-20 01:10:32.770882874 +0200
@@ -96,10 +96,13 @@ struct ieee80211softmac_assoc_info {
*
* bssvalid is true if we found a matching network
* and saved it's BSSID into the bssid above.
+ *
+ * bssfixed is used for SIOCSIWAP.
*/
u8 static_essid:1,
associating:1,
- bssvalid:1;
+ bssvalid:1,
+ bssfixed:1;
/* Scan retries remaining */
int scan_retry;
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-19 18:46:47.000000000 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-20 01:30:59.090882874 +0200
@@ -144,6 +144,12 @@ network_matches_request(struct ieee80211
if (!we_support_all_basic_rates(mac, net->rates_ex, net->rates_ex_len))
return 0;
+ /* assume that users know what they're doing ...
+ * (note we don't let them select a net we're incompatible with) */
+ if (mac->associnfo.bssfixed) {
+ return !memcmp(mac->associnfo.bssid, net->bssid, ETH_ALEN);
+ }
+
/* if 'ANY' network requested, take any that doesn't have privacy enabled */
if (mac->associnfo.req_essid.len == 0
&& !(net->capability & WLAN_CAPABILITY_PRIVACY))
@@ -176,7 +182,7 @@ ieee80211softmac_assoc_work(void *d)
ieee80211softmac_disassoc(mac, WLAN_REASON_DISASSOC_STA_HAS_LEFT);
/* try to find the requested network in our list, if we found one already */
- if (mac->associnfo.bssvalid)
+ if (mac->associnfo.bssvalid || mac->associnfo.bssfixed)
found = ieee80211softmac_get_network_by_bssid(mac, mac->associnfo.bssid);
/* Search the ieee80211 networks for this network if we didn't find it by bssid,
@@ -241,19 +247,25 @@ ieee80211softmac_assoc_work(void *d)
if (ieee80211softmac_start_scan(mac))
dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?\n");
return;
- }
- else {
+ } else {
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.associating = 0;
mac->associated = 0;
spin_unlock_irqrestore(&mac->lock, flags);
dprintk(KERN_INFO PFX "Unable to find matching network after scan!\n");
+ /* reset the retry counter for the next user request since we
+ * break out and don't reschedule ourselves after this point. */
+ mac->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_NET_NOT_FOUND, NULL);
return;
}
}
-
+
+ /* reset the retry counter for the next user request since we
+ * now found a net and will try to associate to it, but not
+ * schedule this function again. */
+ mac->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
mac->associnfo.bssvalid = 1;
memcpy(mac->associnfo.bssid, found->bssid, ETH_ALEN);
/* copy the ESSID for displaying it */
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-19 18:48:52.000000000 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-20 15:27:26.122486954 +0200
@@ -27,7 +27,8 @@
#include "ieee80211softmac_priv.h"
#include <net/iw_handler.h>
-
+/* for is_broadcast_ether_addr and is_zero_ether_addr */
+#include <linux/etherdevice.h>
int
ieee80211softmac_wx_trigger_scan(struct net_device *net_dev,
@@ -83,7 +84,6 @@ ieee80211softmac_wx_set_essid(struct net
sm->associnfo.static_essid = 1;
}
}
- sm->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
/* set our requested ESSID length.
* If applicable, we have already copied the data in */
@@ -310,8 +310,6 @@ ieee80211softmac_wx_set_wap(struct net_d
char *extra)
{
struct ieee80211softmac_device *mac = ieee80211_priv(net_dev);
- static const unsigned char any[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
- static const unsigned char off[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
unsigned long flags;
/* sanity check */
@@ -320,10 +318,17 @@ ieee80211softmac_wx_set_wap(struct net_d
}
spin_lock_irqsave(&mac->lock, flags);
- if (!memcmp(any, data->ap_addr.sa_data, ETH_ALEN) ||
- !memcmp(off, data->ap_addr.sa_data, ETH_ALEN)) {
- schedule_work(&mac->associnfo.work);
- goto out;
+ if (is_broadcast_ether_addr(data->ap_addr.sa_data)) {
+ /* the bssid we have is not to be fixed any longer,
+ * and we should reassociate to the best AP. */
+ mac->associnfo.bssfixed = 0;
+ /* force reassociation */
+ mac->associnfo.bssvalid = 0;
+ if (mac->associated)
+ schedule_work(&mac->associnfo.work);
+ } else if (is_zero_ether_addr(data->ap_addr.sa_data)) {
+ /* the bssid we have is no longer fixed */
+ mac->associnfo.bssfixed = 0;
} else {
if (!memcmp(mac->associnfo.bssid, data->ap_addr.sa_data, ETH_ALEN)) {
if (mac->associnfo.associating || mac->associated) {
@@ -333,12 +338,14 @@ ieee80211softmac_wx_set_wap(struct net_d
} else {
/* copy new value in data->ap_addr.sa_data to bssid */
memcpy(mac->associnfo.bssid, data->ap_addr.sa_data, ETH_ALEN);
- }
+ }
+ /* tell the other code that this bssid should be used no matter what */
+ mac->associnfo.bssfixed = 1;
/* queue associate if new bssid or (old one again and not associated) */
schedule_work(&mac->associnfo.work);
}
-out:
+ out:
spin_unlock_irqrestore(&mac->lock, flags);
return 0;
}
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_module.c 2006-03-28 16:23:33.000000000 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_module.c 2006-04-20 01:24:54.550882874 +0200
@@ -45,6 +45,8 @@ struct net_device *alloc_ieee80211softma
softmac->ieee->handle_disassoc = ieee80211softmac_handle_disassoc;
softmac->scaninfo = NULL;
+ softmac->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
+
/* TODO: initialise all the other callbacks in the ieee struct
* (once they're written)
*/
--
^ permalink raw reply
* [patch 1/3] softmac: add SIOCSIWMLME
From: Johannes Berg @ 2006-04-20 18:02 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Jouni Malinen, softmac-dev
In-Reply-To: <20060420180201.092857000@sipsolutions.net>
[-- Attachment #1: SIOCSIWMLME.patch --]
[-- Type: text/plain, Size: 3181 bytes --]
This patch adds the SIOCSIWMLME wext to softmac, this functionality
appears to be used by wpa_supplicant and is softmac-specific.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Jouni Malinen <jkm@devicescape.com>
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_priv.h 2006-04-19 18:44:51.710074158 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_priv.h 2006-04-20 00:50:54.930882874 +0200
@@ -150,6 +150,7 @@ int ieee80211softmac_handle_disassoc(str
int ieee80211softmac_handle_reassoc_req(struct net_device * dev,
struct ieee80211_reassoc_request * reassoc);
void ieee80211softmac_assoc_timeout(void *d);
+void ieee80211softmac_disassoc(struct ieee80211softmac_device *mac, u16 reason);
/* some helper functions */
static inline int ieee80211softmac_scan_handlers_check_self(struct ieee80211softmac_device *sm)
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-19 18:44:51.710074158 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-19 18:48:52.200074158 +0200
@@ -424,3 +424,35 @@ ieee80211softmac_wx_get_genie(struct net
}
EXPORT_SYMBOL_GPL(ieee80211softmac_wx_get_genie);
+int
+ieee80211softmac_wx_set_mlme(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu,
+ char *extra)
+{
+ struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+ struct iw_mlme *mlme = (struct iw_mlme *)extra;
+ u16 reason = cpu_to_le16(mlme->reason_code);
+ struct ieee80211softmac_network *net;
+
+ if (memcmp(mac->associnfo.bssid, mlme->addr.sa_data, ETH_ALEN)) {
+ printk(KERN_DEBUG PFX "wx_set_mlme: requested operation on net we don't use\n");
+ return -EINVAL;
+ }
+
+ switch (mlme->cmd) {
+ case IW_MLME_DEAUTH:
+ net = ieee80211softmac_get_network_by_bssid_locked(mac, mlme->addr.sa_data);
+ if (!net) {
+ printk(KERN_DEBUG PFX "wx_set_mlme: we should know the net here...\n");
+ return -EINVAL;
+ }
+ return ieee80211softmac_deauth_req(mac, net, reason);
+ case IW_MLME_DISASSOC:
+ ieee80211softmac_disassoc(mac, reason);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+EXPORT_SYMBOL_GPL(ieee80211softmac_wx_set_mlme);
--- wireless-2.6.orig/include/net/ieee80211softmac_wx.h 2006-03-28 16:23:31.000000000 +0200
+++ wireless-2.6/include/net/ieee80211softmac_wx.h 2006-04-19 18:48:30.640074158 +0200
@@ -91,4 +91,9 @@ ieee80211softmac_wx_get_genie(struct net
struct iw_request_info *info,
union iwreq_data *wrqu,
char *extra);
+extern int
+ieee80211softmac_wx_set_mlme(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu,
+ char *extra);
#endif /* _IEEE80211SOFTMAC_WX */
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-19 18:46:29.000000000 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-19 18:46:47.300074158 +0200
@@ -82,7 +82,7 @@ ieee80211softmac_assoc_timeout(void *d)
}
/* Sends out a disassociation request to the desired AP */
-static void
+void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac, u16 reason)
{
unsigned long flags;
--
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-20 19:09 UTC (permalink / raw)
To: simlo; +Cc: linux-kernel, mingo, netdev
In-Reply-To: <Pine.LNX.4.44L0.0604201819040.19330-100000@lifa01.phys.au.dk>
[ Maybe ask questions like this on "netdev" where the networking
developers hang out? Added to CC: ]
Van fell off the face of the planet after giving his presentation and
never published his code, only his slides.
I've started to make a slow attempt at implementing his ideas, nothing
but pure infrastructure so far, but you can look at what I have here:
kernel.org:/pub/scm/linux/kernel/git/davem/vj-2.6.git
don't expect major progress and don't expect anything beyond a simple
channel to softint packet processing on receive any time soon.
Going all the way to the socket is a large endeavor and will require a
lot of restructuring to do it right, so expect this to take on the
order of months.
^ permalink raw reply
* Re: [XFRM Doc]: aevent description
From: David S. Miller @ 2006-04-20 19:12 UTC (permalink / raw)
To: hadi; +Cc: netdev, hidden, herbert
In-Reply-To: <1145530725.5169.12.camel@jzny2>
From: jamal <hadi@cyberus.ca>
Date: Thu, 20 Apr 2006 06:58:45 -0400
> On Fri, 2006-14-04 at 15:05 -0700, David S. Miller wrote:
> > From: jamal <hadi@cyberus.ca>
> > Date: Thu, 13 Apr 2006 09:00:08 -0400
> >
> > > There is dependency on the previous patch i sent since the issue that
> > > patch fixes is assumed in this text description. It would be a good
> > > idea to apply at the same time as the other.
> >
> > Applied, after fixing 28 lines containing trailing whitespace :-)
>
> yikes ;->
> Ok, so how do i avoid this in the future? Note, this was a _brand new_
> file, so it is a little bizarre.
This command:
git apply --check --whitespace=error-all $1
will spit out errors if your patch adds trailing whitespace
or will not apply cleanly to the current GIT tree.
^ permalink raw reply
* Cannot receive multicast packets
From: Andrew Athan @ 2006-04-20 19:24 UTC (permalink / raw)
To: netdev
I sent a similar message to LKML, and linux-dev but was directed to this
list might as most appropriate. Thanks in advance...
It's likely this is a programming error, but I am at a loss.
The simple UDP multicast receive application below, adapted from source
on IBM's web site, will not receive any data. While it is blocked on
recv():
hfclinux2:/home/root/UDP/apps/Crosser2# netstat -ang
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 224.0.0.1
eth0 1 224.0.0.1
eth1 1 224.0.17.44
eth1 1 224.0.0.1
lo 1 ff02::1
eth0 1 ff02::1:ffdd:eb2b
eth0 1 ff02::1
eth1 1 ff02::1:ffdd:eb2c
eth1 1 ff02::1
And tcpdump shows traffic arriving at the interface(see below)! This
leads me to belive the kernel is filtering it, and or not delivering it
to the socket.
The one "strange" thing about this network is that the traffic is
flowing in "dense mode", meaning there is no explicit need for IGMP
messaging (nor any response to such messaging).
Can anyone point me in the right direction regarding why the socket
never receives any data????
Thanks.
Andrew
hfclinux2:/home/root/UDP/apps/Crosser2# uname -a
Linux hfclinux2 2.6.15.1smp #6 SMP PREEMPT Mon Feb 13 11:38:32 EST 2006
i686 GNU/Linux
hfclinux2:/home/root/UDP/apps/Crosser2# tcpdump -i eth1 port 55300
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
12:54:06.980000 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 91
12:54:07.079675 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 46
12:54:07.179869 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 181
12:54:07.280437 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 181
12:54:07.380005 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 181
12:54:07.480073 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 136
12:54:07.680459 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 91
12:54:07.780277 IP 206.200.5.144.2232 > 224.0.17.44.55300: UDP, length 136
hfclinux2:/home/root/UDP/apps/Crosser2# ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:43:DD:EB:2B
inet addr:172.22.71.128 Bcast:172.22.71.255 Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fedd:eb2b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19540 errors:0 dropped:0 overruns:0 frame:0
TX packets:7838 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1563190 (1.4 MiB) TX bytes:1943895 (1.8 MiB)
Base address:0xdcc0 Memory:dfae0000-dfb00000
eth0:1 Link encap:Ethernet HWaddr 00:11:43:DD:EB:2B
inet addr:10.61.6.128 Bcast:10.61.6.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xdcc0 Memory:dfae0000-dfb00000
eth0:2 Link encap:Ethernet HWaddr 00:11:43:DD:EB:2B
inet addr:196.0.34.11 Bcast:196.0.34.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xdcc0 Memory:dfae0000-dfb00000
eth0:3 Link encap:Ethernet HWaddr 00:11:43:DD:EB:2B
inet addr:192.168.254.128 Bcast:192.168.254.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xdcc0 Memory:dfae0000-dfb00000
eth1 Link encap:Ethernet HWaddr 00:11:43:DD:EB:2C
inet addr:192.168.250.128 Bcast:192.168.250.255
Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fedd:eb2c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:137717 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:58314262 (55.6 MiB) TX bytes:1596 (1.5 KiB)
Base address:0xccc0 Memory:df8e0000-df900000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
-------------------------
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
using namespace std;
struct sockaddr_in localSock;
struct ip_mreqn group;
int sd;
int datalen;
char databuf[10];
int main (int argc, char *argv[])
{
sd = socket(AF_INET, SOCK_DGRAM, 0);
if (sd < 0) {
perror("opening datagram socket");
exit(1);
}
{
int reuse=1;
if (setsockopt(sd, SOL_SOCKET, SO_REUSEADDR,
(char *)&reuse, sizeof(reuse)) < 0) {
perror("setting SO_REUSEADDR");
close(sd);
exit(1);
}
}
memset((char *) &localSock, 0, sizeof(localSock));
localSock.sin_family = AF_INET;
localSock.sin_port = htons(55300);;
localSock.sin_addr.s_addr = INADDR_ANY;
if (bind(sd, (struct sockaddr*)&localSock, sizeof(localSock))) {
perror("binding datagram socket");
close(sd);
exit(1);
}
group.imr_multiaddr.s_addr = inet_addr("224.0.17.44");
printf("%d\n",group.imr_multiaddr.s_addr);
group.imr_address.s_addr = inet_addr("192.168.250.128");
if (setsockopt(sd, IPPROTO_IP, IP_ADD_MEMBERSHIP,
(char *)&group, sizeof(group)) < 0) {
perror("adding multicast group");
close(sd);
exit(1);
}
/*
* Read from the socket.
*/
datalen = sizeof(databuf);
if (recv(sd, databuf, datalen,0) < 0) {
perror("reading datagram message");
close(sd);
exit(1);
} else {
puts("success reading");
}
}
^ permalink raw reply
* sendpage and high mem pages
From: Mike Christie @ 2006-04-20 19:29 UTC (permalink / raw)
To: netdev
I was wondering if it is ok to pass sendpage high mem pages. If a piece
of code does this:
struct socket *sock;
sock->ops->sendpage(pg...)
and pg is a highmem page will the network layer do the right thing or
should the caller check the page type and call sock_no_sendpage() for
highmen? It looks like net/sunrpc/xprtsock.c does a check but
drivers/scsi/iscsi_tcp.c and some others do not.
^ 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