Overhead door sensor

A couple of months ago, one of my two garage door openers stopped cooperating. It acted like the light sensor/source pair that are supposed to detect when something or someone is in harm's way weren't working. The green LED on the sensor module wouldn't come on. So, after some weeks of ignoring the problem, I started digging into it.

First I opened up what turned out to be the source module - the one that provides the infrared light "beam" for the sensor to pick up. Not visible signs of problems there. Then I opened up the other one, the sensor module. After a few minutes of tracing out the circuit, I ran across the obvious. Can you spot it (click the pic to expand it)?



In case you missed it, there's a pin near the upper left corner of the board that isn't soldered in. That is the collector pin on a transistor. Pretty important connection to be made in most circuits. I guess this one was bent over far enough that it was contacting the pad on the PCB and had worked that way for untold years. ICs on various boards in the system have batch numbers from late 1997, the house was built in 1998 so the silly thing may have been working for as many as 12 or 13 years with this flaw. I figure either I, the cat or the kids wacked into it one time too many and jostled that delicate connection loose. Anyway, after a bout with the soldering iron, I put it back together and it works fine again.

This experience was similar to another one recently when the blower fan for the air handler in the central heat and air system stopped running. In that case, the fan control PCB's faulty connection *had* been soldered in, but the pad on the PCB apparently was not designed to handle the current. Over time, it melted away the solder first, then arced away at the remnants of the pad until it finally had nothing to arc to. Soldering a piece of 14 AWG wire across the right points took care of that one.

Funny thing, there - I knew exactly what to look for because precisely the same thing had happened at the "old house" a couple of years earlier. Took me about an hour the find and fix the first time and only 15 minutes the second time.

Cable ISPs

Incited by the topic of my previous post, I did a little hunting. The cable ISP I use at home bought a big chunk of their network, including that in my town, from the "upstream" ISP I mentioned earlier. I did a wee ping scan and found that I've been quite naive with respect to cable ISP security.

I discovered that at this ISP (and there's a bit of assumption here) all of the cable modems get a private IP in the 10/8 range in addition to the public and routable "WAN" IP that gets assigned to it. The unhappy part of this is that my cable modem's status web interface is available to anyone on my "local" ISP's network. If I thought about it all, previously, I guess I assumed that the CM's web interface was only local and not exposed to a fair chunk of the Net. Some cable modems only show their connection status, others provide a management login prompt... I imagine that many of them are still set to accept the manufacturers default password. This is on a network with potentially thousands of "local" users. The potential problems compound for those modems that double as wireless routers, such as mine. Once authenticated on it, one can navigate to a page that reveals the pre-shared key that is necessary to get past the WPA encryption on the WiFi side.

In case you want something to take home from this topic... if you have a cable ISP, lock down your modem by changing its default password. It may sound silly and simple, but while totally unsecured wireless routers are vulnerable to anyone who's out wardriving, your cable modem may be open to any basement dweller on your same ISP (or siphoning off a cable subscriber's WiFi).

"So?" you say. "At least the cable ISPs are limited in geographic and IP routing scope, so how much damage could be done?" Consider that pretty much *every* ISP currently has multiple subscribers whose computers are already infected with malware and may be part of a botnet. How much more difficult would it be for the bad guys to leverage an existing malware presence on your local cable ISP to wreak more harm? Plenty of room for clever, evil mischief.

Gotta keep'm separated

Ran into an oddball network issue where an ISP and their upstream are routing private IPs in the range 172.16/12. They aren't advertising bogons to the world at large (I checked), but quietly routing private IPs that appear to comprise a portion of the upstream's management network.

My local environment is two LANs, one on 10.0.0/8, NAT'd to the public Internet and the other on 172.16.0/12 with all manner of Linux and embedded devices hangin' on it. There's a Windows machine that straddles the networks using 2 separate NICs. A cohort noticed the problem at the Windows box when he tried to telnet to a device of his on the 172.16 LAN and got a login prompt for an ADVA Optical Networking device somewhere in the Outernet instead. A traceroute quickly comfirmed that he wasn't going nuts. I guess it ain't up to me to tell an ISP that it's bad mojo to expose their network management nodes to their customers (downstream ISP) and *their* customers (me), but hey, this is mucking with my network! 172.16 is private and I should be able to use any part of it without fear of colliding with someone else's IPs anywhere out on The Internet.

I emailed the NOC POCs of both networks and got responses, so they'll probably work something out. In the meantime, I needed a way to corral my own two networks and keep'm separated. The Windows 'route' command seemed to fit the bill. It ain't exactly like the Linux route command, but with a little reading and testing, I came up with this:

1) Get a command prompt

2) > route PRINT

3) find the numbers (left column) of the interfaces on the main (outside) LAN and the development (inside) LAN

4) Restrict main LAN interface to 10/8:

> route ADD 10.0.0.0 MASK 255.0.0.0 10.0.0.1 METRIC 1 IF [main LAN interface#]

5) Restrict development LAN to 176.16/12:

> route ADD 172.16.0.0 MASK 255.240.0.0 0.0.0.0 METRIC 1 IF [development LAN interface#]

That seemed to do the trick.


So, problem averted but not really solved. How common is it for ISPs, small or large, to route private IP space within their networks and even between their peers and downstream networks?