On Mon, 2004-09-20 at 18:32 -0400, John E. Malmberg wrote: > What version of SAMBA is running on the LINUX system?
Samba 3.0.7 + smbfs 3.0.7. > Other than that, I am not set up to take advantage of your data at the > moment. I do not have any way of reading the etherreal data. If it is because you don't have a Linux system, the ethereal data is not specific to ethereal or Linux. A number of utilities can read it, some of which run on OpenVMS, and many of which run on Windows. Tcpdump, which is available for TCPIP 5.4, can read it. For example: $ tcpdump=="$sys$system:tcpip$tcpdump" $ tcpdump -vr test.cap Also, tcptrace, which, like tcpdump, is based on libpcap, can read it. See: http://jarok.cs.ohiou.edu/software/tcptrace/download.html e.g. $ tcptrace == "$path_to:tcptrace" $ tcptrace -v test.cap Finally, if you run Windows, Ethereal works on Windows as well as Linux. > It may be useful if you can find a specific difference in the protocol > negotiation if the SAMBA versions are the same. Making the Samba versions the same would be a rather costly project for me at this time. I'd like to explore other avenues before trying that. I find it rather interesting that Linux can negotiate Write AndX to write large buffers at a time to OpenVMS, and Windows can negotiate Write AndX to write large buffers at a time to Linux, but Windows can only negotiate Write to write 1K blocks at a time to OpenVMS. So clearly OpenVMS Samba *is* capable of doing Write AndX, since it happily receives them from the Linux client, which writes 4096 byte buffers at a time. Doesn't this indicate that the Samba server, either due to tuning or some other factor, has missed an opportunity to take advantage of a more efficient method of transfer, rather than simply an incompatibility between versions? Also, if pre-allocation is an expensive operation in OpenVMS, doesn't that indicate there is room for improvement here in the current Samba implementation for OpenVMS? Since the Windows host insists on preallocating, and since OpenVMS Samba refuses (or is unable) to send back EOF and allocation responses to the file info requests, it appears that Windows thinks it can only pre-allocate a small amount ahead of where it is writing, instead of further ahead, as it does in the Windows -> Linux case. Wouldn't sending back EOF and allocation figures allow the Windows client to write further ahead, resulting in fewer preallocation requests? As it stands, after the first 64K are written, one file info + one extra preallocation write are done per 1024 byte block written! That is exorbitantly expensive, and totally unnecessary, if only the server would give the client the info necessary to make larger, and therefore fewer preallocation writes. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html