I decided to go PoE to run a few of the phones.  So far only the 7970 is using it, as the switch I got is IEEE 802.3af PoE (because I didn’t feel like selling the motorbike so that I could afford a Cisco switch to run the older Cisco phones).  Not one to let mere electronics stand in the way of me running the Cisco pre-standard phones on 802.3af, I set about with crimp-tool and soldering iron to try and make it work.

It’s probably fair to say that success has been limited.

The problem arises because Cisco implemented a PoE mechanism prior to the IEEE 802.3af standard being ratified.  This method, not surprisingly, is completely incompatible with IEEE 802.3af.  It’s generally referred to as “Cisco pre-standard PoE” — Cisco gear that does PoE usually supports both their pre-standard and IEEE 802.3af.

(When I come across something like this I wonder if a lot of the cost of Cisco gear is soaked up by the added complexity of having to support both the “system they designed and rushed into the market to try and preempt the standards process” as well as the “system the industry agreed on and ratified because the right way is not always the Cisco way”.  But I digress.)

Thanks to some information like this, I found out how an 802.3af-compliant switch senses that it should supply power to the wire.  It’s quite simple: the switch looks for a “signature resistor” across the cable (follow the linky-trail for more info).  This meant it was quite easy to convince my switch that it should apply voltage.  (Susan was a little disturbed by how excited I got about making a little green light come on.)

Actually getting power into the phone is a different matter.  The page I link to above has about five different versions of fact and fiction when it comes to running the Cisco phones off 802.3af PoE gear, but it misses out on one critical piece of information (or at least it will until I get an ID there and update it).

The IEEE 802.3af standard defines the partners in a PoE transaction as the Power Source Equipment (PSE) and the Powered Device (PD).  The PSE can be either a 802.3af-compliant switch, or some kind of intervening device like a PoE midspan or injector.  The standard also defines two “modes” of PoE: Type A, where the power is supplied over the same cable pairs as the Ethernet signal; and Type B, where the power is supplied over the spare pairs in the cable.

The voip-info.org page says that with a resistor and a crossover-wired cable, you can  run a pre-standard Cisco device off an 802.3af PSE.  This is only partly true, because of a very important little piece of info that’s only alluded to on the page.  The critical info is this: while an 802.3af PD should be able to work on either Type A or Type B (as you don’t know what kind of PoE source you’re going to be connected to), a PSE can be Type A or Type B.  This is particularly important when it comes to the pre-standard Cisco phones, as they can only work as a Type B-style device — the Cisco pre-standard had no way to receive power over the data pairs.

This is why folks have success running Cisco phones off midspans and injectors — because they are 802.3af Type B devices.  Type B is used when you are injecting power along the cable run (i.e. without access to the Ethernet PHY).  They then crow on about how they got their Cisco phone working with 802.3af — as always, the devil is in the detail.  In the case of trying to run Cisco phones off 802.3af Type A devices like switches, you are left with the problem of extracting the 48V out of the data pairs without breaking the Ethernet link to the end device.  Not simple.

The page above lists one switch that appears to work with the crossover-cable trick: the Netgear FS726TP.  Knowing what I know about 802.3af now, it would seem that Netgear decided to make their switch a Type B PSE instead of a Type A.  Is it wrong?  Well no, but some folk may be surprised why they don’t get power over some cables when a different switch works fine.

The good thing about the Cisco pre-standard (if there can be a good side to it) is that it should be quite easy to rig up a DIY injector using the original power supply.  Since the phone expects power over the spare pairs, there’s no need to use an adaptor to split the cable out again at the phone end.  A DIY midspan using a single 48V PSU would reduce the losses in running a number of separate power bricks too.

So if there are budding Cisco PoE hackers out there, be aware of the need to know a little bit more about your 802.3af switch than what the manufacturer says on the glossy brochure.

PS: While researching this, I came across a forum comment from someone who said that one of their pet hates was people referring to “Power over Ethernet” when it should be “Power over Cat5″.  Well, one of my pet hates is over-generalisation.  There can be no argument that the way that power is delivered in PoE is specific to the Ethernet wiring of Cat5-style cable.  Power over Token-Ring, if such a thing existed, could not be the same as PoE because different pairs of wires are used.  Likewise Power over ISDN U-Bus, Power over POTS, whatever.  My advice to Mr “Power over Cat5″: keep your generalisations to yourself, if you please!

I re-read my post about the iPod touch and realised I probably wasn’t very balanced in the way I discussed it, particularly in light of the fact that I specifically said it wasn’t going to be a ra-ra post.  Maybe I’ve had a cooling-off period.  :)  So, here goes with some of the negatives I can see…

It doesn’t have a radio, and doesn’t (as far as I know) have sound recording capability — these are a couple of features that many folks find important in a portable audio device.  Also, just because I was out of touch with my original estimate of the price, doesn’t mean that it isn’t overpriced.

16GB of storage, while impressive in some ways, is miniscule for what could be considered, thanks to the size of its screen, Apple’s flagship portable video display device.  A decent amount of storage, such as those now offered on the iPod classic, is going to be needed for a lot of people to take this seriously in comparison to something like a Creative Zen Vision or Archos unit.

Some might say the biggest criticism is the fact that, like the iPhone, there’s limited potential for third-party expansion.  Apple is a visionary company, but they can’t think of everything in advance and to not allow (or make it hard for) third-party applications to be delivered on these devices shows a distinct lack-of-vision.

Maybe I have cooled off on it, but I’m a little less keen on shelling out an AU$549 lump of money now.  Maybe Apple’s early announcement was a bad thing — they might have got a lot of impulse buyers just drop the money on it and then see the negatives, instead of (like me) having some time to think about it before being able to spend the dough.  Not that I think the iPod touch will be a failure, but given the US$200 price drop on the iPhone within six months of release I think I’ll hang onto the trusty-old third gen iPod a bit longer.

Here at the Crossed Wires Campus I’ve had LDAP at the centre of most of what the network does for quite some time now.  User-id management, telephone directory (integrated into the phone system), automount maps, Samba domain database; I even had DHCP running with LDAP as a backend for a while.  Most boxes in the house touch LDAP in some way every time they boot.  To demonstrate the multi-platform portability of that kind of configuration, I even had the Macs in the house able to log on user-ids that existed only in LDAP.  Until recently.

I don’t know the details of it, because it was something I only did occasionally to show that it still worked.  Now it’s stopped working, presumably after a Mac OS X update or other.  When I try and log on with an LDAP user, I get the wobbling password box.  That’s it.  The system logs tell little on the Mac, but on the LDAP server I get an error message about a failed SASL bind.

I’ve only ever set up SASL enough to support IMAPd, and even then it’s just talking to LDAP to do the work.  I use LDAP to store passwords, and for my purposes that’s always worked.  It used to work on the Mac too, but I can’t get him to stop trying to do a SASL bind to LDAP.

At about the same time as this, I was playing with a Jabber bot.  I read the instructions, configured appropriately, and it completely failed to function — its logon to the Jabber server was rejected.  Wireshark to the rescue — it was trying to use SASL to log on the the Jabber server.  Sure enough, my Jabber server was advertising SASL authmechs.  I removed the SASL settings (well, just the available authmechs) and the bot was able to log on.

So I started thinking if these issues were the kick I needed to set up a proper SASL and Kerberos system.  My ideal would be to get saslauthd to provide authentication service without having to go all the way to GSSAPI/Kerberos, something that should be possible…  except we’re talking about security systems here, so it seems that “The Right Way” is the only way.

The OpenLDAP documentation doesn’t discuss the SASL mechs PLAIN and LOGIN, since in their opinion they’re no different from LDAP simple bind.  Be that as it may, it would be nice to know how to do it!

DIGEST-MD5 is next, but the way it works you have to store user passwords in clear-text in LDAP (yes, clear-text passwords!) or use SASLDB2 to store passwords.  The former is unattractive, since I’m not so confident in getting an LDAP ACL right that would protect the password field from undesirable reading while still allowing it to be used, and the latter means I’d have to move everything to SASL auth unless I want to have password synchronisation problems (the very thing that moving everything into LDAP was meant to avoid).

Next comes Kerberos…  If I’m doing a heap of work to cut things to the DIGEST-MD5 SASL mech, might as well go all the way to GSSAPI, right?  That means more work, and again possible password sync issues between the Kerberos DB and those things still getting their passy from LDAP (although it looks as though using SASL you can tell OpenLDAP to consult Kerberos for password validation, so things using LDAP for password checking would actually get handled by Kerberos anyway).

One thing I thought to try was to rebuild OpenLDAP without SASL support — I’ve got a nasty feeling that since the last time the LDAP login worked on the Mac, I added “sasl” to the USE flags on the server.  Being built with SASL support means that slapd is offering it, even if it’s not set up (an ldapsearch for supportedSASLmechs verified this), and the Mac is seeing SASL auth advertised by the LDAP server and demanding to use it…  While a good theory, it’s not the problem.  The only difference in the log now is that there’s no message complaining about a failed SASL connection.

So after all that waffle about SASL, it looks like there’s something else happening. Likely something to do with the strange posixGroup entries it’s looking for called “ffffeeee-dddd-cccc-bbbb-aaaa-0000003c” and so on…

Back to the drawing board.