Fixed decoding of maximum buffer size; this used to come out as 0, which made smbfs switch back to the default minimum supported (1024 bytes).
Corrected use of the maximum raw write size as the size used by the client to perform raw reads with. The maximum allowed are 65535 bytes for a raw read request. Likewise, the maximum raw write size is 65535 bytes, too.
Because the series of write operations are not wrapped into transactions, the cached file size needs to be updated if at least one write access succeeds.
Simplified the directory cache cleanup.
The SMB message length bit #17 is now properly filled in with the respective bit of the payload length.
Added the remaining error codes covered by the "Common Internet File System (CIFS) Protocol" documentation.
smbfs will not work properly with the standard 4K stack size. Testing revealed that 20K are safer, which is why the program startup code now provides as much if needed.
The client capabilities were never properly initialized, which could have led to any number of interesting side-effects, such as NT status information being transmitted instead.
The client now announces itself as a Unix system if the server does so, too.
The record locking command did not initialize the oplock level at all. Fixed.
Other SMB packets were not completely initialized either, which has been corrected.
SMB packet decoder now ignores empty parameter/data and will not try to decode and display these.
SMB_COM_SEARCH decoding had the sources mixed up, decoding client->server traffic as server->client traffic and the other way round.
Decoding of the status field now works properly again in the non-"status32" case.
smba_read() failed to register the number of bytes read successfully by smb_proc_read_raw(). This made all files appear to be empty.
smba_write() did not update the offset value correctly if the first smb_proc_write() call had succeeded.
Decoding is performed before the session header type is checked and, if necessary, rejected.
smb_receive_raw() now only accepts a single session header type (message) and rejects all others. At this stage "positive session response" should no longer appear.
All functions now follow a consistent error reporting scheme. A negative return value always indicates an error condition. A return value of 0 always indicates success, except for the few functions which have to return a count of bytes or directory records upon success.
Previously, it was hard to tell what function returned what in case of error, which led the bugs in smba_write() and smba_read(), neither of which gracefully fell back on SMB_COM_WRITE/SMB_COM_READ, respectively if SMB_COM_WRITE_RAW/SMB_COM_READ_RAW failed.
State variables are now named according to their respective purpose where possible. Previously, it was "rval", "errnum", "result" which were used almost interchangeably regardless of purpose.
Turns out that the length filled in by smb_setup_header() was not actually off by 4 bytes but entirely correct. This caused SMB packets to be sent four bytes short, and probably causing some SMB server implementations to ignore them altogether.
A successful SMB_COM_WRITE_RAW command may cause the server to send interim progress update responses, ending with a final SMB_COM_WRITE_RAW_COMPLETE message. This is now handled correctly.
Signed quantities are now used as such, e.g. the server time zone.
The SMB_COM_READ/WRITE/READ_RAW/WRITE_RAW data is now printed in the scope it was intended for, e.g. the SMB_COM_WRITE_RAW data output begins at the indicated offset rather than at the padding bytes which may precede it.
Added server/client capability flags covered by "Implementing CIFS", but not by the Microsoft reference documentation.
The NetBIOS session header contents are now printed along with the SMB header information.
Added GPLv2 header text.
The SMB date/time, filetime and utime information is now converted into display format instead of just showing up as hexadecimal format numbers.
The end-of-file and allocation size values are now printed in decimal format in addition to hexadecimal format.
Made a note of the fact that the SMB_COM_READ_RAW may be followed by more than one response by the server. The current implementation only catches one response.
The data transmitted by the SMB_COM_WRITE_RAW command is no longer decoded as if it were an SMB message.
Olaf Barthel
Olaf Barthel