|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
It took me a few minutes to track this down, so I figured I'd share it with the world.
In the event of a USB error or warning, the Linux kernel will print a message like the following:
[15740840.830734] usb 2-3: Failed to suspend device, error -71
Most of us have a ton of USB-connected devices, so how does one figure out what "usb 2-3" refers to in order to diagnose the problem? At first, I thought lsusb(8) would help:
(atlantis:17:29:PDT)% lsusb Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 003: ID 0bc2:5031 Seagate RSS LLC FreeAgent GoFlex USB 3.0 Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0409:0058 NEC Corp. HighSpeed Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 006 Device 004: ID 1781:0a98 Multiple Vendors raphnet.net USBTenki Bus 006 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Bus 006 Device 002: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
That's nice, but I don't see bus number 2 and device number 3 or bus number 3 and device number 2 in that list. The verbose (-v) flag doesn't appear to help, either. So, I try usb-devices(1) and am presented with even more information, like this for each device:
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=04.13 S: Manufacturer=Linux 4.13.0-1-amd64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=0000:00:1a.7 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
I still couldn't find a combination of 2-3 or 3-2 in there. So, I started hunting around sysfs for an answer, and ended up finding it:
(atlantis:17:35:PDT)% cd /sys/bus/usb/devices/2-3 (atlantis:17:35:PDT)% lsusb|grep $(cat idVendor):$(cat idProduct) Bus 002 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
For some reason, lsusb(8) doesn't feel like displaying the what I learned is the device number and device path:
(atlantis:17:35:PDT)% echo $(cat devnum)-$(cat devpath) 2-3
Although, I have three "hubs" connected to this machine, so tracking those down is another story. At least I know what I'm looking for, now.
It took awhile, but I finally converted the last two software routers (well, hosts that run routing protocols) on my network that were running Quagga to FRR:
bazooka.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 centauri.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 evolution.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 excalibur.prolixium.com.: Version: 4.0-1~debian9+1 exodus.prolixium.com.: Version: 1.6.3-3 firefly.prolixium.com.: Version: 1.6.3-3 mercury.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 nat.prolixium.com.: Version: 4.1-dev-1.0-1~debian9+1 nox.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 pathfinder.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 proteus.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 remus.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 scimitar.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 sprint.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 starfire.prolixium.com.: Version: 4.1-dev-1.0-1~debian9+1 storm.prolixium.com.: Version: 1.6.3-3 tachyon.prolixium.com.: Version: 3.1-dev tiny.prolixium.com.: Version: 4.0-1~debian9+1 trident.prolixium.com.: Version: 3.1-dev trill.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1 valen.prolixium.com.: Version: 4.1-dev-1.0-1~debian9+1 orca.prolixium.com.: Version: 3.1-dev-1.0-1~debian9+1
The -dev versions above are hand-rolled from the latest source code. There are no pre-built Debian packages for i386 so I was forced to roll them by hand.
The 1.6 versions above are actually BIRD.
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.
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?
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 my.t-mobile.com. It's fairly ironic, too.
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 com.google.Chrome AppleEnableSwipeNavigateWithScrolls -bool FALSE
You can see it's successfully set:
(orion:10:39:PST)% defaults read org.chromium.Chromium
{
AppleEnableSwipeNavigateWithScrolls = 0;
LastRunAppBundlePath = "/Applications/Chromium.app";
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.
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.
Sigh.
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 lxc.network.type = veth lxc.network.name = eth0 lxc.network.link = lxcbr0 lxc.network.hwaddr = 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 192.168.57.1 netmask 255.255.255.0 broadcast 192.168.57.255
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
vethGEVFJP: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
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
vethGEVFJP
(excalibur:14:09:EDT)% sudo lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6
adria RUNNING 0 - 10.3.7.217 2620:6:2000:12e:202:bcff:fe56:cc99
(excalibur:14:10:EDT)%
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) VM ---> LXC (DROPPED)
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 (excalibur:14:18:EDT)%
So, what's the problem, here? I started looking into configuration files. Here's what I found in ~/VirtualBox VMs/dax/dax.vbox:
<Network>
<Adapter slot="0" enabled="true" MACAddress="0002BC56CB39" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
<DisabledModes>
<InternalNetwork name="intnet"/>
<NATNetwork name="NatNetwork"/>
</DisabledModes>
<BridgedInterface name="eth0"/>
</Adapter>
<Adapter slot="1" enabled="true" MACAddress="0002BC56CB99" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
<DisabledModes>
<InternalNetwork name="intnet"/>
<NATNetwork name="NatNetwork"/>
</DisabledModes>
<HostOnlyInterface name="vboxnet0"/>
</Adapter>
<Adapter slot="2" enabled="true" MACAddress="0002BC56CB29" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
<DisabledModes>
<BridgedInterface name="tap0"/>
<InternalNetwork name="intnet"/>
<NATNetwork name="NatNetwork"/>
</DisabledModes>
<HostOnlyInterface name="vboxnet1"/>
</Adapter>
<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:
<!-- ** DO NOT EDIT THIS FILE. ** 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.
Displaying page 2 of 121 of 965 results
     |
This HTML for this page was generated in 0.004 seconds. |