ADUFRAY

Wow, what a hassle. I recently acquired a new Optoma UHZ45 Projector and wanted to play some 3D MKVs I had laying around. This was simple on my old Samsung PN64D800 plasma TV and Kodi, so it should be simple here, too, right? No. Read on!

With the TV, any playing device would work - the TV would let you force 3D processing (side-by-side or top-and-bottom). Unfortunately, this projector doesn’t support that. You need a “real” 3D HDMI signal for it to turn on the 3D mode, otherwise all the options will remain greyed out and disabled. Some quick Googling showed Kodi introduced support for MVC 3D quite some time ago, so I picked my most-capable device to try first: the NVIDIA Shield TV Pro.

No dice.

Well, maybe it can’t do 3D @ 4K resolution, that’s reasonable, and the videos are only 1080p or 720p, anyway. I changed the resolution. Still nothing, all greyed out. Alright, let me try the refresh rate? 60 Hz? No. 24 Hz? No. 23.96 Hz? No! Better check the manual to see what’s officially supported.

Alright, the manual says side-by-side (and top-and-bottom) are only supported on HDMI port 3. (It also says frame-packed content is limited to 1080p/24hz or 720p/60hz, but can be on any of the 3 HDMI ports.) Alright, fair enough. Swapped the HDMI cable and… still no. To Google! Ah, NVIDIA does not support MVC 3D whatsoever. NVIDIA has even said in their forums they won’t support it, or at least there are no plans to. Let me try this Raspberry Pi 4B, surely that can do it.

I load up a fresh install of LibreELEC 11 Beta 1, configure my share, open the video. Too bad! Tried all the resolutions again, nothing. Tried some frame-packed Blu-ray rips, still nothing. More Googling. Apparently the Raspberry Pi 4 didn’t (and, therefore, maybe still doesn’t) support MVC 3D, but the Raspberry Pi 3 did. Alright, I thankfully have one of those, too.

Swap the SD card, boot the Raspberry Pi 3, try various resolutions. Still! Nothing! Is it time to return the projector and get a much more 3D-capable BenQ? More Googling. I found a comment in the Kodi forums where the recommendation was made, “if MVC 3D is important to you, stick with Kodi Leia (v18)”. Kodi somewhat recently changed their video rendering to a new driver, and MVC 3D is “not a priority”, and I guess it’s still broken/unsupported. Thankfully the LibreELEC 9.8.2 release featuring Kodi Leia (v18) is still available for download. In the Expert options there’s a new flag under Settings > System > Video: Enable Full HD HDMI modes for stereoscopic 3D: This option uses frame-packing to output full resolution for 3D through HDMI. Enabling this improves quality of Multiview Video Coding (MVC) videos, but may not be supported by all displays. This sounds promising!

I check everything: Raspberry Pi 3. Kodi v18. 1080p. 24Hz. HDMI 3. MVC video file. Let’s go! And it finally works. On a whim, I decided to try the original half side-by-side video I had: and it works, too! Fantastic. Hopefully this helps someone, I see a million posts on AVSforums of people complaining about Optoma projectors and getting 3D content to work. I nearly gave up myself, so I don’t blame them!

I thought it might be fun to put my Late 2006 iMac (iMac6,1) to some use and install the latest version of Ubuntu on it: 18.04 Bionic Beaver. This older model iMac comes with the Core2Duo chipset, which is 64-bit. Unfortunately the Apple EFI on it only supports 32-bit, and so you will likely be unable to use normal install ISOs. You can avoid this problem by skipping EFI altogether and going into normal BIOS booting. Matt Gadient wrote a very useful blog post describing the problem and a few different fixes. I ended up having to burn an actual DVD for the install to work; I could not get either native EFI solution to work.

After installing Ubuntu, there were two things not working out-of-the-box: the AirPort card and the nVidia drivers.

1. The AirPort card was easy enough to fix and this is well-documented. There is an error in the dmesg output that directs you to the kernel wiki page, but I did not find that particularly useful. As usual, Stack Exchange has a great, thorough answer. If you have network connectivity already via an Ethernet cable, just go ahead and type sudo apt install firmware-b43-installer. The post outlines instructions if you need to do it offline as well. Unplug your Ethernet, reboot, and you should now be able to see your available WiFi networks.

2. The bigger challege was getting the nVidia driver to work. According to Ubuntu bug #1763648, Canonical will no longer be including support for many older GeForce cards, including the 7300 GT. Thankfully, Seth Forshee has already created a patch! I’m not sure the correct way to patch an Ubuntu PPA, so I manually applied the patches to nVidia’s installer file. There’s actually two patches you’ll need to apply: buildfix_kernel_4.14.patch and buildfix_kernel_4.15.patch

However, before we get to patching and installing the official nVidia binary drivers, we need to disable nouveau, the open source version. To do that, enter these commands:

$ sudo su -
# cat << END > /etc/modprobe.d/disable-nouveau.conf
blacklist nouveau
blacklist vga16fb
blacklist rivafb
blacklist nvidiafb
blacklist rivatv
blacklist amd76_edac
options nouveau modeset=0
END
# update-initramfs -u
# reboot

After the system finishes rebooting, we need to install the necessary build tools:

$ sudo apt install gcc make build-essential gcc-multilib dkms mesa-utils

Now we’re ready for patching. Here is the combined patch file (the aforereferenced patches are “meta” patches, as they’re patches to the package and not the software itself, which is sort of like a Russian nesting doll of software changes). This combined patch can be applied to the directory created using sh NVIDIA-Linux-x86_64-304.137.run -x.

Click here to download nvidia-304.137-bionic-18.04.patch.

Once you have the patch saved into your home directory, you can apply it and begin the installation using these commands:

$ ./NVIDIA-Linux-x86_64-304.137.run -x
$ cd ./NVIDIA-Linux-x86_64-304.137
$ patch -p1 < ~/nvidia-304.137-bionic-18.04.patch
$ sudo ./nvidia-installer

You can ignore the first warning about the preinstall failing, as it is merely a check to make sure you want to do this. Go ahead and view less /usr/lib/nvidia/pre-install if you don’t believe me! The build should complete and you should let it update your config files. Reboot again and then verify you’re using the nVidia driver:

$ lshw -c video 2>&1 | grep driver

You want to make sure you see:

       configuration: driver=nvidia latency=0

And not:

       configuration: driver=nouveau latency=0

I recently upgraded my AT&T modem from the NVG 589 to the Pace 5268AC at the insistence of a technician out to repair my ONT. I had been having some packet loss issues and hoped the upgrade would help (it seemed to). However, I noticed immediately my NTP packets were being filtered. I thought this was odd, but found the following resources:

• AT&T’s Broadband Information page
• AT&T’s Fiber Equipment Forum discussing NTP being blocked
• Another AT&T Forum page documenting the 5268AC in particular
• CloudFlare’s blog detailing NTP DDoS Amplification Attacks

After studying all of these pages and looking at countless lines of tcpdump output, I confirmed a few things:

• NTP traffic is indeed filtered both inbound and outbound
• It is not an outright block, but a rate limit
• The outbound filter applies only to traffic with source port 123/udp, an ephemeral port is fine

Sadly, the Network Time Foundation’s reference implementation of ntpd only permits using an ephemeral source port when using ntpdate and not from ntpd itself. Therefore, while behind an AT&T network, it seems not possible to run ntpd without some kind of middleware piece to mangle your UDP packets (e.g., iptables). This makes things very difficult in a modern home with all the following devices using NTP:

• Network security cameras
• iPhones/iPads/Macs
• Media players, like Apple TVs
• Wireless access points
• “Smart” TVs

I was able to configure a local NTP server using OpenBSD’s OpenNTPd, which uses ephemeral source ports by default. Most of my devices I was able to reconfigure to use my local time server, however many devices do not expose that configuration to the end user - in particular iOS devices and Apple TVs. In fact, they were the noisiest devices on the network attempting to sync time. In order to resolve those devices, I had to add stub DNS zones to my local DNS. I created replacement zones for:

• time.apple.com
• time-ios.g.aaplimg.com

Once I pointed those hostnames to my local NTP server, everything seemed to resolve itself. Even systems that I cannot change from ntpd to OpenNTPd can now sync time using my local servers, which is pretty great.

I also looked at using Chrony instead of OpenNTPd, but after installation on my FreeBSD server I received this scary message:

Unfortunately, this software has shameful history of several vulnerabilities
previously discovered.  FreeBSD Project cannot guarantee that this spree had
come to an end.  Please type ``pkg delete chrony'' to deinstall the port
if tight security is a concern.

I liked the idea of using Chrony because my system monitoring tool of choice, Check_MK, already had a plugin to monitor Chrony, and as far as I can tell didn’t have one for OpenNTPd. On top of that, Chrony is now the default NTP server in Red Hat Enterprise Linux starting with version 7.

Since I trust OpenBSD’s security track record vs. a group I’ve never heard of and the most alarming message I’ve ever seen installing a port, I stuck with OpenNTPd. I was also able to make quick work of a Check_MK plugin, despite ntpctl’s absolutely terrible output. (Seriously, who designed that?) Here’s the plugin - you just need to add the sample output’s command either in your plugins directory or directly to check_mk_agent itself, prepending it with <<<openntpd>>> of course.

#!/usr/bin/python

# 2017 (c) adufray.com
# bsd license
# openntpd check_mk plugin to fit with ntp checks
# note: only supports servers/peers, not sensors

ntp_default_levels = (10, 200.0, 500.0) # stratum, ms offset

# Example output from agent:
# $ ntpctl -s a | paste - - | nl | egrep -E '^     1[[:space:]]|[*]' | cut -f 2- | sed -e 's/[[:space:]][[:space:]]*/ /g'
# 4/4 peers valid, clock synced, stratum 4
# 69.164.202.202 from pool us.pool.ntp.org * 1 10 3 2s 30s -0.053ms 8.154ms 1.675ms

def inventory_openntpd(info):
    if info[0]:
        return [(None, "ntp_default_levels")]

def check_openntpd(_no_item, params, info):
    if not info[0]:
        yield 2, "No status information, openntpd probably not running"
        return
    if "clock unsynced" in " ".join(info[0]):
        yield 2, "%s" % " ".join(info[0])
        return

    # Prepare parameters
    crit_stratum, warn, crit = params

    # Check offset and stratum, output a few info texsts
    offset = float(info[1][-3][0:-2])
    stratum = int(info[1][-6])

    # Check stratum
    infotext = "stratum %d" % stratum
    if stratum >= crit_stratum:
        yield 2, infotext + " (maximum allowed is %d)" % (crit_stratum - 1)
    else:
        yield 0, infotext

    # Check offset
    status = 0
    infotext = "offset %.4f ms" % offset
    if abs(offset) >= crit:
        status = 2
    elif abs(offset) >= warn:
        status = 1
    if status:
        infotext += " (levels at %.4f/%.4f ms)" % (warn, crit)
    yield status, infotext, [ ("offset", offset, warn, crit, 0, None) ]

    # Show additional information
    if info[1][1] == "from":
       yield 0, "reference: %s" % "/".join(info[1][0:4:3])
    else:
       yield 0, "reference: %s" % "/".join(info[1][0:2])

check_info["openntpd"] = {
   'check_function':          check_openntpd,
   'inventory_function':      inventory_openntpd,
   'service_description':     'NTP Time',
   'has_perfdata':            True,
   'group':                   'ntp_time',
}

I suppose this will be a solid enough solution until Poul-Henning Kamp’s masterpiece, Ntimed, is released!

In the process of installing a new FreeBSD system, I was presented with the question of which mirror to use. Of course, I’m doing a netinstall, so I want the fastest mirror, but how can I find that information?

for i in {1..15}; do
    echo -n "ftp${i}.us.freebsd.org: ";
    ping -qc1 ftp${i}.us.freebsd.org | tail -1;
done

This was nice, but is ultimately only measuring latency. Most of the servers were between 30-40ms, so nothing conclusive. How about measuring actual transfer speed? To do that, I need a smallish file to download from each one. I found a 25 MB file in the CVS-archive directory that suited this nicely.

for i in {1..15}; do
    echo -n "ftp${i}.us.freebsd.org: ";
    curl -o /dev/null -m 30 ftp://ftp${i}.us.freebsd.org/pub/FreeBSD/development/CVS-archive/projcvs-projects-archive.tar.gz 2>&1 | \
        tail -1 | \
        egrep -o '[^[:cntrl:]]+$';
done

The output could be cleaner probably, but all you have to do is check out the 9th column for the duration of the transfer, and whoever scored lowest wins!

I’ve been a long-time user of XBMC, the Xbox Media Center software, since back when it ran on the original Xbox. It’s always impressed what the developers could do with such little horsepower. I remember playing 720p XviDs on the original Xbox, when it was difficult to do it otherwise.

Now, it is just as impressive. You can stream full bitrate Blu-ray images to your TV via LibreELEC/Kodi and a cheap Raspberry Pi 3. Here’s my part list:

Part	Price
Raspberry Pi 3	$35.00
16 GB microSDHC Card	$5.45
Power Supply	$6.65
VC-1 Codec License	£1.00
MPEG2 Codec License	£2.00
Kodi RPi Case	$19.95
Flirc IR USB	$14.92
Total	~$86.36

All you truly need is the Raspberry Pi, the microSDHC card, and the power supply (you can use any 2 amp power supply and micro USB cable you have lying around, perhaps an old iPad charger), which puts the required cost at about ~$47. The rest are nice-to-haves.

Once you have your parts, load up the LibreELEC (successor to OpenELEC) Raspberry Pi 3 image. If you buy the extra codec licenses, simply execute the following commands:

# mount -o remount,rw /flash
# cat << END >> /flash/config.txt
decode_MPG2=0xbeefcafe  //replace with your keys
decode_WVC1=0xdeadfade
END
# reboot

When you reboot, SSH back into LibreELEC and type these commands to confirm they’re enabled:

# vcgencmd codec_enabled MPG2
# vcgencmd codec_enabled WVC1

You should see the following output:

MPG2=enabled
WVC1=enabled

After all this, I was able to stream ~35 Mb/s bitrate Blu-ray rips from my Samba share across wired Ethernet. The Raspberry Pi 3 also has built-in WiFi, so you can conceivably stream most things without that extra cable — probably not 30+ Mb/s bitrate though.