Jono at Work

Monday, January 31, 2011

My mother-in-law has a Thomson TG585 v8 Router, which is the stock standard unit currently supplied by Telecom NZ with new connections.

I had serious trouble getting my MacBook Pro, iPad and iPhones to connect to the router's WiFi network. We were staying for a week on holiday, so it was a must-have to get connectivity working.

Boy oh boy what a mission.

I rang Telecom (a-la 0800 INDIA) and got told that there is a known issue with Apple devices connecting to this model Thomson router. Good start. He stepped me through turning off 802.11n, which made some improvement, but it didn't fix the problem entirely. I still had to reboot my MBP every time I woke it up from sleep, otherwise it would complain about the WiFi passphrase being incorrect.

To top it off, the mother-in-law bought an AirPrint enable printer yesterday, at my recommendation. It is the HP Photosmart e-AIO B110a, which supports AirPrint after a simple onboard firmware upgrade.

After dicking around setting up the printer onto the WiFi, getting drivers installed, and all the bundled HP crapware onto her HP laptop, I found that AirPrint didn't work on the iDevices very well, if at all. Most of the time, the iPad/iPhone would just say "Printer not found". Bad look for me and my recommendations.

We are heading back home today, so it was incumbent on me to make sure all things work before leaving! After a bit of trial and error configuring the router, I've figured out the settings that seem to work for all Apple devices, non-Apple devices, and the HP wireless printer.

Thursday, January 20, 2011

I recently added a few more sensors to my Micron Scorpion Z6L Home Alarm. The wiring side of things was really easy, but I found that the new zones weren't quite programmed correctly for what I wanted to do.

When I tried Googling around to find the installer manual, I came up with nothing except the Hungarian version. I would suspect that the Alarm System vendors and distributors don't like the idea of just anyone having access to the manual / knowledge; why would they when keeping it to themselves gives them the right to charge ridiculous sums for service calls. I refuse to pay for something that I can easily do myself on a Sunday afternoon.

Ok, anyway, I eventually found a manual for the Scorpion Z4110, which although is slightly a different model, has most of the same programming codes as the Z6L. Once you get your head around the concept of the programming address locations and data, it's pretty easy to figure out the rest.

The key bit that worked for me is that on my unit, the master programming PIN code was still set to the default of "0000". And if this has been changed, there is an "Emergency Access to Program Mode" feature described in the manual which allows you to gain access if locked out. However, the emergency mode feature can also be disabled, so if this has also been disabled by the installer the unit is basically un-programmable by the end user.

Monday, January 19, 2009

One of our devs developed a small ruby app that connects to a remote server over TCP and accepts an xml feed in return. This feed is then translated into our own TCP stream language and passed to a backend app. He needed to simulate a network / remote server outage to test the robustness of his code.

I initially thought that I could just set up an iptables packet filter on the firewall, but adding a quick DROP rule didn't work because the connection remains constantly established. Stopping and starting the ruby app got the packet filter to work, which proved that the DROP rule actually does work for new connections.

Another colleague suggested using a local netcat listener to bridge the TCP connection to the remote server, and point the ruby app at the local listener. Then just tear down the listener to simulate an outage.

The following example didn't work very well, because everything coming back from the other end just ended up in stdout.

Thursday, January 31, 2008

I ran into a problem while trying to install Ubuntu Gutsy on a new machine with an Intel DG33FB motherboard and 8GB RAM. Turns out that quite a few people have seen the issue. The main symptom is that the system performs very poorly, especially at boot time.

One post I saw indicated that a BIOS update would fix the issue. Notably, in version 0348.

Upon checking the Intel site, their currently available version was 0372. I figured that this being a later version it would include the fix from 0348. However, on checking the release notes for 0372, it appears Intel has removed the 0348 fix in 0353... uh?? See here:http://downloadmirror.intel.com/15422/ENG/DP_0372_ReleaseNotes.pdf

Monday, November 12, 2007

A couple of weeks ago I installed Ubuntu 7.10 (Gutsy) on a decent Intel branded Xeon server, with the purpose of running it as a Xen server. I planned to run 4 or 5 Gutsy domUs on it with Apache, etc for various internal web apps.

After doing the usual aptitude setup business on the host machine, I started provisioning the guest images, etc. During the debootstrap process (read: heavy disk I/O), the host server would kernel panic and fall over. I tested similar operations with the non-Xen kernel and the server was stable. I assumed that there was some disk I/O compatibility issue between the Xen kernel and my Intel SRCU42X Raid card, and abandoned the idea of Gutsy. I used Feisty for the host and guests instead, with no problems.

Then, a few days ago (just to humor myself), I tried again to set up a Gutsy Xen server on a basic desktop machine. Dual core Athlon 64 3800+, nForce 4 chipset, single 80GB SATA drive: Same issue - kernel panics during heavy-ish disk I/O operations.

So for now, there is no way I'm using the Xen kernel in Gutsy. Xen on Feisty seems to be really stable on the 4 or 5 boxes that I have running it. The one problem with this is that debootstrap in Feisty doesn't have the scripts for building a Gutsy guest image, so it's a manual process for running Gutsy guests on a Feisty host.