Teardown of an Ubiquiti Nanostation Loco M5

I was doing some work on a Ubiquiti Nanostation Loco M5 yesterday and wound up bricking it (protip: the 'erase all' command in uBoot also erases the bootloader itself... whoops!). Rather than getting out the JTAG I decided I'd do a full teardown of it since I hadn't seen one of this device before.

I'd long since removed the board from the case, so here's the board itself. The silver thing on top is shielding for the RF components. It's pretty easy to pop it off with a flathead screwdriver -- just jam it into the sides until it bends up.

There are a few chips on this board. The big one in the center is the 400MHz MIPS SoC, the Atheros AR7240-AH1A. The chip below that is the Winbond 25X64VFIG, a flash memory module. On the left side of the board, we have an M-Tek H16125MCG, an Ethernet transformer (I'm not sure if this is found on all ethernet devices, or if it has something to do with PoE). Directly above the transformer is a chip that's covered in stickers, the one "mystery chip" on this board (at least to me). Removing the stickers, I found three markings. On the top, it has a logo followed by "MIRA", which appears to be a custom IC manufacturer from Taiwan. There are two other markings: one next to the logo reading P3S56040ETP, and one on the bottom reading 944ANF74-G5. I found one reference to the latter, on this site, suggesting both that this is a 32MB SDRAM chip and that the Buffalo WHR-HP-G300N has a very similar bill of materials to the NSLM5!

Inside the shielded area, directly above the AR7240, is the radio chip, the Atheros AR9280-AL1A. The two chips to the left are both Skyworks SE2593A20, a dual-band WiFi frontend which does all the switching, filtering, and so forth. If you look closely towards the bottom left of the shielded area, you can see two leads running to a pair of connectors for RF pigtails (they're the golden squares with a dark circle). These are the antenna lines -- you can follow them back to the antenna port of each of the frontend chips. I guess they left those leads for testing purposes; I don't know if they're functional.

A couple other points of interest are the serial port on the lower right side of the board, just next to the Ethernet port. The reset button is on the bottom left, under the Ethernet transformer.

Flipping the board over, we see the antennas. These are two panel antennas layered on top of each other. They're attached with some plastic screws and solder to connect them to the antenna leads, along with one metal bolt which looks like it goes to ground. The lower layer of the antenna is the only one that's soldered to the board. The upper layer actually doesn't make any electrical contact with the lower one.

Up to this point, you could probably re-assemble the board. But this is a teardown, so I broke off the solder between the lower antenna and the board. It snaps in two pretty easily.

(Note my current favorite tool in the top right corner, vicegrips!)

There's nothing too exciting underneath, just the bottom of the Atheros chips.

I still have all the parts, so if you'd like better pictures or have questions about any parts I didn't discuss, let me know!

Syrian Internet Cut Off

Well, it's happened again: a country's been cut off the Internet. This time it's Syria.

There's good coverage of the technical details of this outage on the Renesys and CloudFlare blogs. The short version is that all Internet traffic into and out of Syria flows through a single, government-owned ISP, the Syrian Telecommunications Establishment (AS29386). This ISP withdrew their BGP routes from their providers, disabling access for all Syrian IP's (since every ISP in Syria relies on AS29386 for their international connectivity). This is effectively the same network structure that exists in Iran, and it makes it trivial to shut off an entire nation's Internet access: all traffic flows through a single point, and the government controls that point.

My TIER colleague Yahel Ben-David brought up the great point a couple months ago that it's kind of odd that method of choice for country-scale Internet blackouts seems to be withdrawing BGP routes, as opposed to just unplugging cables or powering off routers. The Syrian government tried to blame a cable cut for this blackout, but it's pretty hard to say all your BGP routes just "accidentally" got withdrawn. Withdrawing a BGP route is literally broadcast publicly around the world, so it's not particularly subtle either. I don't have a good explanation of why this is done: maybe the engineers tasked with implementing the blackout are just familiar with BGP? Maybe they don't want to disrupt their consecutive days of uptime numbers? If you're a network engineer who's implemented a national Internet blackout and has the answer, get in touch.

Why wireless mesh networks won't save us from censorship

Or "why the reddit 'Darknet Plan' is a fun but misguided solution to the wrong problem".

It's exciting to see so much interest of late in the Darknet Plan hatched by redditors to build a second, people-owned, censorship-free Internet using a large-scale wireless mesh network. Freedom of speech on the Internet is an important issue and it's important for all of us to take it seriously. Additionally, as someone who thinks wireless networks are the bee's knees (and who does research on wireless networks in his day job), it's exciting to see so much interest in using wireless to circumvent censorship.

That's why it's painful for me to say, "hey guys, this isn't going to work".

I got into this space about five years ago to build a community-owned Internet using solar power and wireless mesh networks -- censorship circumvention wasn't an explicit goal, but it was part of the broader vision. I actually wound up building a couple sizable networks using equipment like this (Orangemesh grew out of this work). After a couple years I developed a pretty good understanding that wireless mesh networks aren't actually a good way to build a real network. These are a few of those reasons.

The Case of the Mystery IGMP Query Request

I've spent two days trying to track down the source of mystery IGMP query requests on a network emulation testbed I'm building. All the machines are (essentially) stock installations of Ubuntu 11.04, with no services running besides sshd.

One of my machines acts as a poor man's Ethernet tap. Its two NICs, which are connected to the two machines that run the system I'm testing, are bridged together, allowing me to run tcpdump on the bridge interface (br0) to capture packet traces from the experiments I run*.

I noticed some strange IGMP queries originating from this monitor machine, and after several hours of hunting for the source I found that it was actually coming from this bridge device! It turns out that the bridge module in Linux supports IGMP snooping. I'm sure this is a useful feature for certain scenarios, but when you're trying to make sure no non-intentional traffic is moving across your NICs it is not at all useful.

Anyway, once you've figured this out the solution is simple: just disable IGMP snooping. You can (thankfully) do this via a sysctl variable:

cd /sys/devices/virtual/net/br0/bridge
echo 0 | sudo tee multicast_snooping

Once you do this, the pesky IGMP queries will go away. You can make this permanent (in Ubuntu, anyway) by adding these lines to a script under /etc/network/if-up.d/.

This page was helpful in solving this problem, as it provides documentation about the sysfs features of the bridge module.

*Yes, I know this is not a real Ethernet tap, but with the equipment, budget, and schedule I have (as well as my desire to run at 1Gbps, rather than 100Mbps) this is the best I can do.