In the ieee80211_free_sta_keys, the key idx 4 is not deleted, since it
is limited by NUM_DEFAULT_KEYS.
----
Chun-Yeow
On Tue, Jun 18, 2013 at 3:56 PM, Yeoh Chun-Yeow <[email protected]> wrote:
> In authsae, we have a GTK with key index 4 as follow:
> install_key(&nlcfg, peer, CIPHER_AES_CMAC, NL80211_KEYTYPE_GROUP, 4, peer_mgtk);
>
> We may need to delete this key while doing re-authentication for the
> same peer mesh STA due to accidental reboot. Otherwise, this GTK key
> is not deleted.
>
> ---
> Chun-Yeow
>
> On Tue, Jun 18, 2013 at 3:31 PM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2013-06-18 at 12:07 +0800, Chun-Yeow Yeoh wrote:
>>> This is to support key deletion for mesh interface, especially
>>> to be used for key which is not deleted even with the deletion
>>> of peer mesh station.
>>
>> Can you explain which keys in mesh aren't deleted? It seems the
>> per-station keys would be deleted when the station is deleted, and
>> something like "GTK" would be deleted when leaving the mesh?
>>
>> johannes
>>
On Tue, 2013-06-18 at 17:07 +0800, Yeoh Chun-Yeow wrote:
> In sta_info_get_bss, should it be:
>
> if ((sta->sdata == sdata &&
> (sta->sdata->bss && sta->sdata->bss == sdata->bss))
>
> in stead of
>
> if ((sta->sdata == sdata ||
> (sta->sdata->bss && sta->sdata->bss == sdata->bss))
What would the point be? Then we could just as well make it *only*
sta->sdata == sdata
and it'd be the same as sta_info_get(). This is intentional for VLAN
handling.
> Otherwise, it seems that we still manage to get sta pointer even the
> bss is NULL.
What's the problem with that? But if this is a problem maybe we need to
explicitly check for non-NULL?
johannes
In sta_info_get_bss, should it be:
if ((sta->sdata == sdata &&
(sta->sdata->bss && sta->sdata->bss == sdata->bss))
in stead of
if ((sta->sdata == sdata ||
(sta->sdata->bss && sta->sdata->bss == sdata->bss))
Otherwise, it seems that we still manage to get sta pointer even the
bss is NULL.
---
Chun-Yeow
On Tue, Jun 18, 2013 at 4:14 PM, Yeoh Chun-Yeow <[email protected]> wrote:
> In the ieee80211_free_sta_keys, the key idx 4 is not deleted, since it
> is limited by NUM_DEFAULT_KEYS.
>
> ----
> Chun-Yeow
>
> On Tue, Jun 18, 2013 at 3:56 PM, Yeoh Chun-Yeow <[email protected]> wrote:
>> In authsae, we have a GTK with key index 4 as follow:
>> install_key(&nlcfg, peer, CIPHER_AES_CMAC, NL80211_KEYTYPE_GROUP, 4, peer_mgtk);
>>
>> We may need to delete this key while doing re-authentication for the
>> same peer mesh STA due to accidental reboot. Otherwise, this GTK key
>> is not deleted.
>>
>> ---
>> Chun-Yeow
>>
>> On Tue, Jun 18, 2013 at 3:31 PM, Johannes Berg
>> <[email protected]> wrote:
>>> On Tue, 2013-06-18 at 12:07 +0800, Chun-Yeow Yeoh wrote:
>>>> This is to support key deletion for mesh interface, especially
>>>> to be used for key which is not deleted even with the deletion
>>>> of peer mesh station.
>>>
>>> Can you explain which keys in mesh aren't deleted? It seems the
>>> per-station keys would be deleted when the station is deleted, and
>>> something like "GTK" would be deleted when leaving the mesh?
>>>
>>> johannes
>>>
On Tue, 2013-06-18 at 11:36 +0200, Johannes Berg wrote:
> > Otherwise, it seems that we still manage to get sta pointer even the
> > bss is NULL.
>
> What's the problem with that? But if this is a problem maybe we need to
> explicitly check for non-NULL?
I should pay attention ... we already check for non-NULL, so I don't
understand what you're trying to say at all.
Maybe you're looking at old code?
johannes