ath5k mesh in 2.6.28?

ath5k mesh in 2.6.28?

[Keir]

Hi,

According to the 802.11s website it seems to claim that mesh
networking is supported for ath5k devices in kernel 2.6.28, however,
upon running ifconfig mesh0 up (having previously created the mesh
device using iw) I get "SIOCSIFFLAGS: Operation not supported".  I
have made sure to compile my kernel with the o11s stack, and a
previous wireless-testing kernel had mesh working on the same
hardware.  Anyone have any idea as to what might be wrong?

Cheers

Keir

Re: ath5k mesh in 2.6.28?

[Bob Copeland]

On Fri, Jan 23, 2009 at 8:30 AM, Keir <keirlawson@gmail.com> wrote:
> Hi,
>
> According to the 802.11s website it seems to claim that mesh
> networking is supported for ath5k devices in kernel 2.6.28, however,
> upon running ifconfig mesh0 up (having previously created the mesh
> device using iw) I get "SIOCSIFFLAGS: Operation not supported".

2.6.28 does not support mesh, at least from looking at the code,
ath5k_add_interface has:

    switch (conf->type) {
    case NL80211_IFTYPE_STATION:
    case NL80211_IFTYPE_ADHOC:
    case NL80211_IFTYPE_MONITOR:
        sc->opmode = conf->type;
        break;
    default:
        ret = -EOPNOTSUPP;
        goto end;
    }

It needs to at least also have NL80211_IFTYPE_MESH_POINT.

Mesh was enabled for 2.6.29 via b706e65b40417e03c2451bb3f92488f3736843fa,
so if you need it in 2.6.28 you can ask Greg to pick it up for stable.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k mesh in 2.6.28?

[Keir]

I would really like support in 2.6.28, but I don't want to
inconvenience anyone... who's Greg?  What I would really like is ath5k
mesh support in a stable kernel, the wireless-testing kernel I'm
currently using is too unstable for my testing.

Cheers

Keir

2009/1/23 Bob Copeland <me@bobcopeland.com>:
> On Fri, Jan 23, 2009 at 8:30 AM, Keir <keirlawson@gmail.com> wrote:
>> Hi,
>>
>> According to the 802.11s website it seems to claim that mesh
>> networking is supported for ath5k devices in kernel 2.6.28, however,
>> upon running ifconfig mesh0 up (having previously created the mesh
>> device using iw) I get "SIOCSIFFLAGS: Operation not supported".
>
> 2.6.28 does not support mesh, at least from looking at the code,
> ath5k_add_interface has:
>
>    switch (conf->type) {
>    case NL80211_IFTYPE_STATION:
>    case NL80211_IFTYPE_ADHOC:
>    case NL80211_IFTYPE_MONITOR:
>        sc->opmode = conf->type;
>        break;
>    default:
>        ret = -EOPNOTSUPP;
>        goto end;
>    }
>
> It needs to at least also have NL80211_IFTYPE_MESH_POINT.
>
> Mesh was enabled for 2.6.29 via b706e65b40417e03c2451bb3f92488f3736843fa,
> so if you need it in 2.6.28 you can ask Greg to pick it up for stable.
>
> --
> Bob Copeland %% www.bobcopeland.com
>

Re: ath5k mesh in 2.6.28?

[Bob Copeland]

> 2009/1/23 Bob Copeland <me@bobcopeland.com>:
> > On Fri, Jan 23, 2009 at 8:30 AM, Keir <keirlawson@gmail.com> wrote:
> >> Hi,
> >>
> >> According to the 802.11s website it seems to claim that mesh
> >> networking is supported for ath5k devices in kernel 2.6.28, however,
> >> upon running ifconfig mesh0 up (having previously created the mesh
> >> device using iw) I get "SIOCSIFFLAGS: Operation not supported".
[...]
> >
> > Mesh was enabled for 2.6.29 via b706e65b40417e03c2451bb3f92488f3736843fa,
> > so if you need it in 2.6.28 you can ask Greg to pick it up for stable.
>
> I would really like support in 2.6.28, but I don't want to
> inconvenience anyone... who's Greg?  What I would really like is ath5k
> mesh support in a stable kernel, the wireless-testing kernel I'm
> currently using is too unstable for my testing.

Your other option is to use compat-wireless with 2.6.28.  That might
be easier.  However, fixing mesh in 2.6.28 isn't a huge change and it
doesn't change any paths for any other opmode, so we might as well
ask...

Hi stable hackers,

Would you consider taking b706e65b40417e03c2451bb3f92488f3736843fa,
"ath5k: fix mesh point operation" for 2.6.28-stable?  It's a new feature 
compared to 2.6.27, so not a regression per se; however, ath5k advertises
mesh support in wiphy->interface_modes but doesn't make good on that 
promise when it comes to actually setting up such an interface.

Here's a rebased patch on top of 2.6.28:

>From 8569edccf7c900aecfaa32ccd4e84c56fb0460c4 Mon Sep 17 00:00:00 2001
From: Andrey Yurovsky <andrey@cozybit.com>
Date: Mon, 13 Oct 2008 18:23:07 -0700
Subject: [PATCH] ath5k: fix mesh point operation

This patch fixes mesh point operation (thanks to YanBo for pointing
out the problem): make mesh point interfaces start beaconing when
they come up and configure the RX filter in mesh mode so that mesh
beacons and action frames are received.  Add mesh point to the check
in ath5k_add_interface.  Tested with multiple AR5211 cards.

Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 drivers/net/wireless/ath5k/base.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index 2d14255..e521555 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -2157,7 +2157,8 @@ ath5k_beacon_config(struct ath5k_softc *sc)
 
 	if (sc->opmode == NL80211_IFTYPE_STATION) {
 		sc->imask |= AR5K_INT_BMISS;
-	} else if (sc->opmode == NL80211_IFTYPE_ADHOC) {
+	} else if (sc->opmode == NL80211_IFTYPE_ADHOC ||
+		   sc->opmode == NL80211_IFTYPE_MESH_POINT) {
 		/*
 		 * In IBSS mode we use a self-linked tx descriptor and let the
 		 * hardware send the beacons automatically. We have to load it
@@ -2748,6 +2749,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
 	switch (conf->type) {
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_ADHOC:
+	case NL80211_IFTYPE_MESH_POINT:
 	case NL80211_IFTYPE_MONITOR:
 		sc->opmode = conf->type;
 		break;
@@ -2819,7 +2821,8 @@ ath5k_config_interface(struct ieee80211_hw *hw, struct
ieee80211_vif *vif,
 	}
 
 	if (conf->changed & IEEE80211_IFCC_BEACON &&
-	    vif->type == NL80211_IFTYPE_ADHOC) {
+	    (vif->type == NL80211_IFTYPE_ADHOC ||
+	     vif->type == NL80211_IFTYPE_MESH_POINT)) {
 		struct sk_buff *beacon = ieee80211_beacon_get(hw, vif);
 		if (!beacon) {
 			ret = -ENOMEM;
@@ -2951,6 +2954,9 @@ static void ath5k_configure_filter(struct ieee80211_hw *hw,
 		sc->opmode == NL80211_IFTYPE_ADHOC) {
 		rfilt |= AR5K_RX_FILTER_BEACON;
 	}
+	if (sc->opmode == NL80211_IFTYPE_MESH_POINT)
+		rfilt |= AR5K_RX_FILTER_CONTROL | AR5K_RX_FILTER_BEACON |
+			AR5K_RX_FILTER_PROBEREQ | AR5K_RX_FILTER_PROM;
 
 	/* Set filters */
 	ath5k_hw_set_rx_filter(ah,rfilt);
-- 
1.6.0.6


-- 
Bob Copeland %% www.bobcopeland.com

Re: [stable] ath5k mesh in 2.6.28?

[Greg KH]

On Fri, Jan 23, 2009 at 11:26:15AM -0500, Bob Copeland wrote:
> Hi stable hackers,
> 
> Would you consider taking b706e65b40417e03c2451bb3f92488f3736843fa,
> "ath5k: fix mesh point operation" for 2.6.28-stable?  It's a new feature 
> compared to 2.6.27, so not a regression per se; however, ath5k advertises
> mesh support in wiphy->interface_modes but doesn't make good on that 
> promise when it comes to actually setting up such an interface.

Based on your patch, I don't have an objection to taking it for the next
2.6.28 release (will have to be after 2.6.28.2 comes out.)  I'll queue
it up for the next review cycle.

thanks,

greg k-h

Re: [stable] ath5k mesh in 2.6.28?

[Greg KH]

On Fri, Jan 23, 2009 at 11:26:15AM -0500, Bob Copeland wrote:
> > 2009/1/23 Bob Copeland <me@bobcopeland.com>:
> > > On Fri, Jan 23, 2009 at 8:30 AM, Keir <keirlawson@gmail.com> wrote:
> > >> Hi,
> > >>
> > >> According to the 802.11s website it seems to claim that mesh
> > >> networking is supported for ath5k devices in kernel 2.6.28, however,
> > >> upon running ifconfig mesh0 up (having previously created the mesh
> > >> device using iw) I get "SIOCSIFFLAGS: Operation not supported".
> [...]
> > >
> > > Mesh was enabled for 2.6.29 via b706e65b40417e03c2451bb3f92488f3736843fa,
> > > so if you need it in 2.6.28 you can ask Greg to pick it up for stable.
> >
> > I would really like support in 2.6.28, but I don't want to
> > inconvenience anyone... who's Greg?  What I would really like is ath5k
> > mesh support in a stable kernel, the wireless-testing kernel I'm
> > currently using is too unstable for my testing.
> 
> Your other option is to use compat-wireless with 2.6.28.  That might
> be easier.  However, fixing mesh in 2.6.28 isn't a huge change and it
> doesn't change any paths for any other opmode, so we might as well
> ask...
> 
> Hi stable hackers,
> 
> Would you consider taking b706e65b40417e03c2451bb3f92488f3736843fa,
> "ath5k: fix mesh point operation" for 2.6.28-stable?  It's a new feature 
> compared to 2.6.27, so not a regression per se; however, ath5k advertises
> mesh support in wiphy->interface_modes but doesn't make good on that 
> promise when it comes to actually setting up such an interface.
> 
> Here's a rebased patch on top of 2.6.28:
> 
> >From 8569edccf7c900aecfaa32ccd4e84c56fb0460c4 Mon Sep 17 00:00:00 2001
> From: Andrey Yurovsky <andrey@cozybit.com>
> Date: Mon, 13 Oct 2008 18:23:07 -0700
> Subject: [PATCH] ath5k: fix mesh point operation
> 
> This patch fixes mesh point operation (thanks to YanBo for pointing
> out the problem): make mesh point interfaces start beaconing when
> they come up and configure the RX filter in mesh mode so that mesh
> beacons and action frames are received.  Add mesh point to the check
> in ath5k_add_interface.  Tested with multiple AR5211 cards.
> 
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
> Acked-by: Nick Kossifidis <mickflemm@gmail.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>

Now queued up, thanks for the backport.

greg k-h

Re: ath5k mesh in 2.6.28?

[Andrey Yurovsky]

Sorry, looks like that's my mistake (I thought the patch had made it
in).  Greg -- thanks for queuing the patch.

For completeness, I should note that ath5k mesh is later broken by
"ath5k: Update PCU code" and fixed again (hopefully both in by
2.6.29!) by "ath5k: Correct usage of AR5K_CFG_ADHOC"

Greg and Keir -- I also suggest Brian's patch, "mac80211: decrement
ref count to netdev after launching mesh discovery", commit
05188d21d21dc8976bff13a9ca73a230eef86d40 for stable as it should apply
there and fixes a bug that will sometimes prevent module unload if a
mesh interface was active.

Thanks,

On Fri, Jan 23, 2009 at 7:17 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Fri, Jan 23, 2009 at 8:30 AM, Keir <keirlawson@gmail.com> wrote:
>> Hi,
>>
>> According to the 802.11s website it seems to claim that mesh
>> networking is supported for ath5k devices in kernel 2.6.28, however,
>> upon running ifconfig mesh0 up (having previously created the mesh
>> device using iw) I get "SIOCSIFFLAGS: Operation not supported".
>
> 2.6.28 does not support mesh, at least from looking at the code,
> ath5k_add_interface has:
>
>    switch (conf->type) {
>    case NL80211_IFTYPE_STATION:
>    case NL80211_IFTYPE_ADHOC:
>    case NL80211_IFTYPE_MONITOR:
>        sc->opmode = conf->type;
>        break;
>    default:
>        ret = -EOPNOTSUPP;
>        goto end;
>    }
>
> It needs to at least also have NL80211_IFTYPE_MESH_POINT.
>
> Mesh was enabled for 2.6.29 via b706e65b40417e03c2451bb3f92488f3736843fa,
> so if you need it in 2.6.28 you can ask Greg to pick it up for stable.
>
> --
> Bob Copeland %% www.bobcopeland.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ath5k mesh in 2.6.28?

[Greg KH]

On Fri, Jan 23, 2009 at 09:29:22AM -0800, Andrey Yurovsky wrote:
> Sorry, looks like that's my mistake (I thought the patch had made it
> in).  Greg -- thanks for queuing the patch.
> 
> For completeness, I should note that ath5k mesh is later broken by
> "ath5k: Update PCU code" and fixed again (hopefully both in by
> 2.6.29!) by "ath5k: Correct usage of AR5K_CFG_ADHOC"
> 
> Greg and Keir -- I also suggest Brian's patch, "mac80211: decrement
> ref count to netdev after launching mesh discovery", commit
> 05188d21d21dc8976bff13a9ca73a230eef86d40 for stable as it should apply
> there and fixes a bug that will sometimes prevent module unload if a
> mesh interface was active.

Which stable kernel should this be for, .27 or .28 or both?

thanks,

greg k-h

Re: ath5k mesh in 2.6.28?

[Andrey Yurovsky]

05188d21d21dc8976bff13a9ca73a230eef86d40 should apply to both .27 and
.28 and it's useful in both places as it fixes a general problem with
all Mesh Point interfaces and both kernels have Mesh Point support in
mac80211.

On Fri, Jan 23, 2009 at 9:40 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Jan 23, 2009 at 09:29:22AM -0800, Andrey Yurovsky wrote:
>> Sorry, looks like that's my mistake (I thought the patch had made it
>> in).  Greg -- thanks for queuing the patch.
>>
>> For completeness, I should note that ath5k mesh is later broken by
>> "ath5k: Update PCU code" and fixed again (hopefully both in by
>> 2.6.29!) by "ath5k: Correct usage of AR5K_CFG_ADHOC"
>>
>> Greg and Keir -- I also suggest Brian's patch, "mac80211: decrement
>> ref count to netdev after launching mesh discovery", commit
>> 05188d21d21dc8976bff13a9ca73a230eef86d40 for stable as it should apply
>> there and fixes a bug that will sometimes prevent module unload if a
>> mesh interface was active.
>
> Which stable kernel should this be for, .27 or .28 or both?
>
> thanks,
>
> greg k-h
>

Re: ath5k mesh in 2.6.28?

[Greg KH]

On Fri, Jan 23, 2009 at 09:29:22AM -0800, Andrey Yurovsky wrote:
> Sorry, looks like that's my mistake (I thought the patch had made it
> in).  Greg -- thanks for queuing the patch.
> 
> For completeness, I should note that ath5k mesh is later broken by
> "ath5k: Update PCU code" and fixed again (hopefully both in by
> 2.6.29!) by "ath5k: Correct usage of AR5K_CFG_ADHOC"
> 
> Greg and Keir -- I also suggest Brian's patch, "mac80211: decrement
> ref count to netdev after launching mesh discovery", commit
> 05188d21d21dc8976bff13a9ca73a230eef86d40 for stable as it should apply
> there and fixes a bug that will sometimes prevent module unload if a
> mesh interface was active.

I think you mean 5dc306f3bd1d4cfdf79df39221b3036eab1ddcf3 instead, there
is no 05188d21d21dc8976bff13a9ca73a230eef86d40 in Linus's tree :)

queued up,

greg k-h