Friday, 28 December 2007

The eircom Master Socket

Have you ever wondered what lurks inside the master telephone socket that eircom provide?  Surprisingly little, as it turns out.  Here is a photo of the insides of one of them:-

Photograph of the inside of an eircom master socket

(click on the photo above for a bigger version) 

The circuit diagram of the master socket is:-

Circuit diagram of the eircom master socket

There are two sets of three connectors.  The connectors are labelled L1, L2 and R.  Each connector is directly connected to its counterpart on the other side via a breakable link on the circuit board.  The breakable links are tracks on the circuit board which run between pairs of oblong holes (visible in the photo above on the far right-hand side).  I think the idea is that two lines could be delivered via the same socket by breaking these links (although I have never seen or heard of this being done).  The (two-wire) eircom line is connected to L1 and L2.  L1 from the left-hand side connects directly to pin 6 on the RJ11 socket and via the breakable link to pin 4 in the RJ11 socket.  Similarly, L2 from the left-hand side connects directly to pin 1 on the RJ11 socket and via another breakable link to ping 3 in the RJ11 socket.  Since pretty much all modern telephones only connect to pins 3 and 4 of the RJ11 socket, this is really all you need.  For historical reasons, there is a 1.8uF capacitor connecting L1 on the left-hand side to the R pin on the left-hand side.  This is connected to pin 2 directly (and pin 5 via another breakable link) on the RJ11 socket.  This provides a separate ringing signal for (old) phones that need it.

Apart from the capacitor, the only other component on the circuit board is a 470K resistor.  Between R and L2.  This (in series with the capacitor) provides a load which eircom can use to test the line remotely when there is nothing else connected (even at a few tens of Hertz, the impedance of the resistor will dominate that of the capacitor).

 I had expected to find some sort of surge arrestor or something like that in there but there isn't one (the equivalent BT master socket has a surge arrestor, but is otherwise identical internally - although obviously the socket is physically different).

 Practically speaking, you can ignore the R pin completely...I think pretty much all modern telephones will derive their own ringing signal from the line and don't rely on it being delivered separately from the master socket.  So the only significant connections in the master socket are these:-

Essential connections in the eircom master socket

The idea is that the eircom line will connect to L1 and L2 on the left-hand side (I think these are labelled S1 and S2 in newer sockets) and you will connect your own internal wiring to L1 and L2 on the right-hand side.  Then, in the event of a fault, it is easy to isolate your internal wiring from the bit eircom are responsible for (thus avoiding a costly call-out charge if you haul out and eircom engineer to a fault which turns out to be with your internal wiring !). 

There are stories told of old modems which require you to snip everything except pings 3 and 4.  I have only come across it twice in my long and distinguished career fiddling with such things.  I can't claim to have a clear understanding of exactly why this is (sometimes) necessary...I have been offered several conflicting explanations.  I think it is to do with some (cheap and nasty) modems shorting some pins together internally.  If anyone would care to volunteer an explanation I will update this article accordingly.

Thursday, 20 December 2007

The source of all network and security problems finally identified!!!

[This post is a slight departure from my stated policy of trying not to increase the average level of inane wittering on the Internet any further by keeping my opinions to myself in this blog, but this particular insight is just too penetrating not to share it with the world. Like all of my opinions, it is - of course - entirely correct ;-) ]

I have had an epiphany. I now know what causes pretty much all network problems: GUIs. At first blush, this may sound like a slightly sweeping statement but I have come to believe in it very deeply. Stick with me here and I will explain why.

Take today for example: Myself and one of my esteemed colleagues squandered an hour of our lives dealing with a guy in a secondary school where we support the Internet router. His Internet access was broken. I'll spare you the long and painful details of the hour...suffice it to say that by the end of it we determined that there was a server sitting between his 140 snotty, insolent teenagers and our router. It took a startlingly large fraction of that hour to glean from this barely-adequate specimen of humanity that this server even existed. We also figured out that - somehow - the server was at the core of the problem. After a conversation reminiscent of having teeth pulled, our hero volunteered that - infact - there had been a change to the server that morning: he had uninstalled Microsoft ISA server off it !! Somehow - and it completely eludes me how anyone can be quite this gormless - it never entered his head that perhaps uninstalling the proxy/firewall software off the server separating the hormonal masses from the Internet router might be somehow related to his current predicament (140 horny teenagers separated from their porn supply and becoming increasingly antsy about it).

So, how do I extrapolate from this to my theory about GUIs being the root of all evil ? Well, if that server had been a Linux server, there is no way on earth that this guy would have taken it upon himself to touch it. The slightly arcane (yes...I admit it) Linux command-line has a way of scaring off people like this who really need most of their brain power just so they remember to breathe regularly and are taking huge risks by trying to apply their limited stock of intelligence to anything else. In short, command-lines have a way of making things appear a little harder to do than they actually are and therefore act as a built-in safety-net, preventing "special" people from trying to do things they are simply not equipped to do. GUIs, have exactly the opposite effect: they allow the dimmest of knuckle-dragging troglodytes to poke and prod at things they don't really understand until eventually they manage to break it.

I formulated a more limited form of this theory some years ago when I formed the opinion that Checkpoint Firewall-1 was the source of all security problems on the Internet. When I first started working in the field of data security I could never really understand how hackers seemed to be able to waltz past the best of access lists and firewalls as if they weren't there. How could it be that the hackers were all so clever and the developers of firewalls were all apparently dribbling idiots ? Then, one day, I was on-site with a large multinational customer watching the guys in there trying to get an application working through a Checkpoint firewall. So, they fired up Checkpoint's very lovely GUI and they added the rule they thought should do the trick. It didn't, so the relaxed the rule a little further. It still didn't, so they relaxed it a little further again, and so the cycle continued through several iterations until eventually the application did work and the "firewall" was reduced to the functional equivalent of a piece of wire. At that moment I understood for the first time that security holes were rarely caused by weaknesses in firewalls and far more often caused by mental deficiencies in those charged with configuring them. I also understood that the GUI was at fault: Checkpoint's (lovely) GUI makes it very easy to set up rules without the bothersome inconvenience of having to have the remotest understanding of what the hell you are doing. If they had a PIX rather than a Checkpoint (these were the halcyon days before PIX Device Manager, when all was right with the world), this would not have happened. The only thing I didn't grasp at the time was exactly how generally-applicable the GUI theory was.