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.
Time is now printed uniformly in hexadecimal format.
dword data is now printed as unsigned integer values.
Decoded error messages should be a bit more readable.
The decoder now handles all SMB commands which the smbfs file system uses, including the two subcommands of the SMB_COM_TRANSACTION2 command which are used (TRANS2_FIND_FIRST2 and TRANS2_FIND_NEXT2).
This is still very ugly and very complex code, but hopefully the next version will only be ugly...
Major rework of the code which decodes individual commands, their parameters and the responses. This is still incomplete, but it's a lot more useful now than before.
The word/dword conversion code should be more robust now, using type casts where needed.
Cleaned up numeric comparisons, so that the types of the quantities compared match.
The SMB packet dump code now prints the current transmit buffer size along with the other packet information.
Because the field and variable name "max_xmit" was used in four different places, with different types in different context, it was hard to know what was what. This is part of the cleanup work.
The word/dword conversion code should be more robust now, using the type casts where needed.
The maximum transmission size provided by the server is now a local variable and no longer stored in the global server parameters because it is really only needed here.
The maximum transmission size limit requested by the user is no longer ignored.
The maximum transmission size is now configurable through a command line/tool type option. This used to be preset to 65530.
Also removed a htons() call that was both wrong and unnecessary.
When converting the server's file modification time for a FileInfoBlock->fib_Date, we now prefer the creation time record if the modification time is not provided.
When the file system enters its packet dispatch loop, its Task priority is increased to 10 unless it already uses a a higher priority level; the priority is restored when the dispatch loop terminates.
The ACTION_READ_LINK packet is now properly rejected as being unsupported.
Raw SMB over TCP is now the default; re-enable the NetBIOS layer with the NETBIOS switch. The DUMPSMB switch enables SMB command decoding, the results of which will be sent to STDOUT if the respective decoding functions have been built into the smbfs command.
This complements the functionality in the updated SMB abstraction layer. Also added a little documentation for some of the various undocumented magic numbers and fields of the SMB commands set up in this implementation. There is more to come, eventually.
All commands which the smbfs program receives or send through the network can now be decoded, printing header information and (eventually) more detailed information about the specific server command. This option is enabled at compile time.
The original implementation would wrap the SMB session setup into a NetBIOS layer, which Windows Vista, Windows 7, etc. no longer support out of the box. The updated code in smba_connect()/smba_start() now supports raw SMB over TCP which is better supported by contemporary software than the legacy NetBIOS option.
The updated SMB abstraction layer supports skipping the NetBIOS protol layer altogether, which improves compatibility with Windows Vista, Windows 7, etc.
- The ACTION_INFO packet is now handled correctly if a ZERO lock
is provided. Previously, it would return failure, prompting DOS
to show its "please insert disk" requester.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@29 26594b9e-b914-4e86-b7a1-9402bd427170
- Integrated Harry Sintonen's fix for the problem caused by large
writes to files. The respective packet size was off by one byte.
Thank you very much!
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@27 26594b9e-b914-4e86-b7a1-9402bd427170
- Modified smb_valid_packet() in proc.c to check whether the packet
received is smaller than expected, not whether the length matches
exactly. This seems to fix the protocol negotiation with Samba 3.2.5
for now. Haven't checked Vista yet, though...
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@23 26594b9e-b914-4e86-b7a1-9402bd427170
- In proc.c, smb_setup_header() initialized the SMB header length
field with a number which was too large by four bytes. Consequently,
what was later committed to the wire would have four trailing data
bytes which could contain random values. This often didn't do much
harm, but it seems that Samba 3.2.4 and Windows Vista don't like the
looks of the trailing junk bytes.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@20 26594b9e-b914-4e86-b7a1-9402bd427170
- The extended directory scanning entry conversion code now swaps
the last modification and last write access date stamps. This
matches the time of the last modification, as returned by the
regular ACTION_EXAMINE_FH/ACTION_EXAMINE packets. Note that the
time resolution is a little bit coarser because the modification
time as expressed by the SMB getattr function cannot represent
60 distinct seconds per minute but only 30. The net effect is
that the resulting time stamps in a directory listing and by
examining a file can differ by one second.
- The DST option's time offset was added to rather than subtracted
from the local time. Fixed.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@17 26594b9e-b914-4e86-b7a1-9402bd427170
- Introduced a new option to account for daylight savings time
when appropriate.
- Looks like some of the time stamps used in "proc.c" are
transmitted in local time after all; brought back the
conversion functions.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@15 26594b9e-b914-4e86-b7a1-9402bd427170
- The time stamps used in "proc.c", as returned and submitted to
the SMB file system on the other end of the wire are apparently
all in Universally Coordinated Time already (or at least, this
seems to be the case with Samba and Windows XP). Hence no conversion
between local time and UTC is necessary, which would otherwise
distort all date stamps converted. I modified the file system to
leave all time stamps essentially unadjusted for local time in
"proc.c". The local time zone adjustments are now performed only
where the time in question is known to be Amiga-specific, such as
the current system time or the date stamp to set for a file.
The time conversion appears to be working correctly now, but it
does ignore the effects of daylight savings time, which you might
want to adjust for manually through the TIMEZONEOFFSET option
(careful though: this overrides your current locale-defined time
zone settings as far as smbfs is concerned).
Unsolved problem: at least Windows XP seems to return different
time stamps for directory listings and for indidivual files. As
far as I can tell, the sets of time stamps returned for either
doesn't match anywhere.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@13 26594b9e-b914-4e86-b7a1-9402bd427170
- It appears that Windows XP can produce directory listings with
file/directory modification times set to 0, indicating that no
such information is available, while the associated last file
write access data is present. Previously, smbfs only reported
the modification. If this data is unavailable and the date of
the last write access is, the last write access will be
reported instead.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@11 26594b9e-b914-4e86-b7a1-9402bd427170
Olaf Barthel