I worked at 3Com in the mid 1980's. We had a smart guy (Stanford grad) working in manufacturing that was doing numerical analysis on failure rates and product returns. His analysis showed that the 3c50x PC Ethernet cards almost never failed and built a case for offering a lifetime warranty. He calculated that it would cost the company almost nothing to offer the warranty.
They were high-quality cards and the lifetime warranty proved to be very popular.
That’s interesting, thank you for they tidbit! Do you have any other stories? Personally I loved the pcmcia cards but mostly because drivers were included from 98se, so in the early 00’s my first job at a of repair shop that was an easy way to get a computer online/networked.
Outside that, I think I missed everything though I have memories of another company that merged into 3x in, xircom? Before they were acquired again.
Lifetime warranties are sort of a scam, mainly because they mean different things to each side of the transaction or perhaps even nothing. The customer thinks "my lifetime". The manufacturer, if honest thinks "the lifetime of us manufacturing the product", if dishonest "the lifetime of the product, when it breaks the warranty is over"
Does the manufacturer have to define what "lifetime" means? Perhaps buried in the small print somewhere.
Lifetime is defined in US law. Most people don't know what the law says. I don't, And I can't be bothered to look it up. But there is a definition in US law.
HP themselves sold Aruba networking equipment with lifetime warranties and then just decided they wouldn’t honor it anymore. So a warranty change after a company acquisition sounds even more plausible in comparison.
I guess they decided no one would take them to court, and if someone did they'd just refund the value of the item (which presumably is low these days).
Which would imply such lifetime guarantee promises are worth very little.
ep0: 3c509 in test mode. Erase pencil mark! This means that someone has
scribbled with pencil in the test area on the card. Erase the pencil
mark and reboot. (This is not a joke).
It is the user’s responsibility (with help from the configuration program) to avoid configuring the boot PROM on the adapter in such a way that the system is not able to boot. If this does occur, you can manually jump the Test Via using a #2 pencil. The Test Via forces the adapter into test mode, which disables the boot PROM so that the adapter configuration program can be run. You must cover the designated area thoroughly with the pencil mark.
Test mode forces the adapter not to perform the Automatic Initialization sequence, which means the EEPROM is not read and the adapter is left in the following configuration:
■ Address Configuration register = 0000h
■ Resource Configuration register = 0000h
■ Product ID register = 0000h
Test mode also shortens the ID sequence to 8 bytes (first is still FFh and last is 69h) and forces it to the active state (that is, the adapter is active and will respond to I/O cycles at base address 0200h even without going through the ID sequence).
After you are done, thoroughly erase the pencil mark.
Wow, there's something so admirable about such a well-thought design that they even considered trusting their customers to be smart enough to be able to help themselves out of being in a pickle.
I have a very personal connection with 3com, though it was in the late 90s.
Ron Crane which was 3com's 4th employee and designed the 3C100, 3com's first ethernet product. Many years later he hired me for my first real job of out school and brought me to the bay area. I then got to work side by side with him and David Boggs (https://en.wikipedia.org/wiki/David_Boggs). At the time I never realized how special working with these two were...wasn't every company in the bay area like this?
I stayed in tough with Ron Crane until his death in 2017. He was both brilliant and incredibly sweet. He was so proud to take me behind the scenes at the Computer History Museum to show some work he'd been going.
One day, Ron (a hardware engineer from Xerox) gave a talk about the theoretical performance of an Ethernet file transfer. He calculated the end-to-end latency and data-rate including disk latency, network latency, the number of clock cycles necessary to send and receive the data, etc.
He had (overhead projector) slides that showed all his assumptions and calculations.
Finally he displayed a slide with a graph showing this theoretical maximum, the actual performance of the 3Com network stack, and (IIRC) the Novell stack. As I recall, actual performance was about an order-of-magnitude lower than the theoretical max.
His point wasn't that our software division should be able to achieve the theoretical max. It was that if we (for example) got halfway there, we would know that Novell would never ship software that was twice as fast as ours.
He was very nice and scholarly about it and did not mean offense. I and many others weren't offended. But a surprising number of people were.
The Computer History Museum has a nice two-part oral history of Bob Metcalf (3Com founder and co-inventor of Ethernet) back in 2006: https://youtube.com/watch?v=zKz07DdaKzw
Metcalfe has a reputation for being brash and outspoken and it clearly shows in the interview. I think it served him well in business and later in life as a pundit. I remember looking forward to his columns in InfoWorld, though I didn't necessarily give much stock to his predictions.
He talks a little bit about the downfall of 3Com in the interview, though he begs-off of talking about things that happened there after he left.
I very much enjoyed the trivia and minutiae about the creation of Ethernet and the Digital / Intel / Xerox relationship that ultimately resulted in it being standardized.
Basically, it was a long listen but there was some good stuff in there.
It was great to work with Metcalfe. I have two funny stories to share.
I was on the Macintosh network os client team. For whatever reason (maybe he was annoyed that Apple copied so much from Xerox) Metcalfe didn't like Macs. In this era Macs used Apple's proprietary AppleTalk/LocalTalk network. We did a demo for 3Com execs using a large external monitor connected via a single black coax cable that looked just like thin-ethernet. He got excited for a moment and came right over to look at the Mac and was very disappointed to see the cable attached to a display! (3Com was working on Ethernet cards for Mac at the time but they weren't ready at the time of this demo.)
For those too young to remember: there was an SF Bay Area baseball park known as Candlestick Park that was briefly branded "3Com Park" -- to the great annoyance of SF Giants fans. During one interview he as asked if in the early days of 3Com he would have done anything differently. He said, "I would have named the company 'Candlestick'!"
I remember those days, with Computer Currents' "Year of the LAN" parody predictions repeated year after year. Macs with PhoneNET definitely made it easier and cheaper in the beginning.
Do you remember which switch models it did happen to you?
I remember that SuperStack 2700 ethernet switches with ATM LEC (lan emulation client) card it did happen under prolonged heavy load heat accumulated with then caused sudden reboots. Occasionally these events switch was as factory reset was done, none of configuration made was left.
First with ATM LANE with ethernet STP (802.3D) was flimsy and buggy, so it took a while when that was fixed without STP spurious loops broadcast storms did quite easily overload edge switches and cause those sudden reboots.
We had to keep minimal ethernet management part configuration printed next to switches so that first entering primary network settings we could TFTP-load production config and get switch back to production quicker. But long without OOB management (serial port & remote telnet) it was always was hurry to get on site fixing locally these events.
I wasn't earning those occasions much after we got most often issues caused switches replaced with another other brand with did not suffer these problems.
> They sold a managed switch that couldn't save its configuration
I don't hate that idea. I wish I could set up our Cisco switches to do that, so on startup they pull down their config via ZTP and never ever ever save local changes.
That'll stop people logging in and making local changes and expecting everyone else to somehow just know about their tampering.
>That'll stop people logging in and making local changes and expecting everyone else to somehow just know about their tampering.
How about changing "enable secret" password and not sharing it with those who you do not approve making changes?
Or even setting up TACACS+ or RADIUS service and getting SSO to network gear that way. TACACS+ even free versions by default as an AAA that last A accounting makes you able to log all logins and commands being executecuted IOS cli.
Also, you can set up a management server (station) which collects all configs, checks in a db or VCS (RCS, CSV, git) which you can then build on changes monitoring, revert back configs as far as you have saved config versions. Like I had while working over 20 years backlog about half thousand switchers and other gear. RANCiD can do it for cheap, if you don't like to buy commercial solution which also can do similar things. Oh, OpenNMS and FreeNMS probably can do this also if you prefer getting those. I didn't use those as we built from mid 90's own systems and didn't bother changing at least when I was still working.
If you still need to allow other users login let other commands that enable level requires, you can use a "parser view group-name" and pick what additional commands you let them also access from exec enable level (15) without letting then become full enable 15 level users.
ps. Cisco IOS has long had service which autoloads config from TFTP server, but that isn't perhaps what you are looking for. It's mostly intended getting initial config uploaded to system enabling remote management over telnet and further making proper config automation easier.
"I predict the Internet, which only just recently got this section here in InfoWorld, will soon go spectacularly supernova and in 1996 catastrophically collapse."
Keep in mind he co-invented Ethernet, so he knew what he was talking about!
Here's hoping we'll be able to look back with equal amusement at the AI doom predictions.
Prior to the time period covered in the article, 3Com had a major disaster in Software. We were losing badly in competition with Novell in the Network Operating System category (though I and others would argue we had a technically superior product) and decided that we would partner with Microsoft and overpower Novell that way. Big mistake.
I was only a consultant at 3Com during this time, so I may have some of the details wrong, but 3Com essentially bet the success of its software division on the partnership. We built a product called 3+Open that was based on OS/2 Lan Manager. The product flopped. But unfortunately 3Com had agreed to multi-million-dollar, fixed annual license payments to Microsoft for OS/2. (Which may have been the right choice had the product been successful.)
To get out of the license payments, 3Com gave all its LAN software IP to Microsoft and exited that business. Microsoft used that technology in Windows NT Lan Manager and essentially destroyed Novell.
If you want details, the Bill Gates Biography "Hard Drive: Bill Gates and the Making of the Microsoft Empire" tells the story of that failed partnership.
I worked for a while doing pre sales support for a company that sold 3Com products. 3+Share and 3+Open were pretty solid but mostly people just bought Netware. The XNS network protocol couldn’t be routed, only bridged, our biggest customer had 3Station disk less PCs and a huge number of 3Servers on a huge national network that gave them headaches managing due to broadcast traffic travelling over slow links. It was a fascinating problem to have in the era before properly smart gear.
Recently saw 2 different network closets one filled with old 3com and HPE switches and the other one was HPE and Aruba. Basically the same switches, basic 24 port 1GbE. Just feeding a bunch of cameras with poe. Surprised the resilience of 3com hardware. Surprised how little changed in-between these generations.
First time i saw 3com's they were already ancient. One of the switches had a coax cable that connected to a hut that was too far away for Ethernet, wifi was not permitted, no one wanted to pull an optic, so we basically replaced everything around that hut an that switch with Mikrotik and just let it to chug along way past it's expiration date.
network cards mostly died when it got integrated into the motherboard - same with soundcards and even graphic cards unless you wanted pro quality sound, extra networking features or a gamer. For everybody else, the basic integrated options were enough. I grew up in that era and not once did I look up what the 3com card offered over another networking card other than 10/100. Just wanted it to work. I'm sure some people are more discerning but not much.
The separate cards may have died, but the same companies, or different ones, are making the chips that go on the motherboard. I think mine has a 2.5G Marvell and a 10G Intel chip.
There were some “interesting” issues with a lot of the cheap hardware for a long time though. A classic example was the WinModem. A fast modem for cheap? Sure! But it was cheap because it outsourced a lot of its processing to the CPU, so if your system was loaded up (in the day when CPUs were almost all single-core) meant there wasn’t enough left over to process inbound data in realtime which meant dropped packets and retries and horrendous lag and throughput.
Standard wisdom was to use an Intel EtherExpress Pro card for a long time after onboard Ethernet was available. Lots of server hardware had unused builtin NICs until they got decent.
"The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
probably the worst PCI ethernet controller ever made...8139 supports bus-master
DMA, but it has a terrible interface that nullifies any performance
gains that bus-master DMA usually offers.
For transmission, the chip offers a series of four TX descriptor
registers. Each transmit frame must be in a contiguous buffer, aligned
on a longword (32-bit) boundary. This means we almost always have to
do mbuf copies in order to transmit a frame, except in the unlikely
case where a) the packet fits into a single mbuf, and b) the packet
is 32-bit aligned within the mbuf's data area. The presence of only
four descriptor registers means that we can never have more than four
packets queued for transmission at any one time.
Reception is not much better. The driver has to allocate a single large
buffer area (up to 64K in size) into which the chip will DMA received
frames. Because we don't know where within this region received packets
will begin or end, we have no choice but to copy data from the buffer
area into mbufs in order to pass the packets up to the higher protocol
levels.
It's impossible given this rotten design to really achieve decent
performance at 100Mbps, unless you happen to have a 400Mhz PII or
some equally overmuscled CPU to drive it."
tldr tldr: it didnt matter past 2001 since slowest low end CPUs were cheap enough to nullify all the potential gains from smart good 100Mbit NICs
I worked at Convergent Technologies at the time, and our CEO went on a vacation cruise and met Metcalf. They decided over drinks with little umbrellas in them, to merge our companies. We were the largest single customer of Intel processors at the time(the PC market was very fragmented).
But the stocks jiggled and the buyout plan was postponed when valuations became uneven, and it never happened.
I installed a bunch of 3Server network servers in the late 80s-mid 90s. They were pretty darned solid. Tech support was an actual human, I knew his name (though have forgotten it now), and we actually went out to lunch one time, as my company was in Mt View and they were in Santa Clara, I think.
I used to have a 905 on my router's external interface, until one week I had to do a modem swap. A couple days after the guy left, I went back in to do some cable cleanup... and when I plugged the cable back in, the surface-mounted jack sheared right off the pcb. While I could have soldered it back on, I'm surprised most cards didn't meet the same fate early on.
They made good stuff. Then the cheap stuff got good enough for 90 percent of the use cases, then they bought into another sector where exactly the same thing happened again, except it was also a completely dead end. I don’t think any peripheral-card-only makers survived except Nvidia
Article is a bit wrong, it's HPE that owns it now, not HP. Comware switches are still actively developed and sold. It's very solid, deployed in places you wouldn't expect where it just runs for years without issue.
Yes, bought TippingPoint[1], one of the first NGIPS makers. That were one of first very capable L2 IPS to market. I did have opportunity to test one for a while, but did not get funding for it approved.
3Com was also one of the early ATM gear vendors with CELLplex 7000 ATM switch and SuperStack 2700 ethernet switches with LEC. I would say mostly[2] reliable and working gear few years before Cisco LS1010's ATM switches, Catalyst 5000 and first 3000 series ethernet switches after acquiring Kalpana.
2) SuperStack switches had bad habit suddenly reboot under prolong3ed heavy load and perhaps heat problems too, which then also occasionally did factory reset and lose configuration. And the menu based configuration with binary only tftp upload/download configs when better alternatives came available these were replaced any location where that ever happened causing issues.
I can't quite remember if the 3c509, 595 or 905 was the fastest and best. I think 905. I created a boot disc for these and a few other NICs that featured on Novell's Cool Solutions.
I remember also original EtherLink 3C501 and 3C505 with 3+Share yay!
Both were quite exiting and beautiful looking new fancy cards early -85 when I first had them on my desk. But in reality 501 was a dumb as a dodo and 505 with its dedicated 80186 (co)processor for 3+Share fileserver intended use not much better.
Here are links to pictures of those wonders we got -80 and cursed them later :)
I bought a 3c595 FastEtherlink card from CompUSA when I was in college because my dorm had ethernet and I was running FreeBSD and I thought tech specs were the be-all end-all.
It was fast, but not noticeably faster than any other cards my friends had. Except I spent way too much on mine.
3c509 was 10base-T ISA, so it's the slowest. 3c595 and 3c905 are 10/100 PCI cards, but the 905 was newer and more efficient (better bus mastering, more CPU offload)
(2022) Yeah.. I know, it says 2026 at the top, but it was posted here in 2025, and you can see it's older. No idea why the author keeps ever-greening (the create date should at least reflect the original post?)
What happened to them? They never really diversified out of network cards, their cards were very very good, but for most people paying 3x as much wasn't worth it.
They split off their Palm (PalmPilot) division in 2000 to focus on Network equipment. The the .com bust happened.
Palm/Handspring/Treo could have been the iPhone, if they'd been better managed.
Apple was also powerful enough (and Cingular at the time, weak enough) that they could dictate the terms and do whatever they wanted. Anyone else would have had their vision ruined by the cellular carriers.
I had a Treo fairly early on. Leave aside the physical keyboard. The iPhone had a whole app and media infrastructure built around it. Could Palm have gone there? Possibly. But that would have been a big step from where they were in the mid/late 2000s.
but the windows phone OS was better, and the hardware very good. They just couldn't get their shit together with the app ecosystem; even paying us devs huge premiums to write apps wasn't enough.
Nope. Innovation doesn't happen that way. Once they took on the keyboard path, it's nearly impossible to innovate into something that's not. Even if a team is innovative enough to come up with it, top level will kill it off
3com was the very first investment I ever bought…I bought my shares on Thursday October 15th, 1987….those that are old enough to remember will know how that turned out.
I can maybe do you one better. I think my first investment was 140 shares of LNUX at F&F IPO pricing of $30/share, purchased Dec, 1999. It opened at $299/share the day of the IPO. Should've sold that day. Eventually sold it all in 2004 for $2.80/share.
>The first thing that happened was 3Com walked away from its enterprise networking equipment business. Admittedly Cisco was hard to compete with. But 3Com was the only brand succeeding at doing it.
I can't really agree with that because 3com never had a serious router product line. They had LAN switching equipment and NICs. There was nothing like a whole product line of routers that could take a full BGP table in the 1999-2000-2001 era, and certainly nothing like medium to large carrier routers. I'm talking about around the same era when the Juniper M40 was released to compete with Cisco in that market. Or a Cisco 12008. Anything broadly along those lines. 3Com was far behind in advanced IP routing and things that would serve as like a metro aggregation router or core router.
A few lessons from my early IT life, all by way of 3Com...
A strange OSPF problem with 3com NetBuilder routers of which nobody could get to the bottom of. Based in a team that maintained the 3Com relationship with this arm of the (UK) civil service, who solely used 3Com networking products (LAN & WAN), we duly rang our contact and described the problem (and attempted fixes)... "You should change the PSU(s)" he said (eh? it's an OSPF problem?!?!?). Apparently they had some sort of (RF?) issue(s) with certain NetBuilder PSUs that had been known (note: undocumented, at least not publicly) to cause "strange" issues (it did resolve the problem).
Lesson 1: Sometimes it's the thing that wouldn't even occur to you that are the root cause.
Having ordered lots (>£1mn) of 3Com enterprise networking equipment (from LAN switches to their CoreBuiler 9000 chassis), and stuck it all in a warehouse, in preparation for a country-wide network upgrade - 3Com shortly thereafter (and seemingly out of the blue) announced their complete withdrawal from the enterprise network market. 3Com's messaging, as I recall, was pretty much - once the existing stock is gone there will be no more, and hardware support would last 2 years and after that - tough! Needless to say this caused quite some consternation with civil service execs, of which I assume invited 3com to a meeting (without biscuits) to discuss the situation. 3Com eventually partially walked back on said withdrawal (continuing to manufacture/sell smaller variants - and card/PSU/etc compatible - of the CoreBuilder 9000) although this wasn't enough to un-sour the relationship.
Lesson 2: Maybe this isn't the best way to treat your customers, and no matter how large the vendor (or how much you spend with them) - this may happen to you.
In one of 3Com's offices (Partington, a delightful place) - if you parked near the edge of the, fenced off, office car park - you may return to your car to find a brick embedded in it as a gift from the one of the locals. I assume much merriment was had by the cheeky scamps when tossing bricks over the fence at 3Com employee's cars.
Lesson 3: Get to this 3Com office early and park in the center of the car park.
Sat with a (TUPEd ex-civil servant, and hence un-sackable) senior network specialist who was updating the network monitoring for all devices in a specific region. This involved refreshing (via SNMP) the interface list of all the routers/switches/etc. During this process, which was basically click refresh - move onto the next device - and then revisit the original device after a while to confirm it had completed, one of the edge routers dropped offline (and didn't return). No problem - traffic would route (and bridge! IPX FTW!) via the backup router/link. The senior network specialist was quite methodical in his polling, moving from one (now offline) edge and around the ring of devices before eventually arriving at the final (note: backup - and now only - route) edge router (NetBuilder). Prior to reaching the final router it had dawned on my little (junior, green) brain that maybe he had triggered a (documented) NetBuilder bug that would cause the router to hang - needing a physical reboot - if SNMP walking a device with an FDDI card (which these routers had). Having voiced my theory, and in doing so suggesting that polling the final router may not be the wisest course of action, he confirmed that it was his job to poll the routers and that is what he was damn well going to do. The backup router dropped offline. 100s/1000s of civil servants now unable to do their job (that required mainframe access that resided beyond the edge routers) and needing physical intervention (i.e. ~1 hour) to resolve. Based on previous observations, I assume productivity for those users dropped by a single-digit percentage within that dark hour.
Lesson 4 (one of many such lessons reinforcing this view): 3Com's enterprise networking software sure has some strange bugs. Also, welcome to the public sector (or public sector adjacent).
Given the various bugs observed during my time in the team - I didn't hold the quality of 3Com's enterprise networking products' software in very high regard. Such low opinions would only be surpassed in later years by Fortinet's security/networking products' software releases.
I am sure that the built-in Intel Ethernet ports on most motherboards have made Network Cards obsolete at least for the Home Market. When I got a 2Wire DSL modem, they threw in an Intel Ethernet card with it for free. Now I use WIFI 6 on my Wifi router and PC, and it is fast enough for me.
I remember when USRobotics was giving away free 56Kbps modems to BBSes if the SYSOP listed that they had a USRobotics modem and kept the BBS up for 24 hours a day.
> I am sure that the built-in Intel Ethernet ports on most motherboards have made Network Cards obsolete at least for the Home Market.
Someone is still making a NIC chip, they're just selling it to the motherboard OEM, instead of selling an add-in board to the customer (or selling a chip to the add-in maker). In a way, this is more sales, because desktops tend to come with a wired nic and a wireless nic, and so do good laptops.
You are understating how integrated this stuff is. If you make an Intel client motherboard, all you need to add for the network is the phy, jack and some passives.
I haven't really been following intel boards. AM4/AM5 chipsets (and cpus) don't have integrated MACs. I didn't realize intel was putting them in for client parts (Xeon-D had them, but Xeon-D is weird :p)
They were high-quality cards and the lifetime warranty proved to be very popular.
Outside that, I think I missed everything though I have memories of another company that merged into 3x in, xircom? Before they were acquired again.
Does the manufacturer have to define what "lifetime" means? Perhaps buried in the small print somewhere.
That sounds like a stupid scam unless you’re super confident in your product.
Which would imply such lifetime guarantee promises are worth very little.
Details (pg 88): https://www.ardent-tool.com/NIC/3c5x9b_Technical_Reference.p...
----------------------------------------
It is the user’s responsibility (with help from the configuration program) to avoid configuring the boot PROM on the adapter in such a way that the system is not able to boot. If this does occur, you can manually jump the Test Via using a #2 pencil. The Test Via forces the adapter into test mode, which disables the boot PROM so that the adapter configuration program can be run. You must cover the designated area thoroughly with the pencil mark.
Test mode forces the adapter not to perform the Automatic Initialization sequence, which means the EEPROM is not read and the adapter is left in the following configuration:
■ Address Configuration register = 0000h
■ Resource Configuration register = 0000h
■ Product ID register = 0000h
Test mode also shortens the ID sequence to 8 bytes (first is still FFh and last is 69h) and forces it to the active state (that is, the adapter is active and will respond to I/O cycles at base address 0200h even without going through the ID sequence).
After you are done, thoroughly erase the pencil mark.
----------------------------------------
And some USB drives are all black, so you have to come up with something else.
So, no, "just use a permanent marker" doesn't solve this issue at its core.
Ron Crane which was 3com's 4th employee and designed the 3C100, 3com's first ethernet product. Many years later he hired me for my first real job of out school and brought me to the bay area. I then got to work side by side with him and David Boggs (https://en.wikipedia.org/wiki/David_Boggs). At the time I never realized how special working with these two were...wasn't every company in the bay area like this?
I stayed in tough with Ron Crane until his death in 2017. He was both brilliant and incredibly sweet. He was so proud to take me behind the scenes at the Computer History Museum to show some work he'd been going.
I know Ron has writen about 3com...but this story captures the Ron I know: https://www.theregister.com/on-prem/2013/05/28/how-god-and-u...
One day, Ron (a hardware engineer from Xerox) gave a talk about the theoretical performance of an Ethernet file transfer. He calculated the end-to-end latency and data-rate including disk latency, network latency, the number of clock cycles necessary to send and receive the data, etc.
He had (overhead projector) slides that showed all his assumptions and calculations. Finally he displayed a slide with a graph showing this theoretical maximum, the actual performance of the 3Com network stack, and (IIRC) the Novell stack. As I recall, actual performance was about an order-of-magnitude lower than the theoretical max.
His point wasn't that our software division should be able to achieve the theoretical max. It was that if we (for example) got halfway there, we would know that Novell would never ship software that was twice as fast as ours.
He was very nice and scholarly about it and did not mean offense. I and many others weren't offended. But a surprising number of people were.
I'm sorry to hear that he passed.
For those with textual proclivities: https://archive.computerhistory.org/resources/text/Oral_Hist...
Metcalfe has a reputation for being brash and outspoken and it clearly shows in the interview. I think it served him well in business and later in life as a pundit. I remember looking forward to his columns in InfoWorld, though I didn't necessarily give much stock to his predictions.
He talks a little bit about the downfall of 3Com in the interview, though he begs-off of talking about things that happened there after he left.
I very much enjoyed the trivia and minutiae about the creation of Ethernet and the Digital / Intel / Xerox relationship that ultimately resulted in it being standardized.
Basically, it was a long listen but there was some good stuff in there.
I was on the Macintosh network os client team. For whatever reason (maybe he was annoyed that Apple copied so much from Xerox) Metcalfe didn't like Macs. In this era Macs used Apple's proprietary AppleTalk/LocalTalk network. We did a demo for 3Com execs using a large external monitor connected via a single black coax cable that looked just like thin-ethernet. He got excited for a moment and came right over to look at the Mac and was very disappointed to see the cable attached to a display! (3Com was working on Ethernet cards for Mac at the time but they weren't ready at the time of this demo.)
For those too young to remember: there was an SF Bay Area baseball park known as Candlestick Park that was briefly branded "3Com Park" -- to the great annoyance of SF Giants fans. During one interview he as asked if in the early days of 3Com he would have done anything differently. He said, "I would have named the company 'Candlestick'!"
Every year that I worked at 3Com, we proclaimed it was "the Year of the Network!" It became a running industry joke.
But of course, Metcalfe's Law contains some fundamental truths: https://en.wikipedia.org/wiki/Metcalfe's_law
Proclaim the Year of the Network some time in 1993 or 1994, and you're golden.
(It was the 1980's version of the Linux Desktop joke)
I remember that SuperStack 2700 ethernet switches with ATM LEC (lan emulation client) card it did happen under prolonged heavy load heat accumulated with then caused sudden reboots. Occasionally these events switch was as factory reset was done, none of configuration made was left.
First with ATM LANE with ethernet STP (802.3D) was flimsy and buggy, so it took a while when that was fixed without STP spurious loops broadcast storms did quite easily overload edge switches and cause those sudden reboots.
We had to keep minimal ethernet management part configuration printed next to switches so that first entering primary network settings we could TFTP-load production config and get switch back to production quicker. But long without OOB management (serial port & remote telnet) it was always was hurry to get on site fixing locally these events.
I wasn't earning those occasions much after we got most often issues caused switches replaced with another other brand with did not suffer these problems.
That is a remarkable decision.
I don't hate that idea. I wish I could set up our Cisco switches to do that, so on startup they pull down their config via ZTP and never ever ever save local changes.
That'll stop people logging in and making local changes and expecting everyone else to somehow just know about their tampering.
How about changing "enable secret" password and not sharing it with those who you do not approve making changes?
Or even setting up TACACS+ or RADIUS service and getting SSO to network gear that way. TACACS+ even free versions by default as an AAA that last A accounting makes you able to log all logins and commands being executecuted IOS cli.
Also, you can set up a management server (station) which collects all configs, checks in a db or VCS (RCS, CSV, git) which you can then build on changes monitoring, revert back configs as far as you have saved config versions. Like I had while working over 20 years backlog about half thousand switchers and other gear. RANCiD can do it for cheap, if you don't like to buy commercial solution which also can do similar things. Oh, OpenNMS and FreeNMS probably can do this also if you prefer getting those. I didn't use those as we built from mid 90's own systems and didn't bother changing at least when I was still working.
If you still need to allow other users login let other commands that enable level requires, you can use a "parser view group-name" and pick what additional commands you let them also access from exec enable level (15) without letting then become full enable 15 level users.
ps. Cisco IOS has long had service which autoloads config from TFTP server, but that isn't perhaps what you are looking for. It's mostly intended getting initial config uploaded to system enabling remote management over telnet and further making proper config automation easier.
An amusing example of his punditry:
"I predict the Internet, which only just recently got this section here in InfoWorld, will soon go spectacularly supernova and in 1996 catastrophically collapse."
Keep in mind he co-invented Ethernet, so he knew what he was talking about!
Here's hoping we'll be able to look back with equal amusement at the AI doom predictions.
https://www.elon.edu/u/imagining/expert_predictions/from-the...
I was only a consultant at 3Com during this time, so I may have some of the details wrong, but 3Com essentially bet the success of its software division on the partnership. We built a product called 3+Open that was based on OS/2 Lan Manager. The product flopped. But unfortunately 3Com had agreed to multi-million-dollar, fixed annual license payments to Microsoft for OS/2. (Which may have been the right choice had the product been successful.)
To get out of the license payments, 3Com gave all its LAN software IP to Microsoft and exited that business. Microsoft used that technology in Windows NT Lan Manager and essentially destroyed Novell.
If you want details, the Bill Gates Biography "Hard Drive: Bill Gates and the Making of the Microsoft Empire" tells the story of that failed partnership.
Source: me, LAN guy since 1990 and NT admin since 1993.
For Microsoft it sounds like it "failed successfully".
MS realy is the trojan horse. Because probabilities multiply into less probable outcomes but result is again and again the same.
Indeed deal as good as the DEC one.
First time i saw 3com's they were already ancient. One of the switches had a coax cable that connected to a hut that was too far away for Ethernet, wifi was not permitted, no one wanted to pull an optic, so we basically replaced everything around that hut an that switch with Mikrotik and just let it to chug along way past it's expiration date.
Standard wisdom was to use an Intel EtherExpress Pro card for a long time after onboard Ethernet was available. Lots of server hardware had unused builtin NICs until they got decent.
https://news.ycombinator.com/item?id=42746741
tldr:
"The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is probably the worst PCI ethernet controller ever made...8139 supports bus-master DMA, but it has a terrible interface that nullifies any performance gains that bus-master DMA usually offers.
For transmission, the chip offers a series of four TX descriptor registers. Each transmit frame must be in a contiguous buffer, aligned on a longword (32-bit) boundary. This means we almost always have to do mbuf copies in order to transmit a frame, except in the unlikely case where a) the packet fits into a single mbuf, and b) the packet is 32-bit aligned within the mbuf's data area. The presence of only four descriptor registers means that we can never have more than four packets queued for transmission at any one time.
Reception is not much better. The driver has to allocate a single large buffer area (up to 64K in size) into which the chip will DMA received frames. Because we don't know where within this region received packets will begin or end, we have no choice but to copy data from the buffer area into mbufs in order to pass the packets up to the higher protocol levels.
It's impossible given this rotten design to really achieve decent performance at 100Mbps, unless you happen to have a 400Mhz PII or some equally overmuscled CPU to drive it."
tldr tldr: it didnt matter past 2001 since slowest low end CPUs were cheap enough to nullify all the potential gains from smart good 100Mbit NICs
But the stocks jiggled and the buyout plan was postponed when valuations became uneven, and it never happened.
3Com was also one of the early ATM gear vendors with CELLplex 7000 ATM switch and SuperStack 2700 ethernet switches with LEC. I would say mostly[2] reliable and working gear few years before Cisco LS1010's ATM switches, Catalyst 5000 and first 3000 series ethernet switches after acquiring Kalpana.
1) https://en.wikipedia.org/wiki/TippingPoint
2) SuperStack switches had bad habit suddenly reboot under prolong3ed heavy load and perhaps heat problems too, which then also occasionally did factory reset and lose configuration. And the menu based configuration with binary only tftp upload/download configs when better alternatives came available these were replaced any location where that ever happened causing issues.
I can't quite remember if the 3c509, 595 or 905 was the fastest and best. I think 905. I created a boot disc for these and a few other NICs that featured on Novell's Cool Solutions.
Nowadays I have QSFP28+ to fiddle with.
Both were quite exiting and beautiful looking new fancy cards early -85 when I first had them on my desk. But in reality 501 was a dumb as a dodo and 505 with its dedicated 80186 (co)processor for 3+Share fileserver intended use not much better.
Here are links to pictures of those wonders we got -80 and cursed them later :)
It was fast, but not noticeably faster than any other cards my friends had. Except I spent way too much on mine.
(Small text changes, and a CTA at the bottom)
https://web.archive.org/web/20220302141059/https://dfarq.hom...
They split off their Palm (PalmPilot) division in 2000 to focus on Network equipment. The the .com bust happened.
Palm/Handspring/Treo could have been the iPhone, if they'd been better managed.
iPhone wasn't just a form factor, the software traces back to NeXTSTEP 1989.
Fact of the matter is nothing could have been the iPhone, everything sucked in 2007.
Apple had the wind in its back with the iPod and Mac OS X Tiger.
The Intel transition was complete.
Apple was firing on all cylinders, what a time to be in your early 20s.
Even Android did a 180 once the writing was on the wall, it originally resembled BlackBerry OS.
But it worked until the other components in PC stopped working first.
Fond memories.
https://en.wikipedia.org/wiki/Geeknet
>The first thing that happened was 3Com walked away from its enterprise networking equipment business. Admittedly Cisco was hard to compete with. But 3Com was the only brand succeeding at doing it.
I can't really agree with that because 3com never had a serious router product line. They had LAN switching equipment and NICs. There was nothing like a whole product line of routers that could take a full BGP table in the 1999-2000-2001 era, and certainly nothing like medium to large carrier routers. I'm talking about around the same era when the Juniper M40 was released to compete with Cisco in that market. Or a Cisco 12008. Anything broadly along those lines. 3Com was far behind in advanced IP routing and things that would serve as like a metro aggregation router or core router.
A strange OSPF problem with 3com NetBuilder routers of which nobody could get to the bottom of. Based in a team that maintained the 3Com relationship with this arm of the (UK) civil service, who solely used 3Com networking products (LAN & WAN), we duly rang our contact and described the problem (and attempted fixes)... "You should change the PSU(s)" he said (eh? it's an OSPF problem?!?!?). Apparently they had some sort of (RF?) issue(s) with certain NetBuilder PSUs that had been known (note: undocumented, at least not publicly) to cause "strange" issues (it did resolve the problem).
Lesson 1: Sometimes it's the thing that wouldn't even occur to you that are the root cause.
Having ordered lots (>£1mn) of 3Com enterprise networking equipment (from LAN switches to their CoreBuiler 9000 chassis), and stuck it all in a warehouse, in preparation for a country-wide network upgrade - 3Com shortly thereafter (and seemingly out of the blue) announced their complete withdrawal from the enterprise network market. 3Com's messaging, as I recall, was pretty much - once the existing stock is gone there will be no more, and hardware support would last 2 years and after that - tough! Needless to say this caused quite some consternation with civil service execs, of which I assume invited 3com to a meeting (without biscuits) to discuss the situation. 3Com eventually partially walked back on said withdrawal (continuing to manufacture/sell smaller variants - and card/PSU/etc compatible - of the CoreBuilder 9000) although this wasn't enough to un-sour the relationship.
Lesson 2: Maybe this isn't the best way to treat your customers, and no matter how large the vendor (or how much you spend with them) - this may happen to you.
In one of 3Com's offices (Partington, a delightful place) - if you parked near the edge of the, fenced off, office car park - you may return to your car to find a brick embedded in it as a gift from the one of the locals. I assume much merriment was had by the cheeky scamps when tossing bricks over the fence at 3Com employee's cars.
Lesson 3: Get to this 3Com office early and park in the center of the car park.
Sat with a (TUPEd ex-civil servant, and hence un-sackable) senior network specialist who was updating the network monitoring for all devices in a specific region. This involved refreshing (via SNMP) the interface list of all the routers/switches/etc. During this process, which was basically click refresh - move onto the next device - and then revisit the original device after a while to confirm it had completed, one of the edge routers dropped offline (and didn't return). No problem - traffic would route (and bridge! IPX FTW!) via the backup router/link. The senior network specialist was quite methodical in his polling, moving from one (now offline) edge and around the ring of devices before eventually arriving at the final (note: backup - and now only - route) edge router (NetBuilder). Prior to reaching the final router it had dawned on my little (junior, green) brain that maybe he had triggered a (documented) NetBuilder bug that would cause the router to hang - needing a physical reboot - if SNMP walking a device with an FDDI card (which these routers had). Having voiced my theory, and in doing so suggesting that polling the final router may not be the wisest course of action, he confirmed that it was his job to poll the routers and that is what he was damn well going to do. The backup router dropped offline. 100s/1000s of civil servants now unable to do their job (that required mainframe access that resided beyond the edge routers) and needing physical intervention (i.e. ~1 hour) to resolve. Based on previous observations, I assume productivity for those users dropped by a single-digit percentage within that dark hour.
Lesson 4 (one of many such lessons reinforcing this view): 3Com's enterprise networking software sure has some strange bugs. Also, welcome to the public sector (or public sector adjacent).
Given the various bugs observed during my time in the team - I didn't hold the quality of 3Com's enterprise networking products' software in very high regard. Such low opinions would only be surpassed in later years by Fortinet's security/networking products' software releases.
I remember when USRobotics was giving away free 56Kbps modems to BBSes if the SYSOP listed that they had a USRobotics modem and kept the BBS up for 24 hours a day.
Someone is still making a NIC chip, they're just selling it to the motherboard OEM, instead of selling an add-in board to the customer (or selling a chip to the add-in maker). In a way, this is more sales, because desktops tend to come with a wired nic and a wireless nic, and so do good laptops.