* [PATCH 0/3] mesh support for ath10k
@ 2015-08-27 10:57 Bob Copeland
2015-08-27 10:57 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Bob Copeland @ 2015-08-27 10:57 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Bob Copeland
Hello,
This was previously sent to ath10k ML, now adding linux-wireless for
wider review. Patch 3 gained a minor change since then to check for
raw mode feature flag from the firmware.
This patchset implements mesh support on ath10k. There aren't many
changes required to the driver, now that most of the required raw-mode
support is upstream.
I've tested VHT multihop on openwrt with the appropriate patches
backported.
Regarding performance: I currently get about 75 Mbps with udp iperf
due to small aggregates, which leaves a lot to be desired. Some users,
however, have reported 300+ Mbps [1], so this is potentially solvable.
[1] http://thread.gmane.org/gmane.linux.drivers.mesh.open80211s/3963
Bob Copeland (3):
ath10k: enable monitor when OTHER_BSS requested
ath10k: check for encryption before adding MIC_LEN
ath10k: implement mesh support
drivers/net/wireless/ath/ath10k/core.c | 6 ++++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 3 ++-
drivers/net/wireless/ath/ath10k/mac.c | 34 +++++++++++++++++++++++++++-----
3 files changed, 37 insertions(+), 6 deletions(-)
--
2.1.4
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested 2015-08-27 10:57 [PATCH 0/3] mesh support for ath10k Bob Copeland @ 2015-08-27 10:57 ` Bob Copeland 2015-08-27 10:57 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland 2015-08-27 10:57 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland 2 siblings, 0 replies; 19+ messages in thread From: Bob Copeland @ 2015-08-27 10:57 UTC (permalink / raw) To: linux-wireless; +Cc: ath10k, Bob Copeland By default, ath10k restricts received frames to those matching BSSID. When other BSS frames are requested (e.g. in mesh mode), add an internal monitor device so those frames are not filtered. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- drivers/net/wireless/ath/ath10k/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 64674c9..7dfe37f 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -1070,6 +1070,7 @@ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar) return false; return ar->monitor || + ar->filter_flags & FIF_OTHER_BSS || test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags); } -- 2.1.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN 2015-08-27 10:57 [PATCH 0/3] mesh support for ath10k Bob Copeland 2015-08-27 10:57 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland @ 2015-08-27 10:57 ` Bob Copeland 2015-08-27 10:57 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland 2 siblings, 0 replies; 19+ messages in thread From: Bob Copeland @ 2015-08-27 10:57 UTC (permalink / raw) To: linux-wireless; +Cc: ath10k, Bob Copeland In the case of raw mode without nohwcrypt parameter, we should still make sure the frame is protected before adding MIC_LEN to avoid skb_under_panic errors. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- drivers/net/wireless/ath/ath10k/htt_tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c index 43aa5e2..1c2d869 100644 --- a/drivers/net/wireless/ath/ath10k/htt_tx.c +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c @@ -528,7 +528,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu) ieee80211_has_protected(hdr->frame_control)) { skb_put(msdu, IEEE80211_CCMP_MIC_LEN); } else if (!skb_cb->htt.nohwcrypt && - skb_cb->txmode == ATH10K_HW_TXRX_RAW) { + skb_cb->txmode == ATH10K_HW_TXRX_RAW && + ieee80211_has_protected(hdr->frame_control)) { skb_put(msdu, IEEE80211_CCMP_MIC_LEN); } -- 2.1.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] ath10k: implement mesh support 2015-08-27 10:57 [PATCH 0/3] mesh support for ath10k Bob Copeland 2015-08-27 10:57 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland 2015-08-27 10:57 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland @ 2015-08-27 10:57 ` Bob Copeland 2015-08-29 17:11 ` Jason Andryuk 2015-09-09 7:57 ` Kalle Valo 2 siblings, 2 replies; 19+ messages in thread From: Bob Copeland @ 2015-08-27 10:57 UTC (permalink / raw) To: linux-wireless; +Cc: ath10k, Bob Copeland Add support for mesh to ath10k. We simply use an AP virtual interface in the firmware in order to enable beaconing without TSF adoption, and use the raw (802.11) transmit mode. Due to firmware limitations, the firmware must operate in raw (non-native 802.11) mode. As this is configured at firmware init time, a new "rawmode" modparam is added, and mesh interfaces are available only if rawmode=true. The firmware must advertise support for rawmode (tested successfully with firmware 10.2.4.70-2). When loaded with rawmode=1, ath10k can operate an open mesh STA via something like the following: ip link set wlan0 down iw dev wlan0 set type mp ip link set wlan0 up iw dev wlan0 set freq 5745 80 5775 iw dev wlan0 mesh join mesh-vht Signed-off-by: Bob Copeland <me@bobcopeland.com> --- Since ath10k ml posting: * added raw mode feature flag check * usage and firmware notes in commit log drivers/net/wireless/ath/ath10k/core.c | 12 ++++++++++++ drivers/net/wireless/ath/ath10k/mac.c | 33 ++++++++++++++++++++++++++++----- 2 files changed, 40 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index b87b986..9dafe25 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -34,16 +34,19 @@ unsigned int ath10k_debug_mask; static unsigned int ath10k_cryptmode_param; static bool uart_print; static bool skip_otp; +static bool rawmode; module_param_named(debug_mask, ath10k_debug_mask, uint, 0644); module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644); module_param(uart_print, bool, 0644); module_param(skip_otp, bool, 0644); +module_param(rawmode, bool, 0644); MODULE_PARM_DESC(debug_mask, "Debugging mask"); MODULE_PARM_DESC(uart_print, "Uart target debugging"); MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode"); MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software"); +MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath"); static const struct ath10k_hw_params ath10k_hw_params_list[] = { { @@ -1117,6 +1120,15 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar) ar->htt.max_num_amsdu = ATH10K_HTT_MAX_NUM_AMSDU_DEFAULT; ar->htt.max_num_ampdu = ATH10K_HTT_MAX_NUM_AMPDU_DEFAULT; + if (rawmode) { + if (!test_bit(ATH10K_FW_FEATURE_RAW_MODE_SUPPORT, + ar->fw_features)) { + ath10k_err(ar, "rawmode = 1 requires support from firmware"); + return -EINVAL; + } + set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags); + } + if (test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) { ar->wmi.rx_decap_mode = ATH10K_HW_TXRX_RAW; diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 7dfe37f..b0f1594 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4176,6 +4176,14 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, case NL80211_IFTYPE_ADHOC: arvif->vdev_type = WMI_VDEV_TYPE_IBSS; break; + case NL80211_IFTYPE_MESH_POINT: + if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) { + ret = -EINVAL; + ath10k_warn(ar, "must load driver with rawmode=1 to add mesh interfaces\n"); + goto err; + } + arvif->vdev_type = WMI_VDEV_TYPE_AP; + break; case NL80211_IFTYPE_AP: arvif->vdev_type = WMI_VDEV_TYPE_AP; @@ -4216,6 +4224,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, * become corrupted, e.g. have garbled IEs or out-of-date TIM bitmap. */ if (vif->type == NL80211_IFTYPE_ADHOC || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_AP) { arvif->beacon_buf = dma_zalloc_coherent(ar->dev, IEEE80211_MAX_FRAME_LEN, @@ -4555,6 +4564,13 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw, if (ret) ath10k_warn(ar, "failed to update beacon template: %d\n", ret); + + if (ieee80211_vif_is_mesh(vif)) { + /* mesh doesn't use SSID but firmware needs it */ + strncpy(arvif->u.ap.ssid, "mesh", + sizeof(arvif->u.ap.ssid)); + arvif->u.ap.ssid_len = 4; + } } if (changed & BSS_CHANGED_AP_PROBE_RESP) { @@ -5294,6 +5310,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, } else if (old_state == IEEE80211_STA_AUTH && new_state == IEEE80211_STA_ASSOC && (vif->type == NL80211_IFTYPE_AP || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_ADHOC)) { /* * New association. @@ -5329,6 +5346,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, } else if (old_state == IEEE80211_STA_ASSOC && new_state == IEEE80211_STA_AUTH && (vif->type == NL80211_IFTYPE_AP || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_ADHOC)) { /* * Disassociation. @@ -6642,14 +6660,16 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = { }, { .max = 7, - .types = BIT(NL80211_IFTYPE_AP) + .types = BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_MESH_POINT) }, }; static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = { { .max = 8, - .types = BIT(NL80211_IFTYPE_AP) + .types = BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_MESH_POINT) }, }; @@ -6688,7 +6708,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = { .max = 2, .types = BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_P2P_CLIENT) | - BIT(NL80211_IFTYPE_P2P_GO), + BIT(NL80211_IFTYPE_P2P_GO) | + BIT(NL80211_IFTYPE_MESH_POINT) }, { .max = 1, @@ -6708,7 +6729,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = { { .max = 1, .types = BIT(NL80211_IFTYPE_AP) | - BIT(NL80211_IFTYPE_P2P_GO), + BIT(NL80211_IFTYPE_P2P_GO) | + BIT(NL80211_IFTYPE_MESH_POINT), }, { .max = 1, @@ -6998,7 +7020,8 @@ int ath10k_mac_register(struct ath10k *ar) ar->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) | - BIT(NL80211_IFTYPE_AP); + BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_MESH_POINT); ar->hw->wiphy->available_antennas_rx = ar->supp_rx_chainmask; ar->hw->wiphy->available_antennas_tx = ar->supp_tx_chainmask; -- 2.1.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-08-27 10:57 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland @ 2015-08-29 17:11 ` Jason Andryuk 2015-08-29 22:25 ` Bob Copeland 2015-09-09 7:57 ` Kalle Valo 1 sibling, 1 reply; 19+ messages in thread From: Jason Andryuk @ 2015-08-29 17:11 UTC (permalink / raw) To: Bob Copeland; +Cc: linux-wireless@vger.kernel.org, ath10k On Thu, Aug 27, 2015 at 6:57 AM, Bob Copeland <me@bobcopeland.com> wrote: > @@ -1117,6 +1120,15 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar) > ar->htt.max_num_amsdu = ATH10K_HTT_MAX_NUM_AMSDU_DEFAULT; > ar->htt.max_num_ampdu = ATH10K_HTT_MAX_NUM_AMPDU_DEFAULT; > > + if (rawmode) { > + if (!test_bit(ATH10K_FW_FEATURE_RAW_MODE_SUPPORT, > + ar->fw_features)) { > + ath10k_err(ar, "rawmode = 1 requires support from firmware"); > + return -EINVAL; > + } > + set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags); > + } > + Is there a reason to hide rawmode behind a modparam, or should the modparam just be removed? Just let the driver set ATH10K_FLAG_RAW_MODE when ATH10K_FW_FEATURE_RAW_MODE_SUPPORT is detected? > @@ -6708,7 +6729,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = { > { > .max = 1, > .types = BIT(NL80211_IFTYPE_AP) | > - BIT(NL80211_IFTYPE_P2P_GO), > + BIT(NL80211_IFTYPE_P2P_GO) | > + BIT(NL80211_IFTYPE_MESH_POINT), > }, > { > .max = 1, Does struct ieee80211_iface_limit need to be conditional on firmware support as well or does interface_modes (below) gate use of MESH_POINT? > @@ -6998,7 +7020,8 @@ int ath10k_mac_register(struct ath10k *ar) > > ar->hw->wiphy->interface_modes = > BIT(NL80211_IFTYPE_STATION) | > - BIT(NL80211_IFTYPE_AP); > + BIT(NL80211_IFTYPE_AP) | > + BIT(NL80211_IFTYPE_MESH_POINT); Set BIT(NL80211_IFTYPE_MESH_POINT) conditionally if ATH10K_FLAG_RAW_MODE is set? Regards, Jason ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-08-29 17:11 ` Jason Andryuk @ 2015-08-29 22:25 ` Bob Copeland 2015-08-30 17:43 ` Yeoh Chun-Yeow 2015-09-01 3:02 ` Jason Andryuk 0 siblings, 2 replies; 19+ messages in thread From: Bob Copeland @ 2015-08-29 22:25 UTC (permalink / raw) To: Jason Andryuk; +Cc: linux-wireless@vger.kernel.org, ath10k On Sat, Aug 29, 2015 at 01:11:03PM -0400, Jason Andryuk wrote: > Is there a reason to hide rawmode behind a modparam, or should the > modparam just be removed? Just let the driver set > ATH10K_FLAG_RAW_MODE when ATH10K_FW_FEATURE_RAW_MODE_SUPPORT is > detected? Yes: you don't want to enable raw mode TX / RX decap in the normal case because it's fairly inefficient compared to "native" wifi mode, according to my understanding. The latter doesn't support mesh framing however. > Does struct ieee80211_iface_limit need to be conditional on firmware > support as well or does interface_modes (below) gate use of > MESH_POINT? If you advertise a combination that isn't supported by interface modes, I believe you'll get a kernel warning when the wiphy is registered. > > > @@ -6998,7 +7020,8 @@ int ath10k_mac_register(struct ath10k *ar) > > > > ar->hw->wiphy->interface_modes = > > BIT(NL80211_IFTYPE_STATION) | > > - BIT(NL80211_IFTYPE_AP); > > + BIT(NL80211_IFTYPE_AP) | > > + BIT(NL80211_IFTYPE_MESH_POINT); > > Set BIT(NL80211_IFTYPE_MESH_POINT) conditionally if ATH10K_FLAG_RAW_MODE is set? Yes, this was discussed on the ath10k mailing list and I'll probably do it in a follow-up patch. It is a little messy because it will involve casting away a const somewhere. -- Bob Copeland %% http://bobcopeland.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-08-29 22:25 ` Bob Copeland @ 2015-08-30 17:43 ` Yeoh Chun-Yeow 2015-09-16 12:39 ` Bob Copeland 2015-09-01 3:02 ` Jason Andryuk 1 sibling, 1 reply; 19+ messages in thread From: Yeoh Chun-Yeow @ 2015-08-30 17:43 UTC (permalink / raw) To: Bob Copeland Cc: Jason Andryuk, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Hi, Bob > Yes: you don't want to enable raw mode TX / RX decap in the normal > case because it's fairly inefficient compared to "native" wifi mode, > according to my understanding. The latter doesn't support mesh framing > however. > The native WiFi mode doesn't support mesh framing. Can you elaborate more on this? Thanks ---- Chun-Yeow ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-08-30 17:43 ` Yeoh Chun-Yeow @ 2015-09-16 12:39 ` Bob Copeland 2015-09-17 17:48 ` Yeoh Chun-Yeow 0 siblings, 1 reply; 19+ messages in thread From: Bob Copeland @ 2015-09-16 12:39 UTC (permalink / raw) To: Yeoh Chun-Yeow Cc: Jason Andryuk, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote: > Hi, Bob > > > Yes: you don't want to enable raw mode TX / RX decap in the normal > > case because it's fairly inefficient compared to "native" wifi mode, > > according to my understanding. The latter doesn't support mesh framing > > however. > > > > The native WiFi mode doesn't support mesh framing. Can you elaborate > more on this? Sorry, missed this before -- the 'nwifi' mode which is the normal datapath for ath10k discards the QoS header and following mesh header when transmitting, if I recall correctly. I also had some issues with the received frames when using nwifi RX decap with raw mode TX, but I don't recall exactly the problem. I can retest with these modes if you really want the details. -- Bob Copeland %% http://bobcopeland.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-16 12:39 ` Bob Copeland @ 2015-09-17 17:48 ` Yeoh Chun-Yeow 2015-09-17 23:56 ` Peter Oh 0 siblings, 1 reply; 19+ messages in thread From: Yeoh Chun-Yeow @ 2015-09-17 17:48 UTC (permalink / raw) To: Bob Copeland Cc: Jason Andryuk, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Hi, Bob I have also tested with nwifi mode for non-secured mesh. It seems to be worked for me with the following two test scenarios: Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k] Node 1 [ath10k] <---> Node 2 [ath9k] I am using the following: compat-wireless-2015-07-21 from OpenWRT firmware-5.bin_10.2.4.70.6-2 I just wondering whether using raw wifi is better for encrypted mesh later? ---- Chun-Yeow On Wed, Sep 16, 2015 at 8:39 PM, Bob Copeland <me@bobcopeland.com> wrote: > On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote: >> Hi, Bob >> >> > Yes: you don't want to enable raw mode TX / RX decap in the normal >> > case because it's fairly inefficient compared to "native" wifi mode, >> > according to my understanding. The latter doesn't support mesh framing >> > however. >> > >> >> The native WiFi mode doesn't support mesh framing. Can you elaborate >> more on this? > > Sorry, missed this before -- the 'nwifi' mode which is the normal > datapath for ath10k discards the QoS header and following mesh header > when transmitting, if I recall correctly. I also had some issues with the > received frames when using nwifi RX decap with raw mode TX, but I don't > recall exactly the problem. I can retest with these modes if you really > want the details. > > -- > Bob Copeland %% http://bobcopeland.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-17 17:48 ` Yeoh Chun-Yeow @ 2015-09-17 23:56 ` Peter Oh 0 siblings, 0 replies; 19+ messages in thread From: Peter Oh @ 2015-09-17 23:56 UTC (permalink / raw) To: Yeoh Chun-Yeow, Bob Copeland; +Cc: linux-wireless, ath10k, Jason Andryuk On 09/17/2015 10:48 AM, Yeoh Chun-Yeow wrote: > Hi, Bob > > I have also tested with nwifi mode for non-secured mesh. It seems to > be worked for me with the following two test scenarios: > > Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k] > Node 1 [ath10k] <---> Node 2 [ath9k] > > I am using the following: > compat-wireless-2015-07-21 from OpenWRT > firmware-5.bin_10.2.4.70.6-2 > > I just wondering whether using raw wifi is better for encrypted mesh > later? nwifi mode will be in trouble when SNAP/LLC encapsulation used since firmware and hardware have no way to distinguish if it's SNAP header or Mesh Control field. -- Peter > > ---- > Chun-Yeow > > On Wed, Sep 16, 2015 at 8:39 PM, Bob Copeland <me@bobcopeland.com> wrote: >> On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote: >>> Hi, Bob >>> >>>> Yes: you don't want to enable raw mode TX / RX decap in the normal >>>> case because it's fairly inefficient compared to "native" wifi mode, >>>> according to my understanding. The latter doesn't support mesh > framing >>>> however. >>>> >>> The native WiFi mode doesn't support mesh framing. Can you elaborate >>> more on this? >> Sorry, missed this before -- the 'nwifi' mode which is the normal >> datapath for ath10k discards the QoS header and following mesh header >> when transmitting, if I recall correctly. I also had some issues with > the >> received frames when using nwifi RX decap with raw mode TX, but I don't >> recall exactly the problem. I can retest with these modes if you really >> want the details. >> >> -- >> Bob Copeland %% http://bobcopeland.com/ > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-08-29 22:25 ` Bob Copeland 2015-08-30 17:43 ` Yeoh Chun-Yeow @ 2015-09-01 3:02 ` Jason Andryuk 1 sibling, 0 replies; 19+ messages in thread From: Jason Andryuk @ 2015-09-01 3:02 UTC (permalink / raw) To: Bob Copeland; +Cc: linux-wireless@vger.kernel.org, ath10k On Sat, Aug 29, 2015 at 6:25 PM, Bob Copeland <me@bobcopeland.com> wrote: > On Sat, Aug 29, 2015 at 01:11:03PM -0400, Jason Andryuk wrote: >> Is there a reason to hide rawmode behind a modparam, or should the >> modparam just be removed? Just let the driver set >> ATH10K_FLAG_RAW_MODE when ATH10K_FW_FEATURE_RAW_MODE_SUPPORT is >> detected? > > Yes: you don't want to enable raw mode TX / RX decap in the normal > case because it's fairly inefficient compared to "native" wifi mode, > according to my understanding. The latter doesn't support mesh framing > however. > >> Does struct ieee80211_iface_limit need to be conditional on firmware >> support as well or does interface_modes (below) gate use of >> MESH_POINT? > > If you advertise a combination that isn't supported by interface modes, > I believe you'll get a kernel warning when the wiphy is registered. > >> >> > @@ -6998,7 +7020,8 @@ int ath10k_mac_register(struct ath10k *ar) >> > >> > ar->hw->wiphy->interface_modes = >> > BIT(NL80211_IFTYPE_STATION) | >> > - BIT(NL80211_IFTYPE_AP); >> > + BIT(NL80211_IFTYPE_AP) | >> > + BIT(NL80211_IFTYPE_MESH_POINT); >> >> Set BIT(NL80211_IFTYPE_MESH_POINT) conditionally if ATH10K_FLAG_RAW_MODE is set? > > Yes, this was discussed on the ath10k mailing list and I'll probably do > it in a follow-up patch. It is a little messy because it will involve > casting away a const somewhere. Great. Glad you've already considered all these things. -Jason ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-08-27 10:57 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland 2015-08-29 17:11 ` Jason Andryuk @ 2015-09-09 7:57 ` Kalle Valo 2015-09-09 9:10 ` Kalle Valo 2015-09-09 11:08 ` Bob Copeland 1 sibling, 2 replies; 19+ messages in thread From: Kalle Valo @ 2015-09-09 7:57 UTC (permalink / raw) To: Bob Copeland; +Cc: linux-wireless, ath10k Bob Copeland <me@bobcopeland.com> writes: > Add support for mesh to ath10k. We simply use an AP virtual interface > in the firmware in order to enable beaconing without TSF adoption, and > use the raw (802.11) transmit mode. > > Due to firmware limitations, the firmware must operate in raw > (non-native 802.11) mode. As this is configured at firmware init time, > a new "rawmode" modparam is added, and mesh interfaces are available > only if rawmode=true. The firmware must advertise support for rawmode > (tested successfully with firmware 10.2.4.70-2). > > When loaded with rawmode=1, ath10k can operate an open mesh STA via > something like the following: > > ip link set wlan0 down > iw dev wlan0 set type mp > ip link set wlan0 up > iw dev wlan0 set freq 5745 80 5775 > iw dev wlan0 mesh join mesh-vht > > Signed-off-by: Bob Copeland <me@bobcopeland.com> I did a quick smoke test and saw the splat below. It's this warning from cfg80211: /* * Don't advertise an unsupported type * in a combination. */ if (WARN_ON((wiphy->interface_modes & types) != types)) return -EINVAL; I didn't immeaditely figure out what's causing this, the interface types looked correct to me. Unfortunately I don't have time to investigate more at the moment, but will look later. [ 152.113232] ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.70.6 api 3 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p [ 152.113448] ath10k_pci 0000:02:00.0: debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 [ 152.226213] ath: EEPROM regdomain: 0x0 [ 152.226296] ath: EEPROM indicates default country code should be used [ 152.226365] ath: doing EEPROM country->regdmn map search [ 152.226434] ath: country maps to regdmn code: 0x3a [ 152.226504] ath: Country alpha2 being used: US [ 152.226573] ath: Regpair used: 0x3a [ 152.226677] ------------[ cut here ]------------ [ 152.226785] WARNING: CPU: 0 PID: 1141 at net/wireless/core.c:530 wiphy_register+0x680/0x780 [cfg80211]() [ 152.226864] Modules linked in: ath10k_pci ath10k_core ath mac80211 cfg80211 [last unloaded: cfg80211] [ 152.227882] CPU: 0 PID: 1141 Comm: kworker/u16:5 Not tainted 4.2.0-wl-ath+ #1044 [ 152.227972] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010 [ 152.228068] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 152.228372] 00000000 00000000 f1c19d08 c18c0e4e 00000000 f1c19d38 c10578ce c1b0f660 [ 152.229343] 00000000 00000475 fb37017a 00000212 fb317130 fb317130 00000088 efe48320 [ 152.230500] 00000008 f1c19d48 c1057932 00000009 00000000 f1c19dac fb317130 f1c10008 [ 152.231541] Call Trace: [ 152.231634] [<c18c0e4e>] dump_stack+0x48/0x60 [ 152.231824] [<c10578ce>] warn_slowpath_common+0x8e/0xd0 [ 152.232014] [<fb317130>] ? wiphy_register+0x680/0x780 [cfg80211] [ 152.232232] [<fb317130>] ? wiphy_register+0x680/0x780 [cfg80211] [ 152.232448] [<c1057932>] warn_slowpath_null+0x22/0x30 [ 152.232561] [<fb317130>] wiphy_register+0x680/0x780 [cfg80211] [ 152.232657] [<c11a3926>] ? __kmalloc+0x216/0x370 [ 152.232749] [<c10acd69>] ? mark_held_locks+0x59/0x80 [ 152.232898] [<fbfcb3d0>] ? ieee80211_register_hw+0x1f0/0x970 [mac80211] [ 152.233468] [<fbfcb3d0>] ? ieee80211_register_hw+0x1f0/0x970 [mac80211] [ 152.233576] [<fc22c7d0>] ? ath10k_hw_scan+0x210/0x210 [ath10k_core] [ 152.233679] [<fc22c5c0>] ? ath10k_start_scan+0x140/0x140 [ath10k_core] [ 152.233794] [<fbfcb541>] ieee80211_register_hw+0x361/0x970 [mac80211] [ 152.233889] [<c1000f0c>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 152.233983] [<c18caef5>] ? restore_all+0xf/0xf [ 152.234084] [<fc22d973>] ath10k_mac_register+0x7c3/0x920 [ath10k_core] [ 152.234196] [<c10a66bc>] ? __lock_is_held+0x3c/0x50 [ 152.236050] [<fc234e61>] ath10k_core_register_work+0x5d1/0x6d0 [ath10k_core] [ 152.236136] [<c1070f00>] process_one_work+0x1d0/0x6c0 [ 152.236204] [<c1070e52>] ? process_one_work+0x122/0x6c0 [ 152.236270] [<c107150a>] worker_thread+0xea/0x3d0 [ 152.236335] [<c10acf5b>] ? trace_hardirqs_on+0xb/0x10 [ 152.236399] [<c1071420>] ? process_scheduled_works+0x30/0x30 [ 152.236466] [<c10773f5>] kthread+0xa5/0xc0 [ 152.236531] [<c18ca917>] ? _raw_spin_unlock_irq+0x27/0x40 [ 152.236596] [<c18cad01>] ret_from_kernel_thread+0x21/0x30 [ 152.236664] [<c1077350>] ? __init_kthread_worker+0x60/0x60 [ 152.236731] ---[ end trace ce831788c6a79cf8 ]--- [ 152.236813] ath10k_pci 0000:02:00.0: failed to register ieee80211: -22 [ 152.236889] ath10k_pci 0000:02:00.0: could not register to mac80211 (-22) -- Kalle Valo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-09 7:57 ` Kalle Valo @ 2015-09-09 9:10 ` Kalle Valo 2015-09-09 16:49 ` Bob Copeland 2015-09-09 11:08 ` Bob Copeland 1 sibling, 1 reply; 19+ messages in thread From: Kalle Valo @ 2015-09-09 9:10 UTC (permalink / raw) To: Bob Copeland; +Cc: linux-wireless, ath10k Kalle Valo <kvalo@qca.qualcomm.com> writes: > Bob Copeland <me@bobcopeland.com> writes: > >> Add support for mesh to ath10k. We simply use an AP virtual interface >> in the firmware in order to enable beaconing without TSF adoption, and >> use the raw (802.11) transmit mode. >> >> Due to firmware limitations, the firmware must operate in raw >> (non-native 802.11) mode. As this is configured at firmware init time, >> a new "rawmode" modparam is added, and mesh interfaces are available >> only if rawmode=true. The firmware must advertise support for rawmode >> (tested successfully with firmware 10.2.4.70-2). >> >> When loaded with rawmode=1, ath10k can operate an open mesh STA via >> something like the following: >> >> ip link set wlan0 down >> iw dev wlan0 set type mp >> ip link set wlan0 up >> iw dev wlan0 set freq 5745 80 5775 >> iw dev wlan0 mesh join mesh-vht >> >> Signed-off-by: Bob Copeland <me@bobcopeland.com> > > I did a quick smoke test and saw the splat below. It's this warning from > cfg80211: > > /* > * Don't advertise an unsupported type > * in a combination. > */ > if (WARN_ON((wiphy->interface_modes & types) != types)) > return -EINVAL; Forgot to mention that this was with 10.2.4.70.6-2 (which has the raw feature bit set, will push it soon) but rawmode modparam not set. And I had applied your patches on top of ath.git master branch (commit d89281c7d6bb9). -- Kalle Valo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-09 9:10 ` Kalle Valo @ 2015-09-09 16:49 ` Bob Copeland 2015-09-10 5:46 ` Kalle Valo 2015-09-10 7:22 ` Johannes Berg 0 siblings, 2 replies; 19+ messages in thread From: Bob Copeland @ 2015-09-09 16:49 UTC (permalink / raw) To: Kalle Valo; +Cc: linux-wireless, ath10k On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: > > I did a quick smoke test and saw the splat below. It's this warning from > > cfg80211: > > > > /* > > * Don't advertise an unsupported type > > * in a combination. > > */ > > if (WARN_ON((wiphy->interface_modes & types) != types)) > > return -EINVAL; OK, this happens when mesh is configured out (we mask off the mesh interface_modes internally but not the types). Sent an updated version with appropriate ifdefs added. -- Bob Copeland %% http://bobcopeland.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-09 16:49 ` Bob Copeland @ 2015-09-10 5:46 ` Kalle Valo 2015-09-10 7:22 ` Johannes Berg 1 sibling, 0 replies; 19+ messages in thread From: Kalle Valo @ 2015-09-10 5:46 UTC (permalink / raw) To: Bob Copeland; +Cc: linux-wireless, ath10k Bob Copeland <me@bobcopeland.com> writes: > On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: >> > I did a quick smoke test and saw the splat below. It's this warning from >> > cfg80211: >> > >> > /* >> > * Don't advertise an unsupported type >> > * in a combination. >> > */ >> > if (WARN_ON((wiphy->interface_modes & types) != types)) >> > return -EINVAL; > > OK, this happens when mesh is configured out (we mask off the mesh > interface_modes internally but not the types). Sent an updated version > with appropriate ifdefs added. Indeed, when I enabled CONFIG_MAC80211_MESH I didn't see the WARN_ON() anymore. (I haven't tested your latest version yet, will do it soon) -- Kalle Valo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-09 16:49 ` Bob Copeland 2015-09-10 5:46 ` Kalle Valo @ 2015-09-10 7:22 ` Johannes Berg 2015-09-15 7:21 ` Peter Oh 1 sibling, 1 reply; 19+ messages in thread From: Johannes Berg @ 2015-09-10 7:22 UTC (permalink / raw) To: Bob Copeland, Kalle Valo; +Cc: linux-wireless, ath10k On Wed, 2015-09-09 at 12:49 -0400, Bob Copeland wrote: > On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: > > > I did a quick smoke test and saw the splat below. It's this > > > warning from > > > cfg80211: > > > > > > /* > > > * Don't advertise an unsupported type > > > * in a combination. > > > */ > > > if (WARN_ON((wiphy->interface_modes & > > > types) != types)) > > > return -EINVAL; > > OK, this happens when mesh is configured out (we mask off the mesh > interface_modes internally but not the types). Sent an updated > version with appropriate ifdefs added. Yeah this is an unfortunate quirk in the APIs ... I think adding the ifdefs to the driver is the best thing to do. johannes ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-10 7:22 ` Johannes Berg @ 2015-09-15 7:21 ` Peter Oh 2015-09-16 12:32 ` Bob Copeland 0 siblings, 1 reply; 19+ messages in thread From: Peter Oh @ 2015-09-15 7:21 UTC (permalink / raw) To: Johannes Berg, Bob Copeland, Kalle Valo; +Cc: linux-wireless, ath10k On 09/10/2015 12:22 AM, Johannes Berg wrote: > On Wed, 2015-09-09 at 12:49 -0400, Bob Copeland wrote: >> On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote: >>>> I did a quick smoke test and saw the splat below. It's this >>>> warning from >>>> cfg80211: >>>> >>>> /* >>>> * Don't advertise an unsupported type >>>> * in a combination. >>>> */ >>>> if (WARN_ON((wiphy->interface_modes & >>>> types) != types)) >>>> return -EINVAL; >> OK, this happens when mesh is configured out (we mask off the mesh >> interface_modes internally but not the types). Sent an updated >> version with appropriate ifdefs added. > Yeah this is an unfortunate quirk in the APIs ... I think adding the > ifdefs to the driver is the best thing to do. > > johannes Can we configure mesh point with hostapd or can we use mesh point without neither wpa_supplicant nor hostapd? Currently I'm trying to bring up mesh point, but whenever I run hostpad after creating mesh point (iw phy0 interface add mesh type mp), hostapd change the interface mode to managed. > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k Thanks, Peter ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-15 7:21 ` Peter Oh @ 2015-09-16 12:32 ` Bob Copeland 0 siblings, 0 replies; 19+ messages in thread From: Bob Copeland @ 2015-09-16 12:32 UTC (permalink / raw) To: Peter Oh; +Cc: Johannes Berg, Kalle Valo, linux-wireless, ath10k On Tue, Sep 15, 2015 at 12:21:35AM -0700, Peter Oh wrote: > Can we configure mesh point with hostapd or can we use mesh point without > neither wpa_supplicant nor hostapd? > Currently I'm trying to bring up mesh point, but whenever I run hostpad > after creating mesh point (iw phy0 interface add mesh type mp), hostapd > change the interface mode to managed. Hostapd can't control the mesh interface, but wpa_supplicant can, though I believe there's a little more work needed to support VHT for mesh in wpa_supplicant. If you want to run an unencrypted mesh, you can start it with iw and the kernel will run the peering manager. If you're asking about a mesh-enabled access point, you can run hostapd separately from wpa_supplicant/iw, as in the below script. (I've only tested that you can bring this up on ath10k, not actual operation, though it should work as far as I know. I've run similar scripts on ath9k.) #!/bin/bash -x # # Example of running a mesh-enabled access point with one radio. # killall hostapd > /dev/null killall wpa_supplicant > /dev/null pubip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}'` last8=`echo $pubip | awk -F . '{print $4}'` meship=10.10.1.$last8 iface=wlan0 ap_iface=ap0 br_iface=br0 mesh_mac=42:00:00:00:00:`printf "%.2x" $last8` channel=36 freq=5180 brctl delbr $br_iface brctl addbr $br_iface # add a new interface for ap operation iw dev $ap_iface del iw dev $iface interface add $ap_iface type managed ip addr flush $ap_iface ip link set $ap_iface down # create hostapd conf for ath10k cat <<__EOM > hostapd.conf interface=$ap_iface driver=nl80211 ssid=mesh-ap hw_mode=a channel=$channel auth_algs=3 own_ip_addr=$meship wpa=1 wpa_passphrase=my_password wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP ht_capab=[HT40+] ieee80211n=1 ieee80211ac=1 vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=$((channel + 6)) bridge=$br_iface __EOM # configure main interface to run in mesh mode ip addr flush $iface ip link set $iface down ip link set addr $mesh_mac dev $iface iw dev $iface set type mp ip link set $iface up # start the mesh # here you might instead run wpa_supplicant for an encrypted mesh iw dev $iface set freq $freq 80 $((freq + 30)) iw dev $iface mesh join mesh-vht sleep 5 # add mesh to bridge (hostapd adds AP interface to bridge) brctl addif $br_iface $iface ip addr add $meship/24 dev $br_iface ip link set $br_iface up # run hostapd hostapd -dd hostapd.conf >hostapd.log 2>&1 & -- Bob Copeland %% http://bobcopeland.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ath10k: implement mesh support 2015-09-09 7:57 ` Kalle Valo 2015-09-09 9:10 ` Kalle Valo @ 2015-09-09 11:08 ` Bob Copeland 1 sibling, 0 replies; 19+ messages in thread From: Bob Copeland @ 2015-09-09 11:08 UTC (permalink / raw) To: Kalle Valo; +Cc: linux-wireless, ath10k On Wed, Sep 09, 2015 at 10:57:30AM +0300, Kalle Valo wrote: > I did a quick smoke test and saw the splat below. It's this warning from > cfg80211: > > /* > * Don't advertise an unsupported type > * in a combination. > */ > if (WARN_ON((wiphy->interface_modes & types) != types)) > return -EINVAL; > > I didn't immeaditely figure out what's causing this, the interface types > looked correct to me. Unfortunately I don't have time to investigate > more at the moment, but will look later. Doh! Yeah this warning is exactly why I marked it supported even if you couldn't use it due to missing rawmode support. Obviously I missed one of the cases, I'll take a look. -- Bob Copeland %% http://bobcopeland.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-09-17 23:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-27 10:57 [PATCH 0/3] mesh support for ath10k Bob Copeland 2015-08-27 10:57 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland 2015-08-27 10:57 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland 2015-08-27 10:57 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland 2015-08-29 17:11 ` Jason Andryuk 2015-08-29 22:25 ` Bob Copeland 2015-08-30 17:43 ` Yeoh Chun-Yeow 2015-09-16 12:39 ` Bob Copeland 2015-09-17 17:48 ` Yeoh Chun-Yeow 2015-09-17 23:56 ` Peter Oh 2015-09-01 3:02 ` Jason Andryuk 2015-09-09 7:57 ` Kalle Valo 2015-09-09 9:10 ` Kalle Valo 2015-09-09 16:49 ` Bob Copeland 2015-09-10 5:46 ` Kalle Valo 2015-09-10 7:22 ` Johannes Berg 2015-09-15 7:21 ` Peter Oh 2015-09-16 12:32 ` Bob Copeland 2015-09-09 11:08 ` Bob Copeland
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).