In testing this, the command "iw mesh0 mesh leave" doesn't stop
beaconing. Beaconing continues with a null mesh id.
Is this the intended behavior?
Steve
iw version 0.9.21-35-gba292ae
wireless-testing at commit 315f05c479f8e98e2df0e23a1bc0829b7e374fe9
On Wed, 2011-01-12 at 05:28 -0500, Steve Brown wrote:
> On Wed, 2011-01-12 at 10:03 +0100, Johannes Berg wrote:
> > On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> > > In testing this, the command "iw mesh0 mesh leave" doesn't stop
> > > beaconing. Beaconing continues with a null mesh id.
> > >
> > > Is this the intended behavior?
> >
> > No, it's not -- what driver are you using?
> >
> > johannes
> >
> ath9k with adapter AR9160 802.11abgn Wireless PCI Adapter (168c:2082)
No idea then, it looks like ath9k correctly handles
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED); so
you should look at what's happening around there.
johannes
On Wed, 2011-01-12 at 06:09 -0500, Steve Brown wrote:
> > Of course maybe mac80211 should be doings omething like this too:
> >
> > johannes
> >
> > --- wireless-testing.orig/net/mac80211/tx.c 2011-01-12 11:44:52.000000000 +0100
> > +++ wireless-testing/net/mac80211/tx.c 2011-01-12 11:45:52.000000000 +0100
> > @@ -2299,6 +2299,11 @@ struct sk_buff *ieee80211_beacon_get_tim
> > struct ieee80211_mgmt *mgmt;
> > u8 *pos;
> >
> > +#ifdef CONFIG_MAC80211_MESH
> > + if (!sdata->u.mesh.mesh_id_len)
> > + goto out;
> > +#endif
> > +
> > /* headroom, head length, tail length and maximum TIM length */
> > skb = dev_alloc_skb(local->tx_headroom + 400 +
> > sdata->u.mesh.vendor_ie_len);
> >
> >
> With the patch, leave/join stop and restart beaconing.
Yeah but evidently ath9k isn't cleanly stopping beaconing, it's still
attempting to beacon but doesn't get a beacon from mac80211 so can't
send one.
johannes
On Wed, 2011-01-12 at 10:03 +0100, Johannes Berg wrote:
> On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> > In testing this, the command "iw mesh0 mesh leave" doesn't stop
> > beaconing. Beaconing continues with a null mesh id.
> >
> > Is this the intended behavior?
>
> No, it's not -- what driver are you using?
>
> johannes
>
The ath5k driver behaves differently. On "leave" it stops beaconing and
on "join", starts back up.
Steve
On Wed, 2011-01-12 at 10:03 +0100, Johannes Berg wrote:
> On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> > In testing this, the command "iw mesh0 mesh leave" doesn't stop
> > beaconing. Beaconing continues with a null mesh id.
> >
> > Is this the intended behavior?
>
> No, it's not -- what driver are you using?
>
> johannes
>
ath9k with adapter AR9160 802.11abgn Wireless PCI Adapter (168c:2082)
Steve
On Wed, 2011-01-12 at 11:46 +0100, Johannes Berg wrote:
> On Wed, 2011-01-12 at 05:28 -0500, Steve Brown wrote:
> > On Wed, 2011-01-12 at 10:03 +0100, Johannes Berg wrote:
> > > On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> > > > In testing this, the command "iw mesh0 mesh leave" doesn't stop
> > > > beaconing. Beaconing continues with a null mesh id.
> > > >
> > > > Is this the intended behavior?
> > >
> > > No, it's not -- what driver are you using?
>
> Of course maybe mac80211 should be doings omething like this too:
>
> johannes
>
> --- wireless-testing.orig/net/mac80211/tx.c 2011-01-12 11:44:52.000000000 +0100
> +++ wireless-testing/net/mac80211/tx.c 2011-01-12 11:45:52.000000000 +0100
> @@ -2299,6 +2299,11 @@ struct sk_buff *ieee80211_beacon_get_tim
> struct ieee80211_mgmt *mgmt;
> u8 *pos;
>
> +#ifdef CONFIG_MAC80211_MESH
> + if (!sdata->u.mesh.mesh_id_len)
> + goto out;
> +#endif
> +
> /* headroom, head length, tail length and maximum TIM length */
> skb = dev_alloc_skb(local->tx_headroom + 400 +
> sdata->u.mesh.vendor_ie_len);
>
>
With the patch, leave/join stop and restart beaconing.
Thanks,
Steve
On Wed, 2011-01-12 at 05:28 -0500, Steve Brown wrote:
> On Wed, 2011-01-12 at 10:03 +0100, Johannes Berg wrote:
> > On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> > > In testing this, the command "iw mesh0 mesh leave" doesn't stop
> > > beaconing. Beaconing continues with a null mesh id.
> > >
> > > Is this the intended behavior?
> >
> > No, it's not -- what driver are you using?
Of course maybe mac80211 should be doings omething like this too:
johannes
--- wireless-testing.orig/net/mac80211/tx.c 2011-01-12 11:44:52.000000000 +0100
+++ wireless-testing/net/mac80211/tx.c 2011-01-12 11:45:52.000000000 +0100
@@ -2299,6 +2299,11 @@ struct sk_buff *ieee80211_beacon_get_tim
struct ieee80211_mgmt *mgmt;
u8 *pos;
+#ifdef CONFIG_MAC80211_MESH
+ if (!sdata->u.mesh.mesh_id_len)
+ goto out;
+#endif
+
/* headroom, head length, tail length and maximum TIM length */
skb = dev_alloc_skb(local->tx_headroom + 400 +
sdata->u.mesh.vendor_ie_len);
On Wed, Jan 12, 2011 at 12:12:48PM +0100, Johannes Berg wrote:
> > > Of course maybe mac80211 should be doings omething like this too:
> > > @@ -2299,6 +2299,11 @@ struct sk_buff *ieee80211_beacon_get_tim
> > > +#ifdef CONFIG_MAC80211_MESH
> > > + if (!sdata->u.mesh.mesh_id_len)
> > > + goto out;
> > > +#endif
> Yeah but evidently ath9k isn't cleanly stopping beaconing, it's still
> attempting to beacon but doesn't get a beacon from mac80211 so can't
> send one.
Sounds like SWBA interrupt should be disabled or at least masked in some
cases when mac80211 indicates some kind of change. I have not looked at
details on what exactly is missing from ath9k. Anyway, yes, it would be
good to make ieee80211_beacon_get_tim() return NULL when mac80211 does
not want any Beacon frames to be transmitted.
--
Jouni Malinen PGP id EFC895FA
On Tue, 2011-01-11 at 16:20 -0500, Steve Brown wrote:
> In testing this, the command "iw mesh0 mesh leave" doesn't stop
> beaconing. Beaconing continues with a null mesh id.
>
> Is this the intended behavior?
No, it's not -- what driver are you using?
johannes