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
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 <[email protected]>
---
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
On Thu, Aug 27, 2015 at 6:57 AM, Bob Copeland <[email protected]> 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
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 <[email protected]>
---
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
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
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/
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 <[email protected]>
---
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
On Sat, Aug 29, 2015 at 6:25 PM, Bob Copeland <[email protected]> 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
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
Kalle Valo <[email protected]> writes:
> Bob Copeland <[email protected]> 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 <[email protected]>
>
> 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
Bob Copeland <[email protected]> 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
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/
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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/ath10k
Thanks,
Peter
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 <[email protected]> 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/
Bob Copeland <[email protected]> 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 <[email protected]>
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
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 <[email protected]> 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/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/
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/
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/