All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [RFC 1/2] ath9k: Fix up hardware mode and beacons with multiple vifs.
Date: Fri, 14 Jan 2011 11:12:10 -0800	[thread overview]
Message-ID: <4D30A00A.4040005@candelatech.com> (raw)
In-Reply-To: <1295031482.3703.16.camel@mythtv.ewol.com>

On 01/14/2011 10:58 AM, Steve Brown wrote:
> On Fri, 2011-01-14 at 09:27 -0800, greearb at candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> When using a mixture of AP and Station interfaces,
>> the hardware mode was using the type of the
>> last VIF registered.  Instead, we should keep track
>> of the number of different types of vifs and set the
>> mode accordingly.
>>
>> In addtion, use the vif type instead of hardware opmode
>> when dealing with beacons.
>>
>> Attempt to move some of the common setup code into smaller
>> methods so we can re-use it when changing vif mode as
>> well as adding/deleting vifs.
>>
>> This needs review.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>> :100644 100644 3108699... a2da259... M	drivers/net/wireless/ath/ath9k/ath9k.h
>> :100644 100644 385ba03... 8de591e... M	drivers/net/wireless/ath/ath9k/beacon.c
>> :100644 100644 0452580... 1a65e53... M	drivers/net/wireless/ath/ath9k/main.c
>> :100644 100644 ea2f67c... 9a2b4a8... M	drivers/net/wireless/ath/ath9k/recv.c
>>   drivers/net/wireless/ath/ath9k/ath9k.h  |   10 +-
>>   drivers/net/wireless/ath/ath9k/beacon.c |   14 +-
>>   drivers/net/wireless/ath/ath9k/main.c   |  263 ++++++++++++++++++++++---------
>>   drivers/net/wireless/ath/ath9k/recv.c   |   17 ++-
>>   4 files changed, 214 insertions(+), 90 deletions(-)
>>
>
> It would be really useful to have both an AP and MESH vif. With the mesh
> and ap vif's bridged, a station connected to the ap could ping outside
> the mesh. Currently, if you add the mesh vif and then the ap vif, it
> sort of works. The other way around, the mesh interval value causes
> beacons to be sent only for the vif associated with slot 0.
>
> Is it possible to consider this case as you overhaul ath9k beaconing?

Perhaps someone else would be better.  I have no way to test mesh
right now, and still do not understand this code too well.

Hopefully the vif-counting work would help with dealing with
your scenario, however...

Also, could you try with my patch(es)?  Part of the problem with the old
code is that if you added mesh second, you would not be in AP mode anymore.
I think that part will be fixed now.  There may be other issues remaining,
however.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: sbrown@cortland.com
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
Subject: Re: [RFC 1/2] ath9k:  Fix up hardware mode and beacons with multiple vifs.
Date: Fri, 14 Jan 2011 11:12:10 -0800	[thread overview]
Message-ID: <4D30A00A.4040005@candelatech.com> (raw)
In-Reply-To: <1295031482.3703.16.camel@mythtv.ewol.com>

On 01/14/2011 10:58 AM, Steve Brown wrote:
> On Fri, 2011-01-14 at 09:27 -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> When using a mixture of AP and Station interfaces,
>> the hardware mode was using the type of the
>> last VIF registered.  Instead, we should keep track
>> of the number of different types of vifs and set the
>> mode accordingly.
>>
>> In addtion, use the vif type instead of hardware opmode
>> when dealing with beacons.
>>
>> Attempt to move some of the common setup code into smaller
>> methods so we can re-use it when changing vif mode as
>> well as adding/deleting vifs.
>>
>> This needs review.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>> :100644 100644 3108699... a2da259... M	drivers/net/wireless/ath/ath9k/ath9k.h
>> :100644 100644 385ba03... 8de591e... M	drivers/net/wireless/ath/ath9k/beacon.c
>> :100644 100644 0452580... 1a65e53... M	drivers/net/wireless/ath/ath9k/main.c
>> :100644 100644 ea2f67c... 9a2b4a8... M	drivers/net/wireless/ath/ath9k/recv.c
>>   drivers/net/wireless/ath/ath9k/ath9k.h  |   10 +-
>>   drivers/net/wireless/ath/ath9k/beacon.c |   14 +-
>>   drivers/net/wireless/ath/ath9k/main.c   |  263 ++++++++++++++++++++++---------
>>   drivers/net/wireless/ath/ath9k/recv.c   |   17 ++-
>>   4 files changed, 214 insertions(+), 90 deletions(-)
>>
>
> It would be really useful to have both an AP and MESH vif. With the mesh
> and ap vif's bridged, a station connected to the ap could ping outside
> the mesh. Currently, if you add the mesh vif and then the ap vif, it
> sort of works. The other way around, the mesh interval value causes
> beacons to be sent only for the vif associated with slot 0.
>
> Is it possible to consider this case as you overhaul ath9k beaconing?

Perhaps someone else would be better.  I have no way to test mesh
right now, and still do not understand this code too well.

Hopefully the vif-counting work would help with dealing with
your scenario, however...

Also, could you try with my patch(es)?  Part of the problem with the old
code is that if you added mesh second, you would not be in AP mode anymore.
I think that part will be fixed now.  There may be other issues remaining,
however.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2011-01-14 19:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-14 17:27 [ath9k-devel] [RFC 1/2] ath9k: Fix up hardware mode and beacons with multiple vifs greearb at candelatech.com
2011-01-14 17:27 ` greearb
2011-01-14 17:27 ` [ath9k-devel] [RFC 2/2] ath9k: Add 'misc' file to debugfs, fix queue indexes greearb at candelatech.com
2011-01-14 17:27   ` greearb
2011-01-14 18:05 ` [ath9k-devel] [RFC 1/2] ath9k: Fix up hardware mode and beacons with multiple vifs Felix Fietkau
2011-01-14 18:05   ` Felix Fietkau
2011-01-14 18:16   ` Ben Greear
2011-01-14 18:16     ` Ben Greear
2011-01-15  1:41   ` Björn Smedman
2011-01-15  1:41     ` Björn Smedman
2011-01-15 14:54     ` Ben Greear
2011-01-15 14:54       ` Ben Greear
2011-01-14 18:58 ` Steve Brown
2011-01-14 18:58   ` Steve Brown
2011-01-14 19:12   ` Ben Greear [this message]
2011-01-14 19:12     ` Ben Greear
2011-01-14 23:19 ` [ath9k-devel] " Björn Smedman
2011-01-14 23:19   ` Björn Smedman
2011-01-14 23:24   ` [ath9k-devel] " Ben Greear
2011-01-14 23:24     ` Ben Greear
2011-01-15  0:55   ` [ath9k-devel] " Steve Brown
2011-01-15  0:55     ` Steve Brown
2011-01-15  1:20     ` Björn Smedman
2011-01-15  1:20       ` Björn Smedman
2011-01-15 11:07       ` Jouni Malinen
2011-01-15 11:07         ` Jouni Malinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D30A00A.4040005@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.