OS/2, DOS LanMan, Amiga and Solaris 2.4 patch for Samba
Eugeny Kuzakov
Eugeny.Kuzakov at lab321.ru
Sat Dec 6 07:03:44 GMT 1997
http://carol.wins.uva.nl/~leeuw/samba/fix.html
What do you think about this ?
It really works.
> OS/2, DOS LanMan, Amiga and Solaris 2.4 patch for Samba
>
> ------------------------------------------------------------------------
>
> This page contains a couple of patches (i.e. new features, bugfixes etc.) for the Samba source code. These will eventually be included in the next official version of Samba, 1.9.18, but for now you'll have to apply them yourself.
>
> If you maintain your Samba server yourself, install the patch of your choice and recompile the binaries. However, if you're not, ask your friendly system administrator to install the patch.
>
> [New! ]A "DOS+OS/2 client patch" for Samba 1.9.17p4 has been created [4-nov-1997]. The patch for 1.9.17p1 and 1.9.17p2 are still available as os2clnt.pat and smb17p2.pat but were removed in favour of 1.9.17p3 and 1.9.17p4 because of table space. And there is a nasty security bug in Samba versions <= 1.9.17p1 anyway (has nothing to do with these patches), so if possible you should upgrade.
>
> [New! ]The official Samba 1.9.17 releases contain fixes for the WPS problem but they are disabled by default. Versions ?= 1.9.17p1 in fact would have made things worse since the OS2_WPS_FIX contained in them are incorrect! The correct fixes can be found in the patches below, for 1.9.17 and higher. I also found a way to avoid the annoying message window "extended attributes cannot be copied" under OS/2. Here's how to make it shut up.
>
> I've got the following patches on offer. Pick the one you want, depending on the Samba version you are using and what fixes you need in the patch:
>
> Samba version: 1.9.16p11 1.9.16p11 1.9.17alpha5 1.9.17p3 1.9.17p4
> ------------------------------------------------------------------------------
> Workaround for
> bug in IBM Peer - - X X X
> ------------------------------------------------------------------------------
> Fix for WPS problem X - X X X
> ------------------------------------------------------------------------------
> LM Announce support X X X X X
> ------------------------------------------------------------------------------
> "Auto" LM Announces - - - X X
> ------------------------------------------------------------------------------
> SMBcopy fix - - - X X
> ------------------------------------------------------------------------------
> Fix for timestamp problem - - X X X
> (Solaris 2.4 and OS/2)
> ------------------------------------------------------------------------------
> Fixes for Amiga (by - - X - -
> Rask Ingemann Lambertsen)
> ------------------------------------------------------------------------------
> Fixes for creating X - X - -
> OS/2 version (Samba/2)
> ------------------------------------------------------------------------------
> download download download download download
>
> older patch ------------> newer patch (preferred!)
>
> ------------------------------------------------------------------------
> To apply the patch smb17p4.pat, goto the directory samba-1.9.17p4/source and execute the command:
>
> patch -p1 ? smb17p4.pat ?? out
>
> To apply the patch os2a5.pat, goto the directory samba-1.9.17alpha5/source and execute the command:
>
> patch -p1 ? os2a5.pat ?? out
>
> To apply the patch os2.pat, go to the directory samba-1.9.16p11/source/ and execute the following command:
>
> patch ? os2.pat ?? out
>
> Comments on the patches: what does that code do anyway?
>
> ------------------------------------------------------------------------
>
> IBM Peer bug workaround for smbclient/smbtar
>
> The original problem description follows:
>
> I noticed a serious bug in Warp 4 and Warp Connect: they can be crashed by the Samba client (smbclient/SMBCLNT.EXE) over the network! Well, not a complete crash such as a TRAP, but it will bring down the SMB networking part of Warp, "IBM Peer". TCP/IP and IPX both keep running. The bug has been confirmed by IBM and other people. It does not to be present in Warp Server.
> When getting/mgetting files from the Warp 4 or Connect machine sometimes that machine crashes (putting files is no problem). It's quite unpredictable. Sometimes it takes a couple of megabytes before it crashes, sometimes it crashes after just a couple of files. The machine doesn't crash completely but the network process PEER.EXE goes down: SYS3175 in DOSCALL1.DLL (an important system library). It looks a bit like the infamous "DIR ..\" bug in NT (which Microsoft first blamed on Samba!). If you have Warp 4 or Connect I would very much appreciate it if you could try and see if you get the same problem. One final note: when smbclient is forced to use one of the older SMB protocols (-m COREPLUS or smaller), the problem is gone. Of course, you'll lose support for long file names then, and many other things.
>
> Technical information: (you may skip this if you just want to use the patch!)
> At first I thought that this may be a buffer overflow problem in IBM Peer. That's because it sometimes crashed and sometimes not. So I set the max xmit parameter in smb.conf to a low value, 2048. I found out that smbclient actually ignores this parameter (it's apparently only used by smbd), but that's a completely different story. Fine, so I decided to hardcode max xmit in client.c to 2048. Warp 4 still crashed. So that could not be it. Then I noticed a very strange thing with tcpdump-smb, the software network analyzer: Warp always managed to send the complete file to the client, up to the last packet and then, just before it crashes, it sends a reply to the client's close command which also contained a lot of data from the last packet! Intuitively, this could not be right. A server should not send the same data twice, even if the second time is a close command. I looked in the source of client.c and found that for dialects higher than COREPLUS (hint! hint!) it sends a "chai!
ned"
> SMBreadX and SMBclose packet. So the easy solution would be to not send these chained commands when the server happens to be a Warp Connect or Warp 4 machine. The question was of course, how do I detect if smbclient actually connects to such a Warp machine? One way to do this could not be use: smbclient and Warp negotiate the LM1.2X002 and this dialect does not send information about the client and server's OSes and server software. This only seems to be supported for by LANMAN2.1 and higher dialects. So I had to think of something else. I came up with using the "max xmit" setting. The SMB clients that are available (DOS, Windows, OS/2 etc.) seem to use distinctive default values for this maximum buffer size setting. In OS/2, the line
> sizreqbuf = 4096
> in the [peer] section of \IBMLAN\IBMLAN.INI sets this default. It corresponds with the 4356 that smbclient sees. Normally, you don't have any reason to change that parameter so that's why I thought Ii could use it to detect whether smbclient is communicating with Warp as a server. If so, smbclient will do a SMBreadX without a chained SMBclose. The next pass in the while(nread) loop, smbclient notices that the complete file has been retrieved, it falls through the loop, it sees that the file has not been closed (close_done boolean) and sends the SMBclose command. A minor disadvantage is that it now sends more packets over the network but this is also the case when smbclient connects to a Warp machine.
> An alternative would be to fix up "method 0" (if that is possible at all) so that it doesn't crash Warp anymore. But the over all best solution would be that IBM fixes the problem in "IBM Peer"...
>
> [New! ]xx-Nov-1997: IBM released new fixpaks for "IBM Peer". Click here. Do they fix the problem? I haven't tried them yet because the FTP server is so slow, but I don't think the problem is gone because the list of fixes doesn't seem to mention this particular problem.
>
> ------------------------------------------------------------------------
>
> Fix for the WPS problem
>
> With the patch, Samba now preserves long filenames when objects are dragged to it from the Workplace Shell. The fix works, but every time you drag an object to Samba, the WPS shows a message window telling you that the file will be copied without its extended attributes. That's fine, but you'll have to click "Yes" every time. After a while, you probably get as annoyed as I was. I found a solution in the online documentation (File and Print Client task handbook): add the line
> SET CONFIRMLOSTEAS=NO
> to your CONFIG.SYS. If you want OS/2 to completely shut up about these extended attributes (I noticed that 4OS/2 prints a harmless "error 282" message when a file is copied without extended attributes; other applications may do that too), do the following: edit \IBMLAN\IBMLAN.INI and find the [requester] section. Edit the digit on position 41 of the wrkheuristics parameter. That should be the one at the utmost right, at the lower row. Change it from 0 (default) to 1. The change will take effect the next reboot. Personally, I leave it to the default. It's only the WPS message window that annoys me.
>
> Technical information: (you may skip this if you just want to use the patch!)
> The problem was that when you dragged a WPS object from the OS/2 desktop to the Samba share, the name got truncated to 8.3. Somehow, OS/2 believed that the Samba remote filesystem could not do long filenames. The only lines that have changed from the previous patch contain the string ERRcannotopen (see smb.h, server.c and trans2.c). Although the fix is amazingly simple, it took me a while to pinpoint the trouble spot. Samba supports long filenames but not extended attributes. There are 2 bits for this indicating the server's capabilities in the SMB packet header (Flags2 field) but it turns out that these are completely ignored by the WPS. This was the first thing that set me on the wrong foot. The second thing was that OS/2 communicates with other OS/2 machines using the LANMAN2.1 dialect, and when it talks to Samba the older LM1.2X002 dialect is negotiated. Only LANMAN2.1 and newer dialects send a string which indicates the name of the server's file system (NativeFileSystem!
[]).
> Warp of course sends the string HPFS then, and I thought that perhaps from this string the client determines that the server supports long filenames. This turned out not to be the case (fortunately, because I would have hated to write an implementation of the LANMAN2.1 dialect :-). But help came from an unsuspected corner, namely Matthieu Willm's OS/2 device driver for the Linux EXT2 filesystem. Another thing that spurred the investigation of the problem was that I could borrow 2 machines from my user group, who weren't doing anything with them over the summer vacation. I used one of them with tcpdump-smb to 'sniff' the exchange of packets on the Ethernet between 2 Warp machines. With this setup, I shared several types of drives from one Warp 4 machine: FAT (which supports extended attributes but not long filenames), HPFS (which supports both extended attributes and long filenames) and EXT2FS (which supports long filenames but not extended attributes). Comparing the traces o!
f the
> conversations between the machines showed that OS/2 wants to open a special file called .+,;=[].. FAT returns "illegal character in name", HPFS just creates the file and EXT2-OS2 returns "cannot open file" (error code 110). Before the fix, Samba returned error code 282 ("extended attributes not supported"). Which would intuitively be the correct response, but unfortunately it resulted in the 8.3 style filenames. When I changed Samba's response to the same as what EXT2-OS2 returns (error code 110), everything went smoothly and the problem was fixed!
>
> ------------------------------------------------------------------------
>
> 'LM Announce' support
>
> You might have noticed the following: Samba servers are 'invisible' to the following clients: Warp 4, Warp Connect, LAN Manager Client for OS/2 and LAN Manager Client for DOS (any others??? JdL). With 'invisible' I mean: if you do a NET VIEW under one of these clients, it doesn't show Samba machines in the list of servers you get. The same is true for the graphical browsers included with Warp 4 (the "File and Print Client Resource Browser") and Warp Connect (whatsitsname?). However, if you do a NET USE x: \\SAMBA\SHARE, you can use that share just fine. So it might not be that much of a problem to you after all. But still, not being able to browse Samba servers is an inconvenience...
>
> Fortunately, we now have a fix for this! Andreas Degert (ad at papyrus.hamburg.com) and I implemented source code so that Samba can (optionally) send 'LAN Manager announcements', which are picked up by the aforementioned clients.
>
> For Samba versions ?= v1.9.17p2 with their respective patches applied, the following line has to added to Samba's configuration file smb.conf to activate the fix:
>
> lm announce = 60
>
> This sets the interval (in seconds) between LAN Manager Announcement packets that the Samba server will send. One broadcast packet per minute per Samba server should not strain your network, but still, if you want to cut back on these broadcasts, increase the number.
>
> The patches for Samba versions 1.9.17p3 and 1.9.17p4 have a new feature: "Auto" LM Announce. Samba will start sending LM Announcements once it detects OS/2 servers sending such announcements (note: I've been thinking of also automatically sending LM Announcements once a DOS LM or OS/2 client connects to the Samba server). Thus, in an all Windows client environment they will not be sent. I figured that in an OS/2 environment the user wouldn't mind having some additional broadcasts on the network so I decided to set the default to "Auto" (2). You can always change this default. Add the following lines to Samba's configuration file smb.conf (the following values are actually already the default).
>
> lm announce = 2
> lm interval = 60
>
> Valid settings for "lm announce" are:
>
> 0: never send any LM Announcements
> 1: always send LM Announcements
> 2 (or higher): send LM Announcements when other servers are already sending
> those announcements (default)
>
> "lm interval" is the number of seconds in between 2 LM Announcements. Setting it higher means less broadcasts but a longer period before DOS+OS/2 clients detect the Samba server, and v.v. Note that you can set this interval only in steps of 10 seconds (if I'm correct) because of a loop timer in Samba. So "lm interval = 15" will be rounded to 20 seconds. The default for "lm interval" is 60 seconds.
>
> Hopefully the Samba team accepts this feature and the "Auto" default, so that DOS LM and OS/2 users will benefit from it in 1.9.18alpha+ without depending on their Samba sysadmin to manually enable this option.
>
> SMBcopy fix
>
> Detlef Plotzky mailed me about 2 bugs in the implementation of the "SMBcopy" command in Samba, which I confirmed. When this SMB/CIFS command is used, for instance through the OS/2 library call DosCopy() on an OS/2 client, to copy a file on the Samba server to another location on that server, it sometimes results in an error. And whenever it succeeds, the timestamp is set to the current time, not the original time/date.
>
> This timestamp problem was reasonably easy to fix. The "last access" and "last modification" timestamps are now set according to how OS/2 does e.g. a copy on its local disks (by watching the "Details" window). With one exception: the "creation" timestamp is set to the current time because I don't know how to set that timestamp under Unix (if it is even possible)...
>
> Not only DosCopy() makes use of SMBcopy, also the WPS. This is an even more serious problem, because the bug results in not being able to copy a file on the remote server to another location on that same remote s
--
Best wishes, Eugeny Kuzakov
Laboratory 321 ( Omsk, Russia )
kev at lab321.ru
More information about the samba
mailing list