Commit b2a151a288 added a check that prevents adding or deleting
stations on non-AP interfaces. Adding and deleting stations is
supported for Mesh Point interfaces, so add Mesh Point to that check as
well.
Signed-off-by: Andrey Yurovsky <[email protected]>
---
net/wireless/nl80211.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e18856c..b28c641 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1763,7 +1763,8 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
goto out_rtnl;
if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
- dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN) {
+ dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN &&
+ dev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
err = -EINVAL;
goto out;
}
@@ -1812,7 +1813,8 @@ static int nl80211_del_station(struct sk_buff *skb, struct genl_info *info)
goto out_rtnl;
if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
- dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN) {
+ dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN &&
+ dev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
err = -EINVAL;
goto out;
}
--
1.5.6.3
Johannes,
On Tue, Jun 16, 2009 at 12:37 PM, Johannes
Berg<[email protected]> wrote:
> On Tue, 2009-06-16 at 12:32 -0700, Javier Cardona wrote:
>
>> There are some mesh parameters that you would probably want to be
>> uniform across the mesh network (timeouts, number of retries, etc).
>> But the only mesh parameter that would result in a different mesh
>> network is the mesh_id, and that's only settable when the mesh
>> interface is created.
>>
>> Do you have a specific configuration parameter in mind?
>
> No, I don't have any in mind. I wasn't aware that only the mesh_id
> defines the mesh, I was under the impression that more needs to match,
> as codified in mesh_matches_local().
In addition to the mesh id, a successful peering requires that peer
candidates use the same methods for path selection, congestion
control, synchronization and authentication. None of these are
configurable via iw (essentially because only one single option for
each method is implemented).
Cheers,
Javier
On Tue, 2009-06-16 at 11:31 -0700, Andrey Yurovsky wrote:
> Commit b2a151a288 added a check that prevents adding or deleting
> stations on non-AP interfaces. Adding and deleting stations is
> supported for Mesh Point interfaces, so add Mesh Point to that check as
> well.
Why? Aren't those automatically discovered like IBSS peers?
johannes
> Signed-off-by: Andrey Yurovsky <[email protected]>
> ---
> net/wireless/nl80211.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index e18856c..b28c641 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -1763,7 +1763,8 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
> goto out_rtnl;
>
> if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
> - dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN) {
> + dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN &&
> + dev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
> err = -EINVAL;
> goto out;
> }
> @@ -1812,7 +1813,8 @@ static int nl80211_del_station(struct sk_buff *skb, struct genl_info *info)
> goto out_rtnl;
>
> if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
> - dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN) {
> + dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN &&
> + dev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
> err = -EINVAL;
> goto out;
> }
On Tue, Jun 16, 2009 at 11:45 AM, Johannes
Berg<[email protected]> wrote:
> On Tue, 2009-06-16 at 11:42 -0700, Andrey Yurovsky wrote:
>> On Tue, Jun 16, 2009 at 11:35 AM, Johannes
>> Berg<[email protected]> wrote:
>> > On Tue, 2009-06-16 at 11:31 -0700, Andrey Yurovsky wrote:
>> >> Commit b2a151a288 added a check that prevents adding or deleting
>> >> stations on non-AP interfaces. ?Adding and deleting stations is
>> >> supported for Mesh Point interfaces, so add Mesh Point to that check as
>> >> well.
>> >
>> > Why? Aren't those automatically discovered like IBSS peers?
>>
>> Yes, they normally are, however it's possible to turn that off from
>> user space (via iw).
>>
>> The reason for this is that it's useful to manually create mesh
>> topologies. ?This is mostly for testing, verification, and
>> experimentation. ?For example, you can manually create a topology
>> where you have two paths and you know one path is better than another
>> and then run a test script that verifies that the right path was
>> taken. ?It could presumably also be used by some user-space "mesh
>> manager" similar to hostapd for APs.
>
> Ok, fair enough. There are a lot of quirks in the mesh API, one of these
> days I'd like to make it less like wext and have you join/leave like the
> ibss commands instead of setting each parameter one by one...
Thanks. We'd like to hear about any quirks/issues as we have some
bandwidth to work on mesh again and we would like to address the
configuration/API issues.
-Andrey
On Tue, 2009-06-16 at 11:55 -0700, Andrey Yurovsky wrote:
> > Ok, fair enough. There are a lot of quirks in the mesh API, one of these
> > days I'd like to make it less like wext and have you join/leave like the
> > ibss commands instead of setting each parameter one by one...
>
> Thanks. We'd like to hear about any quirks/issues as we have some
> bandwidth to work on mesh again and we would like to address the
> configuration/API issues.
Well mostly it's the thing with configuration parameters affecting the
interface "on the fly". But I'm not familiar enough with all of the
parameters to actually know which ones _can_ change on the fly, and
which ones change and thereby make you part of a different mesh.
johannes
On Tue, 2009-06-16 at 12:51 -0700, Javier Cardona wrote:
> > No, I don't have any in mind. I wasn't aware that only the mesh_id
> > defines the mesh, I was under the impression that more needs to match,
> > as codified in mesh_matches_local().
>
> In addition to the mesh id, a successful peering requires that peer
> candidates use the same methods for path selection, congestion
> control, synchronization and authentication. None of these are
> configurable via iw (essentially because only one single option for
> each method is implemented).
Ahh! Ok, goes to show how little I understand the mesh code. IIRC
somebody had a patch to make those configurable though. I guess as long
as those need to be configured while creating the interface the API is
actually very good and much better than I thought :)
johannes
On Tue, Jun 16, 2009 at 11:35 AM, Johannes
Berg<[email protected]> wrote:
> On Tue, 2009-06-16 at 11:31 -0700, Andrey Yurovsky wrote:
>> Commit b2a151a288 added a check that prevents adding or deleting
>> stations on non-AP interfaces. ?Adding and deleting stations is
>> supported for Mesh Point interfaces, so add Mesh Point to that check as
>> well.
>
> Why? Aren't those automatically discovered like IBSS peers?
Yes, they normally are, however it's possible to turn that off from
user space (via iw).
The reason for this is that it's useful to manually create mesh
topologies. This is mostly for testing, verification, and
experimentation. For example, you can manually create a topology
where you have two paths and you know one path is better than another
and then run a test script that verifies that the right path was
taken. It could presumably also be used by some user-space "mesh
manager" similar to hostapd for APs.
-Andrey
>> Signed-off-by: Andrey Yurovsky <[email protected]>
>> ---
>> ?net/wireless/nl80211.c | ? ?6 ++++--
>> ?1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>> index e18856c..b28c641 100644
>> --- a/net/wireless/nl80211.c
>> +++ b/net/wireless/nl80211.c
>> @@ -1763,7 +1763,8 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
>> ? ? ? ? ? ? ? goto out_rtnl;
>>
>> ? ? ? if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
>> - ? ? ? ? dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN) {
>> + ? ? ? ? dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN &&
>> + ? ? ? ? dev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
>> ? ? ? ? ? ? ? err = -EINVAL;
>> ? ? ? ? ? ? ? goto out;
>> ? ? ? }
>> @@ -1812,7 +1813,8 @@ static int nl80211_del_station(struct sk_buff *skb, struct genl_info *info)
>> ? ? ? ? ? ? ? goto out_rtnl;
>>
>> ? ? ? if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
>> - ? ? ? ? dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN) {
>> + ? ? ? ? dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP_VLAN &&
>> + ? ? ? ? dev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
>> ? ? ? ? ? ? ? err = -EINVAL;
>> ? ? ? ? ? ? ? goto out;
>> ? ? ? }
>
Johannes,
On Tue, Jun 16, 2009 at 11:56 AM, Johannes
Berg<[email protected]> wrote:
> On Tue, 2009-06-16 at 11:55 -0700, Andrey Yurovsky wrote:
>
>> > Ok, fair enough. There are a lot of quirks in the mesh API, one of these
>> > days I'd like to make it less like wext and have you join/leave like the
>> > ibss commands instead of setting each parameter one by one...
>>
>> Thanks. ?We'd like to hear about any quirks/issues as we have some
>> bandwidth to work on mesh again and we would like to address the
>> configuration/API issues.
>
> Well mostly it's the thing with configuration parameters affecting the
> interface "on the fly". But I'm not familiar enough with all of the
> parameters to actually know which ones _can_ change on the fly, and
> which ones change and thereby make you part of a different mesh.
There are some mesh parameters that you would probably want to be
uniform across the mesh network (timeouts, number of retries, etc).
But the only mesh parameter that would result in a different mesh
network is the mesh_id, and that's only settable when the mesh
interface is created.
Do you have a specific configuration parameter in mind?
Cheers,
Javier
On Tue, 2009-06-16 at 12:32 -0700, Javier Cardona wrote:
> There are some mesh parameters that you would probably want to be
> uniform across the mesh network (timeouts, number of retries, etc).
> But the only mesh parameter that would result in a different mesh
> network is the mesh_id, and that's only settable when the mesh
> interface is created.
>
> Do you have a specific configuration parameter in mind?
No, I don't have any in mind. I wasn't aware that only the mesh_id
defines the mesh, I was under the impression that more needs to match,
as codified in mesh_matches_local().
johannes
On Tue, 2009-06-16 at 11:42 -0700, Andrey Yurovsky wrote:
> On Tue, Jun 16, 2009 at 11:35 AM, Johannes
> Berg<[email protected]> wrote:
> > On Tue, 2009-06-16 at 11:31 -0700, Andrey Yurovsky wrote:
> >> Commit b2a151a288 added a check that prevents adding or deleting
> >> stations on non-AP interfaces. Adding and deleting stations is
> >> supported for Mesh Point interfaces, so add Mesh Point to that check as
> >> well.
> >
> > Why? Aren't those automatically discovered like IBSS peers?
>
> Yes, they normally are, however it's possible to turn that off from
> user space (via iw).
>
> The reason for this is that it's useful to manually create mesh
> topologies. This is mostly for testing, verification, and
> experimentation. For example, you can manually create a topology
> where you have two paths and you know one path is better than another
> and then run a test script that verifies that the right path was
> taken. It could presumably also be used by some user-space "mesh
> manager" similar to hostapd for APs.
Ok, fair enough. There are a lot of quirks in the mesh API, one of these
days I'd like to make it less like wext and have you join/leave like the
ibss commands instead of setting each parameter one by one...
johannes