Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/debugfs_sta.c | 3 +--
net/mac80211/sta_info.h | 2 --
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index a01d213..4a20722 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -59,7 +59,7 @@ static ssize_t sta_flags_read(struct file *file, char __user *userbuf,
char buf[100];
struct sta_info *sta = file->private_data;
u32 staflags = get_sta_flags(sta);
- int res = scnprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s%s%s",
+ int res = scnprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s%s",
staflags & WLAN_STA_AUTH ? "AUTH\n" : "",
staflags & WLAN_STA_ASSOC ? "ASSOC\n" : "",
staflags & WLAN_STA_PS_STA ? "PS (sta)\n" : "",
@@ -67,7 +67,6 @@ static ssize_t sta_flags_read(struct file *file, char __user *userbuf,
staflags & WLAN_STA_AUTHORIZED ? "AUTHORIZED\n" : "",
staflags & WLAN_STA_SHORT_PREAMBLE ? "SHORT PREAMBLE\n" : "",
staflags & WLAN_STA_WME ? "WME\n" : "",
- staflags & WLAN_STA_WDS ? "WDS\n" : "",
staflags & WLAN_STA_MFP ? "MFP\n" : "");
return simple_read_from_buffer(userbuf, count, ppos, buf, res);
}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index c6ae871..a5c231c 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -31,7 +31,6 @@
* frames.
* @WLAN_STA_ASSOC_AP: We're associated to that station, it is an AP.
* @WLAN_STA_WME: Station is a QoS-STA.
- * @WLAN_STA_WDS: Station is one of our WDS peers.
* @WLAN_STA_CLEAR_PS_FILT: Clear PS filter in hardware (using the
* IEEE80211_TX_CTL_CLEAR_PS_FILT control flag) when the next
* frame to this station is transmitted.
@@ -54,7 +53,6 @@ enum ieee80211_sta_info_flags {
WLAN_STA_SHORT_PREAMBLE = 1<<4,
WLAN_STA_ASSOC_AP = 1<<5,
WLAN_STA_WME = 1<<6,
- WLAN_STA_WDS = 1<<7,
WLAN_STA_CLEAR_PS_FILT = 1<<9,
WLAN_STA_MFP = 1<<10,
WLAN_STA_BLOCK_BA = 1<<11,
--
1.7.3.2
On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
> + rcu_read_lock();
> +
> + sta = sta_info_get(sdata, sdata->u.wds.remote_addr);
> +
> + if (!sta) {
> + rcu_read_unlock();
> + sta = sta_info_alloc(sdata, sdata->u.wds.remote_addr,
> + GFP_KERNEL);
> + if (!sta)
> + return;
> +
> + new = true;
> + }
...
> + rcu_read_unlock();
definitely doesn't look right.
johannes
On 2011-05-31 9:31 PM, Johannes Berg wrote:
> On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
>
>> + rcu_read_lock();
>> +
>> + sta = sta_info_get(sdata, sdata->u.wds.remote_addr);
>> +
>> + if (!sta) {
>> + rcu_read_unlock();
>> + sta = sta_info_alloc(sdata, sdata->u.wds.remote_addr,
>> + GFP_KERNEL);
>> + if (!sta)
>> + return;
>> +
>> + new = true;
>> + }
>
> ...
>
>> + rcu_read_unlock();
>
> definitely doesn't look right.
It's a bit weird because in the case of a new sta being allocated, the
rcu read lock is acquired by sta_info_insert_rcu, and the code inbetween
does not need to be covered by the rcu read lock as the sta entry has
not been added to the list yet.
It should be correct though, unless I'm missing something...
- Felix
On Tue, 2011-05-31 at 21:46 +0200, Felix Fietkau wrote:
> On 2011-05-31 9:31 PM, Johannes Berg wrote:
> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
> >
> >> + rcu_read_lock();
> >> +
> >> + sta = sta_info_get(sdata, sdata->u.wds.remote_addr);
> >> +
> >> + if (!sta) {
> >> + rcu_read_unlock();
> >> + sta = sta_info_alloc(sdata, sdata->u.wds.remote_addr,
> >> + GFP_KERNEL);
> >> + if (!sta)
> >> + return;
> >> +
> >> + new = true;
> >> + }
> >
> > ...
> >
> >> + rcu_read_unlock();
> >
> > definitely doesn't look right.
> It's a bit weird because in the case of a new sta being allocated, the
> rcu read lock is acquired by sta_info_insert_rcu, and the code inbetween
> does not need to be covered by the rcu read lock as the sta entry has
> not been added to the list yet.
> It should be correct though, unless I'm missing something...
Oh right, I forgot about that.
johannes
Adds support for aggregation
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/agg-rx.c | 2 ++
net/mac80211/agg-tx.c | 6 ++++--
net/mac80211/rx.c | 16 ++++++++++------
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 9c0d76c..0f83b37 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -161,6 +161,8 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *d
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+ else if (sdata->vif.type == NL80211_IFTYPE_WDS)
+ memcpy(mgmt->bssid, da, ETH_ALEN);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index cd5125f..7117108 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -79,7 +79,8 @@ static void ieee80211_send_addba_request(struct ieee80211_sub_if_data *sdata,
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_WDS)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
@@ -388,7 +389,8 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
*/
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
- sdata->vif.type != NL80211_IFTYPE_AP)
+ sdata->vif.type != NL80211_IFTYPE_AP &&
+ sdata->vif.type != NL80211_IFTYPE_WDS)
return -EINVAL;
if (test_sta_flags(sta, WLAN_STA_BLOCK_BA)) {
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 683a46b..33f1fb5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2137,7 +2137,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
*/
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
- sdata->vif.type != NL80211_IFTYPE_AP)
+ sdata->vif.type != NL80211_IFTYPE_AP &&
+ sdata->vif.type != NL80211_IFTYPE_WDS)
break;
/* verify action_code is present */
@@ -2681,13 +2682,16 @@ static int prepare_for_handlers(struct ieee80211_rx_data *rx,
}
break;
case NL80211_IFTYPE_WDS:
- if (bssid) {
- if (!ieee80211_is_beacon(hdr->frame_control))
- return 0;
- } else if (!ieee80211_is_data(hdr->frame_control))
- return 0;
if (compare_ether_addr(sdata->u.wds.remote_addr, hdr->addr2))
return 0;
+
+ if (ieee80211_is_data(hdr->frame_control) ||
+ ieee80211_is_action(hdr->frame_control)) {
+ if (compare_ether_addr(sdata->vif.addr, hdr->addr1))
+ return 0;
+ } else if (!ieee80211_is_beacon(hdr->frame_control))
+ return 0;
+
break;
default:
/* should never get here */
--
1.7.3.2
On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
> When a STA entry is created too early, a lot of essential information
> required for rate control is missing.
I don't understand how you can rely on beacons for WDS.
johannes
On Tue, 2011-05-31 at 21:39 +0200, Felix Fietkau wrote:
> On 2011-05-31 9:32 PM, Johannes Berg wrote:
> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
> >> When a STA entry is created too early, a lot of essential information
> >> required for rate control is missing.
> >
> > I don't understand how you can rely on beacons for WDS.
> You usually set up WDS links between APs on the same channel, each
> running both a normal AP vif and a WDS vif. The remote AP's beacons are
> then used to detect the capabilities of the peer.
I don't think we can rely on "usually" unless we also enforce that
somehow. Otherwise this link will basically be dead. There's nothing
that requires you to add WDS to an AP interface only after all.
johannes
When a STA entry is created too early, a lot of essential information
required for rate control is missing.
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/iface.c | 92 +++++++++++++++++++++++++++++++++++++-------------
net/mac80211/rx.c | 10 ++++--
2 files changed, 75 insertions(+), 27 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index dee30ae..3c6af71 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -178,7 +178,6 @@ static int ieee80211_do_open(struct net_device *dev, bool coming_up)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = sdata->local;
- struct sta_info *sta;
u32 changed = 0;
int res;
u32 hw_reconf_flags = 0;
@@ -290,27 +289,6 @@ static int ieee80211_do_open(struct net_device *dev, bool coming_up)
set_bit(SDATA_STATE_RUNNING, &sdata->state);
- if (sdata->vif.type == NL80211_IFTYPE_WDS) {
- /* Create STA entry for the WDS peer */
- sta = sta_info_alloc(sdata, sdata->u.wds.remote_addr,
- GFP_KERNEL);
- if (!sta) {
- res = -ENOMEM;
- goto err_del_interface;
- }
-
- /* no locking required since STA is not live yet */
- sta->flags |= WLAN_STA_AUTHORIZED;
-
- res = sta_info_insert(sta);
- if (res) {
- /* STA has been freed */
- goto err_del_interface;
- }
-
- rate_control_rate_init(sta);
- }
-
/*
* set_multicast_list will be invoked by the networking core
* which will check whether any increments here were done in
@@ -344,8 +322,7 @@ static int ieee80211_do_open(struct net_device *dev, bool coming_up)
netif_tx_start_all_queues(dev);
return 0;
- err_del_interface:
- drv_remove_interface(local, &sdata->vif);
+
err_stop:
if (!local->open_count)
drv_stop(local);
@@ -703,6 +680,70 @@ static void ieee80211_if_setup(struct net_device *dev)
dev->destructor = free_netdev;
}
+static void ieee80211_wds_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb)
+{
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_rx_status *rx_status;
+ struct ieee802_11_elems elems;
+ struct ieee80211_mgmt *mgmt;
+ struct sta_info *sta;
+ size_t baselen;
+ u32 rates = 0;
+ u16 stype;
+ bool new = false;
+ enum ieee80211_band band = local->hw.conf.channel->band;
+ struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band];
+
+ rx_status = IEEE80211_SKB_RXCB(skb);
+ mgmt = (struct ieee80211_mgmt *) skb->data;
+ stype = le16_to_cpu(mgmt->frame_control) & IEEE80211_FCTL_STYPE;
+
+ if (stype != IEEE80211_STYPE_BEACON)
+ return;
+
+ baselen = (u8 *) mgmt->u.probe_resp.variable - (u8 *) mgmt;
+ if (baselen > skb->len)
+ return;
+
+ ieee802_11_parse_elems(mgmt->u.probe_resp.variable,
+ skb->len - baselen, &elems);
+
+ rates = ieee80211_sta_get_rates(local, &elems, band);
+
+ rcu_read_lock();
+
+ sta = sta_info_get(sdata, sdata->u.wds.remote_addr);
+
+ if (!sta) {
+ rcu_read_unlock();
+ sta = sta_info_alloc(sdata, sdata->u.wds.remote_addr,
+ GFP_KERNEL);
+ if (!sta)
+ return;
+
+ new = true;
+ }
+
+ sta->last_rx = jiffies;
+ sta->sta.supp_rates[local->hw.conf.channel->band] = rates;
+
+ if (elems.ht_cap_elem)
+ ieee80211_ht_cap_ie_to_sta_ht_cap(sband,
+ elems.ht_cap_elem, &sta->sta.ht_cap);
+
+ if (elems.wmm_param)
+ set_sta_flags(sta, WLAN_STA_WME);
+
+ if (new) {
+ sta->flags = WLAN_STA_AUTHORIZED;
+ rate_control_rate_init(sta);
+ sta_info_insert_rcu(sta);
+ }
+
+ rcu_read_unlock();
+}
+
static void ieee80211_iface_work(struct work_struct *work)
{
struct ieee80211_sub_if_data *sdata =
@@ -807,6 +848,9 @@ static void ieee80211_iface_work(struct work_struct *work)
break;
ieee80211_mesh_rx_queued_mgmt(sdata, skb);
break;
+ case NL80211_IFTYPE_WDS:
+ ieee80211_wds_rx_queued_mgmt(sdata, skb);
+ break;
default:
WARN(1, "frame for unexpected interface type");
break;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 7fa8c6b..683a46b 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2335,13 +2335,14 @@ ieee80211_rx_h_mgmt(struct ieee80211_rx_data *rx)
if (!ieee80211_vif_is_mesh(&sdata->vif) &&
sdata->vif.type != NL80211_IFTYPE_ADHOC &&
- sdata->vif.type != NL80211_IFTYPE_STATION)
+ sdata->vif.type != NL80211_IFTYPE_STATION &&
+ sdata->vif.type != NL80211_IFTYPE_WDS)
return RX_DROP_MONITOR;
switch (stype) {
case cpu_to_le16(IEEE80211_STYPE_BEACON):
case cpu_to_le16(IEEE80211_STYPE_PROBE_RESP):
- /* process for all: mesh, mlme, ibss */
+ /* process for all: mesh, mlme, ibss, wds */
break;
case cpu_to_le16(IEEE80211_STYPE_DEAUTH):
case cpu_to_le16(IEEE80211_STYPE_DISASSOC):
@@ -2680,7 +2681,10 @@ static int prepare_for_handlers(struct ieee80211_rx_data *rx,
}
break;
case NL80211_IFTYPE_WDS:
- if (bssid || !ieee80211_is_data(hdr->frame_control))
+ if (bssid) {
+ if (!ieee80211_is_beacon(hdr->frame_control))
+ return 0;
+ } else if (!ieee80211_is_data(hdr->frame_control))
return 0;
if (compare_ether_addr(sdata->u.wds.remote_addr, hdr->addr2))
return 0;
--
1.7.3.2
On 2011-05-31 9:32 PM, Johannes Berg wrote:
> On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
>> When a STA entry is created too early, a lot of essential information
>> required for rate control is missing.
>
> I don't understand how you can rely on beacons for WDS.
You usually set up WDS links between APs on the same channel, each
running both a normal AP vif and a WDS vif. The remote AP's beacons are
then used to detect the capabilities of the peer.
- Felix
On 2011-05-31 10:06 PM, Johannes Berg wrote:
> On Tue, 2011-05-31 at 21:39 +0200, Felix Fietkau wrote:
>> On 2011-05-31 9:32 PM, Johannes Berg wrote:
>> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
>> >> When a STA entry is created too early, a lot of essential information
>> >> required for rate control is missing.
>> >
>> > I don't understand how you can rely on beacons for WDS.
>> You usually set up WDS links between APs on the same channel, each
>> running both a normal AP vif and a WDS vif. The remote AP's beacons are
>> then used to detect the capabilities of the peer.
>
> I don't think we can rely on "usually" unless we also enforce that
> somehow. Otherwise this link will basically be dead. There's nothing
> that requires you to add WDS to an AP interface only after all.
I don't think using WDS without APs makes any sense. Since WDS alone
does not use beacons or probe requests, there's nothing else that would
ensure that rate information, HT capabilities, etc. get exchanged.
- Felix
On 2011-06-01 1:02 PM, Johannes Berg wrote:
> On Wed, 2011-06-01 at 12:53 +0200, Felix Fietkau wrote:
>> On 2011-06-01 6:17 AM, Johannes Berg wrote:
>> > On Tue, 2011-05-31 at 22:22 +0200, Felix Fietkau wrote:
>> >> On 2011-05-31 10:06 PM, Johannes Berg wrote:
>> >> > On Tue, 2011-05-31 at 21:39 +0200, Felix Fietkau wrote:
>> >> >> On 2011-05-31 9:32 PM, Johannes Berg wrote:
>> >> >> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
>> >> >> >> When a STA entry is created too early, a lot of essential information
>> >> >> >> required for rate control is missing.
>> >> >> >
>> >> >> > I don't understand how you can rely on beacons for WDS.
>> >> >> You usually set up WDS links between APs on the same channel, each
>> >> >> running both a normal AP vif and a WDS vif. The remote AP's beacons are
>> >> >> then used to detect the capabilities of the peer.
>> >> >
>> >> > I don't think we can rely on "usually" unless we also enforce that
>> >> > somehow. Otherwise this link will basically be dead. There's nothing
>> >> > that requires you to add WDS to an AP interface only after all.
>> >> I don't think using WDS without APs makes any sense. Since WDS alone
>> >> does not use beacons or probe requests, there's nothing else that would
>> >> ensure that rate information, HT capabilities, etc. get exchanged.
>> >
>> > I just don't like the fact that you can create a non-functional WDS
>> > interface by adding it when there's no AP interface.
>
>> Actually, I just noticed that ieee80211_assign_perm_addr forces you to
>> use the MAC address of an existing AP interface for a WDS interface,
>> same as for an AP VLAN interface. So the requirement to also have an AP
>> mode interface is not new.
>
> No, it just uses that since it can use the same address -- there's no
> requirement anywhere that the AP must exist.
Oh, right. I'll send a follow-up patch that forces a WDS to also have an
active AP interface before it's brought up.
- Felix
On Wed, 2011-06-01 at 12:53 +0200, Felix Fietkau wrote:
> On 2011-06-01 6:17 AM, Johannes Berg wrote:
> > On Tue, 2011-05-31 at 22:22 +0200, Felix Fietkau wrote:
> >> On 2011-05-31 10:06 PM, Johannes Berg wrote:
> >> > On Tue, 2011-05-31 at 21:39 +0200, Felix Fietkau wrote:
> >> >> On 2011-05-31 9:32 PM, Johannes Berg wrote:
> >> >> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
> >> >> >> When a STA entry is created too early, a lot of essential information
> >> >> >> required for rate control is missing.
> >> >> >
> >> >> > I don't understand how you can rely on beacons for WDS.
> >> >> You usually set up WDS links between APs on the same channel, each
> >> >> running both a normal AP vif and a WDS vif. The remote AP's beacons are
> >> >> then used to detect the capabilities of the peer.
> >> >
> >> > I don't think we can rely on "usually" unless we also enforce that
> >> > somehow. Otherwise this link will basically be dead. There's nothing
> >> > that requires you to add WDS to an AP interface only after all.
> >> I don't think using WDS without APs makes any sense. Since WDS alone
> >> does not use beacons or probe requests, there's nothing else that would
> >> ensure that rate information, HT capabilities, etc. get exchanged.
> >
> > I just don't like the fact that you can create a non-functional WDS
> > interface by adding it when there's no AP interface.
> Actually, I just noticed that ieee80211_assign_perm_addr forces you to
> use the MAC address of an existing AP interface for a WDS interface,
> same as for an AP VLAN interface. So the requirement to also have an AP
> mode interface is not new.
No, it just uses that since it can use the same address -- there's no
requirement anywhere that the AP must exist.
johannes
On Wed, 2011-06-01 at 13:18 +0200, Felix Fietkau wrote:
> >> >> >> > I don't understand how you can rely on beacons for WDS.
> Oh, right. I'll send a follow-up patch that forces a WDS to also have an
> active AP interface before it's brought up.
Hm, that might be sufficient, but what if the peer isn't sending
beacons?
Can't we add a station entry and then update it if we receive
information from the peer? That'd be more compatible with others devices
that don't necessarily have beacons with WDS, and then we wouldn't have
to require it locally either (since realistically we might have to
interoperate with those anyway?)
johannes
On 2011-06-01 6:17 AM, Johannes Berg wrote:
> On Tue, 2011-05-31 at 22:22 +0200, Felix Fietkau wrote:
>> On 2011-05-31 10:06 PM, Johannes Berg wrote:
>> > On Tue, 2011-05-31 at 21:39 +0200, Felix Fietkau wrote:
>> >> On 2011-05-31 9:32 PM, Johannes Berg wrote:
>> >> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
>> >> >> When a STA entry is created too early, a lot of essential information
>> >> >> required for rate control is missing.
>> >> >
>> >> > I don't understand how you can rely on beacons for WDS.
>> >> You usually set up WDS links between APs on the same channel, each
>> >> running both a normal AP vif and a WDS vif. The remote AP's beacons are
>> >> then used to detect the capabilities of the peer.
>> >
>> > I don't think we can rely on "usually" unless we also enforce that
>> > somehow. Otherwise this link will basically be dead. There's nothing
>> > that requires you to add WDS to an AP interface only after all.
>> I don't think using WDS without APs makes any sense. Since WDS alone
>> does not use beacons or probe requests, there's nothing else that would
>> ensure that rate information, HT capabilities, etc. get exchanged.
>
> I just don't like the fact that you can create a non-functional WDS
> interface by adding it when there's no AP interface.
Actually, I just noticed that ieee80211_assign_perm_addr forces you to
use the MAC address of an existing AP interface for a WDS interface,
same as for an AP VLAN interface. So the requirement to also have an AP
mode interface is not new.
- Felix
On Wed, 2011-06-01 at 13:41 +0200, Felix Fietkau wrote:
> On 2011-06-01 1:30 PM, Johannes Berg wrote:
> > On Wed, 2011-06-01 at 13:18 +0200, Felix Fietkau wrote:
> >
> >> >> >> >> > I don't understand how you can rely on beacons for WDS.
> >
> >> Oh, right. I'll send a follow-up patch that forces a WDS to also have an
> >> active AP interface before it's brought up.
> >
> > Hm, that might be sufficient, but what if the peer isn't sending
> > beacons?
> >
> > Can't we add a station entry and then update it if we receive
> > information from the peer? That'd be more compatible with others devices
> > that don't necessarily have beacons with WDS, and then we wouldn't have
> > to require it locally either (since realistically we might have to
> > interoperate with those anyway?)
> What other devices use WDS without beacons? So far I haven't seen any.
I don't know, at least older mac80211 could do that?
johannes
On 2011-06-01 2:26 PM, Johannes Berg wrote:
> On Wed, 2011-06-01 at 13:41 +0200, Felix Fietkau wrote:
>> On 2011-06-01 1:30 PM, Johannes Berg wrote:
>> > On Wed, 2011-06-01 at 13:18 +0200, Felix Fietkau wrote:
>> >
>> >> >> >> >> > I don't understand how you can rely on beacons for WDS.
>> >
>> >> Oh, right. I'll send a follow-up patch that forces a WDS to also have an
>> >> active AP interface before it's brought up.
>> >
>> > Hm, that might be sufficient, but what if the peer isn't sending
>> > beacons?
>> >
>> > Can't we add a station entry and then update it if we receive
>> > information from the peer? That'd be more compatible with others devices
>> > that don't necessarily have beacons with WDS, and then we wouldn't have
>> > to require it locally either (since realistically we might have to
>> > interoperate with those anyway?)
>> What other devices use WDS without beacons? So far I haven't seen any.
>
> I don't know, at least older mac80211 could do that?
In older mac80211 (at least the versions that I tested), WDS was
completely broken. It also created the station entry without any valid
rates, and it had no means of updating the supported rates list.
- Felix
On Tue, 2011-05-31 at 22:22 +0200, Felix Fietkau wrote:
> On 2011-05-31 10:06 PM, Johannes Berg wrote:
> > On Tue, 2011-05-31 at 21:39 +0200, Felix Fietkau wrote:
> >> On 2011-05-31 9:32 PM, Johannes Berg wrote:
> >> > On Tue, 2011-05-31 at 21:16 +0200, Felix Fietkau wrote:
> >> >> When a STA entry is created too early, a lot of essential information
> >> >> required for rate control is missing.
> >> >
> >> > I don't understand how you can rely on beacons for WDS.
> >> You usually set up WDS links between APs on the same channel, each
> >> running both a normal AP vif and a WDS vif. The remote AP's beacons are
> >> then used to detect the capabilities of the peer.
> >
> > I don't think we can rely on "usually" unless we also enforce that
> > somehow. Otherwise this link will basically be dead. There's nothing
> > that requires you to add WDS to an AP interface only after all.
> I don't think using WDS without APs makes any sense. Since WDS alone
> does not use beacons or probe requests, there's nothing else that would
> ensure that rate information, HT capabilities, etc. get exchanged.
I just don't like the fact that you can create a non-functional WDS
interface by adding it when there's no AP interface.
johannes
On 2011-06-01 1:30 PM, Johannes Berg wrote:
> On Wed, 2011-06-01 at 13:18 +0200, Felix Fietkau wrote:
>
>> >> >> >> > I don't understand how you can rely on beacons for WDS.
>
>> Oh, right. I'll send a follow-up patch that forces a WDS to also have an
>> active AP interface before it's brought up.
>
> Hm, that might be sufficient, but what if the peer isn't sending
> beacons?
>
> Can't we add a station entry and then update it if we receive
> information from the peer? That'd be more compatible with others devices
> that don't necessarily have beacons with WDS, and then we wouldn't have
> to require it locally either (since realistically we might have to
> interoperate with those anyway?)
What other devices use WDS without beacons? So far I haven't seen any.
- Felix
On Wed, Jun 01, 2011 at 02:48:51PM +0200, Felix Fietkau wrote:
> On 2011-06-01 2:26 PM, Johannes Berg wrote:
> >On Wed, 2011-06-01 at 13:41 +0200, Felix Fietkau wrote:
> >> On 2011-06-01 1:30 PM, Johannes Berg wrote:
> >> > On Wed, 2011-06-01 at 13:18 +0200, Felix Fietkau wrote:
> >> >
> >> >> >> >> >> > I don't understand how you can rely on beacons for WDS.
> >> >
> >> >> Oh, right. I'll send a follow-up patch that forces a WDS to also have an
> >> >> active AP interface before it's brought up.
> >> >
> >> > Hm, that might be sufficient, but what if the peer isn't sending
> >> > beacons?
> >> >
> >> > Can't we add a station entry and then update it if we receive
> >> > information from the peer? That'd be more compatible with others devices
> >> > that don't necessarily have beacons with WDS, and then we wouldn't have
> >> > to require it locally either (since realistically we might have to
> >> > interoperate with those anyway?)
> >> What other devices use WDS without beacons? So far I haven't seen any.
> >
> >I don't know, at least older mac80211 could do that?
> In older mac80211 (at least the versions that I tested), WDS was
> completely broken. It also created the station entry without any
> valid rates, and it had no means of updating the supported rates
> list.
Is this settled? Do we want these patches?
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.