To my everlasting regret I got me a Canon Lide 60 scanner a couple of years ago. Canon’s hardware is pretty nice, but their driver support stinks, especially for OSX. This scanner costs me on average much more work than it should to keep going. Same for my Pixma 5200 Canon printer, by the way. Awful.

Anyway, I needed to scan a page from a mag to show on a slide. Hooked up the scanner, tried Canon Toolbox, and sure enough “Failed to open driver”. Internet next, user groups, downloads, complicated shit about uninstalling, reinstalling, rebooting the Mac Pro ten times. No joy. After a few hours (!) of this, I got an inspiration: hey, since I saw “Twain” mentioned, maybe Acrobat Pro 9 (CS4) could import it, instead of using Canon Toolbox? Sure enough, Acrobat found the scanner, looked it over, and promptly crashed.

And then I got my second inspiration: check out OSX Preview. And yes, that one worked. Not only that, but it automatically calibrated the scanner, proceeded to analyze the page, divided it into sections, scanned it, and served it up already partitioned into useful chunks. See the screenshots below. All the time I was just sitting there watching, doing nothing. The only thing I had to do was select the image and hit cmd-R twice to turn it the right way up.

Jeez, that innocent looking little Preview app is becoming mighty useful for any number of things.

I probably should mention that the driver I installed came in a file called “lide60osx11131en.dmg” to be found, somehow, on Canon’s support site. It installs both the drivers and the toolbox, but the toolbox doesn’t work.

After just a day I got an engineer connecting to my system with desktop sharing software and we together went through a number of different configurations. It wasn’t really trivial, since the first config took us nearly three hours. Then I had another question of how to implement more finegrained control over the firewall policies in one direction, but not the other, which had us online another two hours using desktop sharing. The final result was perfect and I’ve learned so much more about the details of autokey VPN tunnels.

I’m totally blown away by the level and quality of support I got for this issue from Juniper. Maybe this particular engineer was exceptionally good and persistent, but I have the impression that it is more of a rule with Juniper. When I bought the SSG-5 I thought it was a little expensive, but after this experience, I’ve totally changed my mind. The support level and quality makes it worth the price hands down.

No, I don’t have shares in Juniper, but after this experience I think I may get some.

Anyway, as I replaced the drum today, I checked the numbers. We got it in the summer of 2003 and it’s never failed yet. It has printed more than 64,000 pages, most in duplex, and has jammed less than 20 times total, according to the event log. The last jam was more than a year ago. It’s running as network printer for all the machines we have and it works flawlessly with any OS we’ve tried so far. The printouts are always just fine. Scrambled output has only appeared maybe twice during all these years. I can’t even remember when it last happened.

There’s always an up to date software package to be had from HP for any Windows version I’ve used. Admittedly, I don’t know about Win 7; I’ve stopped getting new versions of Windows a while back. It has been automatically located and installed on every Mac I’ve had, up to and including Snow Leopard, without any intervention by the user. Just like that. Options and all. Probably due to it running Bonjour flawlessly. I’ve never done a bios update.

As a final bonus, I’ve noticed that its actual consumption of cartridges is not one per 6,000 pages as advertised, but somewhere between 8,000 and 10,000 pages per cartridge.

I simply can’t believe what a good investment this has been. Amazing. Now let’s hope it doesn’t die just because I sang its praises…

You can click any of the images in this post to see the screenshots full size

First, a list of documents you may need, or I may need later and don’t want to lose:

dictionary.freeradius.internal – an Apple document listing the attributes passed to FreeRadius.

A usegroup message with some useful examples

Using OSX Radius with third party devices – has some info on hunt groups

Make sure radius is running

Via Server Admin, make sure Radius is selected in the services tab so it occurs in your list of services in the left pane.

Then select “Radius” in the left panel, select “Settings” and click the dropdown for “RADIUS Certificate”. There you should either select a cert you already have installed on the server, or else select “Manage Certificates…” to go and create one. I already had one, and I had it created by CAcert, a free service for certificates of all kinds.

When you’ve got the cert sorted out, click the button “Edit Allowed Users…” and you’ll get to this screen:

See to it that you’ve selected “For selected services below:” in the left half of the right pane and that “RADIUS” is selected in the list. Then use the plus sign below right to add all groups you want to manage through Radius. Don’t forget to click the “Save” button when you’re done.

If you have any regular wireless access points you want to add, you can do that through the Server Admin as well, but you can’t add any other devices this way.

Just to see if things are more or less right, try to start the Radius server and then check the logs. You can do that by selecting RADIUS in the left panel, click the “Logs” tab on top and then play with the “Start RADIUS” and “Stop RADIUS” button at the bottom of the screen:

If it complains about the lack of any clients, don’t bother. Just leave it off, since we’ll add clients through the command line shortly.

Once you’ve played with this for a while and are satisfied that it is not too bad, you can leave the Radius server off. We’ll start it from the command line later.

It’s important to understand that all the groups you select here, and only those groups, are copied over to the user database in the Radius server. Any users that are not in one of these groups cannot ever be enabled through Radius; they’re simply not seen by the Radius server.

Also important to understand is the fact that this is as far as Apple goes in its GUI implementation of Radius. That is, any user that is enabled for Radius this way can log in to any Radius enabled wireless access points on your net. They don’t make any distinction according to user or group as to what you can do, nor do they implement anything else but wireless access points. This means that for more sophisticated usage, you have to proceed on your own, largely through the command line and config files.

Add clients to radius

A “client” is a piece of equipment that will ask the radius server to authenticate users, so clients are accesspoints, firewalls, maybe switches and routers. Each of these pieces of equipment that you want to have call the radius server needs to be configured in the server with its IP number and a shared secret (password). This shared secred is the same on both sides, so each piece has its secret shared with the radius server, but each pairing has another shared secret. If you want to add just Apple supported wireless access points, you can do that through Server Admin, but for everything else you have to do it as follows.

To add a client to the radius server, you use the radiusconfig utility on the OSX server:

sudo radiusconfig -addclient 172.16.200.241 ssg5 firewall

After you enter this command, radiusconfig will ask you for the shared secret. Remember it, because this is the same secret we will need to enter in the SSG-5 later. A side note: the last parameter is the type and I gave it as “firewall”. As far as I can see, it’s purely descriptive and you can call it “bigbrownbear” for all the difference it makes.

If you check the list of “Base Stations” in Server Admin, you’ll should see this client in the list, at least if Radius is running:

Add the DEFAULT entries to the users file

Even though Radius users are held in an sql-lite database under OSX, the users file still does exist and is read. In this file, we can add in rules that will be processed for any user that is accepted by Radius, so we can add on values to be returned to the Radius client (in our case, the firewall). In the users file, you also have access to some information from Open Directory on OSX, so the users file is the place where information is transformed from OSX Open Directory to Radius clients. This is where the magic happens. We write all our rules for the magic user “DEFAULT”, which matches any user accepted by Radius. More than one rule may match a real user, and all of the matching rules will be applied.

Open the “/etc/raddb/users” file on the server with pico as root:

sudo pico /etc/raddb/users

In that file, towards the end, in among the other “DEFAULT” rules, add this one:

DEFAULT   Group-Name == "Parents"
     NS-User-Group = "majors"

What this rule does is that it checks if the user under OSX in open directory belongs to a group called “Parents” and if so it sends the NS-User-Group attribute with the value “majors” to the client, in this case our firewall. We’ll add another rule:

DEFAULT   Group-Name == "Children"
     NS-User-Group = "kids"

Note: I made the group names very different on the OSX Open Directory side (“Parents” and “Children”) and on the Radius client side (“majors” and “kids”) just to make it extra clear which group is which.

Set up authentication server on the SSG-5

Now we have to tell the SSG-5 how to find and talk to the Radius server. Log in on the SSG-5, go to “Configuration” – “Auth” – “Auth Servers” and click “New”.

Give the OSX Server a name, any name. It’s used to refer to this server when you create policies in the SSG-5 later. Enter the IP number, and select the “Auth” under “Account type”.

In the lower part, select “Radius” radio button, set the “RADIUS Port” to 1812, which is the default on the OSX FreeRadius server. Set the “RADIUS Accounting Port” to 1813, even though we don’t use accounting in this example. In the field “Shared Secret” you have to enter the same shared secret you entered while defining the SSG-5 client on the OSX Server using radiusconfig (see above). Leave the other fields unchanged and click “Save” at the bottom of the screen.

Add external groups to the SSG-5

We configured the OSX FreeRadius, via the DEFAULTS in the users file, to return groups “majors” and “kids” depending on who is logging on. Now we have to set up these groups on the SSG-5 as well. Go to “Objects” – “Users” – “External Groups” and click “New”.

In “Group Name”, write “majors”, then select the “Auth” checkbox for “Group Type”. Click the Ok button, then repeat the process for the “kids” group.

Now we do a policy

Now we finally arrive at the writing of policies that make use of the groups. In this example, I’m going to limit access to the dn.se site, Sweden’s largest newspaper, and I’ll only make it accessible to OSX users that belong to the “Parents” group on OSX. To do this, I’ll first have to make a policy that by default disallows everyone from accessing dn.se, then add a policy that allow members of the external group “majors” to access it anyway (remember that the OSX group “Parents” is translated to the group “majors” in the users file, so the external group is “majors” on the SSG-5). Let’s first do the policy that disallows all access to dn.se for everyone.

Go to “Policy” – “Policies”.

Select from “Trust” in upper left, to “Untrust” in upper right dropbox, then click “New”.

Use dig or nslookup from the command line to find the IP number for dn.se. As of the writing of this post, it was a single IP number: 62.119.189.4.

When the form opens, give the policy a reasonable name like “No DN”, leave the source address set to “Any”, but change the destination address to “62.119.189.4″ and put in “32″ in the mask field. The “Action” dropdown should be set to “Reject” and you can leave everything else as it was and click “Ok”.

Use the move tools in the policy list (far right) to move this policy to the top of the list. The policies are processed from top to bottom, so we want to make sure the rejection happens before any other policy may allow the connection.

Add another policy from “Trust” to “Untrust”, then fill it in as in the following screen:

Give it another name, in this case “Allow DN”. You can now select the destination address from the address book entry dropbox so you don’t have to type it in, it’s just a convenience since the SSG-5 now knows about this IP from the previous policy. The “Action” dropbox should now be set to “Permit”.

If this was all we did, we just simply nullified the previous policy, at least if we put this one above it in the policy list, and that would be pointless. Instead, click on the “Advanced” button at the bottom of the screen.

Now everything comes together. Enable “Authentication” by selecting that checkbox, then select “Auth Server” using the radio buttons. In the dropbox, select the auth server you created earlier, the MiniSL. Slightly to the right, you can select who is going to be authenticated and here you select “User Group”, then “External – majors”. If this selection isn’t available, check that you did define that external group as I described a bit earlier.

With all this done, save. In the list of policies, you should put this new policy at the top using the move tools in the last column so it ends up above the first policy we did that is set to reject connections to dn.se for everyone. The result should look like this:

Testing it all

If you started the Radius server through Server Admin, go there and stop it first. Log in to the OSX server and open a terminal shell. Start the Radius server in debug mode from here by:

sudo radiusd -X

This should get your Radius server running and you’ll see how it handles requests. Now go to a browser on any other machine on the local net and try to open dn.se. You should get a login dialog from the browser itself and if you provide a username and password from someone who is defined in the OSX Workgroup manager, is in the “Parents” group, then you should get access, else not.

I hope it works for you. If not, explore the raclient tool as well, since it’s very useful for finding configuration errors. Once it all works, stop the Radius server on the command line and go start it from Server Admin instead, so it runs as it normally would.

A little remark: if you change settings in the users file, you have to stop and start the Radius server again each time, else it won’t see the changes.

I’m planning to do a post on hunt groups as well, but I haven’t done them yet, so it could be a while.

Additional notes

You will find files with all the predefined attributes in the folder /usr/share/freeradius. Each type of equipment has its own file. The attribute names I used above come from the file “dictionary.netscreen”.

After a lot of soulsearching and getting up to speed on lightly managed L2 switches, I settled for two HP Procurve 1810G with 24 ports each. I’ll probably get another 1810G 8 port unit, too.

So, I put one in the office and the other in the back room. First and foremost, these little buggers are fan-free. No moving parts. Lifetime warranty, low power (8 W or so). The totally silent part was my absolutely major requirement.

This unit allows setting up using a browser and has trunking, VLANs, measurements and not least, monitoring ports. That is, I can hook into any other port and send that output through a selectable monitoring port. Ideal for sniffing on whatever port you desire.
Another totally unexpected boon was that I was able to read the entire manual and learn it all. This is the first time in maybe ten years I’ve ever been able to learn all the features of a non-trivial piece of equipment. And that feels so good.

Oh, and I discovered that OSX Snow Leopard, both server and client, has a super simple graphic UI for setting up virtual interfaces matching VLANs. All I need now is a router/firewall with a couple of connectors, a number of zones, and ability to match zones to interfaces and VLANs.

I’ll probably brag about this system some more once I get to know it better. But meanwhile, it’s the nicest computer purchasing experience I’ve ever had. Except for the Mac Pro. And the MacBook. And the iMac, of course. And the iPhone. And Apple TV.

The problem with the ReadyNAS is that even though you can power them down through their config pages using a browser, there is no way to switch them on again short of actually, physically, walking over there and pressing the blue button. There’s no wake-on-lan or any other similar provision. The only alternative is to have it power on and off according to a schedule, which is what I have done so far. But if you do that, that schedule will be unnecessarily liberal, just in case you need access to the units. I’m mainly using them for Retrospect backups and disk images when doing recovery, and very little else, so I don’t even use them every day. I calculated that the 16 hours a day these two boxes are running, costs me around 900 kWh per year. That’s around $150 in electricity per year. And it’s ecologically rude, too.

So, I got me a little unit from Control by Web. The unit is called WebRelay and you can get it in several different versions. The version I ordered has four outputs and is powered by 5V or PoE (hoping I’ll ever get a switch with PoE, that looked like a good idea). This thing actually has a built-in web server that let’s you configure and use it.

I also ordered a separate power supply from an unrelated brand, so I had to cut off the plug and just screw down the bare leads.

Now that I had the WebRelay powered up, I could configure it from a browser (see the downloadable user manual for details). It’s done using a little arp and a little browser work. That’s it. Very easy. The end result is that you can switch on, switch off, or pulse, any of the four outputs over the lan or the internet.

Time to modify the ReadyNAS boxes. Time to give you a straight warning, too.

I’m only describing what I did, not recommending you do the same. By opening up the box like this you definitely void any warranty you may have. You have a fair chance of destroying the unit, electrocuting yourself, and setting fire to your house. Your wife may divorce you for making burn holes in the curtains or setting the house on fire. Your dog may bite you. Your parents may disinherit you. So, don’t do it. Unless you know what you’re doing, and if so, you wouldn’t be reading this anyway, you’d just do it.

So, that being said, let’s prepare the unit for slaughter. First of all, make four labels for the discs. Strangely, the disc carriages have no identification on the front, so they’re easy to mix up when putting back and I can’t imagine that would do your RAID volumes much good.

This is what the discs should look like, properly labeled:

Now, put those aside in some safe spot.

Remove the four screws from the back panel on the ReadyNAS:

Take off both side panels. On the left side (seen from the back) you have to unplug the flatcable connector close to the top. (It connects the display to the motherboard.) Remove the four screws, including the one under the warranty label (you did read my disclaimer above, didn’t you?).

The right side also has four screws which you should remove while fending off any four-year-olds that try to stuff half-eaten apples into the unit:

Remove the four screws from the top panel:

And this is the access opening for adding RAM, by the way:

The back panel with the main connector and the big fan now comes off easily. Disconnect the fan feed at the bottom left in the picture and put the whole thing aside:

Next, disconnect the huge Molex power connector on the right side and slide out the power supply. Put it aside as well:

Just for kicks, behind the power supply, up agains the front panel, is a board with the LCD display on it (the unit is upside down in this shot):

Now, take out the seven screws that hold the SATA backplane in place. So far all the screws were of the same kind, but these are different, so keep track of which is which:

Now you can easily unplug the SATA backplane and slide it out:

Turning it over, you’ll see the SATA connectors:

Next, we’ll slide out the entire motherboard (the unit is face down in this shot):

And you’ll notice that the motherboard and the frontpanel LEDs and switches board are together on a single carrier of steel:

If you look carefully, you’ll see a little bit too many switches here. Netgear simply put in two switches behind each of the front panel buttons. If you line up the board with the front panel it becomes obvious:

Taking a peek into the box, you can see that the two frontpanel buttons (“backup” and “on/off”) are wide enough to press both their respective buttons at the same time:

Beeping out the wiring with a Fluke 77 (from the ’80s), it becomes clear that the switches are in parallel, as one would expect (a sight of relief, actually, since if there had been some other arrangement, I would have been up the proverbial creek here):

This makes a terrific amount of sense, actually. Not only will the front panel buttons be nicely balanced, but you have built-in redundancy that is bound to prolong the useful life of the unit considerably. I imagine those switches to be the weak point is the system, so having them doubled is great.

To beep out the traces, you need a multimeter with a beep function that won’t blow out your circuits if you misapply it. A regular ohmmeter may deceive you since it gives much too little load, and a battery and beeper may overload the circuits. On the Fluke, this is the setting:

Following the paths and confirming by beeping with the Fluke, we find that these two pins on the connector are connected together when pressing the on/off button:

You can see in the images that I took out the front panel board from the carrier, but you don’t need to do that at all. You can get at all the places as is.

Take a piece of wire and strip it out like in the picture. I chose microphone wire. It should have been a dual lead, each 0.2 mm2, but the store delivered a quad lead. No matter. I cut the extra two leads off very short as well as the screen. Add a bit of solder to the leads:

We need to tie down the cable to the board somehow and I chose to use the connector leads on the motherboard side for that. I wrapped a small tie around one of the legs. Don’t wrap it around multiple legs, since you may push them together if you pull too hard on the tie.

And then I tied down the cable: (don’t forget to trim down the tie)

Finally, solder down the two leads to the right pins on the connector (doesn’t matter which lead goes to which pin, it’s symmetrical):

Cut the cable to about this length, so it sticks out a bit beyond the end of the motherboard:

Now comes the time to the chassis connector. I chose a 3.5 mm stereo phone plug. Don’t use mono! None of the two leads we use should be connected to the chassis of the ReadyNAS, so we have to have a stereo plug and use only the tip and the distal ring.

Flipping it over we can identify the two tabs we need to use:

So, let’s strip the cable at this end. This time I cut the shield short, but saved the two unused leads as an anchor.

I’ll solder those to the tab that connects the chassis, that is the tab closest to the threaded cylinder to the right in the image above. That way, the cable is well anchored. Give a little extra slack to the other two leads, solder all of them carefully:

Slide the motherboard and front panel board on their carrier back into the case, while letting the cable with the chassis connector dangle on the outside:

Take care to place the cable to the side of the backplane connector. There’s no lack of space, really:

Then slide in the backplane and put back the seven screws that holds it to the chassis:

Slide in the power supply and connect the big white Molex:

Reconnect the LCD display cable to the motherboard (the unit is face down in this shot):

It’s time for drilling a hole in the backpanel for our connector. Find a drill bit that is just a tiny size larger than the threaded part of your chassis connector, then drill for king and country.

Except, think a bit first about the exact spot, so that you won’t conflict with components on the motherboard. Don’t rush into it, or you’ll end up with a back panel looking like a swiss cheese. After drilling, bring the back panel close enough so you can put in the new connector and don’t forget to reconnect the fan:

Anchor the connector with the threaded ring that comes with the connector, and tighten it well, but don’t go wild:

This is the right spot to drill that hole (I hope you read this far before starting to drill…):

Let’s make the external cable. Don’t make it too long, since it’s not impossible it will work as an antenna and bring in external electrical noise into the system. Make it just long enough and have the shield connected at the ReadyNAS end (see below):

Screw apart the plug and slide the housing over the cable (it’s so shameful to discover you forgot after soldering on the connector, but in this case you can get it on from the other end, of course):

Strip the cable, preserving the shield this time, but cutting off the two extra leads (if you have those) and make the remaining leads about this long:

It’s best if you have some kind of clamp to hold on to the plug while soldering, but sticking it into the chassis connector works if you don’t:

Solder the shield to the long, outer ring connection and the two active leads to the tip and middle ring, like so:

If you have teflon crimp tubing, you could have used that to protect the solder joints, but I don’t have any. Or can’t find it, at least.

For clarification, it’s the tip and the distal ring that are connected to the active leads and to the front panel switch:

The other end of the external cable should simply be stripped to the two active leads. Cut the other leads and the screen short. If you feel like it, solder the ends so they won’t fray (not a good idea for higher amperage leads like for house lighting, but quite ok for low voltage electronics):

And connect them to the first relay in the WebRelay unit. Note that you have to connect to the “C” (Common) terminal and to the “NO” (Normally Open) terminal. Not to the “NC” (Normally Closed) under any circumstances!. (If you do, you’ll have the same effect as if you pressed the power button on the ReadyNAS forever without ever letting go. Diagnostics… reset… etc, etc…)

Connect the WebRelay to the local net:

Follow the WebRelay user manual to give it an IP number, then configure it via the browser interface (read up on it yourself). Then finally, cross your fingers, click “Pulse” in the web interface (I set it to a 1.5 second pulse) and watch the ReadyNAS start…

…or blow up, or whatever. Mine started. Yihaa!!!

So now I can start this ReadyNAS from anywhere in the house, or even from anywhere on the internet if I open a port in the main router (which I didn’t). I can shut it down using the regular ReadyNAS web interface. I’m a very happy person and tomorrow I’ll do the other unit.

My first mouse has the model number ZC-100-00, while the two more recent ones have the number ZC-100-02. Internally, however, I see no difference, as you’ll notice.

This is how the oldest one looks before being disassembled:

So, let’s take it apart. On the bottom, there’s a felt mat loosely glued to a stiff piece of hard and transparent plastic. Insert a thin screwdriver between the stiff plastic and the case and carefully fold back, starting from the side away from the buttons, that is the side where the the label “Wacom” is on the mouse.

Don’t peel off the whole thing, and don’t bend it too sharply either, since you may want to put it back later. Peeling of 2-3 cm should be enough to get at the screw below it. Unscrew the screw.

There’s only this one screw so now you can easily open the case from this side and unhook it from the other side.

Now, admire the inside and take note of all the potential spare parts you see inside the top half.

The lower part is more interesting for our immediate purpose. Note from left to right: the scroll wheel in it’s optical encoder, the induction spool that picks up power and transmits information to the tablet (I assume), the ballast weight to make it feel more substantial, and below it all, the green circuit board.

There are five switches on this circuitboard. The two red switches are for the side buttons. Two other very similar switches, but entirely black, are to the left, one in each corner, and they are for the two regular mouse buttons. Finally, the scroll wheel rests on a different kind of switch for clicking, but it is hidden from view in this image. You’ll see it better later.

The circuit board isn’t fixed to the case in any way, but it cannot be removed yet, since both the ballast weight and the induction spool hold it down.

The scroll wheel, however, is just resting in a fork, so that is not a problem. (Please disregard the disgusting hairs and muck you see and which very likely explains why the optical encoder to the left had a problem as well). To the left you see the optical encoder, as I already pointed out, and to the right you see the switch the scroll wheel axle rests on, and that allows you to click the wheel. Oh, by the way, if you think the scroll wheel has too much resistance, you can see the metal notched shim next to the encoder to the left. That’s what you need to attack in your useable mouse. I don’t mind the resistance, so I didn’t touch it.

Now, remove the ballast.

The induction spool is resting over a plastic pin sticking up from the lower case and held in place by a rubber ring and some silicon glue.

Now, take care not to damage the leads from the spool to the circuitboard, while you lift off the rubber ring with your fingers. Quite easy to do. That silicon doesn’t do much.

Now you can lift off the circuitboard with scroll wheel and all.

And pull out the wheel from the encoder.

The side with the thicker part is the side that goes into the encoder. To the right and up in the next picture. Remember that.

So, which switch should I take? The two normal button switches, the black ones, are suspect in this mouse. I know the left one is bad and I don’t trust the right one, so I’m having my eye on the two red switches. I see absolutely no difference in these switches except the color, but you can feel a slightly higher resistance in the red ones, so I think that is the difference. Since I think there’s a certain logic in having my right mouse button being slightly stiffer, I go for a red switch to put in place of the right switch in the other defect mouse. This is the one I’m going to take:

…and put in the place of this black one in the other mouse:

To do that, I have to desolder the bad switch in mouse nb 2:

And the good, red switch from mouse nb 1:

Oh, just a by the way, this is a good view of the optical encoder and the left mouse button switch:

The next steps require a few tools. First, a good temperature regulated and narrow-tipped soldering iron so you won’t turn the board or switch into a pool of burnt plastic. I recommend a 30 year old Weller with Curie tips, in a kitchen environment:

Use a fine tip:

You also need either a tin suction tool with moderately worn teflon tip:

…or soldering wick:

Personally, I much prefer the suction tool. You also need something to hold the circuit board, but I mislaid my circuit board frame, so I have to hold on to the circuitboard with one finger, while burning the others. Don’t follow my example.

Heat and suck off the liquid tin on each pin of the switch to remove. This is how it looks after one has been liberated:

Carefully melting and removing the tin from the other pin, then carefully taking out the switch should leave the circuitboard intact. If you can’t do it without destroying this circuitboard, you’ll probably destroy the other one as well and end up with nothing, so take care.

The good switch after removal:

Now the turn comes to the other board where the right switch needs to be removed.

Turn it over

Heat and suck off (or wick off) the tin:

Carefully take out the bad switch. Check that the board is intact and no tin in the way for the new switch:

And check the bottom too:

Put in the new red switch. The orientation doesn’t matter as far as I can make out (there are only two ways to put it in and both work fine):

Check the top side and make sure the switch is flush with the surface of the circuit board:

Now we have three red switches and one black. Who cares.

Time to solder in the new switch. I’m using bad, bad, leadbased solder. To my defense, however, this roll is also 30 years old. And still almost full. The point I do want to make is that it should be thin. And with flux, of course.

Solder the switch into place, taking care not to cold solder and at the same time keep the amount of solder to just enough. This is how it should look after soldering:

Time to reassemble mouse nb 2. Clean out the bottom case first (I blew on it):

Put back the circuit board, taking care to thread the spool over the pin:

Put back the rubber ring with the silicon on the pin:

You may want to clean the scroll wheel if it’s grubby, then lift the circuit board a bit, stick the scroll wheel axis into the encoder, twisting it until it fits, then lower the circuit board back down:

Screw back the ballast into place:

The upper case has two slots:

…and the lower case has corresponding tabs:

…so fit these together first:

Then snap case together and put the screw back:

Now, press back the stiff plastic (with or without the textile mat, in my case without):

Pressing it hard usually makes it stick again:

So I’m left with the textile I took off the good mouse. (Note, the beginning of this story shows how to take off the bottom plastic without peeling off the textile, but my first try involved mouse nb 2, and there I first took off the textile, and only then the transparent plastic base sheet.)

So, now I have two fully functional Wacom mice. And a third non-functional that I’ll save for more spare parts. I’m sure I’ll need it.

The repaired mouse doesn’t have the textile mat underneath, and I glides considerably more easily. So, I don’t know which I prefer, actually. (To the left, the brand new replacement mouse I got.)

Once assembled, I compared the feeling of the repaired mouse to the brand new one, and yes, there is more resistance on the right mouse button compared to the left and to both buttons on the new mouse, so the red switch has a higher spring load. It may even possibly have a slightly longer stroke, but I’m not sure. But it feels just fine, I like it.

To see me test the repaired mouse in WoW, click the image. In the movie, I’m running using both mouse buttons and using the scroll wheel button. I’m changing direction using right button. Changing camera using left button and zooming using the scroll wheel. All work just fine.

Click image for quicktime movie

For other guides to the Wacom mouse, and other mice, checkout Repair4Mouse. If you’ve got your own guide to repair or disassembly of a mouse of some kind, that’s the place to leave a link to it as well.