Epson 3490 Scanner

This is an information that tends to be forgotten on the Internet, so I’m publishing it here. How to get an Epson Perfection 3490 Photo scanner running under Linux, FreeBSD or whatever. Paths may change on your system, so you may need to adapt the instructions below.

1. Install xsane.

2. Download the Epson firmwares. For the Epson 3490, you need esfw52.bin. You may find this file on Internet, although it tends to disappear. But in any case you can also find this file here.

3. Uncompress the firmwares. That is, sudo tar -Jxvf epson-firmwares.tar.xz -C /usr/local/share/sane.

4. Modify /usr/local/etc/sane.d/snapscan.conf, change the firmware line to point to the esfw52.bin firmware. That is following the commands above, change the firmware line to firmware /usr/local/share/sane/epson-firmwares/esfw52.bin.

If you are running FreeBSD

You should still ensure that you can use the scanner as a normal user.

5.Let’s change the owner of the scanner so that it’s available to users in the saned group. Create /etc/devd/saned.conf and add:

notify 100 {
  match "system" "USB";
  match "subsystem" "INTERFACE";
  match "type" "ATTACH";
  match "cdev" "ugen[0-9].[0-9]";
  match "vendor" "0x04b8";
  match "product" "0x0122";
  action "chown -L cups:saned /dev/$cdev && chmod -L 660 /dev/$cdev";
};

Notice the 0x4b8:0x0122, identifying the scanner USB device which you can get from the lsusb command while the scanner is plugged in.

6.Restart devd with service devd restart.

7.Add yourself to the saned group with sudo pw groupmod saned -m

8.You may need to log in again so that new group changes are taken into account.

Fastd and truncated IP

You might have guessed from the last post that I’ve been playing a bit with Fastd the last few days.

However I had some surprises after successfully configuring my first tunnel. Light traffic such as ping would go through without problem. But larger traffic such as rsync transfers or downloading/uploading files would hang endlessly.

At the remote side of the tunnel, I looked with tcpdump at the traffic out of the tun interface. Packets were going through, although packets with a large payload were apparently truncated:

truncated-ip6 - 4 bytes missing
truncated-ip - 4 bytes missing

Indeed large packets were 4 bytes shorter than intended both for IPv4 and IPv6 traffic. This sounded a lot like some kind of MTU mismatch in the tunnel itself. Still, both sides of the tunnel were configured with the same MTU. Also, Fastd ensures that both sides use the same MTU during the tunnel creation.

So what is it? I don’t know. I did not investigate further. But I’ve found a workaround.
Once the tunnel is created, I simply reduce the MTU on the entry/client side interface of the tunnel of 4B. That is in the establish script:

mtu=$(("$INTERFACE_MTU" - 4))
ifconfig "$INTERFACE" mtu "$mtu"

That’s still weird though. So I’d like to find some definitive answer as to why this is happening.

Fastd on FreeBSD

Fastd is nice and small secure tunneling daemon. A bit like OpenVPN, if you wish, but geared toward small devices, simpler in its design and in some ways more generic.

There was a FreeBSD port, but it has been marked as broken. The fix, however, is very simple, if you accept to get rid of AES128 and instead use the SALSA stream cipher:

cmake -DWITH_CIPHER_AES128_CTR=FALSE CMakeLists.txt
make
make install