ath10k mesh + ap + encryption?

ath10k mesh + ap + encryption?

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

Hi,

we have done some experiments last week on ath10k, trying to run mesh 
(802.11s) and access point at the same time, both encrypted. 

We have tested a recent LEDE (reboot-1519-g42f559e) but with 
firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us a 
working encrypted 802.11s network. However, starting an AP at the same time 
didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was 
running unencrypted.

We also tested version 10.2.4.97 (from codeaurora), which is now default in 
LEDE. However, this version apparently doesn't support 11s mesh at all 
(WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 
advertises support).

So here are my questions:

 * Did anyone succesfully run AP and mesh, both encrypted at the same time?
 * Do you have any pointers how we could fix this? Could it be fixable in the 
driver (i.e. not in firmware)?
 * Does anyone have an idea if 11s will be supported in future versions? I 
didn't find any changelogs, but having 11s mode no longer in the service map 
does not make me optimistic.

Thanks,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ath10k mesh + ap + encryption?

[Valo, Kalle]

Simon Wunderlich <sw@simonwunderlich.de> writes:

> we have done some experiments last week on ath10k, trying to run mesh=20
> (802.11s) and access point at the same time, both encrypted.=20
>
> We have tested a recent LEDE (reboot-1519-g42f559e) but with=20
> firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave=
 us a=20
> working encrypted 802.11s network. However, starting an AP at the same ti=
me=20
> didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was=20
> running unencrypted.
>
> We also tested version 10.2.4.97 (from codeaurora), which is now default =
in=20
> LEDE. However, this version apparently doesn't support 11s mesh at all=20
> (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211=20
> advertises support).
>
> So here are my questions:
>
>  * Did anyone succesfully run AP and mesh, both encrypted at the same tim=
e?
>  * Do you have any pointers how we could fix this? Could it be fixable in=
 the=20
> driver (i.e. not in firmware)?
>  * Does anyone have an idea if 11s will be supported in future versions? =
I=20
> didn't find any changelogs, but having 11s mode no longer in the service =
map=20
> does not make me optimistic.

Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
have no knowledge if anyone even tests that firmware branch with ath10k.
I recommend to only use firmware releases from ath10k-firmware.git as we
use those internally with ath10k. In any case, don't make any
assumptions about future from that firmware branch as it's so old.

--=20
Kalle Valo=

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
> > we have done some experiments last week on ath10k, trying to run mesh
> > (802.11s) and access point at the same time, both encrypted.
> > 
> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
> > us a working encrypted 802.11s network. However, starting an AP at the
> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> > 802.11s was running unencrypted.
> > 
> > We also tested version 10.2.4.97 (from codeaurora), which is now default
> > in
> > LEDE. However, this version apparently doesn't support 11s mesh at all
> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> > advertises support).
> > 
> > So here are my questions:
> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
> >  time?
> >  * Do you have any pointers how we could fix this? Could it be fixable in
> >  the> 
> > driver (i.e. not in firmware)?
> > 
> >  * Does anyone have an idea if 11s will be supported in future versions? I
> > 
> > didn't find any changelogs, but having 11s mode no longer in the service
> > map does not make me optimistic.
> 
> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> have no knowledge if anyone even tests that firmware branch with ath10k.
> I recommend to only use firmware releases from ath10k-firmware.git as we
> use those internally with ath10k. In any case, don't make any
> assumptions about future from that firmware branch as it's so old.

This was introduced in December 25th, 2015 after some firmware-related 
problems. I'm CC'ing Martin Blumenstingl who suggested this change.

Since then, ath10k is pulling firmware from here (unless ct firmware is used):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
10.2.4/firmware-5.bin_10.2.4.97-1

However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say 
10.2.4.70.42-2 is more recent? I would have assumed otherwise from the 
numbers. However, 10.2.4.70 has much more sub-revisions. Is there any document 
describing the revisions? I don't understand it at least from this wiki page 
[1].

Thanks!
    Simon

[1] https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ath10k mesh + ap + encryption?

[Valo, Kalle]

Simon Wunderlich <sw@simonwunderlich.de> writes:

> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>> > we have done some experiments last week on ath10k, trying to run mesh
>> > (802.11s) and access point at the same time, both encrypted.
>> >=20
>> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
>> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which g=
ave
>> > us a working encrypted 802.11s network. However, starting an AP at the
>> > same time didn't work (AP doesn't beacon). This wasn't a problem when
>> > 802.11s was running unencrypted.
>> >=20
>> > We also tested version 10.2.4.97 (from codeaurora), which is now defau=
lt
>> > in
>> > LEDE. However, this version apparently doesn't support 11s mesh at all
>> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>> > advertises support).
>> >=20
>> > So here are my questions:
>> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
>> >  time?
>> >  * Do you have any pointers how we could fix this? Could it be fixable=
 in
>> >  the>=20
>> > driver (i.e. not in firmware)?
>> >=20
>> >  * Does anyone have an idea if 11s will be supported in future version=
s? I
>> >=20
>> > didn't find any changelogs, but having 11s mode no longer in the servi=
ce
>> > map does not make me optimistic.
>>=20
>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>> have no knowledge if anyone even tests that firmware branch with ath10k.
>> I recommend to only use firmware releases from ath10k-firmware.git as we
>> use those internally with ath10k. In any case, don't make any
>> assumptions about future from that firmware branch as it's so old.
>
> This was introduced in December 25th, 2015 after some firmware-related=20
> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>
> Since then, ath10k is pulling firmware from here (unless ct firmware is u=
sed):
>
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plai=
n/
> 10.2.4/firmware-5.bin_10.2.4.97-1
>
> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you=
 say=20
> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the=20
> numbers. However, 10.2.4.70 has much more sub-revisions.

As I said before, I just deliver the firmware files to the community and
the firmware team creates the actual releases. But my understanding is
that these are from different branches which are built independently
(and might have different features, like in this case the mesh support)
so I would not make any conclusions if any firmware is "better" just
from the numbers alone.

--=20
Kalle Valo=

Re: ath10k mesh + ap + encryption?

[Sebastian Gottschall]

Am 13.09.2016 um 13:25 schrieb Valo, Kalle:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
>
>> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>>>> we have done some experiments last week on ath10k, trying to run mesh
>>>> (802.11s) and access point at the same time, both encrypted.
>>>>
>>>> We have tested a recent LEDE (reboot-1519-g42f559e) but with
>>>> firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
>>>> us a working encrypted 802.11s network. However, starting an AP at the
>>>> same time didn't work (AP doesn't beacon). This wasn't a problem when
>>>> 802.11s was running unencrypted.
>>>>
>>>> We also tested version 10.2.4.97 (from codeaurora), which is now default
>>>> in
>>>> LEDE. However, this version apparently doesn't support 11s mesh at all
>>>> (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>>>> advertises support).
>>>>
>>>> So here are my questions:
>>>>   * Did anyone succesfully run AP and mesh, both encrypted at the same
>>>>   time?
>>>>   * Do you have any pointers how we could fix this? Could it be fixable in
>>>>   the>
>>>> driver (i.e. not in firmware)?
>>>>
>>>>   * Does anyone have an idea if 11s will be supported in future versions? I
>>>>
>>>> didn't find any changelogs, but having 11s mode no longer in the service
>>>> map does not make me optimistic.
>>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>>> have no knowledge if anyone even tests that firmware branch with ath10k.
>>> I recommend to only use firmware releases from ath10k-firmware.git as we
>>> use those internally with ath10k. In any case, don't make any
>>> assumptions about future from that firmware branch as it's so old.
>> This was introduced in December 25th, 2015 after some firmware-related
>> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>>
>> Since then, ath10k is pulling firmware from here (unless ct firmware is used):
>>
>> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
>> 10.2.4/firmware-5.bin_10.2.4.97-1
>>
>> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
>> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
>> numbers. However, 10.2.4.70 has much more sub-revisions.
> As I said before, I just deliver the firmware files to the community and
> the firmware team creates the actual releases. But my understanding is
> that these are from different branches which are built independently
> (and might have different features, like in this case the mesh support)
> so I would not make any conclusions if any firmware is "better" just
> from the numbers alone.
would be good to have changelogs so see what has been changed to test 
what they have changed in the fw
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]

On Tuesday, September 13, 2016 11:25:21 AM CEST Valo, Kalle wrote:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
> > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> >> Simon Wunderlich <sw@simonwunderlich.de> writes:
> >> > we have done some experiments last week on ath10k, trying to run mesh
> >> > (802.11s) and access point at the same time, both encrypted.
> >> > 
> >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which
> >> > gave
> >> > us a working encrypted 802.11s network. However, starting an AP at the
> >> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> >> > 802.11s was running unencrypted.
> >> > 
> >> > We also tested version 10.2.4.97 (from codeaurora), which is now
> >> > default
> >> > in
> >> > LEDE. However, this version apparently doesn't support 11s mesh at all
> >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> >> > advertises support).
> >> > 
> >> > So here are my questions:
> >> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
> >> >  time?
> >> >  * Do you have any pointers how we could fix this? Could it be fixable
> >> >  in
> >> >  the>
> >> > 
> >> > driver (i.e. not in firmware)?
> >> > 
> >> >  * Does anyone have an idea if 11s will be supported in future
> >> >  versions? I
> >> > 
> >> > didn't find any changelogs, but having 11s mode no longer in the
> >> > service
> >> > map does not make me optimistic.
> >> 
> >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> >> have no knowledge if anyone even tests that firmware branch with ath10k.
> >> I recommend to only use firmware releases from ath10k-firmware.git as we
> >> use those internally with ath10k. In any case, don't make any
> >> assumptions about future from that firmware branch as it's so old.
> > 
> > This was introduced in December 25th, 2015 after some firmware-related
> > problems. I'm CC'ing Martin Blumenstingl who suggested this change.
> > 
> > Since then, ath10k is pulling firmware from here (unless ct firmware is
> > used):
> > 
> > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain
> > /
> > 10.2.4/firmware-5.bin_10.2.4.97-1
> > 
> > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you
> > say 10.2.4.70.42-2 is more recent? I would have assumed otherwise from
> > the numbers. However, 10.2.4.70 has much more sub-revisions.
> 
> As I said before, I just deliver the firmware files to the community and
> the firmware team creates the actual releases. But my understanding is
> that these are from different branches which are built independently
> (and might have different features, like in this case the mesh support)
> so I would not make any conclusions if any firmware is "better" just
> from the numbers alone.

you are right ... those numbers are not a good pointer. I found this repo, and 
from the checkin dates it looks like 10.2.4.97 is indeed way older (from 
September 2015) than 10.2.4.70.42 (April 2016):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/log/10.2.4

I would agree that Changelogs would be helpful.

Thanks for the clarification. We will then stick to the 70's branch then.

Does anyone have pointers for the other questions? :) I would believe hat many 
people would be interested in running AP + Mesh encrypted at the same time (at 
least in the open source community ...).

Thanks,
      Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ath10k mesh + ap + encryption?

[Pedersen, Thomas]

T24gVHVlLCAyMDE2LTA5LTEzIGF0IDE0OjMwICswMjAwLCBTaW1vbiBXdW5kZXJsaWNoIHdyb3Rl
Og0KPiBPbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTYgMTE6MjU6MjEgQU0gQ0VTVCBWYWxv
LCBLYWxsZSB3cm90ZToNCj4gPiANCj4gPiBTaW1vbiBXdW5kZXJsaWNoIDxzd0BzaW1vbnd1bmRl
cmxpY2guZGU+IHdyaXRlczoNCj4gPiA+IA0KPiA+ID4gT24gVHVlc2RheSwgU2VwdGVtYmVyIDEz
LCAyMDE2IDEwOjU5OjMxIEFNIENFU1QgVmFsbywgS2FsbGUNCj4gPiA+IHdyb3RlOg0KPiA+ID4g
PiANCj4gPiA+ID4gU2ltb24gV3VuZGVybGljaCA8c3dAc2ltb253dW5kZXJsaWNoLmRlPiB3cml0
ZXM6DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gd2UgaGF2ZSBkb25lIHNvbWUgZXhwZXJpbWVudHMg
bGFzdCB3ZWVrIG9uIGF0aDEwaywgdHJ5aW5nIHRvDQo+ID4gPiA+ID4gcnVuIG1lc2gNCj4gPiA+
ID4gPiAoODAyLjExcykgYW5kIGFjY2VzcyBwb2ludCBhdCB0aGUgc2FtZSB0aW1lLCBib3RoIGVu
Y3J5cHRlZC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBXZSBoYXZlIHRlc3RlZCBhIHJlY2VudCBM
RURFIChyZWJvb3QtMTUxOS1nNDJmNTU5ZSkgYnV0IHdpdGgNCj4gPiA+ID4gPiBmaXJtd2FyZS01
LmJpbl8xMC4yLjQuNzAuNDItMiBhbmQgdGhlIGluY2x1ZGVkDQo+ID4gPiA+ID4gd3BhX3N1cHBs
aWNhbnQsIHdoaWNoDQo+ID4gPiA+ID4gZ2F2ZQ0KPiA+ID4gPiA+IHVzIGEgd29ya2luZyBlbmNy
eXB0ZWQgODAyLjExcyBuZXR3b3JrLiBIb3dldmVyLCBzdGFydGluZyBhbg0KPiA+ID4gPiA+IEFQ
IGF0IHRoZQ0KPiA+ID4gPiA+IHNhbWUgdGltZSBkaWRuJ3Qgd29yayAoQVAgZG9lc24ndCBiZWFj
b24pLiBUaGlzIHdhc24ndCBhDQo+ID4gPiA+ID4gcHJvYmxlbSB3aGVuDQo+ID4gPiA+ID4gODAy
LjExcyB3YXMgcnVubmluZyB1bmVuY3J5cHRlZC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBXZSBh
bHNvIHRlc3RlZCB2ZXJzaW9uIDEwLjIuNC45NyAoZnJvbSBjb2RlYXVyb3JhKSwgd2hpY2ggaXMN
Cj4gPiA+ID4gPiBub3cNCj4gPiA+ID4gPiBkZWZhdWx0DQo+ID4gPiA+ID4gaW4NCj4gPiA+ID4g
PiBMRURFLiBIb3dldmVyLCB0aGlzIHZlcnNpb24gYXBwYXJlbnRseSBkb2Vzbid0IHN1cHBvcnQg
MTFzDQo+ID4gPiA+ID4gbWVzaCBhdCBhbGwNCj4gPiA+ID4gPiAoV01JX1NFUlZJQ0VfTUVTSF8x
MVMgaXMgZGlzYWJsZWQgaW4gdGhlIHNlcnZpY2UgbWFwLCBidXQNCj4gPiA+ID4gPiBjZmcvbWFj
ODAyMTENCj4gPiA+ID4gPiBhZHZlcnRpc2VzIHN1cHBvcnQpLg0KPiA+ID4gPiA+IA0KPiA+ID4g
PiA+IFNvIGhlcmUgYXJlIG15IHF1ZXN0aW9uczoNCj4gPiA+ID4gPiDCoCogRGlkIGFueW9uZSBz
dWNjZXNmdWxseSBydW4gQVAgYW5kIG1lc2gsIGJvdGggZW5jcnlwdGVkIGF0DQo+ID4gPiA+ID4g
dGhlIHNhbWUNCj4gPiA+ID4gPiDCoHRpbWU/DQo+ID4gPiA+ID4gwqAqIERvIHlvdSBoYXZlIGFu
eSBwb2ludGVycyBob3cgd2UgY291bGQgZml4IHRoaXM/IENvdWxkIGl0DQo+ID4gPiA+ID4gYmUg
Zml4YWJsZQ0KPiA+ID4gPiA+IMKgaW4NCj4gPiA+ID4gPiDCoHRoZT4NCj4gPiA+ID4gPiANCj4g
PiA+ID4gPiBkcml2ZXIgKGkuZS4gbm90IGluIGZpcm13YXJlKT8NCj4gPiA+ID4gPiANCj4gPiA+
ID4gPiDCoCogRG9lcyBhbnlvbmUgaGF2ZSBhbiBpZGVhIGlmIDExcyB3aWxsIGJlIHN1cHBvcnRl
ZCBpbg0KPiA+ID4gPiA+IGZ1dHVyZQ0KPiA+ID4gPiA+IMKgdmVyc2lvbnM/IEkNCj4gPiA+ID4g
PiANCj4gPiA+ID4gPiBkaWRuJ3QgZmluZCBhbnkgY2hhbmdlbG9ncywgYnV0IGhhdmluZyAxMXMg
bW9kZSBubyBsb25nZXIgaW4NCj4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiBzZXJ2aWNlDQo+ID4g
PiA+ID4gbWFwIGRvZXMgbm90IG1ha2UgbWUgb3B0aW1pc3RpYy4NCj4gPiA+ID4gDQo+ID4gPiA+
IFdoeSBpcyBMRURFIHVzaW5nIDEwLjIuNC45Nz8gSXQgc2VlbXMgdG8gYmUgYSBxdWl0ZSBvbGQg
cmVsZWFzZQ0KPiA+ID4gPiBhbmQgSQ0KPiA+ID4gPiBoYXZlIG5vIGtub3dsZWRnZSBpZiBhbnlv
bmUgZXZlbiB0ZXN0cyB0aGF0IGZpcm13YXJlIGJyYW5jaA0KPiA+ID4gPiB3aXRoIGF0aDEway4N
Cj4gPiA+ID4gSSByZWNvbW1lbmQgdG8gb25seSB1c2UgZmlybXdhcmUgcmVsZWFzZXMgZnJvbSBh
dGgxMGstDQo+ID4gPiA+IGZpcm13YXJlLmdpdCBhcyB3ZQ0KPiA+ID4gPiB1c2UgdGhvc2UgaW50
ZXJuYWxseSB3aXRoIGF0aDEway4gSW4gYW55IGNhc2UsIGRvbid0IG1ha2UgYW55DQo+ID4gPiA+
IGFzc3VtcHRpb25zIGFib3V0IGZ1dHVyZSBmcm9tIHRoYXQgZmlybXdhcmUgYnJhbmNoIGFzIGl0
J3Mgc28NCj4gPiA+ID4gb2xkLg0KPiA+ID4gDQo+ID4gPiBUaGlzIHdhcyBpbnRyb2R1Y2VkIGlu
IERlY2VtYmVyIDI1dGgsIDIwMTUgYWZ0ZXIgc29tZSBmaXJtd2FyZS0NCj4gPiA+IHJlbGF0ZWQN
Cj4gPiA+IHByb2JsZW1zLiBJJ20gQ0MnaW5nIE1hcnRpbiBCbHVtZW5zdGluZ2wgd2hvIHN1Z2dl
c3RlZCB0aGlzDQo+ID4gPiBjaGFuZ2UuDQo+ID4gPiANCj4gPiA+IFNpbmNlIHRoZW4sIGF0aDEw
ayBpcyBwdWxsaW5nIGZpcm13YXJlIGZyb20gaGVyZSAodW5sZXNzIGN0DQo+ID4gPiBmaXJtd2Fy
ZSBpcw0KPiA+ID4gdXNlZCk6DQo+ID4gPiANCj4gPiA+IGh0dHBzOi8vc291cmNlLmNvZGVhdXJv
cmEub3JnL3F1aWMvcXNkay9vc3MvZmlybXdhcmUvYXRoMTBrLWZpcm13DQo+ID4gPiBhcmUvcGxh
aW4NCj4gPiA+IC8NCj4gPiA+IDEwLjIuNC9maXJtd2FyZS01LmJpbl8xMC4yLjQuOTctMQ0KPiA+
ID4gDQo+ID4gPiBIb3dldmVyLCBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIG51bWJlcmluZz8gMTAu
Mi40Ljk3ID4gMTAuMi40LjcwLA0KPiA+ID4gYnV0IHlvdQ0KPiA+ID4gc2F5IDEwLjIuNC43MC40
Mi0yIGlzIG1vcmUgcmVjZW50PyBJIHdvdWxkIGhhdmUgYXNzdW1lZCBvdGhlcndpc2UNCj4gPiA+
IGZyb20NCj4gPiA+IHRoZSBudW1iZXJzLiBIb3dldmVyLCAxMC4yLjQuNzAgaGFzIG11Y2ggbW9y
ZSBzdWItcmV2aXNpb25zLg0KPiA+IA0KPiA+IEFzIEkgc2FpZCBiZWZvcmUsIEkganVzdCBkZWxp
dmVyIHRoZSBmaXJtd2FyZSBmaWxlcyB0byB0aGUNCj4gPiBjb21tdW5pdHkgYW5kDQo+ID4gdGhl
IGZpcm13YXJlIHRlYW0gY3JlYXRlcyB0aGUgYWN0dWFsIHJlbGVhc2VzLiBCdXQgbXkgdW5kZXJz
dGFuZGluZw0KPiA+IGlzDQo+ID4gdGhhdCB0aGVzZSBhcmUgZnJvbSBkaWZmZXJlbnQgYnJhbmNo
ZXMgd2hpY2ggYXJlIGJ1aWx0DQo+ID4gaW5kZXBlbmRlbnRseQ0KPiA+IChhbmQgbWlnaHQgaGF2
ZSBkaWZmZXJlbnQgZmVhdHVyZXMsIGxpa2UgaW4gdGhpcyBjYXNlIHRoZSBtZXNoDQo+ID4gc3Vw
cG9ydCkNCj4gPiBzbyBJIHdvdWxkIG5vdCBtYWtlIGFueSBjb25jbHVzaW9ucyBpZiBhbnkgZmly
bXdhcmUgaXMgImJldHRlciINCj4gPiBqdXN0DQo+ID4gZnJvbSB0aGUgbnVtYmVycyBhbG9uZS4N
Cj4gDQo+IHlvdSBhcmUgcmlnaHQgLi4uIHRob3NlIG51bWJlcnMgYXJlIG5vdCBhIGdvb2QgcG9p
bnRlci4gSSBmb3VuZCB0aGlzDQo+IHJlcG8sIGFuZMKgDQo+IGZyb20gdGhlIGNoZWNraW4gZGF0
ZXMgaXQgbG9va3MgbGlrZSAxMC4yLjQuOTcgaXMgaW5kZWVkIHdheSBvbGRlcg0KPiAoZnJvbcKg
DQo+IFNlcHRlbWJlciAyMDE1KSB0aGFuIDEwLjIuNC43MC40MiAoQXByaWwgMjAxNik6DQo+IA0K
PiBodHRwczovL3NvdXJjZS5jb2RlYXVyb3JhLm9yZy9xdWljL3FzZGsvb3NzL2Zpcm13YXJlL2F0
aDEway1maXJtd2FyZS8NCj4gbG9nLzEwLjIuNA0KPiANCj4gSSB3b3VsZCBhZ3JlZSB0aGF0IENo
YW5nZWxvZ3Mgd291bGQgYmUgaGVscGZ1bC4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmlj
YXRpb24uIFdlIHdpbGwgdGhlbiBzdGljayB0byB0aGUgNzAncyBicmFuY2gNCj4gdGhlbi4NCj4g
DQo+IERvZXMgYW55b25lIGhhdmUgcG9pbnRlcnMgZm9yIHRoZSBvdGhlciBxdWVzdGlvbnM/IDop
IEkgd291bGQgYmVsaWV2ZQ0KPiBoYXQgbWFuecKgDQo+IHBlb3BsZSB3b3VsZCBiZSBpbnRlcmVz
dGVkIGluIHJ1bm5pbmcgQVAgKyBNZXNoIGVuY3J5cHRlZCBhdCB0aGUgc2FtZQ0KPiB0aW1lIChh
dMKgDQo+IGxlYXN0IGluIHRoZSBvcGVuIHNvdXJjZSBjb21tdW5pdHkgLi4uKS4NCg0KV2UncmUg
dGVzdGluZyBlbmNyeXB0ZWQgQVAgKyBNZXNoIHF1aXRlIHN1Y2Nlc3NmdWxseSByaWdodCBub3cg
d2l0aA0KdGhpcyBmaXJtd2FyZTrCoGh0dHBzOi8vZ2l0aHViLmNvbS9rdmFsby9hdGgxMGstZmly
bXdhcmUvY29tbWl0LzMwN2NiNDZiDQowNjY2MWViZDMxODY3MjNiNTAwMmRlNzY5YzdhZGQ4Mywg
b2YgY291cnNlIHRoYXQgaXMgZm9yIGEgUUNBNDAxOSBjaGlwLg0KV2hpY2ggY2hpcCBhcmUgeW91
IHVzaW5nPyBJIGNhbiBwb2tlIHRoZSBmaXJtd2FyZSBndXlzIGZvciBwb3NzaWJpbGl0eQ0Kb2Yg
Z2V0dGluZyBhIDEwLjQuMy4yIGZpcm13YXJlIGJ1aWxkIGZvciBpdC4NCg0KdGhvbWFz

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Tuesday, September 13, 2016 5:54:38 PM CEST Pedersen, Thomas wrote:
> On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
> 
> > [...]
> >
> > Thanks for the clarification. We will then stick to the 70's branch
> > then.
> > 
> > Does anyone have pointers for the other questions? :) I would believe
> > hat many 
> > people would be interested in running AP + Mesh encrypted at the same
> > time (at 
> > least in the open source community ...).
> 
> 
> We're testing encrypted AP + Mesh quite successfully right now with
> this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> Which chip are you using? I can poke the firmware guys for possibility
> of getting a 10.4.3.2 firmware build for it.

Hi Thomas,

thanks for the hint! We are using an older QCA9882. I assume your firmware will 
not work for this one? If you can poke the firmware guys, that would be great. 
:)

We also want to test the 70.52 firmware version next, maybe there were some 
changes since the .42 we used.

Thanks,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote:
[...]
> > We're testing encrypted AP + Mesh quite successfully right now with
> > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> > Which chip are you using? I can poke the firmware guys for possibility
> > of getting a 10.4.3.2 firmware build for it.
> 
> Hi Thomas,
> 
> thanks for the hint! We are using an older QCA9882. I assume your firmware
> will not work for this one? If you can poke the firmware guys, that would
> be great.
> :)
> 
> We also want to test the 70.52 firmware version next, maybe there were some
> changes since the .42 we used.

I have just checked it with 10.2.4.70.54:

               | 802.11s encrypted | 802.11s unencrypted
---------------+-------------------+--------------------
AP encrypted   | AP doesn't beacon | works
AP unencrypted | AP doesn't beacon | works

I've also checked 10.2.4.70.12-2 (doesn't seem to support encrypted mesh at 
all) and with rawmode=1 (makes no difference).

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

[Sven Eckelmann]

[-- Attachment #1.1: Type: text/plain, Size: 2695 bytes --]

On Montag, 19. September 2016 11:34:00 CET Sven Eckelmann wrote:
> On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote:
> [...]
> > > We're testing encrypted AP + Mesh quite successfully right now with
> > > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> > > Which chip are you using? I can poke the firmware guys for possibility
> > > of getting a 10.4.3.2 firmware build for it.
[...]
>                | 802.11s encrypted | 802.11s unencrypted
> ---------------+-------------------+--------------------
> AP encrypted   | AP doesn't beacon | works
> AP unencrypted | AP doesn't beacon | works
> 
> I've also checked 10.2.4.70.12-2 (doesn't seem to support encrypted mesh at 
> all) and with rawmode=1 (makes no difference).

I just tested it with a IPQ4019 with the (10.4-)3.2.1-00050 image. And I see a 
similar problem with it. But the AP was not actually active (device was in AP 
mode but no channel was set and it didn't beacon). So we end up again with an 
incomplete initialized AP but hostapd was running.

I've simply disabled the LEDE wifi stuff and ran the attached autostart.sh 
manually. This seemed to work fine. This is rather odd because the same 
configuration for wpa_supplicant and hostapd was used. It also works fine with 
the normal LEDE setup scripts when encryption on the mesh device is disabled 
and it also works fine with ath9k.

With the LEDE scripts/netifd, hostapd thought that the AP went up:

    root@lede:/# hostapd_cli status
    Selected interface 'wlan0-1'
    state=ENABLED
    phy=phy0
    freq=2462
    num_sta_non_erp=0
    num_sta_no_short_slot_time=0
    num_sta_no_short_preamble=0
    olbc=0
    num_sta_ht_no_gf=0
    num_sta_no_ht=0
    num_sta_ht_20_mhz=0
    num_sta_ht40_intolerant=0
    olbc_ht=1
    ht_op_mode=0x11
    cac_time_seconds=0
    cac_time_left_seconds=N/A
    channel=11
    secondary_channel=0
    ieee80211n=1
    ieee80211ac=0
    bss[0]=wlan0-1
    bssid[0]=ac:86:74:00:0e:35
    ssid[0]=LEDE3-1
    num_sta[0]=0

iw dev didn't think so:

    Interface wlan0-1
            ifindex 13
            wdev 0x5
            addr ac:86:74:00:0e:35
            type AP
            txpower 30.00 dBm

Interestingly, it sometimes (randomly) started to work when the AP interface 
was switched to psk2 for encryption instead of using an unencrypted AP.

Right now, it looks like an odd timing problem. Has someone else a good idea 
what to test?


Btw. we never received any (10.4-)3.2 based firmware for QCA988X from QCA. But 
I am also not sure if I find time to retest it again with QCA988x.

Kind regards,
	Sven

[-- Attachment #1.2: wpa_supplicant.conf --]
[-- Type: text/plain, Size: 164 bytes --]

network={
        ssid="openmesh"
        key_mgmt=SAE
        mode=5
        frequency=2462
        psk="9f0a965af38f2d0a13b66d8b46ab962c"
        mcast_rate=18
}

[-- Attachment #1.3: hostapd.conf --]
[-- Type: text/plain, Size: 459 bytes --]

driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=g
channel=11
ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
interface=wlan0-1
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
auth_algs=1
wpa=0
ssid=LEDE3-1
bridge=br-lan
bssid=00:11:22:33:17:02

[-- Attachment #1.4: wifi.lede.config --]
[-- Type: text/plain, Size: 1246 bytes --]

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/soc/a000000.wifi'
        option htmode 'HT20'
        option disabled '0'

config wifi-iface 'extra_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'LEDE3-1'
        option encryption 'none'
        option disabled 0
        option macaddr 'ac:86:74:00:0e:35'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'LEDE2-1'
        option encryption 'psk2'
        option key 'testtest'
        option macaddr 'ac:86:74:00:0e:36'
        option disabled 1

config wifi-iface 'wmesh0'
        option device 'radio0'
        option ifname 'mesh0'
        option network 'lan'
        option mode 'mesh'
        option mesh_id 'openmesh'
        option disabled '0'
        option mcast_rate '18000'
        option macaddr 'ac:86:74:00:0e:37'
        option mesh_ttl 1
        option mesh_fwding 0
#        option encryption 'none'
        option ieee80211w 1
        option encryption 'psk2+aes'
        option key '9f0a965af38f2d0a13b66d8b46ab962c'

[-- Attachment #1.5: autostart.sh --]
[-- Type: application/x-shellscript, Size: 1039 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ath10k mesh + ap + encryption?

[Pedersen, Thomas]

T24gTW9uLCAyMDE2LTA5LTE5IGF0IDA4OjQzICswMjAwLCBTaW1vbiBXdW5kZXJsaWNoIHdyb3Rl
Og0KPiBPbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTYgNTo1NDozOCBQTSBDRVNUIFBlZGVy
c2VuLCBUaG9tYXMgd3JvdGU6DQo+ID4gT24gVHVlLCAyMDE2LTA5LTEzIGF0IDE0OjMwICswMjAw
LCBTaW1vbiBXdW5kZXJsaWNoIHdyb3RlOg0KPiA+IA0KPiA+ID4gWy4uLl0NCj4gPiA+DQo+ID4g
PiBUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBXZSB3aWxsIHRoZW4gc3RpY2sgdG8gdGhl
IDcwJ3MgYnJhbmNoDQo+ID4gPiB0aGVuLg0KPiA+ID4gDQo+ID4gPiBEb2VzIGFueW9uZSBoYXZl
IHBvaW50ZXJzIGZvciB0aGUgb3RoZXIgcXVlc3Rpb25zPyA6KSBJIHdvdWxkIGJlbGlldmUNCj4g
PiA+IGhhdCBtYW55IA0KPiA+ID4gcGVvcGxlIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gcnVubmlu
ZyBBUCArIE1lc2ggZW5jcnlwdGVkIGF0IHRoZSBzYW1lDQo+ID4gPiB0aW1lIChhdCANCj4gPiA+
IGxlYXN0IGluIHRoZSBvcGVuIHNvdXJjZSBjb21tdW5pdHkgLi4uKS4NCj4gPiANCj4gPiANCj4g
PiBXZSdyZSB0ZXN0aW5nIGVuY3J5cHRlZCBBUCArIE1lc2ggcXVpdGUgc3VjY2Vzc2Z1bGx5IHJp
Z2h0IG5vdyB3aXRoDQo+ID4gdGhpcyBmaXJtd2FyZTogaHR0cHM6Ly9naXRodWIuY29tL2t2YWxv
L2F0aDEway1maXJtd2FyZS9jb21taXQvMzA3Y2I0NmINCj4gPiAwNjY2MWViZDMxODY3MjNiNTAw
MmRlNzY5YzdhZGQ4Mywgb2YgY291cnNlIHRoYXQgaXMgZm9yIGEgUUNBNDAxOSBjaGlwLg0KPiA+
IFdoaWNoIGNoaXAgYXJlIHlvdSB1c2luZz8gSSBjYW4gcG9rZSB0aGUgZmlybXdhcmUgZ3V5cyBm
b3IgcG9zc2liaWxpdHkNCj4gPiBvZiBnZXR0aW5nIGEgMTAuNC4zLjIgZmlybXdhcmUgYnVpbGQg
Zm9yIGl0Lg0KPiANCj4gSGkgVGhvbWFzLA0KPiANCj4gdGhhbmtzIGZvciB0aGUgaGludCEgV2Ug
YXJlIHVzaW5nIGFuIG9sZGVyIFFDQTk4ODIuIEkgYXNzdW1lIHlvdXIgZmlybXdhcmUgd2lsbCAN
Cj4gbm90IHdvcmsgZm9yIHRoaXMgb25lPyBJZiB5b3UgY2FuIHBva2UgdGhlIGZpcm13YXJlIGd1
eXMsIHRoYXQgd291bGQgYmUgZ3JlYXQuIA0KPiA6KQ0KDQpIaSBTaW1vbiwNCg0KQWNjb3JkaW5n
IHRvIGZpcm13YXJlIGd1eXMgdGhlIGxhdGVzdCBjb2RlIGNhbiBhY3R1YWxseSBjb21waWxlIGRv
d24gdG8NCmFueSBjaGlwc2V0LCBzbyBpdCBzaG91bGQgc2ltcGx5IGJlIGEgbWF0dGVyIG9mIGdl
dHRpbmcgYnVpbGRzIHJlbGVhc2VkLg0K

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Friday, September 23, 2016 10:18:49 PM CEST Pedersen, Thomas wrote:
> On Mon, 2016-09-19 at 08:43 +0200, Simon Wunderlich wrote:
> 
> > On Tuesday, September 13, 2016 5:54:38 PM CEST Pedersen, Thomas wrote:
> > 
> > > On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
> > > 
> > > 
> > > > [...]
> > > >
> > > >
> > > >
> > > > Thanks for the clarification. We will then stick to the 70's branch
> > > > then.
> > > > 
> > > > Does anyone have pointers for the other questions? :) I would believe
> > > > hat many 
> > > > people would be interested in running AP + Mesh encrypted at the same
> > > > time (at 
> > > > least in the open source community ...).
> > > 
> > > 
> > > 
> > > We're testing encrypted AP + Mesh quite successfully right now with
> > > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> > > Which chip are you using? I can poke the firmware guys for possibility
> > > of getting a 10.4.3.2 firmware build for it.
> > 
> > 
> > Hi Thomas,
> > 
> > thanks for the hint! We are using an older QCA9882. I assume your firmware
> > will 
 not work for this one? If you can poke the firmware guys, that
> > would be great.> 
> > :)
> 
> 
> Hi Simon,
> 
> According to firmware guys the latest code can actually compile down to
> any chipset, so it should simply be a matter of getting builds released.

Hi Thomas,

thats great news, thanks for the heads up!

How are we going to get those builds released? Who can I ask, or do you want 
to take care of that?

Thanks,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ath10k mesh + ap + encryption?

[Martin Blumenstingl]

Hi Simon,

On Tue, Sep 13, 2016 at 1:13 PM, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>> > we have done some experiments last week on ath10k, trying to run mesh
>> > (802.11s) and access point at the same time, both encrypted.
>> >
>> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
>> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
>> > us a working encrypted 802.11s network. However, starting an AP at the
>> > same time didn't work (AP doesn't beacon). This wasn't a problem when
>> > 802.11s was running unencrypted.
>> >
>> > We also tested version 10.2.4.97 (from codeaurora), which is now default
>> > in
>> > LEDE. However, this version apparently doesn't support 11s mesh at all
>> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>> > advertises support).
>> >
>> > So here are my questions:
>> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
>> >  time?
>> >  * Do you have any pointers how we could fix this? Could it be fixable in
>> >  the>
>> > driver (i.e. not in firmware)?
>> >
>> >  * Does anyone have an idea if 11s will be supported in future versions? I
>> >
>> > didn't find any changelogs, but having 11s mode no longer in the service
>> > map does not make me optimistic.
>>
>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>> have no knowledge if anyone even tests that firmware branch with ath10k.
>> I recommend to only use firmware releases from ath10k-firmware.git as we
>> use those internally with ath10k. In any case, don't make any
>> assumptions about future from that firmware branch as it's so old.
Thanks for clarifying this.

> This was introduced in December 25th, 2015 after some firmware-related
> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>
> Since then, ath10k is pulling firmware from here (unless ct firmware is used):
>
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
> 10.2.4/firmware-5.bin_10.2.4.97-1
I initially updated to version 10.2.4.70.13-2, but we decided to
update to the "latest" firmware back then (see the thread at [0])
With the explanation from Kalle it makes sense to only use the
firmware binaries distributed in his repo (to ensure that the firmware
is tested by QCA's internal team).

> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
> numbers.
That looks strange to me as well

as a side-note: I am currently preparing and testing a patch to update
the ath10k-firmware in LEDE to 10.2.4.70.52


Regards,
Martin


[0] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg35623.html