systems_glitch

It's easier to pin failure on a convenient scapegoat, so much the better if it's a faceless group like "pirates." There's a guy who was selling a closed-source version of some open source community developed hardware who's got a thing against me, as I revived the original open source project and started selling hardware kits again. His business failure is definitely because of me, or so he claims Not, you know, selling a low-quality copy at a higher price and then closing the source on the people who *created* the original!

So, I came across this today: http://www.wipo.int/amc/en/domains/search/text.jsp?case=D2017-1828 Apparently the company that owns/develops/whatever pfSense nowadays, NetGate, got slapped around for squatting on opnsense.com and using the domain to discredit the OpnSense project. I'd kinda got the feeling that pfSense was heading toward the closed-source corporate end of the scale. That's unfortunate to see. Guess I'll be trying out OpnSense some time -- I use a plain OpenBSD install on the routers I own/manage, but I often recommend pfSense to clients who want to manage their own.

I've been going through more Sun stuff lately, and decided to get IRC up and going on a few things. First off, SPARCstation 10, Ross HyperSPARC 166 MHz, 128 MB RAM, OpenBSD 5.9, running EPIC4 (excuse the mess!): EPIC4 was compiled from source *on* the SS10. Total configure and build time around 25 minutes! Console terminal is a DEC VT320 in 132 column mode. Took a bit to figure out that, when using a 132-column terminal as the system console, you have to set the width in NVRAM. Setting TERM=vt320-w is not sufficient. Second, a SPARCstation IPX, 40 MHz CPU, 32 MB RAM, SunOS 4.1.4, running ircII-2.2.9: Works fine in a SunView console, too! ircII was also compiled on the actual machine, I forgot to time it, but total build time was around 20 minutes or so. It's restricted to 8-char nicks. It's the oldest version I could find that would just build on SunOS 4 -- ircII-1.75 failed to build.

I'm sure you could come up with a spoofed source to feed it

That old stuff is often hard to kill! At least we don't need a dedicate X application to see if they have coffee, nowadays

https://www.joltcola.com/ Sark tipped me off about this. Picked up 4x cans for $4 at Dollar General tonight. Haven't tried it yet, but I hear it tastes the same as the old regular cola kind, from before the battery bottle days.

The copy of the BSP I ordered should have the schematic in it, I'm guessing it's nearly the same as the 71A (which I did find) except for battery power instead of DC plant power. I will definitely take you up on that offer, if the BSP doesn't include it!

I picked this up in a heap of old computer, radio, and telephone equipment, from a guy who had been an engineer in the Navy, then an engineer/lineman/programmer at Bell Labs in NJ: It's an *actual* milliwatt! I can't find the BSP for it online, but I did find a hardcopy on eBay, so I'll scan that in when I get it. Battery test points, this is the battery (well, the top of an old one): 45V "B batteries" were common in old radios and other higher-than-we're-used-to voltages were common in other types of test gear. For instance, a kick meter uses a different 45V battery (looks like a giant 9V and is still made). Top of the internal circuit subassembly, the battery goes in the space seen at the top of the picture: Here's the circuit: Typical Western Electric, potted networks, switchboard jacks, and expensive resistors and capacitors. Not yet sure if the pot varies pitch or level. You can see there's a single very old GE transistor in a metal can package clipped to the side of the uppermost (4002A) network, presumably the only active component in the circuit.

I started repairing an old 486-based industrial system today, which uses a 486 SBC in a passive ISA backplane. Most (but not all!) consumer hardware uses a RTC with a little CMOS RAM and an external battery and crystal, but potted modules are common on industrial/embedded hardware. Unfortunately this one uses a DS1387, for which there is no modern replacement. Several other people have repaired the DS1387 and posted writeups on the process. Here's my rebuild: http://www.glitchwrks.com/2017/07/27/ds1387-rebuild I used a CR1225 and holder due to space restrictions, here's the final result:

Ancient Sun hardware revival continues! The recent pick-up of Sun hardware included a bunch of "lunchbox" form factor machines (SPARCstation IPC and IPX machines). All of the IPX machines worked, but both IPC machines had dead power supplies. Opened them up to find a bunch of leaking Chemicon and Elna capacitors. I don't know if this is a capacitor plague/counterfeit thing (both are good brands, and were rated 105C) or what. Anyhow, I wrote up the recapping process here: http://www.glitchwrks.com/2017/07/24/ipc-recap I've included a list of part numbers with original capacitor values, as well as a cross-reference to current production Nichicon substitutes. Both supplies work fine, and both SPARCstation IPCs are now functional Here's a pic of the inside of the supply, after recapping: I went ahead and replaced all capacitors except the line-side filter cap. The smaller ones looked OK, but I figured I might as well do all of them, since I had it open, and capacitors are cheap.

Heh, there's a thought! SunOS has a lot of unpatched, exploitable stuff, like RCEs in the rlogin daemon Every now and then I think about trying to put up an old box running an old OS for shell services for some of the vintage computer crowd (a lot of people seem to want to telnet to something and run IRC on their vintage machine)...but then I think about how insecure these old boxes are, and figure if anyone is still scanning for this stuff, it'd be a total maintenance nightmare!

I picked up a big heap of old Sun gear recently, all SPARC32 era stuff. There were two SPARCstation 2 pizzaboxes in the lot, one which worked fine. The other had been parted out -- no RAM, hard disk, or cards, other than an old bwtwo SBus black and white framebuffer, with essentially useless ECL output. Turns out that this one had a cache controller in that weird fibre module format that Sun liked, with tiny unprotected flying leads. Here's one out of a SPARCclassic (note, it's a SPARCv8 CPU, not a cache controller...same style package): I had tried straightening the pins with an X-acto knife and a 40x loupe but couldn't get it to boot. I decided to have one more go at it today, before giving up and parting the machine out. Turns out there was a pin bent and pushed under another pin, which wasn't obvious except from exactly the right angle. I used a bit of 28 gauge Kynar wire to poke it out. Success! I plugged in a disk from another Sun and booted SunOS 4.1.3 just to make sure it was really alive. It was, so I decided to make it a permanent fix and blob some cyanoacrylate glue (superglue) on the pins to protect them from future mushing and fingerpoking. Before: After gluing: And, just to be sure the glue didn't mess anything up, back into SunOS 4.1.3: So, this one dodged the scrap bin and lives on! Now, what do you do with a 40 MHz SPARC32 machine with 4 MB RAM...

This happened this morning: Apparently the floppy drive had a pretty much dead short in it. Apparently the supply on the bench either doesn't have a functioning shutdown circuit or it's high enough wattage that it didn't see this as a problem. Now the shop stinks of burning wire.

Not very in-depth, but an interesting read if you don't know about the old microwave relay system: http://hackaday.com/2017/07/10/horns-across-america-the-att-long-lines-network/

I recently bought an APC AP9211 MasterSwitch, which is a remote controllable 8-outlet PDU. It's got 8 switchable standard outlets so you can poweron/poweroff/reboot machines remotely. It came with an AP9606 web/SNMP management card, which is usable in a bunch of older UPSes and such. The AP9211 is an older unit, but switching power on and off isn't very complicated, and the newer units mostly boast features I don't really need (built in power meters, "too much current" type alerts, et c.), so I bought a cheap AP9211 online. It of course came with an existing, non-reset configuration. The official guide sez to use a serial cable to reset passwords, but I didn't have a USB -> RS232 adapter on hand, so I looked for known vulnerabilities in the management card, and found this little gem: http://mccltd.net/blog/?p=36 Looks like you can dump the EEPROM over a telnet session using a master password that the factory uses to configure new systems (setting things like MAC addresses). I fired up tcpdump and power-cycled the unit to try and figure out what IP/subnet it was configured for. Got an ARP request and grabbed it -- 10.24.40.18/16. Sure enough, telnet in, enter any username and the master password, and you end up in debug firmware! I was able to get the existing password from EEPROM and log in. I could see maybe having this feature on the console port of the management card, but it sure does seem short-sighted to put it on the telnet interface! I wonder how many of these things are still in service -- betting quite a few, since the management cards work in a bunch of different APC products, and things like the MasterSwitch don't really become less useful with age.