Another interesting bug

Superb!

Brilliant story. It could well be true.

It reminds me of the story I once read about a man whose car always failed to start if he stopped to buy raspberry ripple ice cream on the way home, but which never had a problem if he bought mint choc chip instead. The engineer in the garage puzzled over this for ages, and eventually found that if the engine was turned off more than two minutes and then turned back on, it failed to fire; if it was off for less than this time, it restarted OK. The fix was fairly trivial. But why did it depend on what ice cream the owner bought? You've guessed it. The shop always had mint-choc chip ready to serve, whereas they often had to start a new container of raspberry ripple which took slightly longer. There was the explanation.

The weirdest one that I ever encountered was why the screen saver on our Sun workstations would always return to the desktop when anyone walked past the workstation, but would remain on screensaver for ever if no-one walked near. It turned out that the screensaver was triggered to return to desktop if any mouse movement was detected. This was the Sun mice that used a special reflective mouse mat with different colours for the horizontal and vertical lines. The mouse was so sensitive that someone walking across the floor would jiggle the mouse on its mat just enough to register as "usage" and so it would come out of screensaver mode.

In a spooky coincidence, this was posted today:

I remember in the mid 1980s when I started work, LANs used thick Ethernet - cable that was so thick that it was like wrestling a snake - and the cable was marked with gradations ever few centimetres which were the null (or maybe maximum) points of the electrical signal, relative to the start of the cable where you got reflections off the terminators, and these were the places where you should insert a "vampire tap" to connect a transceiver box which in turn was connected to the LAN card in the computer by wrestling-with-snake cable. I'm not sure why thin Ethernet (50 ohm cox with BNC T-pieces) didn't have the same minima/maxima constraints on the placement of T pieces. Oh the "joys" of someone "breaking the LAN", taking off a terminator, or even unplugging a T piece from a computer was sometimes enough to break the LAN for everyone. But the biggest embuggerance was someone who accidentally gave a computer the same IP address as one that was already in use, in the days before DHCP when a router allocates addresses itself and will not allow IP clashes.

Other unfeasibly rigid cables were the "donkey wallopers" that were 8 or

Or in the uni. dept. where someone connected up a laptop with a dhcp server configured and listening and handing out IP's for a completely different subnet!

We had one where one particular users mouse would only allow side to side movement but not up and down. However it only happed for a short period each morning, then went back to normal.

In the end we realised it did not work when it was in bright sunshine - and the lab we were in was tucked into some old workshop space with very high windows that let bright beams of sunlight in - but they tracked across the desks fairly quickly. The light was swamping the (optical IR presumably) sensor on the encoder wheel of the (mechanical) mouse.

To fix it, we "coloured in" the inside of the mouse's case with a black board marker, and it was ok after that!

Fathead physicists at SLAC did this too. The thinnet to their offices was already at the maximum length, but they wanted to extend it to the experimental area. In their equipment racks, they use, yes, 50ohm coax, but it's very thin since they normally use it as patch cable between equipment typically in an ajacent rack. But again yes, they'd heard that ethernet was

They also didn't like that the thinnet came into, and out of, their offices, with a T piece right at the computer. No, they pulled the cable so the T piece was outside the office and used a section of their own VeryThinNet to connect the T piece into the back of their desktop.

The dragon-lady running the Operations Group had their arses for that.

Been there. Done that. Where I used to work, our project was to generate servers that were fully configured for our customer sites. And that meant configuring the server as a DHCP server - for some reason they want a computer rather than a router to do the DHCP. And customer IPs were always (for some reason) in the 10.0.x.y subnet rather than

I wasn't the first to do it and I'm sure I wasn't the last.

I did actually manage to kill the LAN another way. The product I was working on was a way of restoring a PC back to a factory state as fast as possible. This involved using Norton Ghost to copy from a disk image on the server. What I didn't know was that Ghost was designed to work flat-out, so it flooded the LAN with so much traffic that nothing else could get a look-in. I was instrumental in getting Norton to modify Ghost to add a throttling option, to say "only use x Mb/sec of bandwidth", so I could build that option into my product. Better if it takes a bit longer to restore a PC, if it doesn't saturate the LAN and make it unusable for everyone else.

I'd forgotten the delights of the maximum cable length of IIRC 185 metres. Our office was a development department, so we were used to making our own private LANs just used for the team. But we also had a company LAN used for access to email, company servers and The Big Wide World (aka the internet). If we needed to add an extra PC or server to the private LAN (ie insert an extra T piece) it was just a case of warning everyone "OK if I break the LAN for a moment?". Then we would take a BNC off the company LAN by mistake.

Structured cabling, where every computer has its own cable back to the router, switch or hub, made life a LOT easier and less error prone.

I remember the joys of the "human DHCP server" - one person per floor who was designated to hand out IP addresses from a pool every time a new computer needed it, so the PC could be configured with that static IP. DHCP was fantastic when that was introduced. For some reason, all our public LAN PCs were given public addresses, and not private ones in one of the well-known ranges such as 10.x.x.x, 172.x.x.x or 192.x.x.x - there was no NAT. What was done about firewalls was anyone's guess! I suppose it was like IPv6 where all addresses are public and there is no NAT. I've never understood why IPv6 wasn't defined to use a 192 address (maybe 2 bytes for PC address rather than the normal 1 byte) and NAT, but then using a longer IP just for the WAN address since that it what the world is running out of.

Every company has a plentiful supply of Dragon Ladies, probably sourced from an agency Dragons-R-Us ;-)

I think we sometimes extended a T connection with a bit of cable, rather than having the T piece connected directly to the LAN card. I don't remember the sky falling in. Maybe we were lucky and our LAN wasn't too borderline with its compliance to other standards, so we got away with it.

One of the original ethernet designers one opined that the ethenet spec is like a sausage: you can squeeze it here a bit, but too much and it may pop out there. Stay within spec and you should be OK. Step outside and the effects may not be noticeable, or it may fail unpredictably.

Oh yes. We had a server at one end and a PC at the other- no talkee. Put the server in the middle and all OK. No requirements for a PC at one end to talk to a PC at the other @:-)

Then it got silly so we bought a bridge. Then we moved offices and had to rewire so in went CAT 1 or whatever it was and switches....

...and 90% of my time fixing ethernet ceased.

More a hardware issue but I recall on a particular rail project some years ago, a make of relay that had been fine previously was suddenly giving great problems - they appeared to be physically closing the contacts, but not passing current.

After much head scratching the story emerged that the supplier's moulds were wearing, but they didn't have time to replace them and meet our large order schedule. Instead, to get the plastic components down to size, they had been linished. After assembly and test they were then individually bagged and shipped, and we duly built them into our kit, tested as OK and delivered the finished equipment.

Apparently, the dust from linishing, trapped in the plastic bag, formed a thin film over the contacts, and once they had opened under load a few times (this was a 110 V dc system) the arcing was sufficient to fuse a little of the material into an insulating layer. Routine testing alone was sadly insufficient to trigger this.

The simple solution was the service engineer's thumb, which was sufficiently abrasive to clean the contacts without damaging the material.

Chris

When commissioning a new set of rolling stock (Class 314) we came a cross an odd behaviour.

When the driver took power, a fault relay dropped its flag, and the fault light came on bright, and slowly dimmed. As this was a

The fault relay and lamp were fed via a reed relay in the electronics rack, down in the main equipment case under the vehicle. It was physically on the centreline of a large air-cored inductor, which was part of the traction power circuit.

The triggering circuit for the reed relay for some reason had some low volts across the coil even when it was not required to operate. Its magnetic screening was not the best.

The traction power system used thyristors with phase angle control to provide variable dc voltage to the traction motors.

On taking power, the reed relay was affected by the fluctuating magnetic field, and managed to switch at 100 Hz, following the mark-space ratio of the power current. This was observed as the fault light starting bright, and dimming as the phase advanced.

Chris

RFC 2322. "Management of IP numbers by peg-dhcp"

We even had an article about us in the Wall Street Journal

We had an early office network which kept having intermittent cable faults which brought everybody's work to a stop. The IT department gave us no support at all, and our most sophisticated piece of fault-finding equipment was a GBP5 multi-meter from my car boot.

I badgered IT to get some proper kit, but no joy.

Eventually I wrote a proposal for our department to buy a GBP1000 hand-held tester, showing that it would pay back its cost in the first 15 minutes of network inactivity.

Money well spent, and fault easily found and cured.

Chris

I was glad when I ordered a DEMPR so that the various "corners" of the office could only break their little corner ... the netware couldn't break the VAXen etc ...

My favourite quote from that "But if you put beer in front of the geeks, they will come" :-)

I used to have conversations like that with one client... one of their offices (the original one that sort of grew rather than actually being planned or designed) had network infrastructure strewn all over the place - cables draped behind desks, small network switches sat under desks on the floor, router sat on a filing cabinet etc.

I had suggested it could do with a proper data cabinet, and something closer to a structured wiring system. They did not want to spend anything on it at first. Then I added up the cost of all the recent support incidents where they were losing hours of business, no to mention also paying us hours of consultancy time to fix daft network related incidents like "half the office can't print", or "those PCs cant see the file sever", "those phones don't work", or "my machine won't talk to the internet" etc.

Got the order for a partial rewire and data cabinet install shortly after!