Greetings,I am using a Linux device with kernel 3.10.40. The Windows host is using XP PRO (32-bit,) but the problem has laso been observed with Windows 7 64-bit.
When I directly connect the Linux device to the Windows host, a very strange problem arises. First of all: by "directly connect" I mean connecting the network cable from the device's NIC directly to the host's NIC, without any switch in between.
The device then mounts two shares on the host: a RO share, as well as a RW share.
The device opens a file (integrity-check-idx.tmp) for writing on the RW share. Then (without closing it) it scans the contents of the RO share. Afterwards, it writes some result on that file and flushes it before closing it. Straightforward enough.
In the described case where the NICs are directly connected *and* that the Windows host finishes booting before the Linux device does, something strange happens. The file opened for writing is opened on FID 0x4002, then, when opening another file on the RO share, the same FID seems to be reused. That file is closed and FID 0x4002 is then invalid. In the end, when FID 0x4002 is flushed, an error is returned.
Attached you will find an abridged version of the Wireshark capture. Here is the summary:
SMB_COM_NT_CREATE_ANDX integrity-check-idx.tmp on FID 0x4002 SMB_COM_READ_ANDX FID 0x4002 (...browse share...) SMB_COM_NT_CREATE_ANDX append.exe on FID 0x4002 SMB_COM_READ_ANDX FID 0x4002 SMB_COM_CLOSE FID 0x4002 (...) SMB_COM_FLUSH FID 0x4002 Response: NT Status: STATUS_INVALID_HANDLE (0xc0000008)In the case where there is a switch between both NICs, this problem does not happen. In that case, FID 0x4002 is used only once for the file opened for writing (which was created first) and then other FIDs are used for each file that is opened afterwards. Thus, all operations succeed (which is the behavior that I would expect.)
Do you have any idea on how to solve this?I am taking a deeper look at the kernel code, but so far it seems to me like this was a Windows problem and not a problem in our implementation, given that the FID is assigned by the Windows host. Could you please confirm that this is correct so as to provide a workaround?
Thank you in advance for your kind support! Federico Sauter Senior Firmware Programmer -- Innominate Security Technologies AG Rudower Chaussee 13 | 12489 Berlin | Germany tel: +49 30 921028-210 | fax: +49 30 921028-020 www.innominate.com | www.twitter.com/mGuardcom Register Court: AG Charlottenburg, HR B 81603Management Board: Dirk Seewald | Chairman of the Supervisory Board: Christoph Leifer
Attachment:
bug_14517.cap
Description: application/vnd.tcpdump.pcap
