The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: PC Tweakage

Remembering which tweaks worked

  • Pi-Hole with DNS-over-HTTPS

    With none other than Troy Hunt recommending Pi-Hole, I got a Round Tuit:

    unzip 2018-06-27-raspbian-stretch-lite.zip -d /tmp
    sudo dcfldd status=progress bs=1M of=/dev/sde if=/tmp/2018-06-27-raspbian-stretch-lite.img
    

    Raspbian now arrives with ssh disabled, so the first boot requires a keyboard and display:

    Pi-Hole first boot wiring
    Pi-Hole first boot wiring

    Then do some configuration required to get a fresh Raspberry Pi ready for remote access:

    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get install screen iotop
    sudo raspi-config   # enable ssh
    ssh-keygen -t rsa
    cd ~/.ssh
    cp -a /my/public/key authorized_keys
    chmod go-rwx authorized_keys
    cd
    sudo nano /etc/ssh/sshd_config  # unusual port, no root login, etc
    sudo service ssh restart
    

    As the good folks at Pi-Hole say, “Piping to bash is controversial, as it prevents you from reading code that is about to run on your system.” I took a look, it’s beyond my comprehension, so just get it done:

    curl -sSL https://install.pi-hole.net | bash
    

    Configure Pi-Hole:

    • Static IP: 192.168.1.2/24
    • DNS using, say, Cloudflare’s 1.1.1.1
    • DHCP turned off, which is the default

    Configure the router’s DHCP to hand out the Pi-Hole’s IP, with, say, 9.9.9.9 as a backup.

    Boot a few random PCs and whatnot to verify it works as expected, which it did the second time around, thus this particular post.

    Install the Cloudflare Argo Tunnel dæmon, approximately according to suggestions:

    mkdir Downloads
    cd Downloads/
    wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
    tar zxvf cloudflared-stable-linux-arm.tgz
    sudo mkdir /opt/cloudflare
    sudo cp cloudflared /opt/cloudflare/
    

    Start the daemon from within a screen session, also as suggested:

    sudo /opt/cloudflare/cloudflared proxy-dns --port 54 --upstream https://1.1.1.1/.well-known/dns-query --upstream https://1.0.0.1/.well-known/dns-query
    INFO[0000] Adding DNS upstream                           url="https://1.1.1.1/.well-known/dns-query"
    INFO[0000] Adding DNS upstream                           url="https://1.0.0.1/.well-known/dns-query"
    INFO[0000] Starting metrics server                       addr="127.0.0.1:37777"
    INFO[0000] Starting DNS over HTTPS proxy server          addr="dns://localhost:54"
    

    Contrary to the suggestions, you can configure Pi-Hole to use the DoH tunnel (or whatever it’s called) by tweaking its upstream DNS configuration:

    Pi-Hole - Cloudflare DNS config
    Pi-Hole – Cloudflare DNS config

    Then set up systemd to start the daemon automagically:

    sudo nano /etc/systemd/system/dnsproxy.service
    

    Because I put the daemon in /opt/cloudflare, that file differs slightly from the suggestion:

    [Unit]
    Description=CloudFlare DNS over HTTPS Proxy
    Wants=network-online.target
    After=network.target network-online.target
    
    [Service]
    ExecStart=/opt/cloudflare/cloudflared proxy-dns --port 54 --upstream https://1.1.1.1/.well-known/dns-query --upstream https://1.0.0.1/.well-$
    Restart=on-abort
     
    [Install]
    WantedBy=multi-user.target
    

    And then It Just Worked.

    Controversies over the ethics of ad and tracker blocking will go nowhere here, as I’ve cleaned out enough Windows machines to have absolutely no sympathy with the unholy spawn of adtech (not just the company, which I didn’t know existed until just now, but, yeah, them too).

  • Wyze Cam vs. Xiamoi-Dafang Hacks

    The Wyze Cam is a surprisingly inexpensive camera firmly lashed to the Wyze app, with no provision for ordinary IP camera streaming. It seems to be a generic camera with custom firmware and, unsurprisingly, one can commandeer the bootloader with different firmware from a MicroSD card, thereby adding missing functions and suppressing undesired actions.

    Oddly, buying a genuine Wyze Cam directly from Wyze isn’t significantly more expensive than a generic from the usual eBay / Amazon sellers. Bonus: the legit camera arrives next week rather than in a month or two.

    I found one of my few remaining 2 GB MicroSD cards, formatted it with a 512 MB (!) FAT32 partition (per the suggestions), set up the “custom firmware” bootloader, and installed it with no issues.

    Installing the new firmware requires copying a directory tree, configuring the WiFi SSID and password in the usual wpa_supplicant, and rebooting. Works fine and, yeah, the camera now runs Linux.

    I told the router to assign a known IP address to the camera’s MAC address, set up port forwarding for port 8554 to that IP address, put the camera against the storm window in the kitchen, and rebooted everything to get it working:

    Wyze Cam in kitchen window
    Wyze Cam in kitchen window

    Unfortunately, while it works more-or-less well with browsers on the local network, it’s apparently inaccessible from outside. The router manages a DDNS name-to-IP mapping to make itself findable, the port is open, the forwarding seems correct, no image data arrives to browsers outside, and they eventually time out.

    Changing to port 8080 doesn’t help, nor does using MJPEG instead of H264 encoding.

    Even more unfortunately, the router doesn’t do hairpin connections (inside to outside to inside), so I can’t debug this mess from the Comfy Chair.

    This is a placeholder for what I’ve done while I accumulate more knowledge …

  • Troubles in PC Land

    So this happened:

    Dell Optiplex - SSD failure
    Dell Optiplex – SSD failure

    As far as I can tell, the Crucial M5500 SSD in that PC (an off-lease Dell Optiplex 760) stopped being a SATA hard drive, although it seems to work OK when jammed in a USB adapter.

    So I picked up a new-to-me Optiplex 9020 with Windows 8.1 on an SSD, shrank the partition, tried to install Xubuntu 18.04, fat-fingered the UEFI password dance, reinstalled Windows from the SSD’s recovery partition, and got this display after a while (clicky for more dots):

    Dell Optiplex - recovery disk stall
    Dell Optiplex – recovery disk stall

    After letting it stew in its own juices during supper, I forced it off (pushed the power button until it died), restarted, got through the UEFI dance, and it now seems All Good. I made recovery DVDs (remember DVDs?), both before and after the fumbled Xubuntu installation, but didn’t need them.

    I expect we’ll never boot Windows 8.1 again, but it’s there Just In Case.

  • LibreOffice 5.3+ vs. Adobe Type 1 Fonts

    LibreOffice from 5.3 onward (Xubuntu 18.04 uses LO 6.0) no longer supports Adobe Type 1 fonts, which comes as a surprise to those of us who actually bought fonts, back in the day, and have been using them ever since. Apparently, Windows dropped Type 1 font support some time ago.

    Based on some hints, I set up the Adobe Font Development Kit for OpenType. It’s a Python thing, preferably running in a virtual environment to avoid screwing up the rest of one’s system with bizarre dependencies. It seems one (“I”) must not update pip using pip after installing python-pip using apt-get; recovering from that mess was good for another hour of flailing.

    The default AFDKO installation spat out an error message about ufolib (I am not making this up) being at 2.1.1, instead of the required 2.3.1. In for a penny, in for a pound, I updated ADFKO with the “prerelease” option:

    pip install -U afdko --pre
    

    Which fetched ufolib 2.3.1, apparently from wherever Python keeps its prerelease stash. I have NFC what’s going on with any of this.

    An Adobe blog post on the AFDKO tx tool suggested it can convert Type 1 fonts to CFF (a.k.a. Adobe Type 2) fonts and some poking around suggested CFF also figures in OTF fonts.

    tx -cff -n -N -A awb_____.pfb
    --- Filename: awb_____.pfb
    --- FontName: ACaslon-Bold
    tx: --- awb_____.pfb
    tx: (cfw) unhinted
    tx: (cfw) unhinted
    tx: (cfw) unhinted
    tx: (cfw) unhinted
    tx: (cfw) unhinted
    tx: (cfw) There are 222 additional reports of 'unhinted'.
    

    The -A option replaces the bizarre Adobe 8.3 file names with actual font information:

    awrg____.pfb ⇒ ACaslon-Bold.cff
    awbi____.pfb ⇒ ACaslon-BoldItalic.cff
    awi_____.pfb ⇒ ACaslon-Italic.cff
    awrg____.pfb ⇒ ACaslon-Regular.cff
    awsb____.pfb ⇒ ACaslon-Semibold.cff
    awsbi___.pfb ⇒ ACaslon-SemiboldItalic.cff
    

    Regrettably, CFF files don’t actually work as fonts, at least as far as LibreOffice 6.0 (or whatever it uses as a font engine) is concerned.

    Although it’s possible to convert fonts locally with fontforge, doing it one-by-one is tedious and the learning curve for its Python scripting feature seems rather steep. I fired the most vital fonts at Convertio, an online converter running fontforge in the background, got a matching pile of OTF fonts, and installed them in /usr/share/fonts/custom/type1 to indicate their heritage.

    Whereupon LO rammed into a problem I’d had before. The solution this time required sorting the various Caslon and American Typewriter fonts into different “font families” and forcing the TTF names to match their new families. The difference between Medium and Regular seems to have Gone Away.

    I should just use Comic Sans and be done with it …

  • SANE Scanner vs. Xubuntu 18.04

    I recently bumped the desktop PC with the scanner from an old Mint to Xubuntu 18.04, which killed a day with all the system and UI tweakage.

    The old guides for setting up a networked SANE scanner became inoperative with systemd ruling the configurations, so, after some flailing around, I found a newer guide referencing a guide for USB scanners and pointing to a deeper guide for network sharing in the age of systemd.

    The USB guide points out the existence of Access Control Lists for the various device files, which I didn’t know was a thing. AFAICT, you must still be in the scanner group for remote access to happen.

    I lost track of the changes during all the flailing around, but it definitely didn’t Just Work.

    I’m sure all this will change before I must do it again.

  • Amazon Basics AA Cells: Capacity

    Being that sort of bear, I (sometimes) note the date on cells when I change them, as with this notation on the AA alkaline cells in the Logitech trackball:

    Amazon Basics AA cell - mouse runtime
    Amazon Basics AA cell – mouse runtime

    These Amazon Basics AA cells lasted almost exactly two years, compared with 15 and 20 months from the previous two pairs of Duracell AAs. A few months one way or the other probably don’t mean much, but the Amazon cells aren’t complete duds.

    The new Amazon Basics cells have a gray paint job, so they’ve either changed suppliers or branding.

  • Toshiba 3 TB Drive Format & Speed

    A new Toshiba Canvio Basics 3 TB drive has two partitions:

    sudo fdisk -l /dev/sdb
    Disk /dev/sdb: 2.7 TiB, 3000592979968 bytes, 5860533164 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: gpt
    Disk identifier: 575F7910-3F93-4FC5-B50F-7D1F05810EE6
    
    Device      Start        End    Sectors  Size Type
    /dev/sdb1      34     262177     262144  128M Microsoft reserved
    /dev/sdb2  264192 5860532223 5860268032  2.7T Microsoft basic data
    
    Partition 1 does not start on physical sector boundary.
    

    The “Microsoft reserved” partition is new to me. It’s apparently not a real partition, but a dumping ground for Windows disk management information.

    The drive is a classic Black Box:

    Toshiba 3 TB USB drive
    Toshiba 3 TB USB drive

    It comes with no specs, other than the tediously qualified “3 TB”, and the Toshiba web page shows only a 5 Gb/s = 625 MB/s “Max. transfer rate”.

    A quick test slurping data from the Sandisk video-rated MicroSD card extracted from the Fly6 camera shows it can write data at a sustained 21 MB/s:

    time rsync -ahu --progress /mnt/Fly6/ /mnt/part/test/
    sending incremental file list
    ./
    CONFIG.TXT
                 33 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=29/31)
    FLY6.VER
                 14 100%   13.67kB/s    0:00:00 (xfr#2, to-chk=28/31)
    DCIM/
    DCIM/15880604/
    DCIM/15980609/
    DCIM/15980609/09490001.AVI
            499.32M 100%   21.61MB/s    0:00:22 (xfr#3, to-chk=21/31)
    DCIM/15980609/09590002.AVI
            497.75M 100%   20.95MB/s    0:00:22 (xfr#4, to-chk=20/31)
    DCIM/15980609/10090003.AVI
            499.06M 100%   21.31MB/s    0:00:22 (xfr#5, to-chk=19/31)
    DCIM/15980609/10190004.AVI
            278.10M 100%   21.48MB/s    0:00:12 (xfr#6, to-chk=18/31)
    
    ... snippage ...
    
    real	6m26.272s
    user	0m55.900s
    sys	0m25.496s
    

    That’s with the card jammed into an Anker USB 3.0 adapter and both devices plugged into the two USB 3.0 “Super Speed” ports in the front of my desktop box. Plugging them both into the adjacent USB 2.0 ports drops the data rate to 18 MB/s.

    The Sandisk card claims read-write speeds of “up to” 20 MB/s, so it’s the limiting factor.

    Getting reliable performance numbers is surprisingly difficult:

    dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random.bin
    4177526784 bytes (4.2 GB, 3.9 GiB) copied, 214.064 s, 19.5 MB/s 
    1000+0 records in
    1000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 214.922 s, 19.5 MB/s
    
    dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random2.bin
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s  
    1000+0 records in
    1000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s
    

    Obviously, prying bits out of the random number generator limits the overall write speed.

    Zeros, however, are cheap and readily available:

    dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null.bin
    4169138176 bytes (4.2 GB, 3.9 GiB) copied, 23.0091 s, 181 MB/s
    1000+0 records in
    1000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.1775 s, 181 MB/s
    
    dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null2.bin
    4093640704 bytes (4.1 GB, 3.8 GiB) copied, 25.031 s, 164 MB/s 
    1000+0 records in
    1000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 25.7781 s, 163 MB/s
    

    But the caches take a while to drain, even after the command returns:

    time ( dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null3.bin ; sync )
    4118806528 bytes (4.1 GB, 3.8 GiB) copied, 23.0004 s, 179 MB/s
    1000+0 records in
    1000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.5305 s, 178 MB/s
    
    real	0m35.887s
    user	0m0.008s
    sys	0m4.824s
    

    Dividing 4 GB / 35.9 s says the mechanical write speed is close to 110 MB/s.

    Reading proceeds a bit faster, while also running up against the effect of the many caches between the spinning platter and the screen:

    time ( cp /mnt/part/random.bin /dev/null )
    real	0m36.565s
    user	0m0.048s
    sys	0m1.712s
    
    time ( cp /mnt/part/random.bin /dev/null )
    real	0m29.157s
    user	0m0.036s
    sys	0m1.800s
    
    time ( cp /mnt/part/random.bin /dev/null )
    real	0m10.265s
    user	0m0.028s
    sys	0m1.040s
    
    time ( cp /mnt/part/random.bin /dev/null )
    real	0m0.608s
    user	0m0.004s
    sys	0m0.600s
    
    time ( cp /mnt/part/random.bin /dev/null )
    real	0m0.590s
    user	0m0.008s
    sys	0m0.580s
    
    time ( cp /mnt/part/random2.bin /dev/null )
    real	0m31.035s
    user	0m0.056s
    sys	0m1.816s
    
    time ( cp /mnt/part/random2.bin /dev/null )
    real	0m31.024s
    user	0m0.052s
    sys	0m1.860s
    

    Unsurprisingly, copying a brace of 4 GB files in parallel takes twice as long as each cold-buffer read, so disk’s raw read speed seems to be around 130 MB/s.

    The drive’s write speed won’t be the limiting factor while saving camera video data!