Category Archives: roflcakes

In-flight wireless-less

Ah, fantastic news strikes again. From this article:

“The system has been configured to allocate 128 IPs, with 124 IPs for passenger use. However, due to the number of passengers (115) utilising multiple devices (some as high as 2-3 devices) on the plane, more than 3 times the allowed connections were constantly requesting access to the internet,” explained WirelessG CEO Carel van der Merwe.

Now, some quick searching indicates that they’re using tech from Row 44 to do this thing. If it’s just satellite downlink, then I quite don’t get the R3.5 million (~$436k USD given a quick check of the current ZAR/USD) pricetag. If it’s the whole shebang, then I guess Row 44 is making some damn nice licensing fees out of airlines on DHCP leases.

Either way, I find it pretty damn hilarious that they didn’t plan for something like this on a flight for tech journos.

Screw you, Mikrotik

Particularly, your shitty scripting interface.

Using a lot of Mikrotik routers in various places, I’ve grown accustomed to the platform, and it really is quite flexible. However, it has its idiosyncracies. Among them are bugs and regressions between versions (c’mon guys, can you at least get some functional testing in place?), inconsistencies/inabilities in how some things are done at protocol level (unable to forward a default route in BGP), those sort of things. Now before I continue, let me say that I understand how such things can happen, but I do feel annoyed that they can take that long to get resolved. The lack of automated functional testing is also a major bugbear.

So, you have a router, and you probably care about its config. Most people who do this are familiar with the tool rancid (for better or worse – maybe at some point ranrod will be usable), and there are a set of patches to support mikrotik devices over here. As a side effect of this toolchain, I have a set of method that I can use to log in on many devices with a relatively low-effort command method. Consider the following scenario: someone leaves a company, and you wish to update passwords (in the case where you don’t have don’t have tacacs or radius backing auth). On a unix-like system, you have a few options, but in router-/switch-land you’re limited to some other things. Not to worry, we have shell loops, clogin/mtlogin, and a bit of ingenuity! Leading us to make this:

for location in list some locations here; do
  grep 'mikrotik.*up$' "$location/router.db"; done | cut -d':' -f 1 | while read line; do
  mtlogin -c ':global users;
              :foreach i in=[/user find where name="userinquestion"] do={:set users ($users . "," $i);};
              /user set numbers=$users password=shinymoonbicycles; quit' $line;
done

Seems sane enough. Start a for loop, parse our router.db files for a list of routers we care about, loop through those and run the following automated command sequence. Low-effort, quick, gets it all done. Except it runs into this issue:

[automation@Brain] > can't read "users": no such variable

Argh. Apparently we can’t declare or use variables in this fashion. Even though I can do that perfectly okay when I’m logged into an interactive session (…how is this determined?). “But hold on,” I think, “rancid uses +ct in the username to skip colour and terminal detection; maybe I can disable that to get it done”. And no, you can’t. QQ

In my mind, this sort of thing, on top of the earlier listed problems, the utter silliness of the scripting language (really, go look at the way I have to construct a list of users, or, well, anything), and other things such as no clear equivalent of the cisco-alike “no” command that can be used to negate/remove any statement in the config, are among the things that stand in the way of Mikrotik being taken more seriously.

Mikrotik, you have a product with pretty good potential. It wouldn’t hurt to improve these things a bit. You can sell craploads of non-wifi CPE equipment if you could win over the Cisco-hearts. Please, fix this crap.

*publishes post and mails the link to Mikrotik support*

“Maybe your problem is lint?”

And indeed it was!

One of the products we sell at work is a caching platform, something that sells quite well into many of our African clients’ networks because transit is often ridiculously expensive and every Mbps saved is USD500~2000 you can use on something else. Traditionally we’ve been deploying on HP hardware, and as of earlier this week we have some SuperMicro equipment to try out for the platform. One 1U unit, and one 3U 8-blade unit. This post is about the latter of these two.

After racking the thing, and re-installing the blades (took them out to move the chassis. Side note: the clasp which holds the blades in is kinda crappy for self-locking. You need to wiggle it a bit to ensure the blade is properly in place). I started poking around on the systems. First issue I found is that the ethernet controllers are Intel 82580′s, which is not supported in the squeeze kernel we had on our PXEBoot server at the time (updated kernel which does have support is included in 6.0.4, or any version greater than 2.6.32-33). Now we were informed by our supplier ahead of time that there was one blade which was DOA and that they had a replacement on the way, so I got started on preparing the other systems in the meantime (as they would form a cache cluster). Doing this, I experienced some strange weirdness with the power sequence. Sometimes all the blades would power on, sometimes only the first 4 bays, sometimes only 3. Sometimes I could power 5 on, one off, another one, then attempt to reverse the power sequence of the last two but not succeed. A few more combinations like this were tried, including removing a unit far enough to disconnect it from its connector and then reseat it, but suffice it to say that it didn’t make sense.

At this point in time I’m left with the options of removing units from the bays (to eliminate PSU overload), and of changing the order of the units in the bays to see if that makes a difference (which one would not expect, but if all the possible options have been eliminated then whatever’s left is probably the answer). As I start removing the units one by one, I notice that there’s lint on the one blade’s connector. This hadn’t been there when I installed them, so I asked one of my coworkers to bring my torch over so that I could inspect the inside of the chassis. Turns out there’s a bit of lint hanging loose (about 6cm worth, presumably from the sleeving of one of the fans’ power connectors?) inside the chassis, and that it had somehow managed to get caught up in/on the connector. I remove the lint, and suddenly everything is working as expected.

Lessons learned:

  • SuperMicro BMC units probably have a shared power control bus
  • If you’re seeing weird things happening, maybe it’s lint!

Some more on IPv6 in ZA

Well, there we have it. Our ministers have just said that there’s absolutely no reason it should be so hard to do:

Speaking to ITWeb yesterday, acting deputy director-general of the Presidential National Commission on Information Society and Development Themba Phiri said: “The IPv6 issue is a simple transition. All you need is the equipment that enables new registration of the domain names.”

Source: this article. I’m not entirely sure which part about this worries me out the most, but there’s a few strong contenders in-between all the apparently stupidity, clueless and out-of-reachness that this sort of opinion entails. But the fact that these people are policy-makers and decision-makers on things regarding technology here…well, their lack of knowledge is concerning. If their advisors are at fault for this opinion, their advisors should be fired. If their inability to recognize their advisor’s information as complete bullshit is the cause for them to propagate this opinion, it’s just as concerning. How do we fix this?

[update] for the non-technical readers: basically, there’s significantly more to actually getting IPv6 onto a network than just “the registration of the domain names”. Most importantly, domain names have almost nothing to do with IPv6 (short of how your computer can know to access something using IPv6 as opposed to IPv4, and where to actually try to find the resource you’re attempting to access).