Hi everyone,
I recently switch to f_ncm with Windows 10 since rndis 's safety issue.
(the Windows 10 driver version is 10.0.19041.1 2009/4/21)
It seems Windows 10 ncm driver won't send ZLP to let udc properly
separate the skbs.
On Mon, 5 Feb 2024 13:16:50 +0530 Krishna Kurapati wrote:
According to Windows driver, no ZLP is needed if wBlockLength is
non-zero,
because the non-zero wBlockLength has already told the function side the
size of transfer to be expected. However, there are in-market NCM devices
that rely on ZLP as long as the wBlockLength is multiple of
wMaxPacketSize.
To deal with such devices, it pads an extra 0 at end so the transfer
is no
longer multiple of wMaxPacketSize.
I do the iperf3 testing cause gadget constantly report similar error after
a litle modification to get more concrete info:
[ 174] configfs-gadget.0: to process=512, so go to find second NTH
from: 15872
[ 174] FIND NEXT NTH HEAD:000000006c26a12c: 6e 63 6d 68 10 00 86 16 b0
3b 00 00 48 3b 00 00 00 00 52 34 fc 5f 90 fd ca 40 c1 f4 f4 6e 08 00
[ 174] configfs-gadget.0: Wrong NDP SIGN of this ndp index: 15176, skb
len: 16384, ureq_len: 16384, this wSeq: 5766
[ 174] NDP HEAD:00000000298f3cab: 2b 12 48 8f 12 ce 3c c8 d7 39 c0 0d
15 cf 86 14 17 4a 91 85 db df ad 87 f0 35 0d 76 ad 4d 4d 74
[ 174] NTH of this NDP HEAD:00000000af9fbfc9: 6e 63 6d 68 10 00 85 16
00 3e 00 00 90 3d 00 00 00 00 52 34 fc 5f 90 fd ca 40 c1 f4 f4 6e 08 00
[ 174] configfs-gadget.0: Wrong NTH SIGN, skblen 14768, last wSequence:
5766, last dgram_num: 11, ureqlen: 16384
[ 174] HEAD:00000000b1a72bfc: 3f 98 a6 8e 17 f8 bb 29 07 b8 da 13 7f 20
80 8e 77 ca 32 07 ac 71 b8 8d 84 03 d7 1b 96 9b c4 fa
Lecroy shows the wSequence=5765 have 10 Datagram consisting a 31*512
bytes=15872 bytes OUT Transfer but have no ZLP:
OUT Transfer wSequence=5765
NTH32 Datagrams: 1514B * 8 + 580B NDP32
Transfer length: 512B * 31
NO ZLP
OUT Transfer wSequence=5766
NTH32 Datagrams: 1514B * 8 NDP32
Transfer length: 512B * 29 + 432
This lead to a result that the first givebacked 16K skb correponding to
a usb_request contains two NTH but not complete:
USB Request 1 SKB 16384B
(NTH32) (Datagrams) (NDP32) | (NTH32) (Datagrams piece of wSequence=5766)
USB Request 2 SKB 14768B
(Datagrams piece of wSequence=5766) (NDP32)
From the context, it seems the first report of Wrong NDP SIGN is caused
by out-of-bound accessing, the second report of Wrong NTH SIGN is caused
by a wrong beginning of NTB parsing.
Do you have any idea how can this be fixed so that the ncm compatibility
is better for windows users.
Best Regards,
Pan
