* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Johannes Berg @ 2017-01-11 13:26 UTC (permalink / raw)
To: Malinen, Jouni, Arend Van Spriel
Cc: linux-wireless@vger.kernel.org, Kushwaha, Purushottam
In-Reply-To: <20170111131335.GB27748@jouni.qca.qualcomm.com>
On Wed, 2017-01-11 at 13:13 +0000, Malinen, Jouni wrote:
>
> > > @@ -172,6 +174,7 @@ static int cfg80211_conn_do_work(struct
> > > wireless_dev *wdev)
> > > case CFG80211_CONN_AUTH_FAILED:
> > > + *treason = NL80211_TIMEOUT_AUTH;
> >
> > ... but it seems AUTH failure always is a timeout?
>
> The CFG80211_CONN_AUTH_FAILED case is currently used only in
> cfg80211_sme_auth_timeout() which is indeed always a timeout.
Might be worth simply renaming it, since you have the reason there
unconditionally?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/3] cfg80211: Add support to randomize TA of Public Action frames
From: Johannes Berg @ 2017-01-11 13:25 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1483984388-30237-2-git-send-email-jouni@qca.qualcomm.com>
On Mon, 2017-01-09 at 19:53 +0200, Jouni Malinen wrote:
>
> + if (!wdev->current_bss &&
> + !wiphy_ext_feature_isset(
> + &rdev->wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA))
> + return -EINVAL;
> + if (wdev->current_bss &&
> + !wiphy_ext_feature_isset(
> + &rdev->wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA_CO
> NNECTED))
> + return -EINVAL;
> + }
This current_bss stuff is going to be somewhat racy, but I guess we can
live with that.
Looks good, but doesn't apply without the first patch.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/3] cfg80211: Add support to sched scan to report better BSSs
From: Johannes Berg @ 2017-01-11 13:22 UTC (permalink / raw)
To: Vamsi, Krishna, Arend Van Spriel, Malinen, Jouni
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <54d6fd2bc55f4c9290402e692ed27005@aphydexm01b.ap.qualcomm.com>
On Wed, 2017-01-11 at 07:48 +0000, Vamsi, Krishna wrote:
> > -----Original Message-----
>
>
> > > + * @relative_rssi_set: Indicates whether @relative_rssi is set
> > > or not.
> >
> > So you see a use-case for doing a scan with @relative_rssi being
> > zero, right?
>
> Yes. Zero value for relative_rssi is also valid.
Or negative even, I guess?
> > > + * @relative_rssi: Relative RSSI threshold in dB to restrict
> > > scan result
> > > + * reporting in connected state to cases where a matching
> > > BSS is
> >
> > determined
> > > + * to have better RSSI than the current connected BSS.
> > > The relative RSSI
> > > + * threshold values are ignored in disconnected state.
> >
> > The description says "better RSSI" so I suppose it could be typed
> > as u8. The last sentence is intended driver behavior
>
> I like to leave this as s8 only. This will leave more flexibility to
> userspace especially in case of more than two bands in future.
I guess you should reword that - instead of "better" it should say how
this value is applied, as a delta to the current RSSI, and then
reporting the result.
However, I don't understand your comment about this being related to
multiple bands, can you clarify? The relative_rssi just determines the
filter after the adjustment(s) done with rssi_adjust, but how could it
be relevant?
The only use case for relative_rssi being negative would be when you
actually *want* to see slightly worse networks than the one you're
connected to, e.g. to determine if you should use them because they
have better parameters (e.g. HT/VHT or soon HE).
> > > + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]) {
> > > + request->relative_rssi = nla_get_s8(
> > > + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_R
> > > SSI]);
> > > + request->relative_rssi_set = true;
> > > + }
> > > +
> > > + if (attrs[NL80211_ATTR_SCHED_SCAN_RSSI_ADJUST]) {
> >
> > Maybe I misread but I thought this attribute to be applicable only
> > if
> > request->relative_rssi_set is true.
>
> @relative_rssi is valid only when @relative_rssi_set is set to true
> and @rssi_adjust is valid only when @relative_rssi is valid. I think
> that is understandable to drivers and there is no need of explicit
> check here.
It wouldn't be problematic to parse the RSSI_ADJUST only when the
others are present though, so that a driver could apply the rssi_adjust
unconditionally (since, if it's not parsed, the delta will be 0.)
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: wext does not need to set monitor channel in managed mode
From: Johannes Berg @ 2017-01-11 13:15 UTC (permalink / raw)
To: Jorge Ramirez-Ortiz; +Cc: linux-wireless, daniel.lezcano, daniel.thompson
In-Reply-To: <1483971949-10014-1-git-send-email-jorge.ramirez-ortiz@linaro.org>
On Mon, 2017-01-09 at 15:25 +0100, Jorge Ramirez-Ortiz wrote:
> There is not a valid reason to attempt setting the monitor channel
> while in managed mode. Since this code path only deals with this
> mode,
> remove the code block.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Johannes Berg @ 2017-01-11 13:14 UTC (permalink / raw)
To: Arend Van Spriel, Dmitry Shmidt; +Cc: linux-wireless
In-Reply-To: <eb6a9c5e-0817-3b63-1e2f-d6bbff867b05@broadcom.com>
> > Well, we might not even need different commands. We need different
> > storage internally, but if you request the results for a given scan
> > ID then you might get a totally different result format? Though
> > that wouldn't lend itself well to query "everything you have" which
> > is also useful. But even then, it could be done by passing the
> > appropriate "report type" attribute to the dump command - we need
> > that anyway for trigger.
>
> True. With "report type" attribute you do not mean the actual
> report_type thing, right. Hopefully you mean the parameter attribute
> that implicitly relates to a "report type".
Right, I wasn't really thinking in terms of attributes while writing
this. OTOH, something like an attribute *would* be needed, no?
> The risk here is that it
> requires careful description of what user-space needs to look for if
> it gets a notification. I think having separate
> notification/retrieval commands lowers the risk of misinterpretation.
Yeah, fair point.
> Not sure if we're getting ahead of ourselves. Yes, we have to
> determine attributes for each scan "report type", but it is not a
> prerequisite for the other topic.
We'll also have to figure out which report types we need at all :)
> I guess to answer the question about the partial results attributes
> we need to know what the possible higher-level use-cases are. Other
> source of information would be to look what is done for g-scan in
> Android "M" or "N", but not sure if that is best approach as we may
> not consider all use-cases.
Right.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Malinen, Jouni @ 2017-01-11 13:13 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Kushwaha, Purushottam
In-Reply-To: <a59ef282-921d-6591-ab33-0a8dd3ef4294@broadcom.com>
On Mon, Jan 09, 2017 at 09:24:56PM +0100, Arend Van Spriel wrote:
> > diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> > @@ -38,6 +38,7 @@ struct cfg80211_conn {
> > CFG80211_CONN_ASSOCIATE_NEXT,
> > CFG80211_CONN_ASSOCIATING,
> > CFG80211_CONN_ASSOC_FAILED,
> > + CFG80211_CONN_ASSOC_FAILED_TIMEOUT,
>=20
> Was kinda expecting AUTH_FAILED_TIMEOUT....
Me too when going through the changes.. But only the association failure
cases had different triggers that needed a change here.
> > @@ -172,6 +174,7 @@ static int cfg80211_conn_do_work(struct wireless_de=
v *wdev)
> > case CFG80211_CONN_AUTH_FAILED:
> > + *treason =3D NL80211_TIMEOUT_AUTH;
>=20
> ... but it seems AUTH failure always is a timeout?
The CFG80211_CONN_AUTH_FAILED case is currently used only in
cfg80211_sme_auth_timeout() which is indeed always a timeout.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-11 12:21 UTC (permalink / raw)
To: IgorMitsyanko, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <ee946686-699c-da64-4932-f58e3f1a83ad@quantenna.com>
On 2017-01-11 13:15, IgorMitsyanko wrote:
> On 01/11/2017 02:30 PM, Felix Fietkau wrote:
>> On 2017-01-11 12:26, IgorMitsyanko wrote:
>>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>>>> On 2017-01-10 11:56, Johannes Berg wrote:
>>>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>>>> in this environment.
>>>>>> In the long term, yes. For now, not quite sure.
>>>>> There's no "for now" in the kernel. Code added now will have to be
>>>>> maintained essentially forever.
>>>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>>>> idea, that would be quite a bit of code duplication.
>>>> This implementation works, it's very simple, and it's quite flexible for
>>>> a number of use cases.
>>>>
>>>> Is there any remaining objection to merging this in principle (aside
>>>> from potential issues with the code)?
>>>>
>>>> - Felix
>>>>
>>>
>>> Hi Felix, can we consider two examples configurations with multicast
>>> traffic:
>>>
>>> 1. AP is a source of multicast traffic itself, no bridge on AP. For
>>> example, wireless video server streaming to several clients.
>>> In this situation, we can not make use of possible advantages given by
>>> mc-to-uc conversion?
>> You could simply put the AP interface in a bridge, no need to have any
>> other bridge members present.
>>
>>> 2. A configuration with AP + STA + 3 client devices behind STA.
>>> ----|client 1|
>>> |
>>> | mc |----|AP|----|STA|---|---|client 2|
>>> |server| |
>>> ----|client 3|
>>>
>>> Multicast server behind AP streams MC video traffic. All 3 clients
>>> behind the STA have joined the multicast group.
>>> I'm not sure if this case will be handled correctly with mc-to-uc
>>> conversion in bridge on AP?
>> What do you mean by "3 client devices behind STA"? Are you using a
>> 4-addr STA, multicast routing, or some kind of vendor specific "client
>> bridge" hackery?
>
> 3 client devices connected by backbone Ethernet network. Generic
> case is probably STA/AP operating in 4-addr mode (more or less standard
> solution as far as I know).
If the AP is running in 4-addr mode, it will need to have a bridge
interface anyway, because the link to the STA will be split out into a
separate virtual interface (AP_VLAN iftype).
In this case you don't actually need any multicast-to-unicast
conversion, because the multicast traffic will be unicast on 802.11
already (due to use of 4-addr mode).
- Felix
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: IgorMitsyanko @ 2017-01-11 12:15 UTC (permalink / raw)
To: Felix Fietkau, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <015bf651-7584-13c0-16b9-d4e29e23c96b@nbd.name>
On 01/11/2017 02:30 PM, Felix Fietkau wrote:
> On 2017-01-11 12:26, IgorMitsyanko wrote:
>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>>> On 2017-01-10 11:56, Johannes Berg wrote:
>>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>>> in this environment.
>>>>> In the long term, yes. For now, not quite sure.
>>>> There's no "for now" in the kernel. Code added now will have to be
>>>> maintained essentially forever.
>>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>>> idea, that would be quite a bit of code duplication.
>>> This implementation works, it's very simple, and it's quite flexible for
>>> a number of use cases.
>>>
>>> Is there any remaining objection to merging this in principle (aside
>>> from potential issues with the code)?
>>>
>>> - Felix
>>>
>>
>> Hi Felix, can we consider two examples configurations with multicast
>> traffic:
>>
>> 1. AP is a source of multicast traffic itself, no bridge on AP. For
>> example, wireless video server streaming to several clients.
>> In this situation, we can not make use of possible advantages given by
>> mc-to-uc conversion?
> You could simply put the AP interface in a bridge, no need to have any
> other bridge members present.
>
>> 2. A configuration with AP + STA + 3 client devices behind STA.
>> ----|client 1|
>> |
>> | mc |----|AP|----|STA|---|---|client 2|
>> |server| |
>> ----|client 3|
>>
>> Multicast server behind AP streams MC video traffic. All 3 clients
>> behind the STA have joined the multicast group.
>> I'm not sure if this case will be handled correctly with mc-to-uc
>> conversion in bridge on AP?
> What do you mean by "3 client devices behind STA"? Are you using a
> 4-addr STA, multicast routing, or some kind of vendor specific "client
> bridge" hackery?
3 client devices connected by backbone Ethernet network. Generic
case is probably STA/AP operating in 4-addr mode (more or less standard
solution as far as I know).
"Client bridge" approach should not concern us here I think, it will
seem to AP and AP's bridge as a single client.
>
> - Felix
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 12:05 UTC (permalink / raw)
To: Cedric Izoard, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <927a79f16e8c429da7a0d06f1bfb2567@ceva-dsp.com>
> I made a quick test with dongle using ath9k_htc driver and I indeed
> reproduce the issue.
Thanks.
> Here is the stack trace I get:
> I added a trace before calling skb_copy_expand to get the headroom of
> the buffer before the copy and the headroom asked by the driver.
>
> [ 83.200261] MESH fwd: skb_headroom=154, needed headroom=24
Could you also add a similar trace just before calling drv_tx()?
Maybe we're adding something else to this skb?
I can't find anything in the ath9k_htc driver that's adding more than
23 bytes (it's advertising 24) but clearly the last 8 bytes here are
failing:
> [ 83.200346] skbuff: skb_under_panic: text:ffffffffa034c028 len:154
> put:8 head:ffff880213422e00 data:ffff880213422dfa tail:0x94 end:0xc0
> dev:<NULL>
Maybe mac80211 is putting something else? It'd have to be
johannes
^ permalink raw reply
* RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Cedric Izoard @ 2017-01-11 11:35 UTC (permalink / raw)
To: Masashi Honma, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1dd6e9f3-5ad2-1138-8017-c0ab208d9f88@gmail.com>
PiBPbiAyMDE35bm0MDHmnIgxMeaXpSAyMDowMSwgSm9oYW5uZXMgQmVyZyB3cm90ZToNCj4gPiBT
dXJlLCBzc2ggd29uJ3QgLSBJIHdhcyB0aGlua2luZyBvZiBuZXRjb25zb2xlOg0KPiA+IGh0dHBz
Oi8vd3d3Lmtlcm5lbC5vcmcvZG9jL0RvY3VtZW50YXRpb24vbmV0d29ya2luZy9uZXRjb25zb2xl
LnR4dA0KPiANCj4gT2gsIEkgc2VlLiBUaGFua3MsIEkgd2lsbCB0cnkuDQo+IA0KPiBNYXNhc2hp
IEhvbm1hLg0KSGksDQoNCkkgbWFkZSBhIHF1aWNrIHRlc3Qgd2l0aCBkb25nbGUgdXNpbmcgYXRo
OWtfaHRjIGRyaXZlciBhbmQgSSBpbmRlZWQgcmVwcm9kdWNlIHRoZSBpc3N1ZS4NCkhlcmUgaXMg
dGhlIHN0YWNrIHRyYWNlIEkgZ2V0Og0KSSBhZGRlZCBhIHRyYWNlIGJlZm9yZSBjYWxsaW5nIHNr
Yl9jb3B5X2V4cGFuZCB0byBnZXQgdGhlIGhlYWRyb29tIG9mIHRoZSBidWZmZXIgYmVmb3JlIHRo
ZSBjb3B5IGFuZCB0aGUgaGVhZHJvb20gYXNrZWQgYnkgdGhlIGRyaXZlci4NCg0KWyAgIDgzLjIw
MDI2MV0gTUVTSCBmd2Q6IHNrYl9oZWFkcm9vbT0xNTQsIG5lZWRlZCBoZWFkcm9vbT0yNA0KWyAg
IDgzLjIwMDM0Nl0gc2tidWZmOiBza2JfdW5kZXJfcGFuaWM6IHRleHQ6ZmZmZmZmZmZhMDM0YzAy
OCBsZW46MTU0IHB1dDo4IGhlYWQ6ZmZmZjg4MDIxMzQyMmUwMCBkYXRhOmZmZmY4ODAyMTM0MjJk
ZmEgdGFpbDoweDk0IGVuZDoweGMwIGRldjo8TlVMTD4NClsgICA4My4yMDAzNTldIC0tLS0tLS0t
LS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgIDgzLjIwMDM2Ml0ga2VybmVsIEJVRyBh
dCAuLi9uZXQvY29yZS9za2J1ZmYuYzoxMDUhDQpbICAgODMuMjAwMzY0XSBpbnZhbGlkIG9wY29k
ZTogMDAwMCBbIzFdIFNNUA0KWyAgIDgzLjIwMDM2Nl0gTW9kdWxlcyBsaW5rZWQgaW46IGF0aDlr
X2h0YyBhdGg5a19jb21tb24gYXRoOWtfaHcgYXRoMTBrX3BjaSBhdGgxMGtfY29yZSBtYWM4MDIx
MSBhdGggY2ZnODAyMTEgeDg2X3BrZ190ZW1wX3RoZXJtYWwNClsgICA4My4yMDAzNzddIENQVTog
NCBQSUQ6IDI5IENvbW06IGtzb2Z0aXJxZC80IE5vdCB0YWludGVkIDQuOS4wKyAjMw0KWyAgIDgz
LjIwMDM3OV0gSGFyZHdhcmUgbmFtZTogRGVsbCBJbmMuIE9wdGlQbGV4IDk5MC8wNkQ3VFIsIEJJ
T1MgQTE5IDA4LzI2LzIwMTUNClsgICA4My4yMDAzODFdIHRhc2s6IGZmZmY4ODAyMjNlNTVjYzAg
dGFzay5zdGFjazogZmZmZmM5MDAwMGRiODAwMA0KWyAgIDgzLjIwMDM4M10gUklQOiAwMDEwOls8
ZmZmZmZmZmY4MTcwMDk0Yz5dICBbPGZmZmZmZmZmODE3MDA5NGM+XSBza2JfcGFuaWMrMHg1Yy8w
eDYwDQpbICAgODMuMjAwMzkxXSBSU1A6IDAwMTg6ZmZmZmM5MDAwMGRiYmJhMCAgRUZMQUdTOiAw
MDAxMDI4Ng0KWyAgIDgzLjIwMDM5M10gUkFYOiAwMDAwMDAwMDAwMDAwMDg2IFJCWDogMDAwMDAw
MDAwMDAwMDAwNiBSQ1g6IDAwMDAwMDAwMDAwMDAwMDANClsgICA4My4yMDAzOThdIFJEWDogZmZm
Zjg4MDIyNTMxMjZkOCBSU0k6IGZmZmY4ODAyMjUzMGNiMjggUkRJOiBmZmZmODgwMjI1MzBjYjI4
DQpbICAgODMuMjAwNDAwXSBSQlA6IGZmZmZjOTAwMDBkYmJiYzAgUjA4OiAwMDAwMDAwMDAwMDMw
ZTlhIFIwOTogMDAwMDAwMDAwMDAwMDAwNQ0KWyAgIDgzLjIwMDQwMV0gUjEwOiAwMDAwMDAwMDAw
MDAwMDAwIFIxMTogMDAwMDAwMDAwMDAwMDJjOCBSMTI6IGZmZmY4ODAyMjJkMGEwMDANClsgICA4
My4yMDA0MDNdIFIxMzogMDAwMDAwMDAwMDAwOTIwMCBSMTQ6IGZmZmY4ODAyMjFiYTdmMDAgUjE1
OiAwMDAwMDAwMDAwMDAwMDEwDQpbICAgODMuMjAwNDA2XSBGUzogIDAwMDAwMDAwMDAwMDAwMDAo
MDAwMCkgR1M6ZmZmZjg4MDIyNTMwMDAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAwMDAwDQpb
ICAgODMuMjAwNDA4XSBDUzogIDAwMTAgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAwMDgw
MDUwMDMzDQpbICAgODMuMjAwNDEwXSBDUjI6IDAwMDA3ZmQ0MTQwMTBjOTggQ1IzOiAwMDAwMDAw
MjIyNDdkMDAwIENSNDogMDAwMDAwMDAwMDA0MDZlMA0KWyAgIDgzLjIwMDQxMV0gU3RhY2s6DQpb
ICAgODMuMjAwNDEzXSAgZmZmZjg4MDIxMzQyMmRmYSAwMDAwMDAwMDAwMDAwMDk0IDAwMDAwMDAw
MDAwMDAwYzAgZmZmZmZmZmY4MWMzMDhkOQ0KWyAgIDgzLjIwMDQxN10gIGZmZmZjOTAwMDBkYmJi
ZDAgZmZmZmZmZmY4MTcwMTliNyBmZmZmYzkwMDAwZGJiYzAwIGZmZmZmZmZmYTAzNGMwMjgNClsg
ICA4My4yMDA0MjBdICBmZmZmODgwMjIxYmE3ZjAwIGZmZmY4ODAyMjI2ZDE1YTAgMDAwMDAwMDAw
MDAwMDAwMCBmZmZmYzkwMDAwZGJiY2I4DQpbICAgODMuMjAwNDIzXSBDYWxsIFRyYWNlOg0KWyAg
IDgzLjIwMDQyOV0gIFs8ZmZmZmZmZmY4MTcwMTliNz5dIHNrYl9wdXNoKzB4MzcvMHg0MA0KWyAg
IDgzLjIwMDQzNV0gIFs8ZmZmZmZmZmZhMDM0YzAyOD5dIGh0Y19pc3N1ZV9zZW5kLmNvbnN0cHJv
cC4yKzB4MjgvMHg2MCBbYXRoOWtfaHRjXQ0KWyAgIDgzLjIwMDQ0MV0gIFs8ZmZmZmZmZmZhMDM0
YzNkMT5dIGh0Y19zZW5kKzB4MTEvMHgyMCBbYXRoOWtfaHRjXQ0KWyAgIDgzLjIwMDQ0NV0gIFs8
ZmZmZmZmZmZhMDM0ZmJkNz5dIGF0aDlrX2h0Y190eF9zdGFydCsweGQ3LzB4MmEwIFthdGg5a19o
dGNdDQpbICAgODMuMjAwNDUwXSAgWzxmZmZmZmZmZmEwMzUxMzI4Pl0gYXRoOWtfaHRjX3R4KzB4
YTgvMHhkMCBbYXRoOWtfaHRjXQ0KWyAgIDgzLjIwMDQ3MV0gIFs8ZmZmZmZmZmZhMDBkNzAyNz5d
IGllZWU4MDIxMV90eF9mcmFncysweDEzNy8weDFmMCBbbWFjODAyMTFdDQpbICAgODMuMjAwNDg5
XSAgWzxmZmZmZmZmZmEwMGQ3MWZjPl0gX19pZWVlODAyMTFfdHgrMHg3Yy8weDE4MCBbbWFjODAy
MTFdDQpbICAgODMuMjAwNTA2XSAgWzxmZmZmZmZmZmEwMGRjNTc1Pl0gaWVlZTgwMjExX3R4KzB4
ZTUvMHgxMTAgW21hYzgwMjExXQ0KWyAgIDgzLjIwMDUxOF0gIFs8ZmZmZmZmZmZhMDBkZGRlZj5d
IGllZWU4MDIxMV90eF9wZW5kaW5nKzB4OGYvMHgxZjAgW21hYzgwMjExXQ0KWyAgIDgzLjIwMDUy
Ml0gIFs8ZmZmZmZmZmY4MTA5MDM4Nj5dID8gcGlja19uZXh0X3Rhc2tfZmFpcisweDQwNi8weDQ3
MA0KWyAgIDgzLjIwMDUyOF0gIFs8ZmZmZmZmZmY4MTA1ZjExYT5dIHRhc2tsZXRfYWN0aW9uKzB4
ZGEvMHhmMA0KWyAgIDgzLjIwMDUzMl0gIFs8ZmZmZmZmZmY4MTA1ZjZjMj5dIF9fZG9fc29mdGly
cSsweGUyLzB4MjcwDQpbICAgODMuMjAwNTM2XSAgWzxmZmZmZmZmZjgxMDVmODY3Pl0gcnVuX2tz
b2Z0aXJxZCsweDE3LzB4MzANClsgICA4My4yMDA1NDBdICBbPGZmZmZmZmZmODEwN2E1NjU+XSBz
bXBib290X3RocmVhZF9mbisweDEwNS8weDE2MA0KWyAgIDgzLjIwMDU0M10gIFs8ZmZmZmZmZmY4
MTA3YTQ2MD5dID8gc29ydF9yYW5nZSsweDIwLzB4MjANClsgICA4My4yMDA1NDddICBbPGZmZmZm
ZmZmODEwNzZkZTU+XSBrdGhyZWFkKzB4YzUvMHhlMA0KWyAgIDgzLjIwMDU1MF0gIFs8ZmZmZmZm
ZmY4MTA3NmQyMD5dID8ga3RocmVhZF9wYXJrKzB4NjAvMHg2MA0KWyAgIDgzLjIwMDU1NF0gIFs8
ZmZmZmZmZmY4MTg1OGJkMj5dIHJldF9mcm9tX2ZvcmsrMHgyMi8weDMwDQpbICAgODMuMjAwNTU2
XSBDb2RlOiBjNCAwMCAwMCAwMCA0OCA4OSA0NCAyNCAxMCA4YiA4NyBjMCAwMCAwMCAwMCA0OCA4
OSA0NCAyNCAwOCA0OCA4YiA4NyBkMCAwMCAwMCAwMCA0OCBjNyBjNyAyOCA1NyBjMyA4MSA0OCA4
OSAwNCAyNCBlOCAxNSA3OCBhMiBmZiA8MGY+IDBiIDY2IDkwIDU1IDQ4IDg5IGU1IDQxIDU3IDQx
IDU2IDQxIDU1IDQxIDU0IDUzIDY1IDRjIDhiIDM0DQpbICAgODMuMjAwNTk2XSBSSVAgIFs8ZmZm
ZmZmZmY4MTcwMDk0Yz5dIHNrYl9wYW5pYysweDVjLzB4NjANClsgICA4My4yMDA2MDJdICBSU1Ag
PGZmZmZjOTAwMDBkYmJiYTA+DQoNCmNlZHJpYw0K
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-11 11:30 UTC (permalink / raw)
To: IgorMitsyanko, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <058f2afd-2502-e2e5-6427-1536fcd5851f@quantenna.com>
On 2017-01-11 12:26, IgorMitsyanko wrote:
> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>> On 2017-01-10 11:56, Johannes Berg wrote:
>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>> in this environment.
>>>>
>>>> In the long term, yes. For now, not quite sure.
>>>
>>> There's no "for now" in the kernel. Code added now will have to be
>>> maintained essentially forever.
>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>> idea, that would be quite a bit of code duplication.
>> This implementation works, it's very simple, and it's quite flexible for
>> a number of use cases.
>>
>> Is there any remaining objection to merging this in principle (aside
>> from potential issues with the code)?
>>
>> - Felix
>>
>
>
> Hi Felix, can we consider two examples configurations with multicast
> traffic:
>
> 1. AP is a source of multicast traffic itself, no bridge on AP. For
> example, wireless video server streaming to several clients.
> In this situation, we can not make use of possible advantages given by
> mc-to-uc conversion?
You could simply put the AP interface in a bridge, no need to have any
other bridge members present.
> 2. A configuration with AP + STA + 3 client devices behind STA.
> ----|client 1|
> |
> | mc |----|AP|----|STA|---|---|client 2|
> |server| |
> ----|client 3|
>
> Multicast server behind AP streams MC video traffic. All 3 clients
> behind the STA have joined the multicast group.
> I'm not sure if this case will be handled correctly with mc-to-uc
> conversion in bridge on AP?
What do you mean by "3 client devices behind STA"? Are you using a
4-addr STA, multicast routing, or some kind of vendor specific "client
bridge" hackery?
- Felix
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: IgorMitsyanko @ 2017-01-11 11:26 UTC (permalink / raw)
To: Felix Fietkau, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <73f29777-cf95-de99-f7a9-9d82e94c298d@nbd.name>
On 01/11/2017 12:27 AM, Felix Fietkau wrote:
> On 2017-01-10 11:56, Johannes Berg wrote:
>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>> in this environment.
>>>
>>> In the long term, yes. For now, not quite sure.
>>
>> There's no "for now" in the kernel. Code added now will have to be
>> maintained essentially forever.
> I'm not sure that putting the IGMP snooping code in mac80211 is a good
> idea, that would be quite a bit of code duplication.
> This implementation works, it's very simple, and it's quite flexible for
> a number of use cases.
>
> Is there any remaining objection to merging this in principle (aside
> from potential issues with the code)?
>
> - Felix
>
Hi Felix, can we consider two examples configurations with multicast
traffic:
1. AP is a source of multicast traffic itself, no bridge on AP. For
example, wireless video server streaming to several clients.
In this situation, we can not make use of possible advantages given by
mc-to-uc conversion?
2. A configuration with AP + STA + 3 client devices behind STA.
----|client 1|
|
| mc |----|AP|----|STA|---|---|client 2|
|server| |
----|client 3|
Multicast server behind AP streams MC video traffic. All 3 clients
behind the STA have joined the multicast group.
I'm not sure if this case will be handled correctly with mc-to-uc
conversion in bridge on AP?
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-11 11:10 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, Cedric.Izoard
In-Reply-To: <1484132519.23671.12.camel@sipsolutions.net>
On 2017年01月11日 20:01, Johannes Berg wrote:
> Sure, ssh won't - I was thinking of netconsole:
> https://www.kernel.org/doc/Documentation/networking/netconsole.txt
Oh, I see. Thanks, I will try.
Masashi Honma.
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 11:01 UTC (permalink / raw)
To: Masashi Honma, linux-wireless, Cedric.Izoard
In-Reply-To: <670a7439-50b9-4f07-1d7d-cb915547562e@gmail.com>
On Wed, 2017-01-11 at 19:36 +0900, Masashi Honma wrote:
> On 2017年01月11日 19:00, Johannes Berg wrote:
> > Nevertheless, I don't have hardware to try to reproduce it, and I
> > can't
> > see any such issues (even with real forwarding, I even just wrote a
> > wpa_s test for that) in hwsim.
> >
> > Even a photo of the crash on the VT would help. Or maybe you can
> > set up
> > netconsole on the wired interface?
>
> Thanks but SSH console via wired interface and laptop display does
> not show any log...
Sure, ssh won't - I was thinking of netconsole:
https://www.kernel.org/doc/Documentation/networking/netconsole.txt
johannes
^ permalink raw reply
* Re: [1/2] ath10k: add accounting for the extended peer statistics
From: Valo, Kalle @ 2017-01-11 10:49 UTC (permalink / raw)
To: Christian Lamparter
Cc: Mohammed Shafi Shajakhan, linux-wireless,
ath10k@lists.infradead.org
In-Reply-To: <2769662.Qa6eUCGVkY@debian64>
Christian Lamparter <chunkeey@googlemail.com> writes:
> Hello Shafi and Kalle,
>
> On Tuesday, January 3, 2017 10:58:27 AM CET Mohammed Shafi Shajakhan wrot=
e:
>> On Fri, Dec 30, 2016 at 03:35:10PM +0100, Christian Lamparter wrote:
>> > On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo@qca.qualcomm.com> w=
rote:
>> > > Christian Lamparter <chunkeey@googlemail.com> wrote:
>> > >> The 10.4 firmware adds extended peer information to the
>> > >> firmware's statistics payload. This additional info is
>> > >> stored as a separate data field and the elements are
>> > >> stored in their own "peers_extd" list.
>> > >>
>> > >> These elements can pile up in the same way as the peer
>> > >> information elements. This is because the
>> > >> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
>> > >> pull the same amount (num_peer_stats) for every statistic
>> > >> data unit.
>> > >>
>> > >> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats updat=
e")
>> > >> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
>> > >
>> > > My understanding is that I should skip this patch 1. Please let me k=
now if
>> > > I misunderstood. But I'm still plannning to apply patch 2.
>> >=20
>> > I added Mohammed (I hope, he can reply to the open question when he
>> > returns), Since I'm not sure what he wants or not.
>> >=20
>> > As far as I'm aware, the "extended" boolean serves no purpose
>> > because it was only used in once place in debugfs_sta which was
>> > removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
>> > and "ath10k_sta_update_extd_stats_rx_duration" have been unified).
>>=20
>> [shafi] We will wait for Kalle to review from the de-ferred stage
>> and get his opinion as well(regarding the design change).
>> I have no concerns as long this does not changes the existing behaviour.
>> thank you !
>
> Thank you Shafi for sticking around. I just fished your response to=20
> "Re: [PATCH] ath10k: merge extended peer info data with existing peers in=
fo" [0].
> out of my spam-bucket. Kalle, please look if your copy of the mail got=20
> flagged/deleted as well. Judging from the reply in this thread, I think y=
ou
> overlooked it as well?=20
I think I just read the discussion to hastily as it was rather long,
sorry about that.
After really long or confusin discussions, just to help the maintainers
and also avoid miscommunication between participants, it's usually a
good idea to summarise the conclusion. If us maintainers need to figure
out the conclusion ourselves from a long discussion we are bound to make
mistakes, just like I did here.
So something like this would help me a lot:
"Kalle, please drop these patches. I need to work on these a bit more."
Or:=20
"Kalle, me and John came to agreement about foo. So these should be good
to apply."
> After reading it, I think the previous post and the request to put the pa=
tch
> on wait was unnecessary. As of now, it seems to me that the open question=
s
> between us have been settled amically (so to speak). Kalle, do you have a=
ny
> concerns or can you put this in the next round then?
If you both are happy with the patch, I'm happy to take it :)
I actived the patch again in my queue by moving the state from Deferred
to New:
https://patchwork.kernel.org/patch/9461631/
If all goes well I'm expecting to apply it later this week.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-11 10:36 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, Cedric.Izoard
In-Reply-To: <1484128809.23671.11.camel@sipsolutions.net>
On 2017年01月11日 19:00, Johannes Berg wrote:
> Nevertheless, I don't have hardware to try to reproduce it, and I can't
> see any such issues (even with real forwarding, I even just wrote a
> wpa_s test for that) in hwsim.
>
> Even a photo of the crash on the VT would help. Or maybe you can set up
> netconsole on the wired interface?
Thanks but SSH console via wired interface and laptop display does not
show any log...
Masashi Honma.
^ permalink raw reply
* Re: ad-hoc in 5GHz
From: Belisko Marek @ 2017-01-11 10:23 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20170111101031.GA2927@redhat.com>
Hi Stanislaw,
On Wed, Jan 11, 2017 at 11:10 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Hi
>
> On Wed, Jan 11, 2017 at 09:36:00AM +0100, Belisko Marek wrote:
>> this should be general question. I'm using [0] ralink driver to setup
>
> It's Realtek not Ralink, right ?
Ah sorry yes it's Realtek.
>
>> ad-hoc mode. It works fine in 2.4GHz band (channel 1) but when I try
>> to setup ad-hoc for 5GHz (channel 50) it seems it's not working at all
>> (I tried to scan with other device but I cannot ad-hoc network). So my
>> question should ad-hoc mode work in 5GHz band also or there are some
>> restrictions? Many thanks.
>
> Depending on regulatory setting IBSS or IR (initialize radiation) can be
> prohibited on some 5GHz channels, check "iw phy" to see which 5GHz channels
> are allowed to use. If HW hardcoded regulatory do not prohibits IBSS on all
> 5GHZ channels it can be matter or setting proper regulatory domain
> (configure timezone properly and then setregdomain will set domain based
> on it).
I did check that and I use 'iw reg set US' (to setup other regulatory
than 00). But despite of that
I still cannot get 5GHz working. Maybe it's driver issue. Thanks.
>
> Regards
> Stanislaw
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: ad-hoc in 5GHz
From: Stanislaw Gruszka @ 2017-01-11 10:10 UTC (permalink / raw)
To: Belisko Marek; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAAfyv37ZFHkZWfq_gAB7XiqtDqVeT+SG7jfXxnCq2fyzYEKX_w@mail.gmail.com>
Hi
On Wed, Jan 11, 2017 at 09:36:00AM +0100, Belisko Marek wrote:
> this should be general question. I'm using [0] ralink driver to setup
It's Realtek not Ralink, right ?
> ad-hoc mode. It works fine in 2.4GHz band (channel 1) but when I try
> to setup ad-hoc for 5GHz (channel 50) it seems it's not working at all
> (I tried to scan with other device but I cannot ad-hoc network). So my
> question should ad-hoc mode work in 5GHz band also or there are some
> restrictions? Many thanks.
Depending on regulatory setting IBSS or IR (initialize radiation) can be
prohibited on some 5GHz channels, check "iw phy" to see which 5GHz channels
are allowed to use. If HW hardcoded regulatory do not prohibits IBSS on all
5GHZ channels it can be matter or setting proper regulatory domain
(configure timezone properly and then setregdomain will set domain based
on it).
Regards
Stanislaw
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 10:00 UTC (permalink / raw)
To: Masashi Honma, linux-wireless, Cedric.Izoard
In-Reply-To: <12d8a797-6c51-4a79-2820-1f9e2e72b2f5@gmail.com>
> I will call the mesh peers "STA A" and "STA B".
>
> Both STA has one physical wireless I/F and wired I/F.
Ok.
[snip configuration]
> Then STA A or STA B crashes, not both.
Nevertheless, I don't have hardware to try to reproduce it, and I can't
see any such issues (even with real forwarding, I even just wrote a
wpa_s test for that) in hwsim.
Even a photo of the crash on the VT would help. Or maybe you can set up
netconsole on the wired interface?
johannes
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-11 9:38 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, Cedric.Izoard
In-Reply-To: <1484125220.23671.1.camel@sipsolutions.net>
On 2017年01月11日 18:00, Johannes Berg wrote:
> Ok, that's strange, but maybe there's a reason.
>
> Can you extract *any* information whatsoever? Like maybe if you switch
> to a VT console before running into the crash? I don't have any
> hardware to run this on, and hwsim doesn't have any issues.
I will call the mesh peers "STA A" and "STA B".
Both STA has one physical wireless I/F and wired I/F.
I have connected to both with SSH via wired I/F and started
wpa_supplicant with this command for both.
sudo ./hostap/wpa_supplicant/wpa_supplicant -i <ifname> -D nl80211 -c
mesh_sae.conf
STA A's mesh_sae.conf is this.
----------------------
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
user_mpm=1
update_config=0
network={
ssid="mesh0"
key_mgmt=SAE
mode=5
frequency=2412
psk="01234567"
}
----------------------
STA B's mesh_sae.conf is this. The difference is "no_auto_peer=1".
----------------------
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
user_mpm=1
update_config=0
network={
ssid="mesh0"
key_mgmt=SAE
mode=5
frequency=2412
psk="01234567"
no_auto_peer=1
}
----------------------
Booting the wpa_supplicant finishes successfully.
After the successfull peering process, I could see
MESH-PEER-CONNECTED
message on both side.
Then STA A or STA B crashes, not both.
Masashi Honma.
^ permalink raw reply
* Re: [PATCH v9] Add new mac80211 driver mwlwifi.
From: Johannes Berg @ 2017-01-11 9:25 UTC (permalink / raw)
To: David Lin, Kalle Valo
Cc: linux-wireless@vger.kernel.org, Chor Teck Law, James Lin,
Pete Hsieh
In-Reply-To: <5b561668eb5b4804b0007d03bc723f9d@SC-EXCH02.marvell.com>
On Tue, 2017-01-10 at 01:32 +0000, David Lin wrote:
> > The only thing that really seems questionable to me is the whole
> > beacon parsing (and apparent rebuilding in firmware?). It's very
> > odd that you could do that, with a softmac device where all the
> > authentication and association is handled by hostapd anyway, and
> > you can't possibly pretend to handle everything hostapd might throw
> > at you - this will mean that you'll have features hostapd and every
> > other mac80211 supports that you will silently drop afaict - which
> > is rather unexpected.
> >
> > First, you're parsing the data obtained from hostapd, in
> > mwl_fwcmd_parse_beacon(), and then you send them all to the
> > firmware in mwl_fwcmd_set_ies(), but only the things you actually
> > understood. New higher-level features you don't understand, or
> > vendor beacon IEs that aren't WMM, would be completely dropped.
> >
> > I'm not very happy with that behaviour.
> >
> > Why does the firmware require this? Why not just pack all IEs into
> > the pcmd->ie_list_len_proprietary, and leave everything else 0? Or
> > - if perhaps firmware for some reason requires HT/VHT to be treated
> > specially, only parse out the ones that are really needed specially
> > and leave everything else in the ie_list_len_proprietary?
> >
> > Also, this is dropping all the encryption stuff - even those are
> > extensible btw, and hostapd might do so. Having the firmware
> > rebuild those out of out-of-band information is very unexpected for
> > a mac80211 driver.
> >
>
> This driver just extracts needed IEs which is used for the host
> command of firmware. I think we will not support other vendor IEs.
> And if needed, we can add them to pcmd->ie_list_proprietary.
Sure, I see that you're doing this. It still makes no sense though,
since all management frames are handled by hostapd anyway. It would
make some sense if you actually were going to handle association in the
firmware, but it makes no sense here, as far as I can tell.
I'm not sure how hard a line I should draw here, but I'll warn you now
that I won't take this into consideration when adding new features to
mac80211, and certainly Jouni won't take it into account when adding
new features to hostapd, so that such new features will then SILENTLY
and UNEXPECTEDLY (due to mac80211) not work with your driver.
I strongly advise you to reconsider this and try to pass through all
the IEs so that newly added features that shouldn't require firmware
interaction (since hostapd is handling all the association handshake
and IEs to advertise the feature) will automatically and cleanly work.
If you really can't do that, for some reason, then for my benefit as
the mac80211 maintainer and future maintainers of your driver, I'd like
to have documentation in the driver as to why the firmware needs the
driver to split up all those IEs and what it does with them. After all,
a common-sense analysis would suggest that the firmware has no need for
it, since all configuration should come through other places and all
IEs are just for going out on the air.
johannes
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Johannes Berg @ 2017-01-11 9:17 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev, David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Felix Fietkau, Michael Braun
In-Reply-To: <20170109231203.GC5513@otheros>
> > Exactly. My point is that this is breaking the expectation that
> > hosts are actually able to drop such packets.
>
> [readding CCs I removed earlier]
>
> Ah! Thanks. I was worried about creating packetloss :D.
Ah, well, no - at least not in this case.
> Hm, for this other other way round, I think it does not apply for
> the bridge multicast-to-unicast patch if I'm not misreading the
> bridge code:
>
> For a packet with a link-layer multicast address but a unicast IP
> destination, the bridge MDB lookup will fail.
> (http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8
> #L178
> returns NULL)
>
> Case A): No multicast router on port:
> -> bridge, br_multicast_flood(), will drop the packet already
> (no matter if multicast-to-unicast is enabled or not)
>
> Case B): Multicast router present on port:
> -> The new patch does not apply multicast-to-unicast but just floods
> packet unaltered
> ("else { port = rport; addr = NULL; }" branch)
Ah, interesting. This is different then - the mac80211 code is not L3
aware at all.
johannes
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 9:00 UTC (permalink / raw)
To: Masashi Honma, linux-wireless, Cedric.Izoard
In-Reply-To: <aa60ffb2-b756-b807-4976-20f2eca6665d@gmail.com>
On Wed, 2017-01-11 at 17:50 +0900, Masashi Honma wrote:
> On 2017年01月11日 17:02, Johannes Berg wrote:
> > I don't think this makes sense - if you only have two peers then
> > you
> > shouldn't even run into forwarding code paths?
> >
> > johannes
>
> Though it looks odd, the code has run into forwarding code path even
> though peer to peer mesh connection.
>
> fwd_skb = skb_copy(skb, GFP_ATOMIC);
>
> I checked it with printk().
>
> # I know printk() should not be used in the context, just for
> checking.
Ok, that's strange, but maybe there's a reason.
Can you extract *any* information whatsoever? Like maybe if you switch
to a VT console before running into the crash? I don't have any
hardware to run this on, and hwsim doesn't have any issues.
johannes
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-11 8:50 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, Cedric.Izoard
In-Reply-To: <1484121737.23671.0.camel@sipsolutions.net>
On 2017年01月11日 17:02, Johannes Berg wrote:
> I don't think this makes sense - if you only have two peers then you
> shouldn't even run into forwarding code paths?
>
> johannes
Though it looks odd, the code has run into forwarding code path even
though peer to peer mesh connection.
fwd_skb = skb_copy(skb, GFP_ATOMIC);
I checked it with printk().
# I know printk() should not be used in the context, just for checking.
Masashi Honma.
^ permalink raw reply
* ad-hoc in 5GHz
From: Belisko Marek @ 2017-01-11 8:36 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
this should be general question. I'm using [0] ralink driver to setup
ad-hoc mode. It works fine in 2.4GHz band (channel 1) but when I try
to setup ad-hoc for 5GHz (channel 50) it seems it's not working at all
(I tried to scan with other device but I cannot ad-hoc network). So my
question should ad-hoc mode work in 5GHz band also or there are some
restrictions? Many thanks.
[0] - https://github.com/diederikdehaas/rtl8812AU
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox