As software updates cease for operating systems, they eventually begin to lose access to parts of the LAN and internet due to out of date encryption features, as well as the inability to handle file sharing protocols like SBM3, which is somewhat of a necessity if you have e.g. a NAS on the LAN. Such too was the case with [watermark_hd]’s 20-year old PowerPC Macs and their installations of OS X Tiger and Leopard.
Cue Aqualink, a native SMB3 client for these older OS X versions that uses [Ronnie Sahlberg]’s libsmb2 server/client library for SMB2 and SBM3. The source code can be found over on GitHub, along with a Japanese translation. By using a local WebDAV server Tiger’s built-in mount_webdav feature can be used to mount these remote volumes.
While you can often still use SMB1 even on modern Windows and Linux/BSD via Samba, allowing even retro systems like these PowerMacs to speak SMB3 is at least a great boost for network security, even if the aforementioned encryption shortcomings mean that you cannot quite run encrypted file shares yet.
Although OS X eventually began to adopt modern SMB versions, some of us may remember how incredibly buggy they were, to the point that us OS X users often had to fall back to CIFS (SMB 1.0), so this is another potential use for this Aqualink application.
I get around this. My main is a PC running Windows 11 and I set it as FTP server that my old Macintosh can access for files that I can’t get directly with ancient Netscape 2 browser. Macintosh Garden (last I checked) is still capable on older browsers so I can still download abandoned programs directly.
Allowing such ancient devices to access any network — unless its completely isolated — is extremely irresponsible but even then with how much power these old machines pull it brings it into “ethically dubious” territories.
“oh it can use smb3 tho” in the HAD article also conveniently ignores the part of the github readme which states:
“AquaLink’s WebDAV NAS server sends passwords as HTTP Basic Auth over plain, unencrypted HTTP”
SMB3 won’t save you from this; what a terrible article.
Not sure I would agree with much of this…
For a corporate LAN, I wouldn’t recommend doing this, plenty of other devices, but for a home LAN, there are much worse security vulnerabilities from cheap 3rd party “IoT” devices (cameras, printers, etc) to the crappy consumer router that most ISPs bundle or force you to use. Those that enjoy retro computing are generally aware of the lack-of-modern-security-features that older OSes bring. And will either isolate the network accordingly, or understand the risks of connecting to a modern network. I’ve run several vintage systems at home, and the biggest issue I’ve had has not been security or power, but reliability. These systems generally have rather “vintage” capacitors and other components, that need maintenance/replacing, and has parts get harder to find, less systems exist.
The comment on power is questionable at best. How does my 2002 PowerBook G4 with a 65W power supply consume more power than a modern multicore Intel/AMD desktop system with a 135W CPU, 200W+ GPU, and 1000W power supply? Even a modern comparable system, a professional mobile workstation consumes twice the power at max load. If you want “ethically dubious”, we shouldn’t be selling modern power hungry x86 based systems at all.
From running netstat, the WebDAV server binds to localhost, which you would have noticed if you fully read the notes. Trying to probe the port from a remote system while the application is running results in a “Connection refused”, not saying you may be able to chain an exploit, but again, you generally don’t have your client system connected directly on the internet. (in Public IP space)
Using the software proves interesting, as it’s not as “native” and seamless as an experience as I was hoping, but for a hobby project it’s a start. It will be more useful as modern macOS versions drop SMBv1 client support. (SFTP would be the next route for me)
Thank you FUD police. I am pretty sure that most if not all of the people using this are hobbyists and are not using it in production environments…….
and if by chance they are using it in a prod environment then the sys admins need to fire whoever is doing this. Either way it is a fun little tool to allow older hardware to still be fun.
But at principle he’s right.
The same had been discussed here in German forums a few years ago when XP went EOL, btw.
Some forum users even argued that XP users that go online should be punished for being such a threat to society.
Because they’re responsible for botnets if their PCs catch some malware and spyware that causes harm to everyone.
By comparison, rand was very polite and forgiving, I think.
I mean, sure, a BSD system isn’t Windows (XP or 98SE), so it’s not as endangered.
Still, they shouldn’t be left running all day or night while being connected to the internet if they’re unsupervised. 🤓☝️
On other hand, Mac OS X Tiger to Snow Leopard (there’s a PPC port) are all-time classics by now
and they can run beloved software that modern macOS can’t.
They also have backwards compatibility mechanisms such as Classic Environment (to run Mac OS 9 software) or Rosetta (intel version; to run PPC code).
Maybe SMB3 makes it easier to share files with these valuable OSes in an intranet or LAN. 🙂
Because modern OSes are dropping support for older SMB protocols and because physical media are not always easy to access on both systems.
Filesystems change, older OSes can’t see high capacity devices or are their SD card readers have a 2 GB or 4GB limit (pre SDHC, SDXC).
A network connection via RJ45 ethernet might be simplest solution herd.
My DOS machines are accessible from the DMZ and are running either Workgroup Add-On or LANtastic. Neither with a routable IP, one with no IP at all (IPX)
😎👍
There’s also an DOS/Windows 3.1x network stack for AppleTalk/AFP, by the way.
It was included on the installation disks for the PhoneNet PC Card (by Farallon Computing).
The software includes a Chooser utility (two, actually; one for DOS and Win3) and has support for other NICs such as NE2000 network card, as well.
That way, a LAN between vintage IBM PCs and Macintosh Computers running System 6/7 and up can be built.
Without relying on TCP/IP and its various shortcomings (large overhead on vintage hardware).
Windows NT line has been shipped with AppleTalk support, too.
Linux has netatalk, I vaguely remember.
Not sure about OS/2 right now.
Mac OS X 10.2 (and 10.3; prior 10.3.9) is latest version with full support for the legacy protocols, I vaguely remember.
Later versions nolonger speak the very old AFP protocols used by early Macs.
Some information:
https://lowendmac.com/2007/vintage-mac-networking-and-file-exchange/
https://en.wikipedia.org/wiki/Apple_Filing_Protocol#Compatibility
Personally I found the article helpful and informative and expect the software to be useful for maintaining some of my old powerpc “museum pieces” that I still boot up on occasion.
The “WebDAV NAS server” mentioned in that readme is a separate feature of the project, independent from the SMB2/3 support, and you would have to deliberately choose to run it. If you took that to mean that Aqualink’s implementation of SMB2/3 is sending plaintext passwords over the network, you’re mistaken.
You’re absolutely right. The WebDAV local sharing feature (the one that turns an iBook into a NAS) deliberately uses plaintext HTTP with Basic authentication to work around the fact that the older, standard OpenSSL included in Tiger can’t properly handle TLS 1.2. Passwords are transmitted in plain text.
Without making excuses, I’ve just added a warning to both the README and the app’s UI stating, “Use only on a LAN; do not expose this to the outside world by opening ports on your router.” Thank you for pointing this out—it was very helpful.
A fundamental fact of solid-state physics that dopant diffusion never truly stops. At room temperature the drastic difference in the shelf live is governed by how scaling down to the nanometer scale turns a microscopic drift into a catastrophic failure. EUV devices (below 7nm) win on power usage, but ancient 1980’s devices (1000nm to 3000nm) win on device longevity.
It would take billions of years for solid-state dopant diffusion to ruin a 1980s junction. Modern chips will fail after about 10 to 20 years, unless stored at cryogenic temperatures which would boost the lifetime to around 50 years.
i wonder sometimes about these sorts of claims. fwiw, i believe them when it comes to flash memory, though i’ve never seen flash fail to time.
i read once (here, i think) that ram has some fault rate such that i could observe single bit flips in a reasonable amount of time by monitoring a disposable amount of memory (a couple GB). so i performed the experiment…and i found a fault pretty quickly. so i improved my monitoring and eventually nailed down two specific bytes that were repeatedly failing. so i added the kernel commandline to disable those pages, and i haven’t seen a failure since. i eventually replaced that bad ram module and haven’t seen a failure on that one either.
so my point is, it seems like ymmv…i’m using an 8 year old cpu as my daily driver (and it’s hard to imagine wanting to upgrade!) so maybe i’ll get to see this happen, or maybe i won’t. but overall i feel like when i read something surprising like “modern chips will all fail in 20 years”, i don’t necessarily believe it.
Flash is a totally different story altogether, they predominantly fail read-only on number of block program/erase cycles:
SLC 50,000 to 100,000 writes
MLC 30,000 to 35,000 writes
TLC 1,500 to 5,000 writes
QLC 150 to 1,000 writes
PLC 10 to 100 writes
The interesting thing is that every single read at the very lowest level is corrupt and needs to be regenerated from the Low-density parity-check (LDPC) codes. Now do not get me wrong the data recovered using LDPC is perfect.
And modern flash devices are predominantly built using multiple technologies to maximize size while keeping devices functioning within warranty for typical usage. I’ve burned through more than most through atypical usage, so much so that I stick to industrial MicroSD cards (~4 PB write limit for a 64 GB card).
I’ll bet @rand is loads of fun at parties
we used Dave back in the 1990ies for SMB…. still runs well today with Linux custom configured Samba SMB2/3 Gateways.
Btw, I am the only one who associates SMB with Super Mario Bros. first? 😂
When I read IT news about SMB1, SMB2 and SMB3 I must think of the NES classics.
But just about half a second later, I realize that it is about networking.
Huh. I see SMB and always think I have to figure out whether it means a diode package or an RF connector. But you do you.
I’ve fixed the issue mentioned in a previous article regarding “lack of support for encrypted SMB3 shares.” I’ve added an option to require SMB3 encryption.
Furthermore, during the implementation process, I identified a previously undiscovered bug in libsmb2 itself (a bug where the SessionId field in the encryption header was not endian-converted for big-endian environments, causing connection failures to standard SMB shares on both macOS and Windows 11) by analyzing packet captures on a physical machine. I have already reported this to the upstream project along with a fix: https://github.com/sahlberg/libsmb2/issues/477
It appears to be a bug that no one had noticed because it happened to work on x86 and ARM platforms. I was only able to find it because I tested it on PowerPC (big-endian).