I have an old Lenovo T 410 which I upgraded to Win 10. It’s been working fine even after an image backup and restore onto an SSD. Last week I noticed while playing with the Azure Resource Portal that I was working over WiFi only, my LAN switch port wasn’t even showing link detection.
I did the usual diagnostic steps – check all the physical elements such as cabling and ports, did a BIOS reset back to defaults, updated the driver, installed the Lenovo specific driver updates all without result. One thing I did notice was while in BIOS configuration the switch port link detection burst into life. When I booted back into the OS it went off again.
Uninstalling the NIC in Device Manager gave me link detection but the device itself naturally didn’t work. Weird.
After playing about with the device installation status for a bit I started going through the property sheet for the NIC to see if it was a setting such as TCP offload. Before I even changed a setting the link detection started working again. Turning off the WiFi radio showed I still had an internet connection which was good. This has survived a few reboots so I’m cautiously optimistic. However I’m baffled on why it fixed the problem, somehow the driver got tickled into life by the act of opening the property sheet.
Looking in the event log for the NIC I can see a single event about the driver not being migrated which must be a factor but I need to do some more reading to understand what that means.
When I span up an ubuntu client a couple of months ago I decided to use Firebird to access my Hotmail email account. Without really thinking about what I was doing I changed the default setting of the Account set up process to use POP as the email protocol.
I then happily used Thunderbird without issue. Sometime later I used the web interface of Hotmail and discovered that searching on specific terms gave back far less search results that I was expected. After a bit of investigation it turns out that Firebird has a default option of deleting email from the server 7 days after having been downloaded when using the POP protocol. This meant all the historic email I had in Hotmail now resided on my Unbuntu device and I could no longer access it from either the browser interface or other email clients.
I naively started to look at what programs existed out there to upload emails into Hotmail without success. Some time passed and I ran into an article comparing the POP and IMAP protocols. The former coincided with my understanding of the protocol, however, I realised that I had a gap in my knowledge of IMAP. It turns out that it’s a synchronisation protocol that ensures all devices have the same view of mail and folders rather than the classic client/server type of affair you get with POP. A far better overview is published here.
In Firebird I just saved the downloaded email into a separate folder from the inbox, and deleted my Hotmail account. I hen set the Account up again but made sure I didn’t alter the default of IMAP. Once synchronisation had completed I just drag and dropped the email messages in the saved folder back into the newly created inbox. Left it a couple of hours and hey presto – all my email is again available in Hotmail’s web interface (albeit as soon as I access a restored message it’s date/timestamp is updated to now meaning the message appears newer than it actually is).
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 Uncategorized
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. 😊