Present Location: News >> Blog


> Ignoring ICMPv6 PTBs
Posted by prox, from Seattle, on December 30, 2017 at 21:31 local (server) time

I've started a list of websites that are inaccessible from tunnels or VPNs because they block ICMPv6 PTBs.

Really, it's getting annoying.  The one that got added tonight was  It's fairly ironic, too.

Comments: 0
> macOS Pro Tip
Posted by prox, from Seattle, on December 16, 2017 at 13:43 local (server) time

I didn't really like Chrome/Chromium's two-finger back/forward navigation feature as I'd accidentally trigger it once or twice a week.  However, I let my wife use my MacBook today and within a few minutes she was screaming about the same thing.  So, I found a solution and set it for the two browsers I use:

defaults write org.chromium.Chromium AppleEnableSwipeNavigateWithScrolls -bool FALSE
defaults write AppleEnableSwipeNavigateWithScrolls -bool FALSE

You can see it's successfully set:

(orion:10:39:PST)% defaults read org.chromium.Chromium                                             
    AppleEnableSwipeNavigateWithScrolls = 0;
    LastRunAppBundlePath = "/Applications/";
    NSNavLastRootDirectory = "~/Desktop";
    NSNavPanelExpandedSizeForOpenMode = "{712, 448}";
    NSNavPanelExpandedSizeForSaveMode = "{712, 504}";

I'm really not sure how useful this is considering back/forward in browsers really does more harm than good nowadays with JS-rich sites so it's curious Google has this enabled by default.

Comments: 0
> iOS 11 Sucks
Posted by prox, from Seattle, on October 25, 2017 at 00:18 local (server) time

Warning: Whiny rant below!

I hate iOS 11.  There's nothing I like about it.  It makes my iPad (2017 model, 7th generation, whatever you want to call it) much more difficult to use and provides me absolutely no benefits over iOS 10.

Here's a list of useful applications that are no longer supported since they're 32-bit only (indirectly, this is Apple's fault):

Also, there's a bug in iTunes 12.7 that results in all of the tracks from my legally-purchased (albeit manually tagged) music showing up as separate albums.  Yes, that makes browsing music by album fairly useless.  Other folks are suffering from the same problem but the only solution seems to be to downgrade iTunes, something I can't do because older versions don't support my iPad.

The one thing they could have done for me is to allow location services to be toggled from the control center.  But nope, that's not part of the available toggles that can be customized.  Figures, since Apple wants that to stay on 24x7.


Comments: 0
> VirtualBox Host-Only Networking
Posted by prox, from Seattle, on August 19, 2017 at 11:39 local (server) time

For about two weeks, I've been trying to troubleshoot some odd host-only networking issues with VirtualBox.  It turned out to be a configuration-related bug in a file marked DO NOT EDIT THIS FILE, which, of course, I ultimately had to edit.

I previously had two VirtualBox VMs, dax (FreeBSD) and adria (Linux) connected together using intnet networking.  The setup worked, but I wanted to convert the adria VM to an LXC instance since I didn't actually need full VM emulation.  I spun up the LXC with the following in its configuration file:

# Networking = veth = eth0 = lxcbr0 = 00:02:bc:56:cc:99

Then, I put the following in /etc/network/interfaces on the host:

# lxcbr0: bridges vboxnet1/vtnet2 on dax to adria
# This cannot be auto because vboxnet1 does not exist on boot
#auto lxcbr0
iface lxcbr0 inet manual
        bridge_ports vboxnet1
        bridge_fd 0
        bridge_maxwait 0

Since VirtualBox's bridging doesn't play nice directly with LXC veth interfaces (explained here), I decided to convert dax's interface to host-only networking (vboxnet1) and use Linux's native bridging on the host to connect the VM and LXC.  I ended up with the following:

(excalibur:14:09:EDT)% ifconfig vboxnet1
vboxnet1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        ether 0a:00:27:00:00:01  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 13  overruns 0  frame 0
        TX packets 19796  bytes 29052799 (27.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(excalibur:14:09:EDT)% ifconfig vethGEVFJP
        inet6 fe80::fca5:45ff:fee5:ecb2  prefixlen 64  scopeid 0x20<link>
        ether fe:a5:45:e5:ec:b2  txqueuelen 1000  (Ethernet)
        RX packets 15215  bytes 1209437 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19678  bytes 29042119 (27.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(excalibur:14:09:EDT)% brctl show         
bridge name	bridge id		STP enabled	interfaces
lxcbr0		8000.0a0027000001	no		vboxnet1
(excalibur:14:09:EDT)% sudo lxc-ls -f     
NAME  STATE   AUTOSTART GROUPS IPV4       IPV6                               
adria RUNNING 0         - 2620:6:2000:12e:202:bcff:fe56:cc99 

Looks good, right?  Wrong.  Connectivity worked, but only in one direction, and it seemed to be stopping on vboxnet1.  After lots of tcpdumps, I figured out the following.

LXC ---> VM  (GOOD)

More specifically:

LXC -- vethGEVFJP --> lxcbr0 -- vboxnet1   --> VM  (GOOD)
VM  -- vboxnet1   --> lxcbr0 -- vethGEVFJP --> LXC (DROPPED)
     |---- DROPPED HERE

Here are all of the things I tried, but none worked:

It seemed that the problem was on the VirtualBox side between vboxnet1 and the actual VM (vtnet2 on FreeBSD).  This was odd, because I also have vboxnet0 connected to the host and the configuration is identical:

(excalibur:14:18:EDT)% VBoxManage showvminfo dax|grep NIC|head -n3
NIC 1:           MAC: 0002BC56CB39, Attachment: Bridged Interface 'eth0', Cable connected: on,\
Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps,\
Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none
NIC 2:           MAC: 0002BC56CB99, Attachment: Host-only Interface 'vboxnet0', Cable connected: on,\
Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps,\
Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none
NIC 3:           MAC: 0002BC56CB29, Attachment: Host-only Interface 'vboxnet1', Cable connected: on,\
 Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps,\
Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none

So, what's the problem, here?  I started looking into configuration files.  Here's what I found in ~/VirtualBox VMs/dax/dax.vbox:

        <Adapter slot="0" enabled="true" MACAddress="0002BC56CB39" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          <BridgedInterface name="eth0"/>
        <Adapter slot="1" enabled="true" MACAddress="0002BC56CB99" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          <HostOnlyInterface name="vboxnet0"/>
        <Adapter slot="2" enabled="true" MACAddress="0002BC56CB29" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
            <BridgedInterface name="tap0"/>
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          <HostOnlyInterface name="vboxnet1"/>
        <Adapter slot="3" cable="true" type="82540EM"/>
        <Adapter slot="4" cable="true" type="82540EM"/>
        <Adapter slot="5" cable="true" type="82540EM"/>
        <Adapter slot="6" cable="true" type="82540EM"/>
        <Adapter slot="7" cable="true" type="82540EM"/>

The only thing that was different between vboxnet0 and vboxnet1 was the BridgedInterface under the DisabledModes tag.  It must have been added during my original try to get LXC connectivity working and then modified when I used the TAP device during troubleshooting.  It shouldn't matter because it's disabled.  Also, there's a big warning on the top of the file stating:

** If you make changes to this file while any VirtualBox related application
** is running, your changes will be overwritten later, without taking effect.
** Use VBoxManage or the VirtualBox Manager GUI to make changes.

Well, I made changes to it and removed that one BridgedInterface line, but when the VM was stopped.  Bingo, that fixed it.  I now have bidirectional networking through the Linux bridge between my VM and LXC instance.

This smells like a bug.  VirtualBox must erroneously apply some networking state when it reads through DisabledModes when it really shouldn't.  As a result, I opened ticket 17022.

Comments: 0
> rtl8192cu vs 8192cu on RPi
Posted by prox, from Seattle, on June 22, 2017 at 02:06 local (server) time

From the RPi annoyances department..

I did a kernel upgrade on one of my Raspberry Pis earlier today by installing the latest raspberrypi-kernel from testing (1.20170515-1).  It installed Linux 4.9.28+ and I instantly realized there was something wrong since the Wi-Fi was very latent and would periodically disconnect from any nearby WAPs.  I use the Edimax EW-7811u USB stick since this Raspberry Pi is one of the original model Bs without Wi-Fi.

After debugging a bit and searching the Internet it appeared that I was now using the wrong driver, rtl8192cu instead of 8192cu:

(henry:22:18:PDT)% uname -a
Linux henry 4.9.28+ #998 Mon May 15 16:50:35 BST 2017 armv6l GNU/Linux
(henry:22:19:PDT)% lsmod|grep -i rtl
rtl8192cu              79230  0
rtl_usb                12234  1 rtl8192cu
rtl8192c_common        57894  1 rtl8192cu
rtlwifi                85339  3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211              650547  3 rtl_usb,rtlwifi,rtl8192cu
cfg80211              525710  2 mac80211,rtlwifi

Apparently, before this upgrade the 8192cu driver was being used.  So, I added "blacklist rtl8192cu" to /etc/modprobe.d/raspi-blacklist.conf and rebooted.  Bingo, the right module is now being used:

(henry:23:04:PDT)% lsmod|grep 8192
8192cu                597868  0
cfg80211              525710  1 8192cu

No more Wi-Fi drops!

Comments: 0
> Caribbean Cruise
Posted by prox, from Seattle, on June 11, 2017 at 15:02 local (server) time

It's been awhile since I've posted something here, again.

Devon and I recently completed a Caribbean cruise on the Norwegian Escape.  The ship itself was fairly new (built in 2015) but was packet to the gills.  There were over 4,100 passengers!  As a result, it was difficult to use the elevators from time to time.

Blue Lagoon

We departed out of Miami and visited Nassau, St. Thomas, and Tortola.  I uploaded some random photos.  The image above is from the north side of Blue Lagoon, which was pretty deserted.

Comments: 0
> BIRD Musings
Posted by prox, from Seattle, on February 22, 2017 at 00:09 local (server) time

I started messing with BIRD the other day to work around some IPv6 issues with Quagga.  The configuration is fairly simple, but I ran into a weird issue where it picks the wrong interface IPv4 address from some of my OpenVPN tunnels.  For example, I've got these interfaces:

(storm:0:06:EST)% ip a s tun0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1456 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet peer scope global tun0
       valid_lft forever preferred_lft forever
(storm:0:06:EST)% ip a s tun1
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1456 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet peer scope global tun1
       valid_lft forever preferred_lft forever

Here's what BIRD sees:

bird> show route protocol direct1       dev lo [direct1 23:53:06] * (240)     dev tun0 [direct1 23:53:06] * (240)     dev tun1 [direct1 23:53:06] * (240)   dev eth0 [direct1 23:53:06] * (240)

The addresses shown are the remote end of the OpenVPN tunnels, not the local end, which I'd expect.


Update: Well, this should have been obvious:

(storm:0:34:EST)% ip r s p kernel   dev tun0 scope link src dev tun1 scope link src dev eth0 scope link src

I suppose I'll have to figure out how to get the link source to be visible to BIRD so I can advertise it, which is one of my odd requirements here.

Comments: 0
> apt-get SIGABRT
Posted by prox, from Seattle, on February 05, 2017 at 22:10 local (server) time

As I was doing upgrades on a few of my Raspberry Pi machines (running Raspbian), I ran into a situation where apt-get would SIGABRT on any action.  Depending on the shell, the message to the user is a little different and also overwrites a different amount of APT's status message.  Here's Zsh:

(storm:20:50:EST)% sudo apt-get --purge remove quagga-pimd quagga-isisd quagga-ospfd quagga-ospf6d
zsh: abort      sudo apt-get --purge remove quagga-pimd quagga-isisd quagga-ospfd

Here's Bash:

prox@storm:~$ sudo apt-get --purge remove quagga-pimd 
Aborted package lists... 48%

No matter what the operation (install, upgrade, update, remove), APT would just get a SIGABRT.  There was nothing in the kernel log buffer and the RPi 3 I was on at the time wasn't out of disk space or memory.  Since this RPi had just completed a dist-upgrade and I had rebooted it, everything was more-or-less up-to-date with the "testing" channel of Raspbian.  I searched the web and couldn't find anything related to "abort" or "SIGABRT" on Debian or Raspbian.  There were also no bugs filed against any of the relevant packages.  So, I figured that I had just hit a bug and started downgrading.  I used dpkg-repack on another RPi 3 of the following packages, which I downgraded to:


On the upgraded RPi, I'd been running APT 1.4~beta4, libc 2.24-9, and dpkg 1.18.18.  Unfortunately, none of the downgrades did the trick.  My next step was to downgrade the kernel, but I started to think something was maybe gummed up with APT itself, possibly in its database since it always received the SIGABRT about 50% of the way through reading package lists.  I ended up looking up the various storage directories and decided to clear out /var/lib/apt/lists.  I did another apt-get upgrade and things started working again:

(storm:21:55:EST)% sudo apt-get update
Get:1 jessie InRelease [22.9 kB]
Get:2 testing InRelease [15.0 kB]
Get:3 jessie/main armhf Packages [141 kB]                   
Get:4 testing/main armhf Packages [11.7 MB]           
Get:5 jessie/ui armhf Packages [53.6 kB]                
Get:6 testing/contrib armhf Packages [56.0 kB]                                                                     
Get:7 testing/non-free armhf Packages [95.1 kB]                                                                    
Get:8 testing/rpi armhf Packages [1,360 B]                                                                         
Fetched 12.1 MB in 24s (493 kB/s)                                                                                                                              
Reading package lists... Done
(storm:21:59:EST)% sudo apt-get --purge remove quagga-pimd quagga-isisd quagga-ospfd quagga-ospf6d
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libquagga0 quagga-bgpd quagga-core quagga-ripd quagga-ripngd
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  quagga* quagga-isisd* quagga-ospf6d* quagga-ospfd* quagga-pimd*
0 upgraded, 0 newly installed, 5 to remove and 8 not upgraded.
After this operation, 957 kB disk space will be freed.
Do you want to continue? [Y/n] 

Apparently something had gotten corrupted in the downloaded package lists and APT didn't handle it properly.  I'd submit a bug for this but I didn't think to backup /var/lib/apt/lists beforehand so I'm not sure how to reproduce this.  Anyway, if you get a SIGABRT when running apt-get, rm /var/lib/apt/lists/* and things will be happy again.

Also, in other news, Lady Gaga's Super Bowl LI performance was pretty decent.  The drones were a nice touch.

Comments: 0

Previous PageDisplaying page 2 of 121 of 961 results Next Page