Monday, January 31, 2011

Telecom NZ Thomson TG585v8 with Apple, Airprint and HP Photosmart e-AIO WORKING

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.

Interface Type: 802.11b/g
Channel Selection: Automatic
Allow multicast from Broadband Network: (Ticked)
Use WPA-PSK Encryption: (Selected)
WPA-PSK Version: WPA2


Thursday, January 20, 2011

Micron Scorpion Z6L Installation and Programming Manual

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.

I found the original file on the Eagle Alarms site, but I've since put it up on to make sure it floats around the internet a bit more:

Update 1st March 2016: PDF file now here:

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.

Friday, September 18, 2009

Back to it, thanks Google

I've been listening to Twig over the last couple of weeks and I'm all keen to get my start putting some of my brain store back out there (even if I'm the only one who ever reads this blog).

I'll going to try out some of the stuff I've been hearing about and see where the journey leads. I like the look of Pubsubhubbub (gosh that is an ugly name), and where Google Reader is going.

Where I work we generate business event notifications for our customers. RSS has been available right from day dot, but the aggregation of these in GR has got some legs.

Monday, January 19, 2009

Using netcat to break TCP connections during testing

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.
nc -l -p 1234 | nc 1234

So I ended up using a fifo like this:
mkfifo backpipe; nc -l -p 1234 < backpipe | nc 1234 > backpipe

That works great and can just be killed with a CTRL-C to simulate a broken network, remote server outage, etc

Sunday, December 28, 2008

Slow Linux screen refresh over Lights-Out Virtual KVM

I have been reinstalling Linux (Centos 5.2) on a DL140 G3. I am working from home over the holidays so I needed to do it using the iLO Virtual KVM and an ISO mounted with the virtual CD Rom.

I'm RDP-ing to a Windows XP VM which is on the same 100Mbit network as the iLO device as the, to make sure that the virtual CD is speedy.

I found that RDP on top of the KVM screen is really slow at refreshing the whole screen, and sometimes only partial sections update - even in text install mode.

In the end, the best method seems to be to use the vga parameter in text mode, when confronted with the CD boot prompt. A-la:
# linux text vga=771

Thursday, January 31, 2008

Intel DG33FB 8GB ram slow boot problem

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:

They have also consequently made the 0348 BIOS unavailable on their download portal. However a quick Google around for the file shows that it is still available on their site:

I don't know what is wrong with the 0348 update that made Intel remove it three days after releasing it. But, it fixes my 8GB issue so I don't mind.

AFAIK this affects the following motherboards: DP35DP / DG33TL / DG33BU / DG33FB

This BIOS code is: DPP3510J.86A

The update relase is called: DPP3510J.86A.0348

Monday, November 12, 2007

Ubuntu Gutsy Xen Kernel Panic

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.