Dmesg errors "bad smb2 signature" #307
Comments
|
Okay. windows client seems send wrong signature. I think that you turn signing feature on windows client or ksmbd. Can you show me your smb.conf file ? and can you answer about the following question ?
|
|
There are only two windows clients, and the issue was observed on both of them at different times. The share is mapped as a network drive, the drive stops working after some random time with the mentioned error, but can be restored by unmapping and remapping. Windows 10 21H2 build 19044.3570 on both machines. I don't have a separate smb.conf file, but ksmbd.conf is provided below. ksmbd-tools from 52a3955 built and make install'ed on the server machine. I am able to apply test patches to the tools and kernel if needed. |
|
Can you give me wireshark dump(or tcpdump) that captured patckets on problem situation to me ? |
Sure. Will capture once I can observe the problem again. Might take some time, can't pinpoint a way to reproduce it yet. |
|
Really thanks for your help! I am trying to reproduce it, But it is not easy to reproduce it. If you find some pattern for this issue, It will be really helpful to fix this issue. |
|
Please tell me what tcpdump filters should I apply, or if you want the unfiltered dump. |
|
Stranged.. I unzip it using gunzip. But I can not open it using wireshark... |
|
Please check the checksum of the file. I've double checked, this should work. |
|
I'll leave tcp stream hexdump below, just in case. |
|
wireshark on linux (version 4.0.6) opens the file without issue (directly, or after gunzip). The packet dump is a series of Tree Connect Request messages from the client, with the server responding STATUS_ACCESS_DENIED, which is what is expected if the signature is wrong. The TCP checksum on response packets is incorrect, but that may be because of checksum offload. Responses from the server are also systematically retransmitted which suggests some packet loss is occurring. @darkwrat |
Yes, indeed. I still have the issue present, can collect more data before restoring.
These are excerpts from nmcli on the server. A windows client has a X520-DA2 card installed and is connected via SFP+ cable directly to the server's built in card. The server bridges this link with 1Gbps from a router, and gets DHCP from the bridge. The second client usually connects over wifi, but that machine is off now. Perhaps the bridge may be the source of "retransmissions" in the dump? It was captured with -i any. |
@mmakassikis Really good catch! How did you know that ? |
|
@namjaejeon On the other hand, retransmissions indicate something is happening. IIRC, either a retransmission timeout expired, or duplicate acks have been received (both of which indicate packet loss). @darkwrat On the client, do you still get the ERROR_ALREADY_ASSIGNED error ? |
enp3s0f1 is the one connected to the winows box. I think retransmissions are bogus because the same packet is captured twice -- once on the bridge member and once on the bridge itself. I've seen this before on vlan interfaces.
Yes, in the popup messagebox when trying to open the network disk. Also I tried doing Z: in cmd, and get "Incorrect signature." (or "invalid signature", i have to lookup translations of error texts..) |
|
So ISTM the problem is two-way, the client cannot verify server's signature, and the server cannot verify client's signature. It happens rarely and randomly, and gets stuck there. Perhaps the root cause could be found in sess_key corruption? I'm inclined to make some debug patches for the kernel with more logging and warns, and run them until the next occurrence of the issue. @namjaejeon any advice on the above? should anything of interest be included? |
Ah yes, that may confuse wireshark. Can you share a capture done with "-i enp3s0f1" rather "-i any" ? It seems smb3 multichannel can bind multiple tcp connections even if there's only a single NIC. Can you try disabling multichannel on the client with the following powershell command ? |
Done.
Executed, the first messagebox was "Access denied", then ERROR_ALREADY_ASSIGNED again. |
Thanks. You were right: it went from all segments being retransmitted to basically none.
Did you unmap/remap the drive ? I'm not sure when the parameter is applied. Normally, the steps are:
In the packet dump, the endpoints are in step 3, so it's either:
|
If I do this, the problem could be gone, and I'll probably have to wait for a week to observe it again :)
Oh yes, sorry, the capture was already done at that point when I changed the EnableMultiChannel setting. I'll try to keep tcpdump running for long time to capture the entire session. |
beware of long running tcpdump, as you could end up filling all of your RAM (which may happen very fast if you transfer a few large files from/to the server) |
Thank you for the heads up. I hope won't be an issue, the server has 256 GB of RAM. Writing a tcpdump filter to match 0xfe534d42 in packet body takes more time than I expected though ) |
|
http://ams2.trail5.net/smb2_20231025.pcap.gz 4 GB file, captured as Must contain the moment when issue appeared. |
|
This 20 MB chunk should be more digestible and possibly complete. |
Hello,
I have ksmbd running on linux 6.6-rc5, and a couple of windows clients. Sometimes clients cannot reconnect to the share with ERROR_ALREADY_ASSIGNED, and dmesg contains:
Please advise on what debug should I collect, and also tell me if this is not a correct place to report this issue.
Thanks,
Max
The text was updated successfully, but these errors were encountered: