This is too cool not to share -- TIER's VillageBTS project in Papua finally went live this week. Check out the blog post Kurtis Heimerl, whose thesis work VBTS is, wrote on the TIER blog. I spent a few weeks helping deploy this back in November.
It's only been a few days, but the network is already turning a profit (at least on operating costs; capital expenditures, like the BTS itself, were paid for by TIER's grant funds). I think that's a huge demonstration of the value this system brings to the local community, and not something you usually see in academic development work. A quick glance at the logs shows that in the first four days of operation we've already handled almost 1100 SMS (about 40% were between users of our network, with the remainder between our users and the outside world).
All in all, very cool so far. I can't wait to see how this project evolves.
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!
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.
I'm building a custom Python package for a project I'm working on, and it took me more time than should have been needed to figure out how to achieve the import behavior I wanted for that package. The directory structure looks like this:
project_dir/ foo.py package/ __init__.py Bar.py Baz.py Qux.py
Each of the files in the package defines some classes; for now, we can assume they each have just one eponymous class.
foo.py is the driver script that the user actually runs, which mainly just accepts command line arguments and imports the package.
What I'd like to be able to do in
foo.py is say:
import package b = package.Bar("asdf") b.something()
If all my classes were in a single Python source file called
package.py, this would be the default behavior. Alternatively, I could say
from package import * in foo.py, but that would import my modules directly and frankly I think it looks ugly.
The way to achieve the desired behavior is to perform the imports of each module in the package in the
__init__.py file, like so:
from Bar import * from Baz import * from Qux import *
Now, when we import the package, all the associated modules come with it.