Closed raenye closed 9 months ago
What is meaning ksmbd-server ? Does that mean ksmbd.mountd?
Versions of the relevant openwrt packages.
But ksmbd.{mountd,control,addshare,adduser} -V
all return ksmbd-tools version : 3.4.8
.
kmod-fs-ksmbd - 5.15.120-1
What ksmbd kernel module are you using ? Can you test it with the latest #master of ksmbd ?
https://github.com/cifsd-team/ksmbd
Thanks.
OpenWrt no longer uses the module but the upstream driver.
5.15.120. I could try with 5.15.123, but the kernel is compiled as part of the OpenWrt build process, and I'm not sure how to make it use a git tree.
root@fenix:~# strings /lib/modules/5.15.120/ksmbd.ko | grep 5.15
vermagic=5.15.120 mod_unload
the upstream driver.
Thanks. I was advised on the forum to open an issue here; where should I ask then?
This is the proper place.
So I'm not sure what is the difference between upstream and here, or between "module" and "driver" :(
Upstream I meant by kernel.org.
Anyway, I'll gladly build with debug options, test, and provide more information if you could tell me what is needed. Thanks.
@raenye Can you give me wireshark dump (or tcpdump) after capturing packets on problem situation ?
@namjaejeon I narrowed it down to OneNote for Microsoft 365 running on one particular Win11 PC.
The client has several open notebooks that reside on the server running ksmbd
, tcpdump
shows some client-server synchronization of cached copies over SMB.
For instance, the log messages
Mon Jul 31 01:25:55 2023 kern.err kernel: [823130.727969] ksmbd: cli req too short, len 112 not 116. cmd:10 mid:186162
Mon Jul 31 01:25:55 2023 kern.err kernel: [823130.735827] ksmbd: cli req too short, len 112 not 116. cmd:10 mid:186164
Mon Jul 31 01:25:55 2023 kern.err kernel: [823130.746769] ksmbd: cli req too short, len 112 not 116. cmd:10 mid:186167
seem to relate to the following packets captured with tcpdump -A port 445
:
Hoping this helps to reproduce an equivalent setup; alternatively, perhaps could you kindly write which tcpdump
parameters would be useful for debugging.
Thanks!
Okay. I could not reproduce it using windows 10 client. I will try OneNote for Microsoft 365.
OneNote for Windows 10 is a different program, it's cloud only; only OneNote desktop (was 2016, then 365) can do local notebooks. Please let me know if further information is needed. Thanks.
Update: I upgraded from kernel 5.15.133 to 6.1.55 and the problem disappeared. No change in clients. Should I closed as resolved?
@raenye Yes, You can close this ISSUE. Thanks!
I just like to leave a comment here telling that I experience currently the same issue with OneNote365 running on a Win11 PC. The notebooks are stored on the ksmbd share. The log is spammed with the same error messages as described in the first post by @raenye.
Beside the anoying error messages there is a really nasty problem. The OneNote notebooks are not syncing properly anymore. As soon as you add a new chapter to a notebook it starts complaining. So basically OneNote is not useable anymore with ksmbd running on kernel 5.15 and as this is the current stable in OpenWrt it is a really bad situation. I can imagine that it takes quite some time until the 6.1.55 will become the next stable release.
I found out that creating a new tab in OneNote typically creates a new file where the notebook is stored. The file on the ksmbd share is only half the size compared to the size when the notebook is on a different share. On the different share no complains about syncing.
It would really be beneficial if anyone knows how to bypass this issue.
@Luckyparty I am backported ksmbd patches to new linux-5.15.145. It is not released yet. I think that openWRT can pull linux-5.15.145 after it is released.
If you want to check your issue with ksmbd backport patches right now, you can use the following kernel.
git clone https://github.com/namjaejeon/stable-linux-5.15-ksmbd
Thanks.
Hello,
I started using
ksmbd
on a WD MyBookLive device running OpenWrt, and my logs are filled with this message (idle and transfer) File access seems to work fine. There is some periodicity in the timing, which changes over time (used to be three every 30 secconds, a few days later three every 40 secconds, in the logs below it's three plus one lagging. Clients are a few Win11 laptops and desktops.Please advise.
Thanks, R.
Log excerpts:
Note that it's mostly
len 112 not 116
but sometimeslen 136 not 140
. I haven't seen other numbers.The
mid
counter resets very rarely, after asock_read failed: -108
:Config (3 out of 6 identically configured shares):
Version: