Present Location: News >> Blog


> Testing IPv6 Node Information Queries
Posted by prox, from Seattle, on December 31, 2017 at 20:25 local (server) time

After reading There’s No Place Like ::1 — Enumerating Local IPv6 networks, I decided to try it out on a couple of my local LANs.  Surprisingly enough, Linux, Solaris, IRIX (yes, IRIX), and Windows do not seem to respond to these (RFC 4620) queries but FreeBSD, iOS, and macOS do.

Here's a segment with a few Apple hosts on it:

(trill:17:07:PST)% ping -c 2 -N name ff02::1%br0
PING ff02::1%br0(ff02::1%br0) 56 data bytes
30 bytes from fe80::223:dfff:fe7f:2678%br0: odyssey; seq=1; ttl=64
26 bytes from fe80::885:e847:e16b:a305%br0: atv; seq=1; ttl=64 (DUP!)
28 bytes from fe80::dea9:4ff:fe8b:dd95%br0: orion; seq=1; ttl=64 (DUP!)
29 bytes from fe80::10b3:60fb:bef0:90d2%br0: lantea; seq=1; ttl=64 (DUP!)
30 bytes from fe80::223:dfff:fe7f:2678%br0: odyssey; seq=2; ttl=64

--- ff02::1%br0 ping statistics ---
2 packets transmitted, 2 received, +3 duplicates, 0% packet loss, time 1001ms

atv is an AppleTV, orion & odyssey run macOS (varying versions), and lantea is an iPod.  Now, here's a segment with a few Linux & Windows hosts:

(starfire:17:13:PST)% ping -c 2 -N name ff02::1%eth3
PING ff02::1%eth3(ff02::1%eth3) 56 data bytes
27 bytes from fe80::200:aaff:feac:f871%eth3: host; seq=1; ttl=64
27 bytes from fe80::200:aaff:feac:f871%eth3: host; seq=2; ttl=64

--- ff02::1%eth3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms

Not much here, except a strange reply from something calling itself host, which is actually my Xerox Phaser 6280 laser printer.

Also, Junos (FreeBSD-based), Cisco IOS, and IOS-XR (QNX-based) seem to ignore these too.

The conclusion here is, of course, that layer 2 is insecure.  But really, who cares about a name if most things run some sort of mDNS agent nowadays, anyway?

Comments: 0
> 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

No Previous PageDisplaying page 1 of 120 of 954 results Next Page