Automount not working with FreeBSD 12

FreeBSD 12 is out. This is great! However I had the surprise to find that the automount feature didn’t work in KDE, probably also Gnome, XFCE and any other desktop environment that provide such a feature.

The culprit was easy to find, the Hardware Abstraction Layer has not yet updated to the peculiarities of the latest FreeBSD release.

See, when HAL tries to mount a vfat filesystem on FreeBSD, it adds by default the large option which according to FreeBSD 11.2 mount_msdosfs’s manpage provide support for very large files (>128GB). This option, however, was removed in FreeBSD 12. Thus automount fails.

To temporarily fix this, edit /usr/local/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi. Then remove the large option in the vfat match for FreeBSD. That is:

  <match key="volume.fstype" string="vfat">
    <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
      ...
  </match>
  <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="FreeBSD">
    ...
    <!-- <append key="volume.mount.valid_options" type="strlist">large</append> -->
  </match>

This was already reported in #221709.

Don’t forget the pipe subshell

This is a common error while using pipe over while loops. Consider this shell snippet:

#!/bin/sh

cat file.txt | while read line
do
  echo "inside loop"
  exit 1
done

echo "outside loop"
exit 0

You’d expect the script to exit on the first line in file.txt. However execute this script and you have:

inside loop
outside loop

It is as if the exit 1 inside the loop is ignored. Another example:

#!/bin/sh

a=0
cat file.txt | while read line
do
  echo "inside loop"
  a=1
done

echo "outside loop"
echo "a=$a"

Here you’d expect the value of a to be 1 at the end of the script. Instead, if you execute this you have:

inside loop
outside loop
a=0

It’s as if the variable a isn’t even updated. In fact it is, though only inside the loop. So what is happening here?

The pipe (|) you use to feed the loop creates a subshell. In fact this is really just another process. So the exit 1 or a=1 only apply to these piped processes.

How can you fix that?
In the simple case presented above, you can simply use file redirection:

while read line
do
  ...
done < file.txt

But what if you really want to feed the loop with the output of another process. Like you would do with find for instance.

If you use bash you can use process substitution as described here. But you shouldn’t use bash for scripting anyway. For shell scripting you might be tempted to use a temporary file to store the process output:

# Use a temporary file.
tmp=$(mktemp)
find . > $tmp
while read line
do
  ...
done < $tmp 
rm $tmp

However this consumes disk space, and the loop only starts after the find process exited. Another option would be to use a named fifo:

fifo=$(mktemp -u)
mkfifo $fifo
find . > $fifo &

while read file
do
  ...
done < $fifo
rm $fifo

This time you create a single file, yet no disk space is used (apart for the fifo inode itself). Also the find command is a child process, so the loop reads find output as it comes.

Although the version above already works as it should, you may want to use an anonymous fifo. This way you only need to create a fifo file, although you can delete it immediatly. You can achieve this with a little help from our beloved file descriptor 3.

fifo=$(mktemp -u)

# Create fifo
mkfifo $fifo

# Create fd 3 and unlink fifo file.
exec 3<> $fifo
rm $fifo

# Redirect find to fd 3.
find . >&3 &

# Feed fd 3 to while loop.
while read line
do
  ...
done <&3 # Close fd 3. exec 3>&-

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 {{your-user}}

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

Chromium on FreeBSD

Good news everyone! Chromium is now perfectly usable on FreeBSD.
The longstanding hanging tab bug has been resolved. See also PR 212812 and this this FreeBSD forum post.

This was fixed in r337328 but is not yet available in 11.2-RELEASE. Fortunately there are temporary fixes too that you can use while waiting for the patch to be included in the next release.

First add this line to /etc/sysctl.conf:

net.local.stream.recvspace=16384

Second use a memory backed filesystem for the chromium cache. A script to do so was included in the chromium package, but it has since been removed now that a proper fix is coming in.

But if you want to do this manually, first ensure that ~/.cache/chromium directory exists and is empty. Then in /etc/fstab add this line with $USER changed accordingly:

md /home/$USER/.cache/chromium mfs rw,late,noatime,noexec,nosuid,-w$USER:$USER,-s300m 2 0

This will mount the chromium cache path on an UFS partition over a memory backed virtual disk.

I’ve been testing this for several days now and it works like a charm. Don’t forget to remove this workaround when you are past r337328 though.

Random wallpapers

If you ever want to randomly change your wallpapers every few minutes, hours or whatever, I just made a script to do just that. You can find it here.

This script will at regular interval select a random file within the specified directory and use the specified command to use it as a wallpaper. For example if you want to change your wallpaper every 10 minutes with a picture in ~/Pictures/wallpapers.

wp-random.sh 600 ~/Pictures/wallpapers/ feh --bg-scale

Note that we use feh here to setup the wallpaper, but you can use any command you like.

You can use SIGUSR1 to redraw the current wallpaper (for example if you just enabled the VGA output and the background needs a redraw), or SIGUSR2 to force the selection of another wallpaper:


WP_RANDOM_PID=$(cat /tmp/wp-random_$DISPLAY.pid)

# Redraw current wallpaper
kill -SIGUSR1 "$WP_RANDOM_PID"

# Select another wallpaper
kill -SIGUSR2 "$WP_RANDOM_PID"

D-Link DIR AP and IPv6

If you have one of those very common D-Link DIR WiFi router/AP (such as the DIR-605L rev B2), you should know that they don’t get very well with IPv6. At least the vendor firmware doesn’t. Probably most people around here don’t even know and probably don’t even care. But that’s really no good 🙁

Apparently not all IPv6 messages seem to get through. ICMP6 echo-request on link-local addresses are not a problem. However RS messages between Ethernet ports don’t always get through. Here is a little diagram of what goes through and what doesn’t:

This was tested with FreeBSD 11.1-RELEASE-p9 and Debian 9.4.0 and on two different hosts (my trusty ol’ ThinkPad X201 and a homemade station with a Ralink Ethernet card). Still a lot of packets to test though. Don’t know if IPv6 packets themselves go through or not. However RS/RA don’t and that’s sufficient to make IPv6 completely unusable.

I will update the figure above when I know more. Although that may be never, don’t know yet. One solution would be to upgrade the firmware to either DD-WRT or Tomato router. However those are not supporter on the DIR 605L rev B2. Also this was supposed to be a replacement and we already bought a much better alternative.

FreeBSD on Intel Broadwell

Around two years ago I posted about using FreeBSD 10 on the X250. A great deal has happened since then.

It is now possible to use the Intel Broadwell integrated graphic card (among others) under FreeBSD-CURRENT FreeBSD-STABLE! Also if I’m right, this will be integrated in FreeBSD 11.2-RELEASE. What a great day it is for FreeBSD on the desktop. I bet FreeBSD 12 will be truly great!

Note that it works much better on STABLE now than CURRENT because CURRENT is -well- not that stable…

So if you want to try this now, what you first need to do is to upgrade to the STABLE branch. For this you need to fetch the source, buildworld, buildkernel and installworld. Here is a very quick tuto (that you may need to adapt though). You can also find this here.


# Don't forget to upgrade RELEASE
# in any case that there were any bugs in the building tools.
freebsd-update fetch
freebsd-update install
reboot
freebsd-update install

# Replace the current source tree with STABLE.
mv /usr/src /usr/src-RELEASE
svn checkout svn://svn.freebsd.org/base/stable/11 /usr/src

# Build! Build! Build!
cd /usr/src
make buildworld -j4

# Customize (while you are at it) and build STABLE kernel.
cd /usr/src/sys/amd64/conf
cp GENERIC {YOUR-CONF}
vim {YOUR-CONF}
cd /usr/src
make buildkernel KERNCONF={YOUR-CONF}
make installkernel KERNCONF={YOUR-CONF}
reboot

# Now it's time to install world over the new kernel.
# In the meantime we also update configuration files
# with mergemaster.
mergemaster -p
cd /usr/src
make installworld
mergemaster -Ui
reboot

Now that your are on the latest STABLE, you can update the ports tree and install drm-next.


# Install ports tree if needed.
portsnap fetch
portsnap extract

# Install drm-next.
cd /usr/ports/graphics/drm-next-kmod
make install clean

Finally you must tell rc.conf to use the new i915 module instead. That is, add in /etc/rc.conf:


kld_list="/boot/modules/i915kms.ko"

Just one final reboot and you are done! Test this with the xorg and mesa-demos ports. Just startx from your user and check /var/log/Xorg.0.log to see if the intel driver was correctly loaded.