This is the story on how I spent far too much money and time getting a scanner to work over iSCSI so that I could prove “Chris O” wrong on StackExchange. The TL;DR is that yes scanners work fine over iSCSI.
It begins with waking up to the thought “could I connect a scanner to SCSI disk array chassis” - probably after watching too much Adrian’s Digital Basement. I think this this is very much possible, but the thought morphed into - what about iSCSI arrays. While I joked about it I put off further investigation when I saw the price for iSCSI bays. They are still stupid expensive.
The idea still stuck with me though and I wanted to do some more research into if anyone had. I didn’t find much. All I really found was Chris saying it couldn’t be done because:
iSCSI isn’t a complete encapsulation of the SCSI protocol over TCP/IP. … Source: 15 years of managing iSCSI storage networks.
This bugged me a lot because it didn’t point to any sources. I decided to read through iSCSI RFCs and couldn’t find anything that would suggest that it wouldn’t work. I suspect Chris hasn’t had as much experience managing iSCSI scanner networks. Being theoretically correct is one thing though - I wanted to be practically correct.
The Setup
A minimal test setup requires three things:
- iSCSI Target (this is a server for normal people)
- iSCSI Initiator (this is the client for normal people)
- A SCSI scanner
Turns out that even though iSCSI arrays are still expensive tgt (iSCSI Target software) on Linux supports passthrough devices.
So our setup ends up being:
- Linux
tgtiSCSI Target - Virtual machine on a different computer iSCSI initiator
- A SCSI scanner
With the discovery of tgt I thought this project would be simple, however a reoccurring theme with this project is that the simple things end up being the hardest. The first problem is that inexpensive scanners only existed in my head. Turns out most scanners sold 2nd hand today either don’t have SCSI or are pricey. Eventually I came across a Canoscan FS4000US film scanner for a reasonable price.
The reason it was a reasonable price is that the slide/film mounts were missing. This most certainly wouldn’t be a problem as I don’t need to actually scan film (she thought).
Drivers
There’s a bit of a meme about printers being the worst computer accessory to setup, configure and maintain. I don’t believe this is true. Scanners a far far far worse - this is why you don’t see scanners today - we lost. The FS4000US was released to market sometime around 2001 and 2002 from my research. It received 32bit drivers up to Vista.
My first task was to test the scanner on USB to ensure it worked prior to iSCSI fun. Luckily VueScan still exists and provides a driver replacement for the FS4000US. It was able to detect the scanner. Great win!
A slippery slide
VueScan however would not let me scan as it couldn’t detect the slide/carriage for the media being inserted. When I purchased the scanner I knew the slide was missing. I was hoping that it would just scan without checking, and if it did check it would just need a limit switch locked down. This was not the case - the FS4000US has a loading mechanism (it’s actually fairly complex) and uses a light sensor to perform alignment.
After many attempts to “trick” the sensor I started designing a 3d printed slide replacement however before kicking off a print I decided I’d try “one more time”. I managed to trick the sensor into thinking film was loaded and VueScan happily scanned an image!
Other parts SCSI or SSCCSSII
It’s time to talk about SCSI. The FS4000US is “SCSI-2”, which at the time was the latest specification for the SCSI standard. Confusingly SCSI-2 refers to two different specifications - Wide and Narrow. Wide came about in 2003, while Narrow came out in 1994. As such the FS4000US is Narrow SCSI. The best way to think of narrow and wide is that they double the bus width - more pins. Because of the additional bus width the number of devices on the SCSI bus changed from 8 to 16.
There’s some other considerations with SCSI as well - SE/HVD (Single ended / high voltage differential) or LVD (low voltage differential). Along with clock speed. The FS4000US is narrow, 10MHz, SE/HVD. Modern SCSI is wide, 160MHz, LVD.
The good news is that most SCSI devices are backwards compatible (usually sacrificing speed on the bus). The only important consideration is usually LVD vs SE/HVD. I hunted down a PCIe SCSI card and ended up with a Dell LSI20320IE. This has an internal SE/HVD connector.
Oh connectors. Connectors. I mentioned the difference between wide and narrow, but here’s where it gets fun. Our FS4000US has a HD50 connector (50 pins) - this is usually a little bit unique but not unheard of. The LSI20320IE has a HD68 connector (68 pins). So how do we connect a narrow device to a wide controller? We buy a dubious cable.
I ended up with this HD68 to HD50 cable. I’m pretty certain this is designed for when your connecting a newer hard drive to an older controller. Why would this matter though?
Well as SCSI is a bus you end up with long cables with many devices sharing the cabling. As there’s no dedicated device at the start or end of the bus the signal would reflect off the end of the cable. This is why we have SCSI terminators. Often these are built into devices and as long as you set the terminator on the first and last device everything is fine. Other times you might use dedicated terminators plugged into the cable. These terminators prevent signal reflections and make the bus stable.
Bringing this back to the cable, we have 68 pins on our wide side and 50 pins on the narrow. This means there’s a bunch of pins that are left unterminated. This originally concerned me, but on my very simple SCSI configuration I realised that this would likely be fine. This is because the cable likely only contains 50 pins and the SCSI card itself will be acting as the first terminator - there should be no reflections at this point. On a complex bus with multiple devices this could be a problem though.
I did look into proper 68 to 50 adapters however these are either very expensive or just not available. I guess their usage was fairly rare to start with.
Anyway, my HD68 to HD50 cable worked just. Lol just joking. Once again the simple things end up being the hardest. I bought an external cable, but the SCSI controller card has the HD68 connector on the inside of the card. It physically wouldn’t fit. So I took to the cable with a Stanley knife and cutters. Eventually it fit.
Unit testing
It’s usually best to test each part of a complex system individually. My plan was to connect the scanner with SCSI on my Windows machine and do a scan. This was to test that SCSI scanning worked locally before moving to iSCSI.
I downloaded the latest drivers I could find for the SCSI card and promptly got a green screen of death. Followed by boot looping Windows. The driver installed the 32bit driver on a 64bit system. Windows was not happy. The simple things.
I tried some 64bit drivers. This installed ok, no boot loop however I got a This device cannot find enough free resources that it can use. error. I never worked out what was happening here.
Fine. I rebooted into Linux. It could see the controller and the scanner - huge win. But no one ever wrote Linux Xane drivers for this scanner. Fine I thought - I would run a Windows VM, pass through the PCIe device and run a supported Windows Server 2008R2 setup. Turns out in version 7 for VirtualBox they removed PCI passthrough. I’ll try virt-manager.
Virt-manager approach saw seabios hang on boot. I tried to get uEFI working but my Linux build was too old to have the required files. Do I even need to passthrough the entire PCIe device though? Maybe I just pass through the SCSI device. virt-manager GUI however didn’t show a way to passthrough the devices so I learnt how to build the XML myself. Start the VM and get permission denied. Turns out apparmour was unhappy about it. Fixed up apparmour only to find Windows Server build didn’t have drivers for the virtual SCSI controller. Arghhhhhhhhh. Lets give up with this.
Yolo
Someone in a forum helpfully suggested that rather than using virt-manager for SCSI passthrough just use iSCSI. So lets just do that (sans virt-manager). It shows up on the bus. It’ll be fine right?
On my Linux host I started tgt service and configured the passthrough device. There’s some helpful documentation here. It comes down to these commands
tgtadm --lld iscsi --op new --mode target --tid 1 \
-T iqn.2001-04.com.example:test
tgtadm --lld iscsi --op new --mode logicalunit \
--tid 1 --lun 1 --bstype=sg --device-type=pt -b /dev/sg1
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
That’s it. The part I thought would cause me the most grief worked just fine.
Operating system woes
I decided that I wanted to use my laptop to connect to the iSCSI target. MacOS doesn’t have native iSCSI, so I decided I would run a virtual machine. Fired up Windows 11 in parallels however it seems like iSCSI has been completely removed in Windows 11. Maybe it’s the ARM build I have? It’s the simple things once again.
So I build a Windows 7 VM in UTM. Setup iSCSI Initiator. Excitement as the scanner shows up in device manager. Install VueScan and go to scan. Unlike before I can’t seem to do the magic to make the scanner happy about being loaded. Turns out the logic for checking that there is something loaded into the scanner is performed in software. I suspect that VueScan implements this logic different between SCSI and USB versions? Simple things.
tgt configuration? not sure.
Scanning
After a lot of messing around I eventually built a Windows XP VM along with downloading some sketchy DLL files. Wildestdreams has some third party software to run the scanner over SCSI. It doesn’t implement any media checking so will happily scan without being loaded!
With that I was able to perform a scan over iSCSI. Of course the scan quality is rubbish because I’m not using film, the slide and haven’t calibrated the gain for each channel but the point remains it scans over iSCSI. Chris O - you’re wrong!
I did try the original Canon Twain driver - I think with the correct slide/tray it would work fine. It’s just very picky about the loading.
The original dream
The original dream was having a bunch of flat bed scanners connected to a disk array enclosures. While I can’t afford to see it happen, this experiment gives me hope. There’s no guarantee that it’ll work though as who knows what those iSCSI controllers are doing.