...

I want the lurkers to speak up.

I'm an inveterate lurker ... I have never been to a meeting as, generally, they are too far away .. I'm a lurker (well for a while), but mainly can't make meetings ...

Me too. But once spoken up, we've broken cover and are no longer lurkers. However, we must occasionally pop up to thank the active people for all their advice and comments. I've been lurking here (and in many other places) for a few years and it's all been very useful even if am often forced by other pressures to skim or delete the digests I get. This list is very useful to me and, I am sure, to many of the other 200 inactive subscribers. Please keep it going and when we can we'll contribute.

A minor reason I lurk is that we are here entirely FreeBSD based. Not Linux, but the same in most respects. Another is that I feel too busy (I know that applies to everyone). A third is that I am on the southern fringe of your geographical area.

Anyway, I post now because I have just made what I feel is a critical, though non-Linux, discovery: see last half of message.

Send out an annual resubscribe to non-posters, with two monthly reminders before removal?

Too much effort, unless the copies are costing you money.

One or two may be lost, but are they benefitting anyway?

Yes, most of us lurkers are benefitting.

Don't want to accidentaly unsubscribe people if we can help it.

Good.

My thanks to Brett and Adam on this one. I don't care what the group calls itself if I can get such instant, high-quality advice at a moment's notice.

Hear, hear.

It's a hard life for a bear of little brain.

Exactly.

================= here's the meat =================

Discovery:

I don't know how many of you run a network of machines. Five, ten, fifty or the five hundred we have here? Well, we have things called hubs, and things called switches, and things called routers (which are based on FreeBSD boxes with multiple interfaces). Some of our switches are intelligent or managed, but we don't manage them, being half a dozen makes (whichever was cheapest at the time) it's difficult keeping track of all the different management methods, and anyway most of that sort came with CDs that don't run on FreeBSD so they sit on the shelf.

Anyway, consider our switches. Each has one incoming port, maybe seven or fifteen or twenty-three outgoing ones. Feeding rows of RJ45 outlets through miles of Cat-5 cabling. These feed client machines through drop leads. The RJ-45 outlets are often arranged in pairs, as a pair fits nicely in a single-outlet box.

You have the picture? Fairly common, I think.

It all works very well. Very much more resistant to lightning than our Econet system was (we still run Econet, BTW). Doesn't work when the mains power is off, common in this country environment (indeed, we've had eleven power cuts in eleven months) and there's also trip switches that go off from time to time. But that's not the problem. The system works well on a 24/365 basis.

But - there's a problem. Suppose you see a drop lead hanging from an outlet cos the user has gone off with his or her portable, isn't it nice and tidy to plug the free end into the adjacent outlet?

It is, and it generally causes no trouble.

But they now make better switches. Remember the old ones - you press the little button for the input lead, cos to connect two of these hubs or switches together you need a reversed lead or a reversed port? The new ones have auto MDX/MDIX on them, so you don't need reversed leads any more. Just plug them together with straight leads, and they'll work. Very convenient, although in practice you rarely needed reversed leads anyway.

So - have you tried shorting any two outlets together, as in the "tidy-the-lead" scenario above?

No?

Try it.

If your network has no broadcasts on it, you may be OK.

But if there's a broadcast, it'll go out one port and in the other, then out again, and again, and again.

This broadcast storm will feed its way up your network till it all comes to a glutinous halt, until blocked by am intelligent switch or router.

We've had a few of these halts. We eliminated the switch responsible. But we've now determined that there was nothing wrong with the switch. It was just too intelligent, in that it had auto MDX/MDIX. But not intelligent enough, in that it caused broadcast storms if two ports were shorted.

We never had the problem before (that is, before 13 months ago), because with the older switches you needed a crossover lead to do the damage.

With the newer ones, all you need is a normal drop lead and a yen for tidiness.

===== well, that's the discovery. Now for the rant =========

The entire Base-T Cat-5 RJ45 system is powerful, flexible and convenient.

But how could they possibly have designed it so that it can be brought down so easily by any tidy end-user?

============= OK, OK =======================================

I know we can sort it out in various ways. I am told that configuring DEVICE_POLLING in the kernels will protect our routers and servers by polling the network cards instead of allowing them to interrupt. But my immediate reaction is to source simpler switches, those without auto-MDX/MDIX. Unfortunately, these are becoming rare beasts now.

And to ask you who else has come across the danger to corporate networks posed by the convenience of auto-crossover ports.