Windows File Sharing

Upgrading the SMB file and printer sharing client for RISC OS to support the newer SMB 2.x protocol is a real flashback to the 1990s, but not in a way that makes me nostalgic. My first task is to remove the ancient support for NetBIOS Frames (NBF), more commonly called “NetBEUI”, and add support for direct TCP connection to port 445, in preference to NetBIOS-over-TCP/IP on ports 137 and 139. You can see these action items on the bounty to add this feature.

There is some absolutely bizarre stuff in the NetBIOS-over-TCP/IP (NBT) protocol, like how NetBIOS names are encoded by expanding each byte into two nybbles and then adding it to the ASCII value for ‘A’. The example given in RFC 1001 is "The NetBIOS name" in the NetBIOS scope "SCOPE.ID.COM" becomes FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM. Thankfully, all of this is handled by the SMB 1 code which has many comments complaining and asking why did they make it this horrible?

For testing purposes, I set up a Windows 2000 and a Windows Vista SP2 VM in VirtualBox, and the current RISC OS “LanManFS” client can connect to both of those. Windows Vista supports SMB 1.0 and 2.0.2 (with SP1), and I plan to add client support for SMB 2.0.2 and 2.1 servers. Windows 7 added SMB 2.1.

Thankfully, the SMB 2.x protocol is much simpler than the overgrown SMB 1, which was originally designed at IBM in early 1983, and had many extensions over the years to support long filenames and other features. The concepts are the same, but in 2008, it was a good time to streamline everything. Microsoft has not been the most friendly about their proprietary protocols, but they did eventually start publishing their specifications, including regular updates. The version of the SMB 2/3 spec I’m using is dated 27 Feb 2023; just 3 months ago.

The major impetus for the feature bounty to add SMB 2 support to the RISC OS file sharing client is that current Windows, macOS, and UNIX (Samba) versions have all either disabled by default or removed SMB 1 support, for performance, reliability, and security reasons. In some cases you can manually re-enable it, but I can definitely see why it’s worth a decent sum of money to the RISC OS community to be able to easily connect to Windows 10 or 11, or Samba 4.15.

BTW, there were other proprietary protocols layered on top of Ethernet besides “NetBEUI”. Apple had AppleTalk, which Apple Filing Protocol used before moving to TCP/IP, while Novell had IPX/SPX for their proprietary NetWare file server OS. There was a time when you could make good money as a certified NetWare administrator. It’s possible, although I doubt very common, to run SMB on top of IPX/SPX (in addition to direct TCP, NetBEUI, and NetBIOS-over-TCP/IP), and there were a number of MS-DOS games that used IPX/SPX for LAN multiplayer gaming. I should also mention DECnet, used by OpenVMS.

Update: Curiously, Wikipedia says that Samba 4.11 disabled SMB1 because of the 2017 WannaCry ransomware attack, which exploited remote code execution vulnerabilities in Microsoft’s implementation of SMB1 discovered, but not reported, by the NSA. Even though Samba’s implementation was presumably not vulnerable to the attack, I suspect that the Samba maintainers disabled SMB1 in order to pressure sysadmins into also disabling SMB1 on their Windows clients and servers (in case Microsoft didn’t fix all of the buggy code).







One response to “Windows File Sharing”

  1. […] I explained in a previous post, the SMB file sharing protocol originally created by IBM and popularized by Microsoft Windows is […]

Leave a Reply

Your email address will not be published. Required fields are marked *