I have encountered kernel crash when I have used mesh SAE connection
with ath9k_htc device (Sony UWA-BR100). I have tried to connect 2 peers
to each other, then only one peer crashes.
By bisect, this commit looks causes this issue.
commit d8da0b5d64d58f7775a94bcf12dda50f13a76f22
Author: Cedric Izoard <[email protected]>
Date: Wed Dec 7 09:59:00 2016 +0000
mac80211: Ensure enough headroom when forwarding mesh pkt
When a buffer is duplicated during MESH packet forwarding,
this patch ensures that the new buffer has enough headroom.
I do not have any crash log because the computer was fully uncontrollable.
Regards,
Masashi Honma.
> 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 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
>
> yes mac80211 is adding the security header.
> headroom asked to skb_copy_expand should also take sdata-
> >encrypt_headroom into account.
I suspected that, since it was about the only place that was adding
anything, but I couldn't test it :)
Can you send a patch?
johannes
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
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.
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.
PiA+IEhlcmUgaXMgdGhlIHN0YWNrIHRyYWNlIEkgZ2V0Og0KPiA+IEkgYWRkZWQgYSB0cmFjZSBi
ZWZvcmUgY2FsbGluZyBza2JfY29weV9leHBhbmQgdG8gZ2V0IHRoZSBoZWFkcm9vbSBvZg0KPiA+
IHRoZSBidWZmZXIgYmVmb3JlIHRoZSBjb3B5IGFuZCB0aGUgaGVhZHJvb20gYXNrZWQgYnkgdGhl
IGRyaXZlci4NCj4gPg0KPiA+IFvCoMKgwqA4My4yMDAyNjFdIE1FU0ggZndkOiBza2JfaGVhZHJv
b209MTU0LCBuZWVkZWQgaGVhZHJvb209MjQNCj4gDQo+IENvdWxkIHlvdSBhbHNvIGFkZCBhIHNp
bWlsYXIgdHJhY2UganVzdCBiZWZvcmUgY2FsbGluZyBkcnZfdHgoKT8NCg0KV2hlbiBjYWxsaW5n
IGRydl90eCgpIHRoZSBoZWFkcm9vbSBpcyBub3QgYmlnIGVub3VnaCBmb3IgdGhlIGRyaXZlci4N
Cg0KPiANCj4gTWF5YmUgd2UncmUgYWRkaW5nIHNvbWV0aGluZyBlbHNlIHRvIHRoaXMgc2tiPw0K
PiANCj4gSSBjYW4ndCBmaW5kIGFueXRoaW5nIGluIHRoZSBhdGg5a19odGMgZHJpdmVyIHRoYXQn
cyBhZGRpbmcgbW9yZSB0aGFuDQo+IDIzIGJ5dGVzIChpdCdzIGFkdmVydGlzaW5nIDI0KSBidXQg
Y2xlYXJseSB0aGUgbGFzdCA4IGJ5dGVzIGhlcmUgYXJlDQo+IGZhaWxpbmc6DQo+IA0KPiA+IFvC
oMKgwqA4My4yMDAzNDZdIHNrYnVmZjogc2tiX3VuZGVyX3BhbmljOiB0ZXh0OmZmZmZmZmZmYTAz
NGMwMjggbGVuOjE1NA0KPiA+IHB1dDo4IGhlYWQ6ZmZmZjg4MDIxMzQyMmUwMCBkYXRhOmZmZmY4
ODAyMTM0MjJkZmEgdGFpbDoweDk0IGVuZDoweGMwDQo+ID4gZGV2OjxOVUxMPg0KPiANCj4gTWF5
YmUgbWFjODAyMTEgaXMgcHV0dGluZyBzb21ldGhpbmcgZWxzZT8gSXQnZCBoYXZlIHRvIGJlDQoN
CnllcyBtYWM4MDIxMSBpcyBhZGRpbmcgdGhlIHNlY3VyaXR5IGhlYWRlci4NCmhlYWRyb29tIGFz
a2VkIHRvIHNrYl9jb3B5X2V4cGFuZCBzaG91bGQgYWxzbyB0YWtlIHNkYXRhLT5lbmNyeXB0X2hl
YWRyb29tIGludG8gYWNjb3VudC4NCg0KY2VkcmljDQo=
On Wed, 2017-01-11 at 08:35 +0900, Masashi Honma wrote:
> I have encountered kernel crash when I have used mesh SAE
> connection
> with ath9k_htc device (Sony UWA-BR100). I have tried to connect 2
> peers
> to each other, then only one peer crashes.
>
> By bisect, this commit looks causes this issue.
>
> commit d8da0b5d64d58f7775a94bcf12dda50f13a76f22
> Author: Cedric Izoard <[email protected]>
> Date: Wed Dec 7 09:59:00 2016 +0000
>
> mac80211: Ensure enough headroom when forwarding mesh pkt
I don't think this makes sense - if you only have two peers then you
shouldn't even run into forwarding code paths?
johannes
> 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
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.
PiA+IFdoZW4gY2FsbGluZyBkcnZfdHgoKSB0aGUgaGVhZHJvb20gaXMgbm90IGJpZyBlbm91Z2gg
Zm9yIHRoZSBkcml2ZXIuDQo+IA0KPiBPay4NCj4gDQo+ID4gPg0KPiA+ID4gTWF5YmUgd2UncmUg
YWRkaW5nIHNvbWV0aGluZyBlbHNlIHRvIHRoaXMgc2tiPw0KPiA+ID4NCj4gPiA+IEkgY2FuJ3Qg
ZmluZCBhbnl0aGluZyBpbiB0aGUgYXRoOWtfaHRjIGRyaXZlciB0aGF0J3MgYWRkaW5nIG1vcmUN
Cj4gPiA+IHRoYW4NCj4gPiA+IDIzIGJ5dGVzIChpdCdzIGFkdmVydGlzaW5nIDI0KSBidXQgY2xl
YXJseSB0aGUgbGFzdCA4IGJ5dGVzIGhlcmUgYXJlDQo+ID4gPiBmYWlsaW5nOg0KPiA+ID4NCj4g
PiA+ID4gW8KgwqDCoDgzLjIwMDM0Nl0gc2tidWZmOiBza2JfdW5kZXJfcGFuaWM6IHRleHQ6ZmZm
ZmZmZmZhMDM0YzAyOA0KPiA+ID4gPiBsZW46MTU0DQo+ID4gPiA+IHB1dDo4IGhlYWQ6ZmZmZjg4
MDIxMzQyMmUwMCBkYXRhOmZmZmY4ODAyMTM0MjJkZmEgdGFpbDoweDk0DQo+ID4gPiA+IGVuZDow
eGMwDQo+ID4gPiA+IGRldjo8TlVMTD4NCj4gPiA+DQo+ID4gPiBNYXliZSBtYWM4MDIxMSBpcyBw
dXR0aW5nIHNvbWV0aGluZyBlbHNlPyBJdCdkIGhhdmUgdG8gYmUNCj4gPg0KPiA+IHllcyBtYWM4
MDIxMSBpcyBhZGRpbmcgdGhlIHNlY3VyaXR5IGhlYWRlci4NCj4gPiBoZWFkcm9vbSBhc2tlZCB0
byBza2JfY29weV9leHBhbmQgc2hvdWxkIGFsc28gdGFrZSBzZGF0YS0NCj4gPiA+ZW5jcnlwdF9o
ZWFkcm9vbSBpbnRvIGFjY291bnQuDQo+IA0KPiBJIHN1c3BlY3RlZCB0aGF0LCBzaW5jZSBpdCB3
YXMgYWJvdXQgdGhlIG9ubHkgcGxhY2UgdGhhdCB3YXMgYWRkaW5nIGFueXRoaW5nLA0KPiBidXQg
SSBjb3VsZG4ndCB0ZXN0IGl0IDopDQo+IA0KPiBDYW4geW91IHNlbmQgYSBwYXRjaD8NCg0KU3Vy
ZSwgSSB3aWxsIHNlbmQgYSBwYXRjaC4NCg0KY2VkcmljDQo=
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
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.
> 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
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