I’ve had a 2012 Nexus 7″ for a while now and performance has been dropping off over the last few releases of Android, Lollipop being pretty poor but better than some.
I’ve just flashed the Nexus back to KitKat 4.4 and performance is really good again. There’s a lot of contravening steps out on the Internet but I stuck with the instructions provided by Google which worked out fine.
I was using Ubuntu to control the device and had to download the SDK to get to the compiled tools needed. Hundreds of MB for just a couple of executables. Still, it was a good introduction to udev to allow the Nexus to be recognised as a device.
For my current client we’ve had a request in to enable video Hangouts. The first attempt was to run the traffic through the on-premise McAfee Web Gateways that are used to inspect all traffic in and out of the Internet. Performance wasn’t great and on looking closer we could see that all traffic was TCP based. In consultation with the supplier the conclusion was that the MWG can only process TCP traffic as it’s a stateful engine. We knew we needed to be using UDP to get the performance we needed as this was a video stream.
We reconfigured a single office to route the Google netblock of addresses directly to the perimeter firewalls and then conducted an experiment to see what happened. The pilot user population reported great performance. This was a bit of a surprise as we had expected to do DNS changes to allow the Chrome Hangout functionality (which was previously a discrete plug-in) to resolve the video servers. By default all our browser clients hand off all Internet access to the MWG’s including DNS resolution.
In consultation with some Google deployment specialists we believe that the following is happening:
1. Both users start their Chrome browser which immediately establishes a TCP connection to Google through the MWG’s
2. One user calls the other using Hangouts, the session initiation is established over the existing TCP connection to Google
3. Each client initiates UDP traffic to Google using the subset of Google netblock IP addresses returned in the session initiation
4. Video commences
The key points to note are that the Hangouts video functionality didn’t need to resolve the IP address hence we didn’t have to expose Internet name resolution into the internal DNS. The Hangouts functionality is not proxy aware – the UDP traffic was routed by default, enabled by the office router change directing Google traffic to the perimeter firewalls. My belief is that the Hangouts functionality tries to route out to Google before falling back to other protocols (and potentially discovering the MWG’s).
There is discussion out on the Internet about full cone NAT firewalls and the like. Our perimeter firewalls (without divulging suppliers) do NATing and are smart enough to allow inbound UDP traffic to be received and routed to the client that sent out UDP traffic to Google even though the traffic from Google is essentially unsolicited. I guess that makes them full cone.
Posted in Work
I’ve been having a lot of UI slowness problems with my 1st generation Nexus 7. I’ve seen a lot of people reporting the same symptoms online. Luckily I stumbled across this post online which seems to have done a lot of good:
Credit to the Blinkbox help site for this. I just purchased a Chromecast to link up with my Nexus 7 running 4.4.4. Annoyingly when I tried to cast a YouTube video I got an error occurred message. Fruitless reboots and power-off’s later I eventually stumbled across the solution – my BT HomeHub 5 has a Smart Setup enabled by default under Advanced Settings | Home Network | Smart Setup. Turn this off and it all worked.
This altered by understanding of the Chromecast devices, I had assumed it was a pure TCP/UDP transmission of the video across the local network. The implication is that the Nexus is acting as a remote control device similar to the DLNA device types and the Chromecast is streaming the content from the Internet itself.
It’s still annoying that individual apps have to be Chromecast enabled, the is a mirror screen option but it looks like my first generation Nexus 7 doesn’t support it even thought it’s present under Settings | Display.
So there I was assuming the display could be remoted using native X11 capabilities and it turns out xbmc on the pi uses opengl for embedded systems – gles. This means the app runs locally with no inbuilt way to remote the display. The solution is to run vnc, on the latest builds it’s part of the distribution so just needs an initctl start vnc and then use the glvncviewer on Ubuntu. 😊
Well I never knew that:
Using pipes take me back to my decade of Unix.
I realised back in May last year that the Cisco CCNA certification was to be revised on September 2013. So I spent July and August hitting a couple of books I had bought previously and going over an accelerated CCNA course I took in 2011. Luckily I passed first time.
The point of this post is that it reminded me that me actually studying a subject for a certification is very different to reading a technical book or looking at blog posts. While hard work, it does provide a lot of technical context and capability when talking to my network colleagues at work.
It had been years since I’d done a certification exam. I may now even be inspired to study for the CCNA Wireless.