mac80211: Fix headroom allocation when forwarding mesh pkt

2017-01-11 Thread Cedric Izoard
This patch fix issue introduced by commit "mac80211: Ensure enough headroom when forwarding mesh pkt" When forwarding mesh pkt, mac80211 may also add security header, and it must therefore be taken into account in the needed headroom. Signed-off-by: Cedric Izoard --- net/mac8021

RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash

2017-01-11 Thread Cedric Izoard
> > When calling drv_tx() the headroom is not big enough for the driver. > > Ok. > > > > > > > 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 h

RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash

2017-01-11 Thread Cedric Izoard
> > 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

RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash

2017-01-11 Thread Cedric Izoard
> 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. Hi, I made a quick test with dongle using ath9k_htc driver and I indeed re

RE: [PATCH] mac80211: Ensure enough headroom when forwarding mesh pkt

2016-12-07 Thread Cedric Izoard
> > - fwd_skb = skb_copy(skb, GFP_ATOMIC); > > + if (skb_headroom(skb) >= local->tx_headroom) > > + fwd_skb = skb_copy(skb, GFP_ATOMIC); > > + else > > + fwd_skb = skb_copy_expand(skb, local->tx_headroom, > > +   0, GFP_ATOMIC); > > Why b

[PATCH v2] mac80211: Ensure enough headroom when forwarding mesh pkt

2016-12-07 Thread Cedric Izoard
When a buffer is duplicated during MESH packet forwarding, this patch ensures that the new buffer has enough headroom. Signed-off-by: Cedric Izoard --- net/mac80211/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index d2a00f2

[PATCH] mac80211: Ensure enough headroom when forwarding mesh pkt

2016-12-06 Thread Cedric Izoard
When a buffer is duplicated during MESH packet forwarding, this patch ensures that the new buffer has enough headroom. Signed-off-by: Cedric Izoard --- net/mac80211/rx.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index d2a00f2

[PATCH v4] mac80211: Get IV len from key conf and not cipher scheme

2015-03-17 Thread Cedric Izoard
ength is then read from key->conf.iv_len initialized with cs->hdr_len. Signed-off-by: Cedric Izoard --- net/mac80211/key.c | 1 + net/mac80211/key.h | 1 + net/mac80211/wpa.c | 13 ++--- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/net/mac80211/key.c b/net/m

[PATCH v3] mac80211: Get IV len from key conf and not cipher scheme

2015-03-11 Thread Cedric Izoard
ength is then read from key->conf.iv_len initialized with cs->hdr_len. Signed-off-by: Cedric Izoard --- Sorry I didn't paid enough attention in my previous mail include/net/mac80211.h | 5 - net/mac80211/key.c | 1 + net/mac80211/wpa.c | 13 ++--- 3 files chan

[PATCH v3] mac80211: Get-IV-len-from-key-conf-and-not-cipher-scheme

2015-03-11 Thread Cedric Izoard
When a key is installed using a cipher scheme, a new flag IEE80211_KEY_FLAG_CIPHER_SCHEME is set. This flag is used on TX path to test for "cipher scheme" key, instead of testing for sta->cipher_scheme as sta is NULL for bcast/mcast messages. For cipher scheme key, security header length is then re

Re: [PATCH v2] mac80211: Get IV len from key conf and not cipher scheme

2015-03-10 Thread Cedric Izoard
On 10/03/2015 17:48, Johannes Berg wrote: > On Tue, 2015-03-10 at 16:46 +0000, Cedric Izoard wrote: >>> How can this be correct? You have a cipher scheme, so you want to >>> encrypt, but now you're not doing that? Perhaps you should drop the >>> frame instead? &

Re: [PATCH v2] mac80211: Get IV len from key conf and not cipher scheme

2015-03-10 Thread Cedric Izoard
> How can this be correct? You have a cipher scheme, so you want to > encrypt, but now you're not doing that? Perhaps you should drop the > frame instead? > On Tx, cipher scheme is "only" available trough sta pointer and is only used in ieee80211_crypto_cs_encrypt to get security header len. Since

[PATCH v2] mac80211: Get IV len from key conf and not cipher scheme

2015-03-10 Thread Cedric Izoard
Do not always dereference sta to get cipher scheme as it may be null for broadcast messages. Instead get IV length from key configuration which has been initialized with cipher scheme. Signed-off-by: Cedric Izoard --- net/mac80211/wpa.c | 22 +++--- 1 file changed, 11

Re: [PATCH] mac80211: Get IV len from key conf and not cipher scheme

2015-03-10 Thread Cedric Izoard
> If key is installed without cipher scheme and the cipher is not in explicitly > implemented ciphers setting non zero key->conf.iv_len, the > ieee80211_key_alloc() function will set key->conf.iv_len to 0. Perhaps it > makes sense to add key->conf.iv_len == 0 verification to > ieee80211_crypto

Re: [PATCH] mac80211: Get IV len from key conf and not cipher scheme

2015-03-10 Thread Cedric Izoard
On 10/03/2015 12:58, Stepanov, Max wrote: >> From: Cedric Izoard >> To: linux-wireless@vger.kernel.org >> Cc: johan...@sipsolutions.net >> Subject: [PATCH] mac80211: Get IV len from key conf and not cipher >> scheme >> Date: Tue, 10 Mar 2015 08:52:23 + &g

[PATCH] mac80211: Get IV len from key conf and not cipher scheme

2015-03-10 Thread Cedric Izoard
Do not always dereference sta to get cipher scheme as it may be null for broadcast messages. Instead get IV length from key configuration which has been initialized with cipher scheme. Signed-off-by: Cedric Izoard --- net/mac80211/wpa.c | 19 --- 1 file changed, 8 insertions