This patch contains following modifications:
- Add mesh capabilities on fw.c to permit creation of mesh
interfaces using this driver.
- Modify carl9170_set_operating_mode, to use AP-style beaconing
with mesh interfaces.
- Allow beacon updates for NL80211_IFTYPE_MESH_POINT type in
carl9170_handle_command_response.
Signed-off-by: Javier Lopez <[email protected]>
---
drivers/net/wireless/ath/carl9170/fw.c | 1 +
drivers/net/wireless/ath/carl9170/mac.c | 2 +-
drivers/net/wireless/ath/carl9170/rx.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/carl9170/fw.c b/drivers/net/wireless/ath/carl9170/fw.c
index cba9d04..b03d7bf 100644
--- a/drivers/net/wireless/ath/carl9170/fw.c
+++ b/drivers/net/wireless/ath/carl9170/fw.c
@@ -304,6 +304,7 @@ static int carl9170_fw(struct ar9170 *ar, const __u8 *data, size_t len)
if (SUPP(CARL9170FW_WLANTX_CAB)) {
if_comb_types |=
BIT(NL80211_IFTYPE_AP) |
+ BIT(NL80211_IFTYPE_MESH_POINT) |
BIT(NL80211_IFTYPE_P2P_GO);
}
}
diff --git a/drivers/net/wireless/ath/carl9170/mac.c b/drivers/net/wireless/ath/carl9170/mac.c
index dfda919..a5f5fa0 100644
--- a/drivers/net/wireless/ath/carl9170/mac.c
+++ b/drivers/net/wireless/ath/carl9170/mac.c
@@ -318,10 +318,10 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
bssid = common->curbssid;
switch (vif->type) {
- case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_ADHOC:
cam_mode |= AR9170_MAC_CAM_IBSS;
break;
+ case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_AP:
cam_mode |= AR9170_MAC_CAM_AP;
diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
index dc99030..3be2130 100644
--- a/drivers/net/wireless/ath/carl9170/rx.c
+++ b/drivers/net/wireless/ath/carl9170/rx.c
@@ -206,6 +206,7 @@ void carl9170_handle_command_response(struct ar9170 *ar, void *buf, u32 len)
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_ADHOC:
+ case NL80211_IFTYPE_MESH_POINT:
carl9170_update_beacon(ar, true);
break;
--
1.7.9.5
On Fri, Jul 27, 2012 at 7:30 AM, Christian Lamparter
<[email protected]> wrote:
> On Friday 27 July 2012 05:52:49 Javier Cardona wrote:
>> On Thu, Jul 26, 2012 at 1:12 PM, Christian Lamparter
>> <[email protected]> wrote:
>> > On Thursday 26 July 2012 21:59:03 Javier Lopez wrote:
>> >> This patch contains following modifications:
>> >>
>> >> - Add mesh capabilities on fw.c to permit creation of mesh
>> >> interfaces using this driver.
>> >>
>> >> - Modify carl9170_set_operating_mode, to use AP-style beaconing
>> >> with mesh interfaces.
>> >>
>> >> - Allow beacon updates for NL80211_IFTYPE_MESH_POINT type in
>> >> carl9170_handle_command_response.
>> >>
>> >> Signed-off-by: Javier Lopez <[email protected]>
>> > Hm, what about virtual interfaces?
>> >
>> > Do you think it's save to share a MESH node with
>> > a STA, IBSS, AP interface on the same hardware?
>>
>> Does this hardware support multiple beacons?
>> If not, we probably should limit the driver
>> to only accept one beaconing vif at a time
>> (e.g. one mesh vif + multiple STAs vifs ok).
> oh yes. In fact, Due to your modifycations to fw.c
> you have to update carl9170_op_add_interface as well.
> As you are currently claiming any mesh/ap/sta
> combination, even though it's not supported in the
> code atm.
>
> Just add a case for NL80211_IFTYPE_MESH in the
> switch (main_vif->type) block and to the
> if ((vif->type == ...) below.
>
>> > On a side node: Can you tell me anything about
>> > the crypto of mesh traffic? Because currently,
>> > the code will disable any hardware crypto
>> > offload for any mode other than STA and AP.
>>
>> The hardware crypto needs to support one tx/rx
>> pairwise key per peer, a groupwise key for each
>> peer and management frame protection.
>> Not sure if this is the case for this hardware,
>> so until we do, it seems reasonable to disable
>> crypto offload.
> ok, a groupwise key for each peer is not possible
> with the hw. (no need to change anything, swcrypto
> is selected in this case).
>
> Regards,
> Chr
>
> BTW: Did you do any experiments? I.e.: Does it really
> work?
Basic peering and pinging with ath9k_htc seems to work. We only have
one of these cards, so we cannot run our full test suite. Testing
will continue when we receive more cards.
Javier
On Thursday 26 July 2012 21:59:03 Javier Lopez wrote:
> This patch contains following modifications:
>
> - Add mesh capabilities on fw.c to permit creation of mesh
> interfaces using this driver.
>
> - Modify carl9170_set_operating_mode, to use AP-style beaconing
> with mesh interfaces.
>
> - Allow beacon updates for NL80211_IFTYPE_MESH_POINT type in
> carl9170_handle_command_response.
>
> Signed-off-by: Javier Lopez <[email protected]>
Hm, what about virtual interfaces?
Do you think it's save to share a MESH node with
a STA, IBSS, AP interface on the same hardware?
Regards,
Chr
On a side node: Can you tell me anything about
the crypto of mesh traffic? Because currently,
the code will disable any hardware crypto
offload for any mode other than STA and AP.
Hi Christian,
I just wanted to give you an update about the mesh support on
carl9170. Today we've been testing the unique carl9170 card we have, a
D-link DWA-160.
We tested on a mesh network with 5 nodes (1 carl9170 + 4 ath9k_htc
cards) and we haven't seen any problem on this setup. All mesh
functionalities seem to work correctly.
We are still waiting to receive more carl9170 cards, once we have them
we'll run new tests on them.
Cheers,
Jlo
On Fri, Jul 27, 2012 at 2:16 PM, Christian Lamparter
<[email protected]> wrote:
> On Friday 27 July 2012 17:12:32 Javier Cardona wrote:
>> On Fri, Jul 27, 2012 at 7:30 AM, Christian Lamparter wrote:
>> > BTW: Did you do any experiments? I.e.: Does it really
>> > work?
>>
>> Basic peering and pinging with ath9k_htc seems to work.
>> We only have one of these cards, so we cannot run our
>> full test suite. Testing will continue when we
>> receive more cards.
>
> Ok, thanks. I'll take care of updating the information
> on the wiki now.
>
> Regards,
> Chr
--
Javier Lopez
Software Engineer
cozybit Inc.
On Friday 27 July 2012 17:12:32 Javier Cardona wrote:
> On Fri, Jul 27, 2012 at 7:30 AM, Christian Lamparter wrote:
> > BTW: Did you do any experiments? I.e.: Does it really
> > work?
>
> Basic peering and pinging with ath9k_htc seems to work.
> We only have one of these cards, so we cannot run our
> full test suite. Testing will continue when we
> receive more cards.
Ok, thanks. I'll take care of updating the information
on the wiki now.
Regards,
Chr
On Friday 27 July 2012 05:52:49 Javier Cardona wrote:
> On Thu, Jul 26, 2012 at 1:12 PM, Christian Lamparter
> <[email protected]> wrote:
> > On Thursday 26 July 2012 21:59:03 Javier Lopez wrote:
> >> This patch contains following modifications:
> >>
> >> - Add mesh capabilities on fw.c to permit creation of mesh
> >> interfaces using this driver.
> >>
> >> - Modify carl9170_set_operating_mode, to use AP-style beaconing
> >> with mesh interfaces.
> >>
> >> - Allow beacon updates for NL80211_IFTYPE_MESH_POINT type in
> >> carl9170_handle_command_response.
> >>
> >> Signed-off-by: Javier Lopez <[email protected]>
> > Hm, what about virtual interfaces?
> >
> > Do you think it's save to share a MESH node with
> > a STA, IBSS, AP interface on the same hardware?
>
> Does this hardware support multiple beacons?
> If not, we probably should limit the driver
> to only accept one beaconing vif at a time
> (e.g. one mesh vif + multiple STAs vifs ok).
oh yes. In fact, Due to your modifycations to fw.c
you have to update carl9170_op_add_interface as well.
As you are currently claiming any mesh/ap/sta
combination, even though it's not supported in the
code atm.
Just add a case for NL80211_IFTYPE_MESH in the
switch (main_vif->type) block and to the
if ((vif->type == ...) below.
> > On a side node: Can you tell me anything about
> > the crypto of mesh traffic? Because currently,
> > the code will disable any hardware crypto
> > offload for any mode other than STA and AP.
>
> The hardware crypto needs to support one tx/rx
> pairwise key per peer, a groupwise key for each
> peer and management frame protection.
> Not sure if this is the case for this hardware,
> so until we do, it seems reasonable to disable
> crypto offload.
ok, a groupwise key for each peer is not possible
with the hw. (no need to change anything, swcrypto
is selected in this case).
Regards,
Chr
BTW: Did you do any experiments? I.e.: Does it really
work?
On Thu, Jul 26, 2012 at 1:12 PM, Christian Lamparter
<[email protected]> wrote:
> On Thursday 26 July 2012 21:59:03 Javier Lopez wrote:
>> This patch contains following modifications:
>>
>> - Add mesh capabilities on fw.c to permit creation of mesh
>> interfaces using this driver.
>>
>> - Modify carl9170_set_operating_mode, to use AP-style beaconing
>> with mesh interfaces.
>>
>> - Allow beacon updates for NL80211_IFTYPE_MESH_POINT type in
>> carl9170_handle_command_response.
>>
>> Signed-off-by: Javier Lopez <[email protected]>
> Hm, what about virtual interfaces?
>
> Do you think it's save to share a MESH node with
> a STA, IBSS, AP interface on the same hardware?
Does this hardware support multiple beacons?
If not, we probably should limit the driver to only accept one
beaconing vif at a time (e.g. one mesh vif + multiple STAs vifs ok).
> On a side node: Can you tell me anything about
> the crypto of mesh traffic? Because currently,
> the code will disable any hardware crypto
> offload for any mode other than STA and AP.
The hardware crypto needs to support one tx/rx pairwise key per peer,
a groupwise key for each peer and management frame protection.
Not sure if this is the case for this hardware, so until we do, it
seems reasonable to disable crypto offload.
Cheers,
Javier
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com