Prolixium dot com

LTE on The Nexus 4

prox — Tue, 04 Jun 2013 18:53:05 UTC

We all know by now that the Nexus 4 sports an LTE radio that is unsupported and has recently been disabled by Google. However, it does work if you enable it. Should you bother, though?

I'll try to answer that question, given I've spent a few days with it in two locations (Herndon, VA and Charlotte, NC) on T-Mobile.

First, the radio will only work with the 2.0.1700.33 radio firmware, which is the original firmware that was installed on my Nexus 4. This radio firmware works fine with Android 4.2.2, even though it was originally released in 4.2.1. Although most people will say that radio firmwares aren't tied to specific Android versions, I've encountered at least one situation where this wasn't the case - so, beware. This radio firmware can be downloaded from here.

Second, the radio only supports E-UTRA band IV. This is AWS, with a center frequency of 1700 MHz. Here's a handy list of all frequency bands used by the air interface of LTE, E-UTRA. As a result, you'll be able to use it with T-Mobile USA, among other things.

Third, lots of things don't work. This is hardly shocking news, since the darn thing is unsupported. Here's a short list:

Location services are not provided by LTE. Unless Wi-Fi or GPS is enabled, the Nexus 4 will have no clue where it is in the world.
Some applications crash and misbehave. The two camera applications that I use, the stock camera and CameraZOOM FX, both seize up and are generally very slow. I suspect this is due to some background location processing that is foiled because there is no location information, even though the cellular connection is active. Words with Friends and Draw Something crash and lock up, too.
LTE doesn't work after a reboot. It has to be manually enabled via the *#*#4636#*#* hidden menu.
No voice services are provided over LTE, at the moment. This is expected, but I'll list it just for completeness.
Voice calls bump the phone back to GSM/UMTS. It doesn't interrupt data, though - it's a smooth handoff. I'm not sure why this happens, considering all radios are active. I would think the phone should be able to send voice over the GSM or UMTS radio and keep data enabled over the LTE radio. It's not a big deal since the phone will go back to LTE a minute or so after the voice call is ended.
And here's the clincher.. the LTE performance is not impressive. I've only been able to get 16 Mbps downstream and 19 Mbps upstream on T-Mobile with a very strong signal. I've seen some much better speed tests at some of the T-Mobile test locations, but I might just have high expectations.

Other than the above, it does work. If you decide to use it, be aware that the FCC has technically not approved the Nexus 4 for LTE operation and you'll most likely have to stick with the 2.0.1700.33 radio and some sort of unofficial Android build (CyanogenMod works) forever.

Punta Cana Vacation

prox — Sat, 01 Jun 2013 19:27:57 UTC

I recently went on a nice vacation in the Punta Cana area of the Dominican Republic.

I stayed at the Riu Palace Punta Cana, an all-inclusive resort on the beach. It was the first time I've stayed at an all-inclusive resort so it took awhile to get used to the fact that yes.. everything is included. The beach scene was fairly idyllic:

On the last day I took an excursion, which involved Snuba and driving a speed boat. The Snuba experience was pretty fun but it's too bad there wasn't much to see in the area where we were. Driving (piloting?) the speed boat was an interesting experience, one I would like to do again, given the opportunity!

One odd thing about the resort was its Internet connectivity. There was included Wi-Fi powered by a bunch of what looked to be WDS repeaters on a flat 172.21/16 IPv4 network uplinked to a single MikroTik router with several low-speed Internet connections a few hops away. As a result, it was horribly slow - I couldn't even break 1 Mbps. Here's some CDP from the wire showing the repeaters:

00:23:02.907300 CDPv1, ttl: 120s, checksum: 376 (unverified), length 70
	Device-ID (0x01), length: 10 bytes: 'NANO1PCANA'
	Address (0x02), length: 13 bytes: IPv4 (1) 172.21.255.250
	Capability (0x04), length: 4 bytes: (0x00000002): Transparent Bridge
	Version String (0x05), length: 9 bytes: 
	  XM.v5.5.2
	Platform (0x06), length: 3 bytes: 'N2N'
	Port-ID (0x03), length: 3 bytes: 'br0'

The MikroTik router appeared to round-robin sessions through all of the Intenet connections, which resulted in my source IPv4 address changing constantly. Since the Wi-Fi was not encrypted, I was connected via a VPN most of the time, which reconnected every 5-10 minutes. I guess that is the cheap way of getting more bandwidth - I suspect the Internet connections were just low-speed DSL links instead of something more robust.

I managed to snag some bandwidth statistics from the MikroTik router through just following unauthenticated HTTP links:

The above is from the one "LAN" interface on the MikroTik box. There wasn't too much traffic considering the resort is pretty large. I guess the Internet connectivity was too slow that nobody bothered with it (or they were doing more vacation-ish things).

Anyway, I took a bunch of photos with my Nexus 4, Canon 60D, and GoPro HERO3. The HERO3 actually performed admirally during the Snuba and speed boat appearance considering I had 720p@60 video running most of the time. I was concerned the battery would die, but it didn't. One thing that sucked, though - I switched the video mode to 1080p@24 to get some more detail and was sorely disappointed when I played it back. For some reason the video exhibited very poor tearing like it was taken with 5-year old cellphone. I recall that didn't happen at 1080p@60, though. So, for some reason that low frame rate introduces some buffering problems on the HERO3.

Android Bugs

prox — Sun, 07 Apr 2013 14:52:11 UTC

If you follow me on Google+, you'll know that I'm a big Android fan but am starting to get annoyed with the constant OS bugs that plague platforms running vanilla Android (eg, Google's Nexus line of devices).

One of my recent posts had me wondering if I should ditch Android and switch to the iPhone. Ultimately, I'd lose too much (IPv6 on T-Mobile, certain apps, etc.), so I'm probably not going this route.

Anyway, here's a list of some recent bugs that continue to plague vanilla Android (more or less - I'm using the M2 build of CyanogenMod 10.1) running on my Nexus 4 along with the fixes or workarounds that I've found.

The Camera Stops Working

This is documented in issue 40996 and happens maybe once a week to me. All applications that use the camera freeze and require a kill.

I haven't really confirmed this yet, but the supposed fix is to switch to video mode and then switch back.

Mobile Data Stops Working

This only happens to me once a month so I haven't really been able to research it too much. Even though mobile data is enabled, a GNU/Linux interface (rmnet0, p2p1, etc.) is not created in the OS so applications cannot access the Internet. If the PDP context is just IPv4 or just IPv6, the behavior is a little bit different; the data connection connects for 3-4 seconds and then disconnects. It does this every 20-30 seconds or so. Most of the time bad network conditions (no service, very poor signal, etc.) trigger this condition.

The fix that I've found is to enter the testing screen (*#*#4636#*#*), go to Phone information, and select the "Select radio band" in the menu. The application crashes but then mobile data starts working again. It's weird.

Bluetooth Stops Working

Sometimes after switching Bluetooth on or off or enabling or disabling airplane mode, the Bluetooth subsystem stops working. I took a video of this behavior:

This is documented in issue 42255. This one is frustrating because Google fixed this in 4.2.1 but it came back in 4.2.2.

The only workaround I know of is to never disable Bluetooth and never use airplane mode (turn off the wireless radio in the Phone information screen after using *#*#4636#*#*).

Snow!

prox — Sun, 17 Feb 2013 14:17:02 UTC

After almost two years of not seeing any snow here in Charlotte, we finally got a good snowfall last night. I took a few photos at night and the next day. Strangely enough, even though it snowed for a few hours, the majority of the accumulation happened over a three minute period. I have a few time lapses of driving home and at my condo that I might put up on YouTube, later today.

In other non-news, people really don't know how to drive in the snow, down here. Shocker, I know!

DMCA and Phone Unlocking

prox — Sat, 26 Jan 2013 10:08:12 UTC

It's January 26, 2013. This means that, among other things, it's now illegal in the United States to unlock a carrier-locked UE (ie, phone, tablet, etc.) without the provider's consent. See accurate coverage here and here.

Unfortunately, lots of people and online news sources seem to be spreading misinformation about this. They say incorrectly that "jailbreaking and unlocking is illegal on Jan. 26." Wrong! jailbreaking of iOS devices is completely separate from unlocking, although one often leads individuals to do the other. It is still legal to jailbreak or root your UE, although this may void the warranty of the specific device.

This law is, of course, thanks to the DMCA.

IPv6 NAT+PAT on GNU/Linux

prox — Tue, 22 Jan 2013 18:37:33 UTC

Let the flogging begin! Yep, I'm using IPv6 NAT+PAT on GNU/Linux.

Sure, for awhile it's been possible to do this in other operating systems (Junos, ScreenOS, IOS, FreeBSD, OpenBSD, etc.).. but not GNU/Linux.

The ip6tables MASQUERADE target was introduced in kernel 3.7 as ip6t_MASQUERADE.ko. Since I have a setup at home that involves using a Verizon Wireless LTE USB stick for backup Internet access (see this and this on the struggles I had to undertake to get it to work with GNU/Linux), this is a requirement for me if I want my IPv6 Internet traffic to use the connection as well. Verizon Wireless has supported native IPv6 on their LTE network since it launched, back in December of 2010.

I had to roll a vanilla kernel from kernel.org and use the deb-pkg target since the latest kernel in Debian is based on 3.2. I also had to grab iptables 1.4.17, build it, and install it from scratch, too. The three configuration options I enabled in the kernel were the following:

CONFIG_NF_NAT_IPV6=m
CONFIG_IP6_NF_TARGET_MASQUERADE=m
CONFIG_IP6_NF_TARGET_NPT=m

I'm not using NPTv6, yet, but I might try that out in the future. Once built and installed, I added the following familiar line to my iptables configuration script to enable MASQUERADE functionality for IPv6 on the upstream interface:

ip6tables -t nat -A POSTROUTING -s $VOXELV6 -o $EXT -j MASQUERADE

Since my internal network is numbered out of my IPv6 block from Voxel dot net (now Internap) that is usually tunneled to a server I have with them, $VOXELV6 is defined as 2001:48c8:1:100::/56. $EXT is wwan0, which is the USB stick. A very simplified diagram of this setup is shown below:

Normally, IPv6 traffic flows through the tunnel between starfire and dax. When the Road Runner connection fails or is otherwise manually depreferenced on starfire (this will also bring down the OpenVPN tunnel to dax), IBGP moves IPv4 and IPv6 connectivity over to evolution where formerly only IPv4 NAT took place.

Now, both IPv4 and IPv6 NAT+PAT is done on evolution. It works fairly well:

(evolution:17:44)% sudo ip6tables -t nat -S POSTROUTING    
-P POSTROUTING ACCEPT
-A POSTROUTING -s 2001:48c8:1:100::/56 -o wwan0 -j MASQUERADE

(destiny:17:30)% mtr --report --report-cycles=32 -w 2001:4860:4860::8888 
HOST: destiny                            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- et3.starfire.prolixium.net          0.0%    32    0.2   0.3   0.2   0.4   0.0
  2.|-- et0.evolution.prolixium.net         0.0%    32    0.5   0.5   0.5   0.6   0.0
  3.|-- 2600:1004:b01d:66b7:0:4a:d1a7:7f40  0.0%    32   34.7  44.7  32.1  68.8   8.0
  4.|-- 2001:4888:0:1000:201:200::          0.0%    32   49.0  45.3  31.4 100.3  12.5
  5.|-- 2001:4888:20:2010:201:25::          0.0%    32   83.2  47.3  32.9  83.2  12.5
  6.|-- 2001:4888:20:2000:201:1:0:1         3.1%    32   56.9  47.1  36.1  62.7   6.6
  7.|-- 2001:4888:20:1002:201:24::          0.0%    32   52.5  43.9  32.1  61.8   8.2
  8.|-- 2600:804:21f::1                     0.0%    32   52.9  56.5  40.7  82.0   9.1
  9.|-- Loopback0.GW1.MIA19.ALTER.NET       0.0%    32   62.1  75.5  54.9 137.5  18.4
 10.|-- 2600:804:80f::a                     0.0%    32  115.0 123.5 108.4 159.1  12.0
 11.|-- 2001:4860::1:0:245c                 0.0%    32   80.3  80.3  62.1 159.9  21.0
 12.|-- 2001:4860::8:0:464f                 0.0%    32   75.5  87.9  65.1 160.6  18.6
 13.|-- 2001:4860::2:0:a7                   0.0%    32   99.7  84.7  69.5 126.2  13.0
 14.|-- ???                                100.0    32    0.0   0.0   0.0   0.0   0.0
 15.|-- google-public-dns-a.google.com      3.1%    32   94.0  84.1  71.6 102.7   8.2

It's been stable for about an hour, now, so that's good enough for me. Since I'm not using a tunnel with this connection, I can also get a full 1500 byte MTU:

(destiny:18:23)% ping6 -c 4 -M do -s 1452 he.net.     
PING he.net.(he.net) 1452 data bytes
1460 bytes from he.net: icmp_seq=1 ttl=54 time=140 ms
1460 bytes from he.net: icmp_seq=2 ttl=54 time=167 ms
1460 bytes from he.net: icmp_seq=3 ttl=54 time=136 ms
1460 bytes from he.net: icmp_seq=4 ttl=54 time=134 ms

--- he.net. ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 134.451/144.745/167.546/13.340 ms

So, what about the flogging? That's because lots of people will say this is the wrong way of doing things. They say I should call up Verizon Wireless and petition them to support DHCPv6-PD, in addition to the 3GPP-mandated /64 assigned to the cellular interface (see section 1.5.3 of RFC 3314). They also say NAT is evil.

Sure, I could do that, but it won't help me now. Even though NAT does suck in general, I say IPv6 NAT+PAT works fine in certain circumstances like this. It's just a tool, it can be used for good and as well as evil. To be honest, I don't find NAT or this use of it inherently evil.

If you want, read some of my other blog entries on the topic of IPv6 NAT+PAT.

MIT

prox — Tue, 22 Jan 2013 13:10:41 UTC

It looks like MIT's domain, mit.edu., got pwn3d:

(destiny:13:02)% whois mit.edu                                        

This Registry database contains ONLY .EDU domains. 
The data in the EDUCAUSE Whois database is provided 
by EDUCAUSE for information purposes in order to 
assist in the process of obtaining information about 
or related to .edu domain registration records. 

The EDUCAUSE Whois database is authoritative for the 
.EDU domain.         

A Web interface for the .EDU EDUCAUSE Whois Server is 
available at: http://whois.educause.net 

By submitting a Whois query, you agree that this information 
will not be used to allow, enable, or otherwise support 
the transmission of unsolicited commercial advertising or 
solicitations via e-mail.  The use of electronic processes to 
harvest information from this server is generally prohibited 
except as reasonably necessary to register or modify .edu 
domain names.

You may use "%" as a wildcard in your search. For further 
information regarding the use of this WHOIS server, please 
type: help 

--------------------------

Domain Name: MIT.EDU

Registrant:
   Massachusetts Institute of Technology
   Cambridge, MA 02139
   UNITED STATES

Administrative Contact:
   I got owned
   Massachusetts Institute of Technology
   MIT Room W92-167, 77 Massachusetts Avenue
   Cambridge, MA 02139-4307
   UNITED STATES
   (617) 324-1337
   cunt@mit.edu

Technical Contact:
 OWNED NETWORK OPERATIONS
   ROOT
   US
   DESTROYED, MA 02139-4307
   UNITED STATES
   (617) 253-1337
   owned@mit.edu

Name Servers: 
   FRED.NS.CLOUDFLARE.COM      
   KATE.NS.CLOUDFLARE.COM      

Domain record activated:    23-May-1985
Domain record last updated: 22-Jan-2013
Domain expires:             31-Jul-2013


(destiny:13:02)% dig +short @FRED.NS.CLOUDFLARE.COM. mit.edu. A 
141.101.117.213                                                
141.101.116.213

Whoops! Here is more information.

GoPro HERO3: Black Edition

prox — Tue, 25 Dec 2012 20:02:57 UTC

I picked up a GoPro HERO3: Black Edition camera a few weeks ago. I like to do silly things with time lapses and HD video, so I figured this camera would be a good fit for my creative side.

The Good

The camera's got a nice wide-angle lens. This makes it easy to see at least 170°, which usually includes enough context for the scene to make it enjoyable.

The resolution and frame rate on the camera is great. I usually shoot things in 720p at 60 FPS since the 1080p mode chews up the MicroSD card too quickly. The modes that I use to shoot have the following bitrate, according to MPlayer on GNU/Linux:

720p@60: 20 Mbps H.264 video / 128 Kbps 2 channel 48,000 16-bit samples/sec AAC audio
1080p@60: 30 Mbps H.264 video / 128 Kbps 2 channel 48,000 16-bit samples/sec AAC audio

The encoding is variable bit rate (VBR), so the averages might be slightly different. This page on Wikipedia shows published bit rates. The camera also supports a few 4K modes, but at lower frame rates. It'll also do 848 x 480 at a whopping 240 FPS. I need to do something creative with this!

A Wi-Fi remote control is included, which is handy when unattended operation of the camera is required. The small LCD display on the camera is duplicated on the Wi-Fi remote control, too, so no features are lost during remote operation. That being said, using the remote adds a considerable amount of lag for button presses.

Unlike many newer consumer electronics that don't have removable batteries (I'm looking at you, Apple!), the GoPro cameras all seem to have removable batteries. Among other things, this allows one to swap out the battery during shooting (although this has some implications that I'll disuss in the next section).

The included water-proof enclosure is nifty. It works well under water to 200 meters (I haven't tried this) and appears to be fairly shock-absorbant, too. Unfortunately, audio doesn't penetrate it very well, which is to be expected. All three buttons are still available when in the enclosure, but to replace the battery and connect USB or HDMI, the camera must be completely removed.

The Bad

Let's start out with the worst feature: the HERO3 will overwrite files if you restart the camera. As far as I can tell, if you turn on the camera, take video or photos, turn off the camera, then turn it back on, it'll immediately start overwriting the previous files regardless of how much free space is on the MicroSD card.

Normally, the HERO3 will write files to the directory DCIM/100GOPRO files with a format of GOPRxxxx.yyy where xxxx is the file numbers (0001 to 9999) and yyy is the extension (LRV, THM, MP4, or JPG). This format will switch to Gxxxxxxx.yyy when the number of files hit 10,000, which happens often during the time lapse mode. Most cameras do something like this, it's nothing out of the odrinary. However, the difference is that when most cameras are powered off and then powered back on, the file numbering starts off with the last file written (usually the highest numbered one). The HERO3 just resets the counter and starts writing over prior files. This can even be seen from the number on the LCD display.

There's a configuration knob labeled "loop" that, according to the manual, causes the camera to treat the MicroSD card as a sort of circular buffer and start to overwrite earlier files when the MicroSD card reaches capacity. This is disabled by default and seems to have no direct relation to this behavior.

As a result, I lost several videos and time lapse sequences before discovering this behavior. In my opinion, this makes the software on the HERO3 fundamentally "broken" and not fit for sale. I probably could have said the same thing about the early releases of JUNOS-ES on Juniper's line of SRX firewalls and J-series routers, though. They just don't make stuff like they used to. Hopefully this will be fixed in a software update. I opened up a support ticket with GoPro about this just to be sure they're aware of it. If they're not.. ugg.

On December 14, 2012, GoPro released a firmware update (HD3.03.02.00) for the HERO3 that allows it to work with the GoPro iOS application. This allows for a live view and the ability to control the camera and its various settings from an iPad, iPod, or iPhone. This sounds neat but.. it just doesn't work for me.

The application works by connecting to the camera over Wi-Fi. The camera itself becomes an access point (the SSID and pre-shared key are set when you download the firmware, but it's really just a text file) and the iOS device is supposed to connect to it. The IPv4 network used is 10.5.5.0/24 and addresses are handed out via DHCPv4. This method is used by other things (like the Brookestone Rover) and is fairly annoying since it prevents iOS device from simultaneously accessing the Internet while connected to whatever specific device is being used. Anyway, once the iOS device is connected to the camera's Wi-Fi SSID the application will "find" the camera by just connecting to the default gateway. This is all well and good but, for me, the camera constantly disassociates my iPad after the GoPro application is open for maybe 15 to 30 seconds. At first I thought it was our Wi-Fi IPS system at work that sometimes misbehaves since that was the first place I tried it. However, it did the same thing for me at home. I am betting the bug is in the HERO3 firmware since the Wi-Fi connectivity on iOS isn't handled at all by the GoPro application.

In the time lapse mode, white balance seems to be evaluated only when the sequence is started. If the lighting conditions change dramatically into the sequence, the subsequent images will often either look too bright or too dark. I searched around for a setting to fix this but found nothing. I opened up a support ticket about this.

When shooting on & off at 720p or 1080p, the battery will last about 90 minutes, then die. I suppose the camera is made for activities that don't last for several hours. Things like scuba diving, skiing, and surfing come to mind. Still, it's annoying. I assume if the video FPS could be dropped to 30 for 720p this would increase the battery life considerably. Unfortunately (as seen in the above Wikipedia link), there doesn't seem to be any video format that is "easy" on the encoding process. Everything is at least 20 Mbps. This lack of flexibility is a bad move on GoPro's part, in my opinion.

The camera and battery both heat up tremendously when shooting video. I suspect this is due to the encoding processing required that heats up the CPU and simultaneously drains the battery very quickly. It becomes uncomfortable to hold at times and probably decreases the overall life of the battery.

Sometimes the MicroSD card becomes unreadable by the camera. Although this happened just once it was a large pain in the butt because I had to reformat the MicroSD card after backing up everything, first. I still don't know what was wrong with the MicroSD card since connecting it to a USB reader on GNU/Linux worked fine. The camera would lock up when starting up, requiring the battery to be pulled.

The HDMI connection is quirky. I tested this on a Vizio TV (W32L A20, 1366x768) and a Samsung computer monitor(S20B350, 1600x900). The Samsung monitor worked but the Vizio TV never detected a signal, possibly due to a handshake failure. Furthermore, when I went to play the videos that were stored on the MicroSD card in my HERO3, none were listed. After taking a short video when still connected to the monitor I went to play it back and the HERO3 complained that the video format was unsupported. So, the HDMI feature seems useless unless you want to.. well, just see live video from the camera or change settings on a big screen.

The Odd

The camera came in a fairly annoying package. It took some considerable work to break it and the Wi-Fi remote free due to some tight and thick wires. The camera actually sits on a removable plastic base that, upon first glance, is just part of the packaging. However, I'm not so sure of this, since it is very useful and works great when placing the camera on a smooth or semi-smooth surface. The rubber "feet" on the base were originally connected to the packaging but still contain some stickiness that serves to keep the base still when placed on, oh.. the dashboard of a moving vehicle:

I can't seem to find a similar base on the accessory list, so I'm holding onto this thing! I'll probably have to replace the feet eventually, when the stickness wears off. I suspect double-sided tape will serve as a decent replacement.

There are some odd "LRV" video files that are created along side of the MP4 files. Apparently these files are the "Low Resolution Version" of the matching MP4 files. They're used for quick previews, apparently. Unfortunately, they eat up some space on the MicroSD card and there's no way to turn them off.

The HERO3 actually runs Linux 2.6.38.8, apparently:

(orion:10:51)% strings HD3.03-firmware.bin|grep Linux.version 
Linux version 2.6.38.8 (rlim@ubuntu) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 PREEMPT Thu Dec 13 00:05:05 PST 2012
Linux version

The boot loader is apparently some "Amboot" loader that starts the Linux kernel. I'm wondering if we're going to see some alternate (less buggy!) firmwares for the HERO3 in the future. BusyBox httpd 1.19.3, PHP 5.x, and hostapd all are present in the firmware, from what I can see.

Conclusions

The HERO3 is a nice rugged video camera that probably shouldn't have been released until the software was ready. At this point, it's too buggy to use seriously because of the file overwriting issue. That being said, I am still having some fun with it:

I keep telling people that I'm going to get the head mounting kit and swim a few laps in the aquatic center. Hopefully the software will be improved by the time I do that!