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. The official release 1.9.18 contains two of these patches: the LM Announce support and the WPS fix. With the default settings for 1.9.18, the LM Announce support will kick in automatically once Samba detects an OS/2 system on the network. The WPS fix on the other hand is not enabled by default, because the Samba team is not quite convinced of its safety for non-OS/2 clients. IMHO there should be no worries but I will add another check to really make sure that this code is only executed when an OS/2 client connects. For now, read below how you can edit the source to enable the fix.

I hope to bring out a patch for 2.0.x in due course, with all my remaining fixes. Hold on please...

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.

Older patches for 1.9.17p1 and 1.9.17p2 are still available as os2clnt.pat and smb17p2.pat but are not mentioned in the table below.

The official Samba 1.9.17 releases contain fixes for the WPS problem but they are disabled by default. (In fact, versions <= 1.9.17p1 in fact would have made things worse since the OS2_WPS_FIX they contain 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 appear 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 "chained" 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 used: 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 I 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 with the COREPLUS dialect 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". I have mailed IBM on this and got a reply from tech support. Timothy Sipples ("Mr. OS/2") translated this for me from "IBM lingo" into plain English. It turns out that IBM is not willing to fix it because I am not a big corporate account! I think they don't understand the situation: I don't have a problem, they have! As you can read above I made a workaround to fix it for myself, but what if some bozo makes an OS2NUKE program based on this error? Windows contains a whole range of much more serious networking bugs, but at least Microsoft fixes them...

5-Feb-1998: IBM re-released fixpak IP08406 for "IBM Peer". Click here. Do they fix the problem? I haven't tried them yet 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 this fix, long filenames will be preserved when objects are dragged from the Workplace Shell to a share on the Samba server. Version 1.9.18alpha13 and up include this fix but it is not enabled by default. For these versions, edit the file includes.h in the source directory and add the following line somewhere (a good place would be after #include "local.h"):

#define OS2_WPS_FIX

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


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 and server.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 of 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

Samba versions >= v.1.9.18alpha13 contain our patch for LM Announce support support. This means that Samba servers will show up with NET VIEW and in the Network Neighbourhood, provided they are on the same subnet as your DOS LanMan or OS/2 machine. Please refer to the manual for Samba's configuration file smb.conf.5 for information on the parameters lm announce and lm interval. Note that these settings are a bit different from the patches below.

Samba servers before version 1.9.18 without patch 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 have a fix for this. Andreas Degert (ad@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. (They did! Jeremy Allison added this fix to his completely rewritten nmbd!)

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 server (i.e. hold "Ctrl" while dragging the object). I seem to have fixed this by problem making sure that the destination path contains a backslash (see reply.c::reply_copy()). This is to please the routine called resolve_wildcards(). I don't know why this works, but it seems to have the side effect that no wildcards can be used anymore. (Actually, I had the impression that wildcards worked for the unpatched source, but somehow even that I don't see anymore...). I decided to put in this fix so that at least WPS copying works; DosCopy()'s with wildcards are much rarer.
Note! Copying a WPS folder on the remote server to another location on that same remote server is not supported by Samba! You'll get ERROR 58: the specified server cannot perform the requested action. This is because "tree copy" is not (yet) implemented. Ugly workaround: you can copy the folder first to your local disk and then move/copy it the new location.

Back to top

Back to "Using Samba with DOS or OS/2"

Back to Jacco's homepage