|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
From the "tiny blogs" department...
Yep, I'm a Zsh fan. I've always been one and probably won't change.
One of the nifty features of Zsh is the ability to expand wildcards on the command-line in a particular order. For me, this often comes in handy when combined with some sort of media player. For example, what if I wanted to watch videos in a directory with MPlayer and start with the most recently modified ones? Zsh has that covered:
% mplayer *.mp4(oa)
The (oa) tells Zsh to expand '*' to all files in $CWD but to order the expansion by last modified. There are a few other sort specifiers, but I find 'a' the most useful. Using a capital 'O' will reverse the sort order.
OpenSSH 7.0 was released a few months ago and deprecated both the ssh-dss and ssh-rsa keys used for SSHv2 public key authentication. I haven't found a definitive source stating why these key types were deprecated other than some issue with entropy (doesn't make sense to me because that sounds like a machine-specific problem). I, unfortunately, still use these keys quite a bit and it's not feasible to completely convert to one of the newer key types.
OpenSSH 7.0 appeared in FreeBSD ports pretty quickly and recently made its way into Debian testing (stretch).
So, what are the newer key types supported? From what I can tell, it's just ecdsa and ed25519 for SSHv2. From the OpenSSH 6.2 ssh-keygen(1) manpage:
-t type
Specifies the type of key to create. The possible values are
``rsa1'' for protocol version 1 and ``dsa'', ``ecdsa'' or ``rsa''
for protocol version 2.
From the OpenSSH 7.1 ssh-keygen(1) manpage:
-t dsa | ecdsa | ed25519 | rsa | rsa1
Specifies the type of key to create. The possible values are
"rsa1" for protocol version 1 and "dsa", "ecdsa", "ed25519", or
"rsa" for protocol version 2.
Even though dsa and rsa keys are still listed above in the 7.1 man page as being capable of created, they're not accepted by default anymore by ssh or sshd:
debug1: Next authentication method: publickey debug1: Skipping ssh-dss key /home/prox/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
(if you're wondering, and I was too, DSS is a document that describes the creation of DSA keys as answered here)
Running ssh -Q key will also dump the list of keys acceptable by ssh:
(nox:11:46:CST)% ssh -Q key ssh-ed25519 ssh-ed25519-cert-v01@openssh.com ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01@openssh.com ssh-dss-cert-v01@openssh.com ecdsa-sha2-nistp256-cert-v01@openssh.com ecdsa-sha2-nistp384-cert-v01@openssh.com ecdsa-sha2-nistp521-cert-v01@openssh.com
The solution seems obvious, just throw out the old keys and use an ecdsa key, right? Sure, that'll work for OpenSSH versions that support it. However, sometimes I have to log into a few legacy boxes that only support RSA and DSA keys (Solaris, IRIX, random network devices, etc. - I've got some old stuff!).
What about keeping around the old keys? Sure, we can use PubkeyAcceptedKeyTypes in sshd_config and ssh_config like this:
PubkeyAcceptedKeyTypes ssh-dss,ssh-rsa
The only problem is that this option only exists in 7.0 and above. I use a common ~/.ssh/ssh_config for all of my systems and OpenSSH 6.x barfs on that line.
What's the solution? Well, one is to not upgrade to OpenSSH 7.0, but that's just delaying the inevitable. My solution may just be to use two keys, one for modern systems and one for very old systems that don't support ecdsa or ed25519. Regardless, it's pretty annoying, but security always is, right?
Update 20151229: This page highlights some of these differences and workarounds, too.
Unlike most folks, I value first-hop latency on residential networks over gobs of bandwidth. Why? It's likely to have a larger impact to my web browsing experience than bandwidth, in many cases.
I've got 50 Mbps downstream and 10 Mbps upstream at home via Comcast Business, at the moment. Unfortunately, I pay a bit for it because I have a static IPv4 /29 prefix. Anyway, the 50 Mbps downstream is good enough for streaming and downloading most content (20 Mbps would work, too, I guess). The 10 Mbps is mildly sufficient for me but gets a little painful when uploading videos or transferring large files via rsync over SSH.
If I could pay $5 or $10 more per month for 100 Mbps downstream, I probably wouldn't bother. Excluding video-rich sites, I don't see more than 4-5 Mbps at peak when loading web pages and browsing the web.
However, I'd pay more to reduce the first-hop latency since most web content is coming from CDN nodes that are nearby. Lower latency impacts the initial stages of TCP significantly and can have a large impact on transferring web content quickly over short-lived connections.
Comcast's got an Akamai CDN node on-net, which is about 10 ms from me:
(valen:12:31)% mtr --report --report-cycles=10 --report-wide www.akamai.com. Start: Tue Nov 17 12:31:34 2015 HOST: valen Loss% Snt Last Avg Best Wrst StDev 1.|-- 2001:558:4082:48::1 10.0% 10 8.3 24.3 8.3 133.6 41.0 2.|-- te-0-2-0-5-sur03.burien.wa.seattle.comcast.net 0.0% 10 13.6 10.6 7.8 13.6 1.7 3.|-- be-21-ar01.seattle.wa.seattle.comcast.net 0.0% 10 10.0 10.8 9.2 13.8 1.5 4.|-- be-33650-cr02.seattle.wa.ibone.comcast.net 60.0% 10 14.2 12.6 11.3 14.2 1.0 5.|-- hu-0-11-0-0-pe04.seattle.wa.ibone.comcast.net 0.0% 10 10.3 11.3 9.1 16.6 2.1 6.|-- as20940-2-c.seattle.wa.ibone.comcast.net 0.0% 10 9.7 11.5 9.7 14.4 1.3 7.|-- 2600:1409:a:1a0::22d9 0.0% 10 9.6 13.3 9.1 24.9 5.0
While I live in West Seattle, apparently the CMTS I use is down south in Burien, WA, likely due to the geography of the region. It takes about ~7-8 ms to get to the CMTS. This is my first hop latency (hop 1 is my Comcast modem since it's in L3 mode for the static IPv4 assignment). As you can see above, the bulk of my latency to the Akamai cache is due to the first hop. DOCSIS has a request/grant system (see slide 16 in this PDF) for accessing upstream bandwidth, which adds an extra "round trip" to the communication from my cable modem to the CMTS. If that were somehow lowered to 1 ms or so (GPON?), I'm sure most of the web would "feel" faster since my latency to the cache would be around 2-3 ms.
As another example, Google doesn't have a cache on Comcast's network but they aren't too far away:
(valen:12:31)% mtr --report --report-cycles=10 --report-wide www.google.com. Start: Tue Nov 17 12:32:08 2015 HOST: valen Loss% Snt Last Avg Best Wrst StDev 1.|-- 2001:558:4082:48::1 30.0% 10 27.5 13.4 9.2 27.5 6.5 2.|-- te-0-2-0-5-sur02.burien.wa.seattle.comcast.net 0.0% 10 8.1 9.8 8.1 11.6 0.8 3.|-- be-21-ar01.burien.wa.seattle.comcast.net 0.0% 10 9.3 9.2 8.0 10.2 0.6 4.|-- he-0-13-0-0-ar01.seattle.wa.seattle.comcast.net 0.0% 10 11.2 10.3 8.7 14.6 1.6 5.|-- be-33650-cr02.seattle.wa.ibone.comcast.net 70.0% 10 13.6 12.5 10.5 13.6 1.6 6.|-- 2001:558:0:f510::2 60.0% 10 13.3 12.0 9.8 13.3 1.4 7.|-- 2001:559::cfa 0.0% 10 9.4 11.7 8.6 28.9 6.1 8.|-- 2001:4860::1:0:9aa5 0.0% 10 9.7 11.0 8.8 14.0 1.8 9.|-- 2001:4860::8:0:6999 0.0% 10 10.2 16.4 9.3 50.7 12.6 10.|-- 2001:4860::8:0:61e1 0.0% 10 14.4 17.0 12.7 44.6 9.7 11.|-- 2001:4860::8:0:924a 0.0% 10 16.1 17.0 15.0 20.8 1.5 12.|-- 2001:4860::2:0:90fe 0.0% 10 16.3 17.6 15.7 22.0 1.8 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- pb-in-x93.1e100.net 0.0% 10 28.1 18.8 14.9 28.1 4.6
That 15 ms to the Google content node could be reduced to around 7-8 ms if my first-hop latency went away, too!
It just so happens that I graph my first-hop latency to the CMTS using SmokePing. Here's a graph over the last year:
It doesn't change too much. I'm curious what happened in June to drop my latency by what looks to be 1-1.5 ms, but only Comcast would really know. The heightened latency in January and February were due to a memory leak in my cable modem, I think.
Also, low latency is obviously good for gaming, which doesn't really apply to me, and other interactive applications like SSH. vimdiff(1), for example, is pretty painful on a high latency connection due to the way if repaints the entire terminal window.
To compare my Comcast connection with other residential technologies, here's what I've seen for first hop latencies:
Obviously, the lowest latency is going to come from an Ethernet-based service, something like wave G (formerly condointernet). I'm fairly sure it's limited to apartments and condiminiums in major metropolitan areas like downtown Seattle.
So, in a nutshell, that's why I'm not impressed with 300 Mbps vs. 50 Mbps DOCSIS service, a 50 Mbps Ethernet DIA service might be appealing.
Fun, it looks like there's a new upstream release for the net-tools package. The ifconfig(8) output looks a little different, now. Old:
(destiny:22:10)% ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1c:c0:b2:8d:bd
inet addr:10.3.5.107 Bcast:10.3.5.255 Mask:255.255.255.0
inet6 addr: fe80::21c:c0ff:feb2:8dbd/64 Scope:Link
inet6 addr: 2001:48c8:1:105:21c:c0ff:feb2:8dbd/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:368571536 errors:0 dropped:0 overruns:0 frame:0
TX packets:288951501 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:340038876351 (316.6 GiB) TX bytes:116559393418 (108.5 GiB)
Interrupt:20 Memory:d3300000-d3320000
New:
(destiny:22:14)% ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.3.5.107 netmask 255.255.255.0 broadcast 10.3.5.255
inet6 fe80::21c:c0ff:feb2:8dbd prefixlen 64 scopeid 0x20<link>
inet6 2001:48c8:1:105:21c:c0ff:feb2:8dbd prefixlen 64 scopeid 0x0<global>
ether 00:1c:c0:b2:8d:bd txqueuelen 1000 (Ethernet)
RX packets 368903989 bytes 340125988245 (316.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 289091263 bytes 116569592018 (108.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xd3300000-d3320000
I wonder how many screen-scraping tools are now broken..
Now, that all being said, you should really be using ip(8) instead of ifconfig(8). It's 2015.
Among many other bugs, Android 5.x seems to have a DHCPv4 bug that prevents it from getting addresses from some embedded systems. For me, this includes the Wi-Fi functions on the GoPro HERO3 and Canon EOS 70D.
We all remember DORA from our networking 101 classes, right?
Unfortunately, with Android 5.x this turns into DORN when talking to some DHCP servers.
That's right, the server sends a NAK for the DHCP request, which usually indicates the requested address is invalid or in use.
I realized this while on my honeymoon earlier this year and was not pleased at all. I routinely use the Wi-Fi capabilities of my GoPro HERO3 camera with a "selfie stick" to shoot accurate photos. The HERO3 turns itself into a Wi-Fi access point and allows a single client to connect in order to use the GoPro application, which is used to control & view live video on camera. Usually this works without a hitch, but not this time. When connecting to the camera the Wi-Fi status hung in the "Obtaining IP address..." phase. After debugging a bit I realized that the server was sending NAKs for the DHCP request from my phone and I had upgraded my OnePlus One to CyanogenMod 12.0 (Android 5.0) a few weeks earlier. Here's what logcat says:
I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9 I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9 I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9 I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9
(the HERO3 uses 10.5.5/24 with the camera 10.5.5.9 and the clients starting around 10.5.5.109 or so)
The entry that's missing is the DHCP request debug entry, where Android should be sending a message to the DHCP server asking for 10.5.5.109. This is actually happening and can be seen via a packet capture:
20:48:52.890280 IP (tos 0x0, ttl 64, id 21568, offset 0, flags [none], proto UDP (17), length 330)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c0:ee:fb:24:8c:59 (oui Unknown), length 302, xid 0x1d11a2f4, Flags [none]
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255, fb:24:8c:59:00:01:00:01:1c:c4:48:b1:c0:ee:fb:24:8c:59
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 12: "dhcpcd-5.5.6"
Hostname Option 12, length 5: "omega"
Parameter-Request Option 55, length 10:
Subnet-Mask, Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, MTU, BR, Lease-Time
RN, RB
20:48:52.896211 IP (tos 0x0, ttl 64, id 81, offset 0, flags [none], proto UDP (17), length 326)
10.5.5.9.bootps > 10.5.5.109.bootpc: BOOTP/DHCP, Reply, length 298, xid 0x1d11a2f4, Flags [none]
Your-IP 10.5.5.109
Server-IP 10.5.5.9
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.5.5.9
Subnet-Mask Option 1, length 4: 255.255.255.0
Lease-Time Option 51, length 4: 10368000
TTL Option 23, length 1: 64
MTU Option 26, length 2: 1500
RN Option 58, length 4: 10368000
RB Option 59, length 4: 10371600
Domain-Name Option 15, length 3: "lan"
BR Option 28, length 4: 10.5.5.255
Default-Gateway Option 3, length 4: 10.5.5.9
20:48:52.897006 IP (tos 0x0, ttl 64, id 41212, offset 0, flags [none], proto UDP (17), length 342)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c0:ee:fb:24:8c:59 (oui Unknown), length 314, xid 0x1d11a2f4, Flags [none]
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255, fb:24:8c:59:00:01:00:01:1c:c4:48:b1:c0:ee:fb:24:8c:59
Requested-IP Option 50, length 4: 10.5.5.109
Server-ID Option 54, length 4: 10.5.5.9
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 12: "dhcpcd-5.5.6"
Hostname Option 12, length 5: "omega"
Parameter-Request Option 55, length 10:
Subnet-Mask, Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, MTU, BR, Lease-Time
RN, RB
20:48:52.902836 IP (tos 0x0, ttl 64, id 82, offset 0, flags [none], proto UDP (17), length 272)
10.5.5.9.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 244, xid 0x1d11a2f4, Flags [none]
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Except for some absurdly high lease times, there's nothing invalid I see in the DHCP request above. So, why is the HERO3 sending a NAK? Here's what I know:
Since the 70D and HERO3's DHCP servers are closed, I can't look at their debug log to see what's happening. The only workaround I have so far is to assign a static IPv4 address to my OPO when connecting to the HERO3, which is 10.5.5.109/24 with a default gateway of 10.5.5.9. I don't believe the default gateway is used for the application functionality, but provides some fake HTTP responses that cause Android and iOS' Internet connection quality tests to succeed.
I'd submit a bug for this but I'm worried it'll go nowhere or be tagged WONTFIX like this request for DHCPv6 support.
I've often been annoyed at the way LXC does bridging. Here's a sample common configuration:
lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:50:56:1a:ad:dc
This assumes lxcbr0 is a bridge (created by brcrl addbr lxcbr0). The above configuration will create a pseudo-random interface name that is mapped to the LXC and add it to the bridge, resulting in the following:
(starfire:19:58)# brctl show bridge name bridge id STP enabled interfaces lxcbr0 8000.fe3ffd02f7b8 no vethXHEHXF
This works well most of the time but not if you want to directly connect an LXC to something that has native bridging capabilities like VirtualBox. Sure, you could create a host-only interface with VirtualBox and add it to lxcbr0 but this is really unneeded (and probably slow, too).
A better way is to dispense with the Linux bridge itself and have VirtualBox bridge directly to the virtual Ethernet. This doesn't work out of the box because the interface name is pseudo-random. However, I was looking through the lxc.container.conf(5) man page the other day and found the lxc.network.veth.pair option. This allows one to specify the virtual Ethernet interface's name that appears on the outside of the container!
Here's a better sample configuration:
lxc.network.type = veth lxc.network.veth.pair = foobar0 lxc.network.hwaddr = 00:50:56:1a:ac:cc
This creates a foobar0 interface that connects to the LXC, which can be bridged to VirtualBox through its native method:
VBoxManage modifyvm testvm --nic1 bridged --nictype1 82543GC --bridgeadapter1 foobar0
Easy!
I've neglected this blog for too long. Here's a small update, mostly on one subject:
I got married to my beautiful wife on March 14, 2014. Yes, Pi Day. Some photos are here. Note that these are copyrighted (I need to update picscript to handle defining a license per gallery, now).
Devon and I went on our honeymoon to Hawaii. We took a cruise on NCL's Pride of America and hit the following islands:
I took a few photos and quite a few videos, which I haven't put anywhere just yet. I took a few time lapses, one of which is below:
We stayed for two nights in the Mariott Resort & Spa on Waikiki Beach, too.
Alright, I've been venting on various social networks about this so I think it's time I write a blog entry on it.
tl;dr: Android 5.0 (Lollipop) is the worst version of Android I've used and will most likely be the reason why my next phone will not run Android.
I have been running CyanogenMod 11.0 nightly builds on my OnePlus One since I got the phone (October of 2014) and have been happy with it. CyanogenMod is the only Android variant that works on the OnePlus One with the officially-supported build being version 11S. CyanogenMod 11 is based on Android 4.4 and adds "tweaks" and usability enhancements to the user interface. The enhancements I typically find most useful are the additional tiles (3G/LTE, data, tethering, performance, lock delay, etc. one-tap toggles) and privacy guard (limit individual applications' access to personal data).
The upgrade was a mistake, really. I decided to upgrade to a newer nightly build of 11 at the beginning of January but was instead presented with a list of nightly builds of CyanogenMod 12, instead of 11. Nighty builds for 11 apparently have ceased with most development effort likely going toward 12. Not paying attention to this, I tapped upgrade and bricked my phone (going from 11 to 12 probably required a wipe, which I would have done anyway). After backing up some unsaved stuff on my phone via ADB I decided to do a clean install of 12 instead of going back to 11, since I would be forced to eventually.
Android's Material Design doesn't really bother me. I don't care if buttons, widgets, and windows are flat, 3D, or something else. I typically don't like special effects and animations, though, and try to disable them as much as possible. Android 5.0 still let me disable the animations (this is not a problem anymore) completely, so that made me happy.
There's a new battery saver mode that has been added in Android 5.0. It shuts off all vibrations, throttles the clock on the CPU and GPU, and dims the screen. I find it useful when I'm at the office since I hardly use my phone when I'm at my desk.
Unfortunately, I've already come to the end of the parts of Android 5.0 that don't bother me. The rest is all downhill.
The notifications system changed for the worse. I want the old system back.
Android 5.0's notification system seems to be an odd copy of how iOS does notifications plus some general stupidity. I always found iOS' notification system to be pretty horrible (although, I only use it on an iPad.. I do not own an iPhone). Instead of notifications lining up in the status bar at the top of the screen, they now display as a large rectangle over the status bar and takes up precious screen real estate until you swipe them away.
To make things worse, when one swipes down the status bar to display all notifications, there's no easy way of getting rid of them like there was in prior version of Android. The "clear notifications" button no longer exists at the top of the notification screen but at the bottom of all notifications.
So, if you have about half a dozen notifications pending (installed programs, messaging, e-mail, etc. - you don't have to be a social media "rock star" to get tons of notifications), you have to drag them all up to reveal the "clear notifications" button. Who came up with this? This gets significantly worse if you have applications always running that have a permanent notification—it only takes 3-4 additional notifications to push the "clear notifications" button off the screen.
Notifications no longer display on the status bar when the phone is locked. They now are displayed under the clock with three options: 1) display all content 2) hide content 3) hide notifications completely. None of these options work for me—I want notifications in the status bar! I ultimately just hid them from view completely because they are annoying. If my phone makes a message I now have to unlock it to see what kind of notification I got.
This is really still in the "notifications suck" category but deserves its own section. The sound profiles changed and are now terrible. Apparently Android is trying to get away from applying sound profiles to all applications and instead applying profiles that selectively allow what notifications can make sounds (or vibrations) at a given time.
Instead of being able to select "vribate only" or "quiet hours" (allow only phone calls to make sounds), I now have three options:
The priority setting is kind-of tunable, meaning you can set up priority interruptions that can be 1) events and reminders 2) calls 3) messages.. but, uh, nothing else. It's very half-baked.
What bugs me specifically about this is that there is no "vibrate only" setting. This is what I miss from all previous versions of Android. I simply want to put my phone in vibrate mode before entering a meeting—I still want the phone to let me know things are happening by vibration but not generate any sounds from the speaker. The only way I can see to do this is to enable the "all" mode and slide the volumes all of the way to the left (yet somehow remembering exactly where they were before).
The little person icon on the top right of the notifications drawer is annoying. It's apparently for some multi-user garbage that, in my opinion, doesn't belong on a phone and there's no way of getting rid of it. Seriously, who has a phone that they share with someone else?
There's a little weather widget that is enabled by default in the notification drawer. I liked it but I couldn't figure out how to change the temperature from Farenheit to Celsius, so I turned it off. The standard News & Weather widget allows one to choose temperature units.
I think that these are the result of CyanogenMod and not Android 5.0 itself so they are going in a different category.
There's something horribly wrong with the radio firmware for the OnePlus One that comes with CM12. I can't use an IPv6-only APN or even an IPv4/IPv6 one, anymore, without the radio crashing. I have to use the IPv4 APN on T-Mobile, now. It's really strange why an APN setting would trigger a bug in the radio firmware, but I can reproduce it all day and twice on Sundays:
<3>[78188.227080] SMSM: Modem SMSM state changed to SMSM_RESET. <3>[78188.227291] Fatal error on the modem. <3>[78188.227413] modem subsystem failure reason: :Excep :0:. <6>[78188.227521] subsys-restart: subsystem_restart_dev(): Restart sequence requested for modem, restart_level = RELATED. <3>[78188.227670] Notify: start reset <6>[78188.241363] subsys-restart: subsystem_shutdown(): [e0a4b900]: Shutting down modem <4>[78188.341484] pil-q6v5-mss fc880000.qcom,mss: Port c5c7c280 halt timeout <3>[78188.345214] smd_pkt_read notifying reset for smd_pkt_dev id:8 <3>[78188.345271] Ramdump(ramdump_smem): No consumers. Aborting.. <3>[78188.345283] restart_notifier_cb: unable to dump smem -32 <3>[78188.346650] smd_pkt_read notifying reset for smd_pkt_dev id:1 <3>[78188.346717] smd_pkt_read notifying reset for smd_pkt_dev id:5 <3>[78188.346957] smd_pkt_read notifying reset for smd_pkt_dev id:2 <3>[78188.347183] smd_pkt_read notifying reset for smd_pkt_dev id:6 <3>[78188.347402] smd_pkt_read notifying reset for smd_pkt_dev id:3 <3>[78188.347627] smd_pkt_read notifying reset for smd_pkt_dev id:9 <3>[78188.347850] smd_pkt_read notifying reset for smd_pkt_dev id:7 <3>[78188.348071] smd_pkt_read notifying reset for smd_pkt_dev id:4 <3>[78188.349135] smd_pkt_read notifying reset for smd_pkt_dev id:0 <3>[78188.370990] modem_notifier_cb: sysmon_send_event error -38 <3>[78188.371158] M-Notify: General: 4 <6>[78188.372614] subsys-restart: subsystem_powerup(): [e0a4b900]: Powering up modem <6>[78188.377927] pil-q6v5-mss fc880000.qcom,mss: mba: loading from 0x0d100000 to 0x0d149000 <6>[78188.413792] pil-q6v5-mss fc880000.qcom,mss: mba: Brought out of reset <6>[78188.416378] pil-q6v5-mss fc880000.qcom,mss: modem: loading from 0x08000000 to 0x0ce00000 <3>[78188.439592] smd_write_start: packet header failed to write <3>[78188.439693] msm_ipc_router_smd_remote_write: ipc_rtr_smd_ipcrtr chnl reset <4>[78188.649183] audit: audit_lost=13258 audit_rate_limit=20 audit_backlog_limit=64 <3>[78188.649229] audit: rate limit exceeded <6>[78188.978289] pil-q6v5-mss fc880000.qcom,mss: modem: Brought out of reset <3>[78189.061349] Notify: smsm init <6>[78189.096582] pil-q6v5-mss fc880000.qcom,mss: mba: Power/Clock ready interrupt received <6>[78189.096641] pil-q6v5-mss fc880000.qcom,mss: Subsystem error monitoring/handling services are up <6>[78189.098020] subsys-restart: subsystem_restart_wq_func(): [e0a4b900]: Restart sequence for modem completed.
This happens about a second or two after the data connection is established, results in about 5-10 seconds of no signal, then repeats. Apparently I'm not the only one who has this problem considering the reply to my post.
The OnePlus One has always had a great camera, IMHO. It has done very well in low light and features HDR in hardware, which looks great most of the time. Unfortunately, it seems that the CM12 upgrade has messed up the camera, somehow. Photos get progressively blurrier as the light level decreases. HDR use seems to compound this effect. I'm not sure what was done but I've added a post about this, too.
Videos don't play anymore. I can record a video with the camera application just fine but whenever I go to play it back on the phone I get a "Cannot play video." message. I haven't really looked into this because I don't take videos with my phone too often. The videos themselves are fine since they play fine on a computer when transferred.
I would have gone back to CM11 after encountering these issues with CM12 but, as I mentioned, it seems that CM11 development is winding down (completing) and there are no more nightly builds. Also, it's likely that more applications will start to require Android 5.0 in the future.
This latest horrible regressions of an upgrade from Google is really making me think that the OnePlus One will be my last Android phone. I really don't want to go to iOS since it's not an open platform and I will have to always wait for the next jailbreak to have a usable device (I rely on having shell access and a customizable control center). The Ubuntu phone stuff looks interesting but it's likely there won't be many applications for the platform for quite sometime (if ever).
Update: 2015/03/02
Most of the issues above still exist.
The IPv6 issue still exists but has changed, slighty. I have a post about it. Now, the radio firmware doesn't crash anymore but IPv6 only works when the phone is connected via LTE (regardless of the APN in use). For example, the IPv6-only APN will connect via LTE but refuse to pass any data packets if the phone drops down to UMTS (voice call, for example). It will also refuse to connect to the APN if the current network is not LTE. This is somewhat workable for me since I almost always have LTE coverage, but it's still a PITA if I want to use data on my phone while in a voice call. I keep IPv6 fully disabled, now, as a result.
I found a nice bug in the video player. Both the stock video player and the Google "Photos" applications refuse to play videos recorded by the camera application and say "Can't play this video.":
Gee, thanks for the detail, but of course Google assumes their user population is a bunch of idiots, so they don't bother providing any details on why it can't play the video. The videos are actually correctly encoded and play fine when transferred to a general purpose computer.
I've never had much luck with sending or receiving MMS objects on Android. I've had issues as far back as the 2.x series on the Nexus One! Android 5.0 / CM12 seems to be no exception, but this case refuses to even try to do anything:
For some reason, MMS objects larger than some unknown size can't be downloaded anymore with the AOSP messaging application (the only one I care to use, since it's not "linked" in any way to Google). The only people who send me MMS objects anyway are iPhone users, so I can't really view any pictures from them anymore. Even objects 688 KiB in length refuse to download. The only thing that works is group messaging, since those are tiny files. What's the deal, here? Is there some 3GPP specification that everyone else but Android is following.. or maybe Android is just not following it?
Update 2015/04/03
The lack of video playback apparently wasn't limited to the Video Player application and affected Instagram, too. After searching around (mega bug thread here) I tried selecting the use of NuPlayer (experimental) instead of AwesomePlayer in developer settings. This fixed it. Of course, now I'm forced to use an experimental Android component vs. the legacy one.
Displaying page 4 of 121 of 965 results
     |
This HTML for this page was generated in 0.003 seconds. |