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 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
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
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.
I disagree with RFC6797 on HTTP Strict Transport Security, especially Section 12.1: No User Recourse. If you want to stop users to randomly press the big red BYPASS button because they have no clue what they are doing, you might as well stop them to use a computer.
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
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:
# Redraw current wallpaper
kill -SIGUSR1 "$WP_RANDOM_PID"
# Select another wallpaper
kill -SIGUSR2 "$WP_RANDOM_PID"
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.