Present Location: News >> Blog


> Odd iFit Boot Loop Fix
Posted by prox, from Seattle, on April 03, 2018 at 22:47 local (server) time

tl;dr I ran into a boot loop issue with my NordicTrak treadmill.  Turning off NTP solved the problem.

My wife and I purchased a NordicTrak C 990 treadmill in late 2016.  It doesn't get all that much use (I still prefer going to the pool and swimming) but we both periodically use it.  I have an iFit membership that's mostly a waste of money but allows the machine to report and track my workouts online.

The control plane of the machine runs Android 2.x and has always felt pretty brittle outside of the iFit application.  Connecting to Wi-Fi, for example, is done through the Android system dialog screens rather than through an iFit-branded screen.

Anyway, the whole system was working fine until I decided to use it today.  I put the key in and Android indicated it couldn't connect to Wi-Fi.  So, I power cycled the system (naturally).  Upon reboot the iFit screen would load but then after 10-15 seconds trigger a reboot of Android.  I searched around and found instructions like this that described how to reinstall the iFit application.  However, these instructions didn't work for me because even if I could draw the "figure 8" on the screen to exit the iFit application's splash page, the OS would still reboot seconds later.

I took a guess that something Wi-Fi-related was causing the reboot so I shut the 2.4GHz radios on my two Cisco WAPs (the treadmill is one of two devices that still use 2.4GHz only).  The reboots stopped.  Something network-related was definitely causing it.  Maybe it's some update check that is returning a value that is triggering a bug in Android?  So, I ran tcpdump(8) on my local router.  I started a continuous ping and the last packets transferred before the system rebooted were NTP queries.  Thinking that something time-related was killing the OS I went into Android settings and disabled network-provided time.  The system was still stable after boot even when Wi-Fi is on, now.

The system date was 2012-01-01 so I tried setting it to 2018-04-03.  Instantly, the system locked up and after a few seconds rebooted.  I even tried setting it to a last known good date earlier in the year when I knew the treadmill was still working - same thing, triggered a reboot.  It would appear that either something in the OS can't handle the date changing too drastically or there's something that can't handle a 2018 date.

So, the treadmill is functional but I now can't login to my iFit account.  I'm guessing that somehow the date is passed as one of the login parameters and the iFit platform rejects the login attempt.  I'll play more with it later and will not be renewing my iFit membership if I still can't login.

Hopefully this post will be useful to someone who's given up and about to buy a new treadmill..

Update: I played around with setting the date a bit more.  Even setting it to 2012-01-02 triggers a reboot.  It would appear the date can't actually be set, now.

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

Previous PageDisplaying page 2 of 121 of 963 results Next Page