Present Location: News >> Blog


> Android 5.0 / CyanogenMod 12.0 on The OnePlus One
Posted by prox, from Seattle, on February 07, 2015 at 22:21 local (server) time

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.

Why Did I Upgrade?

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.

First Impressions

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.

Battery Saver

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.

Notification System

The notifications system changed for the worse.  I want the old system back.

Annoying Notifications

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.

Full Notifications

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.

Clear 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.

Notification Sounds

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).

Miscellaneous Annoyances

Multiple Users

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.

CyanogenMod Annoyances

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.":

Can't play the 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?

Comments: 0
> Net Neutrality Questions
Posted by prox, from Seattle, on February 05, 2015 at 01:20 local (server) time

Rather than go into my opinion about the FCC reclassifying broadband networks in the US as common carriers under Title II, I figured I'd just pose some questions that I haven't seen answers to, so far.  In fact, I haven't seen many "gory technical details" at all.

First, what ISPs are going to be reclassified?  What is the definition of broadband Internet nowadays, anyway?  Is it just the 25 Mbps / 3 Mbps throughput requirement or is it just the multi-media requirement, both, or neither?  Does the multi-media component require circuit switching (e.g., ATSC + DOCSIS) or can it be extended to different kinds of services (TV, phone, data, etc.) over the same packet-switched protocol?  If so, this extends the definition of broadband to many more ISPs' offerings including commercial ones.

I've heard that blocking certain TCP and UDP ports constitute a net neutrality violation.  Some popular examples are VPN-related ports like UDP/4500 (IPsec NAT-T), IP/50 (IPsec ESP), UDP/1194 (OpenVPN), etc. or BitTorrent-related ports (traditionally TCP/6881-6889) but how about the less-common ports?  How about TCP/135 or TCP/139?  These are routinely blocked by many residential ISPs since they have a bad history of abuse and are hardly ever legitimately used over the Internet.  Would blocking TCP/135 be considered a net neutrality violation?  What if there's a huge amplification attack vector discovered on some UDP service that happens to be listening on most home routers.. can an ISP block that without someone screaming about a net neutrality violation?  Assuming that those "bad" ports aren't considered net neutrality violations, what if I decided to run a web server on TCP/135?  Would that then bring TCP/135 into the scope of violation once again?

To go even further than just blocking ports, how about broadband ISPs that only hand out unroutable IPv4 address space (RFC 1918, squat space, or other junk) and use NAT+PAT to provide Internet access?  Without some sort of UPnP there's no way for that host to receive unsolicited traffic from the Internet at large.  Peer-to-peer "stuff" breaks.  Does the choice of the address selection constitute a net neutrality violation?  How about mobile networks offering IPv6 but firewall all inbound connections (hello, Verizon Wireless)?  The IPv6 address space is typically publicly routable so the inbound filtering is certainly a net neutrality violation.. or is it?

What is the real definition of "fast lane" as it relates to net neutrality?  The easy [naïve] answer to this might be something like "providing a faster connection to Facebook than Google"—but it's not that simple.  Speaking only as it relates to the network infrastructure, the definition of "fast" is dependent on some general variables like link speed, RTT, and network congestion.  While it's conceivable that link speed and network congestion can be made somewhat equal for a few networks (i.e., Google, Facebook, etc.) it's less likely that the RTT will be equal.  Paths to other networks are almost never going to be equal because the chance that both the interconnect locations to the remote networks and destinations on the remote networks will be equal from an RTT perspective is highly unlikely.  For example, is Comcast providing a "fast lane" to Google for a certain service area that may be closer to a peering point with Google than it is to a peering point for Facebook?  The content providers' network architecture certainly makes a big difference, here.  If Google has caches at every peering points but Facebook doesn't, how does an ISP provide equally fast lanes?

How do on-net caches play into this?  Google and Netflix are two examples of content providers that offer on-net caches so ISPs don't have to eat transit costs to get content to their customers.  It also provides a much better experience due to the lower latency—is this also considered a "fast lane"?  To add an additional twist on this, how about Akamai's on-net caches?  Well, wouldn't this favor only content providers that pay Akamai to host objects on their CDN?

How about peering vs. transit vs. customers?  Does a peering connection (how many peering locations?) constitute a net neutrality violation?  What if a small content provider has one transit provider and decides to get another one, would other customers of that second transit provider now have a "fast lane" to that content provider?  There are many permutations.

I doubt I'll ever hear definitive answers to all of these questions.  It's possible many of these questions will become invalid, too.

Comments: 2
> Linux Router Upgrade: Celeron to Pentium 4
Posted by prox, from Seattle, on January 20, 2015 at 14:54 local (server) time

After setting up an LXC on my aging "core" router at home, starfire, I started thinking it might be time for an upgrade.  starfire has been a Celeron-based Dell Dimension 2350 with 4x Intel Gigabit Ethernet and 1x Broadcom Fast Ethernet NICs.  Rather than replacing the whole box, I figured it would be cost-effective to get a boost in performance by spending $23 on eBay and upgrading it to a Pentium 4 2.5 GHz CPU (SL6PN).

After the upgrade, transit latency dropped quite a bit:

Celeron 2.0 GHz to Pentium 4 2.5 GHz

Good enough.  Apt seems slight faster, too, although I suspect that's because of the larger L2 cache vs. clock speed.

Comments: 0
> Concise Year in Review for 2014
Posted by prox, from Seattle, on January 01, 2015 at 22:39 local (server) time

I seem to do these "year in review" things every other year.  I'm primarily doing one this year because the world really needs a hand-written review to stand out in the sea of those horrible computer-generated Facebook ones.  However, unlike previous years, it will be very short.


Space Needle

I moved to Seattle, WA at the end of February.  I don't mind the weather—the rain makes for humid winters and there are frequent instances of a few sunny (but cold!) days; today is one of them.  That being said, it's taken some time for me to adjust to an urban area.

I Changed Employers

Amazon Web Services

I bid adieu to my colleagues at Time Warner Cable and started at Amazon Web Services in February, too.  It's a fun, challenging, and fast-paced environment.  I still feel like a n00b, frequently.


Burntshirt Vineyards

I got engaged!  I'll be married in March of this year.

(more information about the last three events can be found here)


River Liffey

(the River Liffey, near Temple Bar in Dublin)

I traveled 41,888 km (26,028 mi) in 2014 between the following (not including layovers):

The trips to Dublin and Austin were for work but were both pretty fun.  I'll probably be returning to Dublin in the next year or two again but I'm not sure about Austin.


Interstellar makes my year in review because it's one of the best (top three or four) science fiction movies I've seen.  That says a lot.  I only wish I could have seen it in IMAX (the theater schedules were terrible!).

New Christmas Tree

After Christmas for the past 4-5 years I've convinced myself that my artificial tree wouldn't survive another year.  However, the artifial tree I picked up in 2005 lasted a full eight (8) years.  I figured it would not survive a move across the country, so I picked up a new tree, this year.  It's a 7.5 ft. Pre-Lit Fraser Fir.  As I do every year, here's a time lapse of the installation:

(this is the first year I've added music to the time lapse.. hopefully it's not annoying!)


No conclusions.  2014 was what it was.

Comments: 0
> IPv6 on Comcast Business
Posted by prox, from Seattle, on December 06, 2014 at 01:02 local (server) time

Comcast Business decided to give me some IPv6 lovin' a week or two ago on my DOCSIS connection.  Unfortunately, it still seems to be a work in progress.

IPv6 Options

The above is the IPv6 configuration screen on my (well, Comcast Business') NETGEAR CG3000DCR.  I've got a /56 that I suspect was obtained via DHCPv6-PD on the DOCSIS interface.  The LAN interface has a /64 out of that /56 and supports DHCPv6-PD as well.  It's also got RAs enabled with RDNSS:

21:08:16.491207 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::c604:15ff:febe:e634 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120
	hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
	  source link-address option (1), length 8 (1): c4:04:15:be:e6:34
	    0x0000:  c404 15be e634
	  prefix info option (3), length 32 (4): 2601:8:a401:4c00::/64, Flags [onlink, auto], valid time 345600s, pref. time 345600s
	    0x0000:  40c0 0005 4600 0005 4600 0000 0000 2601
	    0x0010:  0008 a401 4c00 0000 0000 0000 0000
	  unknown option (24), length 24 (3): 
	    0x0000:  3800 0005 4600 2601 0008 a401 4c00 0000
	    0x0010:  0000 0000 0000
	  rdnss option (25), length 40 (5):  lifetime 60s, addr: 2001:558:feed::1 addr: 2001:558:feed::2
	    0x0000:  0000 0000 003c 2001 0558 feed 0000 0000
	    0x0010:  0000 0000 0001 2001 0558 feed 0000 0000
	    0x0020:  0000 0000 0002

The RDNSS allows IPv6 clients that have not yet embraced DHCPv6 to mostly work without IPv4, which is nice (although I still think it's a hack).

I was puzzled by the other options on the configuration screen, though.  The "Enable Unicast" and "Enable Rapid Commit" initially meant nothing to me and I assumed the "Enable EUI-64 Addressing" toggled the "A" flag in the RA.  I individually toggled all of the options and compared the results, which required a few reboots, unfortunately.  From what I can tell the "Enable Rapid Commit" and "Enable EUI-64 Addressing" options do absolutely nothing to the RA messages.  However, "Enable Unicast" removes all the flags and all but one option in the RA:

20:59:52.178671 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c604:15ff:febe:e634 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
     hop limit 64, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
       source link-address option (1), length 8 (1): c4:04:15:be:e6:34
         0x0000:  c404 15be e634

I'm not sure why that option isn't labeled appropriately or why enabling "unicast" would result in such a configuration.  Silly consumer networking equipment.

Anyway, I threw a host on the link and, of course, started running some traceroutes.  I expected to see the LAN interface of the CG3000DCR as the first hop, but I didn't:

HOST: rpi                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:558:4082:48::1                              0.0%     1   10.8  10.8  10.8  10.8   0.0
  2.|--    0.0%     1    9.0   9.0   9.0   9.0   0.0
  3.|--       0.0%     1    8.7   8.7   8.7   8.7   0.0
  4.|--       0.0%     1   11.8  11.8  11.8  11.8   0.0
  5.|--  0.0%     1   10.9  10.9  10.9  10.9   0.0
  6.|--   0.0%     1   26.2  26.2  26.2  26.2   0.0
  7.|--     0.0%     1   27.0  27.0  27.0  27.0   0.0
  8.|--       0.0%     1   29.3  29.3  29.3  29.3   0.0
  9.|--                        0.0%     1   81.8  81.8  81.8  81.8   0.0
 10.|--                                           0.0%     1   37.3  37.3  37.3  37.3   0.0

Other than the bad PTR on hop #7, the first hop was unexpected.  Is it, instead, the DOCSIS interface address that's being used in the ICMPv6 response?

(rpi:21:45)% mtr -rwc1 2001:558:4082:48::1
Start: Fri Dec  5 21:46:21 2014
HOST: rpi                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:558:4082:48::1  0.0%     1    9.1   9.1   9.1   9.1   0.0

Maybe.  But when I traceroute to my host from the outside, why do I see 2001:558:a2:f3::2, instead?

HOST:                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a00:86c0:ff0a:2906::1                      0.0%     2    1.0   1.0   1.0   1.0   0.0
  2.|-- 2a00:86c0:26c::9                            0.0%     1    0.3   0.3   0.3   0.3   0.0
  3.|-- 2001:559::ca1                               0.0%     1    0.9   0.9   0.9   0.9   0.0
  4.|--  0.0%     1    1.6   1.6   1.6   1.6   0.0
  5.|-- 2001:558:0:f747::2                          0.0%     1   19.2  19.2  19.2  19.2   0.0
  6.|--    0.0%     1   20.4  20.4  20.4  20.4   0.0
  7.|-- 2001:558:a2:f3::2                           0.0%     1   18.8  18.8  18.8  18.8   0.0
  8.|-- 2601:8:a401:4c00:ba27:ebff:fe8f:7486        0.0%     1   28.4  28.4  28.4  28.4   0.0

This appears to be an anomaly when an ICMPv6-based traceroute is used.  A UDP one works as expected:

(rpi:21:49)% mtr -u -rwc1          
Start: Fri Dec  5 21:49:35 2014
HOST: rpi                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2601:8:a401:4c00:c604:15ff:feee:e634             0.0%     1    0.9   0.9   0.9   0.9   0.0
  2.|-- 2001:558:4082:48::1                              0.0%     1   16.2  16.2  16.2  16.2   0.0
  3.|--    0.0%     1    8.9   8.9   8.9   8.9   0.0
  4.|--       0.0%     1   13.0  13.0  13.0  13.0   0.0
  5.|--       0.0%     1   12.5  12.5  12.5  12.5   0.0
  6.|--  0.0%     1   11.1  11.1  11.1  11.1   0.0
  7.|--   0.0%     1   28.2  28.2  28.2  28.2   0.0
  8.|--     0.0%     1   26.7  26.7  26.7  26.7   0.0
  9.|--       0.0%     1   31.8  31.8  31.8  31.8   0.0
 10.|--                        0.0%     1   38.2  38.2  38.2  38.2   0.0
 11.|-- ???                                             100.0     1    0.0   0.0   0.0   0.0   0.0

2001:558:4082:48::1 is obviously the CMTS.

Now that we've got the initial exploring out of the way, I figured I would try the "static route" feature on the CG3000DCR to see if it worked with IPv6 at all:

IPv6 Static Route Fail

This was a complete fail.  I tried adding a /64 static route to a static host I have on the link with a subnet mask of "64" and then one of "ffff:ffff:ffff:ffff::" but both failed.

As far as the permanency of this rather useless /56 I'm given, a quick look around on the support forums made me conclude that the current prefixes are dynamic and static prefixes will be rolled out in the future.  I suppose that answers the question about reverse DNS delegation, too.  I can't imagine that being a possibility at all without static assignments.  I also sure do hope that they provide an option for delegation instead of just adding individual records like they do for IPv4 (and, poorly, I may add, since it must be done via a phone call).

I guess I'm not ready to dump my tunnels, yet.  I'd like a static assignment and reverse DNS.  Otherwise, the sweetness of native IPv6 still feels like a downgrade.

Comments: 2
> Inappropriate Words
Posted by prox, from Seattle, on November 19, 2014 at 01:00 local (server) time

No, it's not what you think.

I've recently realized I am starting to use a few words inappropriately:

Comments: 0
> DNS Stupidity
Posted by prox, from Seattle, on September 23, 2014 at 01:18 local (server) time

Whatever you want to call it, I'm a firm believer that this should work:

% cat /etc/resolv.conf
% host has address has IPv6 address 2001:db8::1
% host has address has IPv6 address 2001:db8::1

Unfortunately, it seems like most operating systems are starting to break this by not appending the search prefix to short names that contain dots.  Windows and Mac OS X have changed to this broken behavior by default and now require obscure tweaks to get the correct behavior back.

Now, since Linux lately is becoming a wannabe Mac OS X, it apparently now suffers from the same issue:

(destiny:22:08)% host has address
(destiny:22:08)% host nox.ext               
Host nox.ext not found: 3(NXDOMAIN)
(destiny:22:08)% cat /etc/resolv.conf

We can see that the resolver libraries aren't bothering to append to nox.ext in the second query:

22:08:45.103912 IP > 28936+ A? (39)
22:08:45.104274 IP > 28936* 1/7/14 A (507)
22:08:45.104703 IP > 13808+ AAAA? (39)
22:08:45.104970 IP > 13808* 0/1/0 (108)
22:08:45.105245 IP > 55206+ MX? (39)
22:08:45.105450 IP > 55206* 0/1/0 (108)
22:08:46.946125 IP > 38662+ A? nox.ext. (25)
22:08:46.946415 IP > 38662 NXDomain 0/1/0 (100)

However, I've got another machine sitting here that's running the same version of libc-bin (2.19-7) and does work.  I'm failing to identify the delta between these machines.

Is this a bug?  Is this expected behavior?  How do I fix it?  No, the "ndots" parameter for /etc/resolv.conf is irrelevant.

Update: As some folks have pointed out, the reliance of short names even on controlled networks is being discouraged due to the new ICANN TLDs.  I've been aware of the consequences of using short names and the potential for blackholing legitimate external sites using these new TLDs and still believe I should be able to use the legacy resolver behavior.  If there's another way of not having to type a million times per day, though, I'm all ears!

Update 2: After a post I made to debian-user I realized that the ndots parameter is not irrelevant and fixed my issue.  However, changing it shouldn't have fixed the issue because the defaults (I checked the source) are ndots:4.

Update 3: I'm an idiot.  I wasn't using anything other than host(1) to do testing.  host(1) implements its own resolver library and reads /etc/resolv.conf itself.  Apparently something changed in host(1), but didn't impact anything else!  Case closed!

Comments: 3
> systemd-journal
Posted by prox, from Seattle, on August 02, 2014 at 23:14 local (server) time

I've been slowly converting my Debian boxes over to the systemd init system (by installing the systemd-sysv package), recently.  I haven't encountered any problems, yet.

However, it seems that my lab box has some systemd component already burning away at the CPU cores:

systemd fail

The worst part is that I haven't installed systemd-sysv on that box, yet!

Update: It looks like these systemd-journal processes are running under my Linux containers, which are using systemd.  journalctl(1) does not show any errors so I killed both processes (they immediately respawned) and the CPU usage is gone.  Yeah.. we're going to be dealing with issues like this for years.  Sigh.

Comments: 0

No Previous PageDisplaying page 1 of 117 of 934 results Next Page