A few days ago my USRP B100 with WBX daughterboard arrived. It is an awesome piece of kit, judging just from how the PCBs are designed and laid out. The online reviews and demos also agree. My first challenge is going to get the USRP up & running with GNU Radio on my 2013 iMac. I say challenge as many online references are for PPC versions of Mac OS, or simply outdated, as an example, Jon Jacky’s page. And it’s from 2010, just three years ago!

So, like I did with Imagick and MAMP, I’m going to try and write a step-by-step, easy to follow guide as I go along. This is going to be a live post, so keep checking every few days for progress!

Day one: brewing the drivers

The lack of up-to-date, complete information on how to drive the USRP under Mac OS is surprising. Given the market share and BSDness of OS X, one could safely assume it would be a more prone target than, say, Windows. My first attempt to install GNU Radio using macports didn’t go down so well, and having suffered dependencies hell before, I went looking for other ways, without giving it a second look. After some Google time, I found a set of Homebrew recipes in titanous’ GitHub, which claims to have been tested on 10.8. The result is that I could start GNU Radio, but I was missing the WX GUI components, and had only f-ugly QT components. I blame myself for not reading the instructions end-to-end, and the instructions for not pointing out that WX GUI had to be installed beforehand. Other stuff was duplicated. Some stuff was missing. As an example, I could not find the “Variable Slider” component used in Balint Seeber’s tutorial on YouTube. As an example of the ugliness, and keeping up with my obnoxiousness when it comes to user interfaces, here is a graphical review of the window resulting from Balint’s first test:

I had also installed, but was missing in the sources, the driver for the USRP, following instructions found somewhere else. After a couple of email exchanges with the good people at Ettus, I was pointed to a promising set of guides, back on macports. These will come tomorrow, though.

Day 2: playing with MacPorts

The pointers given by Balint were this tutorial by Andy Bardagjy on getting the right sdcc version to install, followed by installation of the gnuradio port, and finally setting the Python path variables. As some of this info was a bit old, I checked out the sdcc ticket on trac, and it’s shown as fixed, so I’m attempting to go ahead with 3.0.0. For the record, trying to clone 57740 (v2.9.0) failed upon build, so that’s another reason for attempting to go with 3.0.0.

Installing the USRP driver also went fine, just that the port name has been changed to UHD. My first attempt to install GNU Radio after this appeared to work, but for some reason, gnuradio-companion was nowhere to be seen. Trying to install any of the gnuradio-<whatever> ports resulted in an error informing me that they had been replaced by ‘gnuradio’ with options.

After some more Google time, I found this ticket on the MacPorts trac, that explains the issue, and suggests a fix. I managed to get GNU Radio with gnuradio-companion working, at least visually, by running

sudo port install gnuradio +grc +python27 +qtqui +wxgui

which includes the WX GUI components. But it doesn’t include the USRP sources. So, let’s try this instead (after port clean etc.)

sudo port install gnuradio +uhd +grc +swig +wxgui +qtgui +python27

Now, I can see the UHD USRP sources in Companion! More to come later…

Day 3: getting some results!

Finally, the light at the end of the tunnel starts to appear. The WX GUI objects are now present in Companion, but they are also ugly as hell. Maybe it’s a Mac OS rendering issue, I’ll have a go on Ubuntu to see the difference.

The Guide™

Step-by-step, here is how to get your USRP to work under Mac OS X 10.7 and 10.8. By the time you read this, new versions of the different pieces of the puzzle could have appeared, so I’m not making guarantees.

1. Install MacPorts if you haven’t yet done so. Grab it here.

2. Install sdcc – the bugs that were reported appear to have been fixed, so v3.0.0 is fine:

sudo port install sdcc

3. Install the UHD driver for the USRP, including libusb and Python 2.7:

sudo port install uhd +libusb +python27

When you do this, Boost 1.53 will also be installed, which doesn’t seem to give any problems.

4. Install GNU Radio, with UHD support, GRC (the Companion), the WX and QT GUIs (just in case):

sudo port install gnuradio +uhd +grc +swig +wxgui +qtgui +python27

You may see the following, depending on what you had installed before trying this procedure:

Error: org.macports.activate for port qwt returned: Image error: /opt/local/include/qwt/qwt.h is being used by the active qwt52 port.  
Please deactivate this port first, or use 'port -f activate qwt' to force the activation.

I didn’t really feel like bug hunting any longer, so I just forced it with

sudo port -f activate qwt

and was done with. I’ll rest my case with a short quote from Miguel de Icaza’s post on why he ended up with a Mac instead of Linux. He started the GNOME project and Mono.

The build may finish with a complaint about qwt52 not installing as qwt is already installed (WTF?), but gnuradio starts OK.

Once this is done, you should be able to start gnuradio-companion. In order to use the B100, you need to add, for example, a UHD: USRP Source. Here is an updated example of a WFM receiver, you can download the .grc file here.

So these are the rates for calling Spain from Abu Dhabi if you have a Movistar contract SIM:

There’s NO way I’m going to pay 17€ for a 5-minute phone call home once I get there. It’s amazing how screwed up the world of phone carriers is – the same phone call on a Du prepaid SIM will cost me 1.8€. Plus, you can pick up a Du SIM at their Abu Dhabi airport shops as you arrive, they operate 24/7.

So yesterday I got a couple of normal Yubikey OTP devices (plus one beta NFC version) from Yubico – in a surprisingly quick time!

I’m not going to get into a review of the Yubikey, other than saying it’s an awesome device – there are plenty you can read out there.

While the OTP universe is nice and sweet, allowing you to secure access to a number of services with your physical key, plus a number of second-factor inputs, I wanted one of the keys to function as a simple password entry device for Mac OS. In addition, it would be great if I could use the key to lock my Mac when I leave my workspace unattended, a security policy rarely followed in the real world.

I had been using a piece of software from Rohos Rohos sucks ass, I’ve now installed TokenLock ($2.99 on the Mac App Store, and it works great) to lock my desktop, tied to a simple USB flash drive, but this meant that Rohos had to keep my password stored somewhere, and you cannot call up Rohos whenever you are asked for a password. The sole functionality Rohos provides in this case is password entry whenever an OS password request window comes up.

Enter the Yubikey

Interestingly, you can use Rohos in USB-key mode, by choosing the Yubikey as your USB device – after all, it has a serial number. Once you have chosen the USB device, simply enable “Lock desktop” from the list of actions upon USB removal. After you choose the Yubikey as your USB device in TokenLock’s preferences, when you need to leave your desktop, simply pull the Yubikey out, and it will be locked for you. Of course, you must enable the usual combination of “disable automatic login” and “require password” in OS X’s Security preferences.

For the login part to work, you need to program your Mac’s password into the Yubikey’s first or second slots. I chose the first as I wanted speed over keeping the original OTP configuration. If you want to keep Yubico’s OTP, write the static password to the second slot, you then need to tap the button on the key for 2-5 seconds.

When you arrive back at your workstation, insert the Yubikey, and tap the button – your password will be entered for you, and you’ll be logged in!

So finally I managed to get in the NSFW Corporation beta – after some back-and-forth involving a mysterious bug that caused my email to not make it in the beta on time. I have one word to start off this review: awesome.

It’s hard to describe what it is – my best description, aside from the official line of being “a news-weekly that’s published daily“, is that it’s a mix of witty articles on a variety of topics, complimented with an audio podcast (Lord, do I hate that word – if you have a better one, let me know, Paul!). NSFW is Paul Carr’s brainchild, founded after a string of startup failures and literary successes, and is showing promise. The first literary success is ironically based on the string of startup failures, but I digress.

Two articles from the pilot issue are titled This is Why They Hate Us: The Meat Monster, a funny take on why the rest of the world hates the United States and 10k-kcalorie burgers, and Best Practices For: The New Secret Service, which includes tips such as “An agent should now wrestle his partner to the ground at the first hint of an erection“. It is hilarious and entertaining reading, with a touch of political incorrectness that I witnessed only in UK media while I was living there, plus the right dose of swearing. It’s not called NSFW for nothing.

NSFW Live is the audio part of the site, with Paul and Josh Ellis, a contributor with a deep, movie-trailer voice, which reminds me of Beau Weaver (check out his free In A World ringtone). Josh makes the intro, and the back-and-forth with the guest begins. In the first episode, Patrick Sauer is invited to opine on whether Ron Paul masturbates to ‘Atlas Shrugged‘. A touchy subject if there is one (no pun intended… sort of). The clips last for around 30 minutes, and are highly entertaining.

Once it becomes live to the general public, a yearly subscription will cost $26, which is very good value for money. Right now, content is optimized for the iPad, but you can still read it in a desktop browser such as Safari or Chrome – Firefox was quirky at times, with random Javascript events being triggered for no apparent reason. Maybe it’s Firebug, but I didn’t investigate further.

Grumpy old git – things that could improve

As I’m an anal-retentive asshole when it comes to user interfaces and usability, I have a few constructive criticisms to make. First, on being iPad-optimized, and the very first thing you see when you arrive at nsfwcorp.com – the login form.

Before digging in, one curiosity for those technically-minded: there is almost no “normal” HTML in the site’s source. Each page is a collection of Javascript includes, which generate content dynamically. This has one advantage in being able to adapt to user browser & device specifics without much server-side heavy lifting, for example, by making use of jQuery’s deviceAgent.match (in this case, to send iPhone users to comingsoon.html – bastards!).

So without further ado, here is the Javascript-generated login form:

Nothing really much to it – however, this is the HTML source for the two fields:

<input name="username" id="loginUsername" placeholder="Email" type="text">
<input name="password" id="loginPassword" placeholder="Password" type="password">

So by now you must be thinking “yeah, you really are an anal-retentive asshole, what about those?!“. Simply put, they are not iPad – or more exactly, iOS – optimized. One of the neat things Mobile Safari gives web developers is extra form field tags, which make the device aware of the type of input being sought, so it can adapt the keypad accordingly. This is how the login form looks on an iPad, once you tap on the ‘Email’ field (click for large version):

There are two issues here: first, we capitalize the first letter of the user’s email address, which is not really A Bad Thing™, but doesn’t look pretty. The second, and most important, is regarding usability. By using type=”email” instead of type=”text” in the form field, the user gets to see this:

which is how iOS optimizes itself for email address entry. Depending on your particular concoction of underscores and dashes, this can save you some time. The whole list of supported form types can be found here.

My second irk is the amount of screen space the header graphic takes once you get in:

Of course, you can scroll down right away and see the various articles, but having the titles of the first two cut off doesn’t look that good.

The third issue has to do with scroll position between page transitions. If you scroll down, say about half-way down, and want to read Who’s The Leader Of The Club That’s Made For You And Me (if you’ve seen Full Metal Jacket, the answer is of course Mickey Mouse):

you are dropped just below mid-page into the article, thus:

instead of here:

If you’ve read the article, the answer is, of course, Walt Disney’s head filled with blue water, a sort of eerie Magic 8 Ball.

The final issue has more to do with strategy and people’s spelling abilities – or lack thereof. Allow me to explain: how many of you have typed nswfcorp.com in your browser and have landed in a “server could not be found” page? OMG! Someone has registered that already by the time I’m typing this, I hope it’s not a spammer trying to take advantage of those who cannot spell or type that well, a-la-holders of .cm domains. Or a pissed-off ex-girlfriend of Paul’s who re-directs the domain to goatse or meatspin or worse.

Worry not, as I was typing this, I thought I’d do Paul a favor (OK, maybe he doesn’t give a shit, so maybe not) and register the domain, which I’ll transfer to him for free. When I started Whisher, it didn’t occur to me that a competitor could buy wisher.com (the correct spelling) and redirect it to his own site – a point our first VC painfully reminded me of, and which cost us $30k and convincing the Wisher sisters, owners & operators of a real estate agency in the US, and owners of the domain.

In all, nothing extremely hard to fix – I’m really looking forward to the next issue!

This is a short post distilled from hours of frustration at the mangling of App logos by Facebook. Basically, if you want this:

instead of this:

make sure you flatten your image in Photoshop, and save as a 75×75 pixel GIF, with the dithering applied in “Save for web…”. Otherwise, Facebook will take your nice, transparent PNG and convert it to GIF with whatever dithering they choose, with results usually quite crappy. Feed the right GIF, and no conversion is required nor performed.

After frustration with FreeBSD’s ports system on a slow box such as the net6501 (it took literally 7 hours and endless “continue” buttons to get subversion installed), I decided to try and install Ubuntu. No clear instructions can be found on the net as to how to do it over a serial terminal, the only option available with the Soekris, so after some mix & match of various hints and pointers, I managed to do it. Here is how.

1. My setup

My particular net6501 is the mid-range version, with a 1GHz processor, 1Gb of RAM, and an internal Transcend 16GB flash drive. I also got the case & power supply, of course.

2. Get the Ubuntu Server ISO

Easy, just grab it here (32-bit version).

3. Create a bootable USB drive

You will need at least a 1GB flash drive, 2GB is recommended. I use Sandisk or other well-known brands, less likely to give headaches. The easiest way to create the bootable USB drive is to use Ubuntu’s own Startup Disk Creator, found under System in your standard Ubuntu desktop distribution. I use Macs so I run mine inside Parallels, with no issues at all.

4. Edit the boot menu configuration

You need to find a file named txt.cfg in your bootable USB drive and open it in a text editor. You will find a line that reads:

kernel /install/vmlinuz

The line after that begins with append – it needs to end up like this:

append console=ttyS0,19200n8 file=/cdrom/preseed/ubuntu-server.seed initrd=/install/initrd.gz

You need 19200 as that is the default speed on the Soekris serial port.

5. Connect a serial cable to the Soekris

A null-modem cable is needed. I use a DB9 adapter male/female adapter and a normal serial cable.

6. Open a serial terminal

The terminal needs to support VT100 emulation. Unfortunately all terminal apps for Mac that support this are payware and suck. I ended up using Hyperterminal in a Windows XP Parallels VM. It was rock solid throughout the procedure.

Set the terminal to 19200/8/N/1, no flow control, VT100 emulation.

7. Connect the bootable USB to the Soekris

The external USB port next to the DB9 will do fine.

8. Boot up the Soekris

Once you see the 5…4…3… countdown, hit Control+P, and then type

boot 81

and hit enter. Check that 81 is your USB drive, it should appear at the start of the boot log in the terminal. Adjust as required. You should now see a boot: prompt, type “install” and enter – an Ubuntu text-based install should follow, continue with the normal setup procedure after this.

That’s all folks – the toughest part was to find the terminal settings for the menu, if you get errors related to unknown video modes, you have not edited the right file or have done so incorrectly. Enjoy!

For the record, apt-get installed subversion on the same box in 30 seconds flat. FreeBSD needs to fix its package management system. Vim on FreeBSD requires over 500 individual file downloads with over 500 fixes/patches to the base version – ridiculous!

This is a quick post – let’s compare Dropbox new TOS lines about the license you give them when you upload “stuff” to the service:

We sometimes need your permission to do what you ask us to do with your stuff (for example, hosting, making public, or sharing your files). By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services.

with Box.net’s same lines about the same license you give them:

By registering to use the Services, you understand and acknowledge that Box.net and its contractors retain an irrevocable, royalty-free, worldwide license to use, copy, and publicly display such content for the sole purpose of providing to you the Services for which you have registered. In the event that you give Box.net the right to distribute your content, additional terms may apply to Box.net’s usage or distribution of this content.  You continue to retain all ownership rights in any User Content you provide and shall remain solely responsible for your conduct, your User Content, and any material or information transmitted to other Users for interaction with other Users.  Box.net does not claim any ownership rights in any User Content.

Box.net is asking for a license to use, copy and publicly display your content, whereas Dropbox goes much further, asking for rights to distribute (which is not the same as copy), prepare derivative works, and perform (eg. play in a concert!?). The wording in bold on Box.net’s TOS is key, however, as it clearly states that this license is used for the sole purpose of providing the service you ask for. Dropbox, in turn, says extent reasonably necessary, which is extremely vague.

You said everyone else

Indeed, let’s take a look at Amazon S3′s TOS, where clause 8.2 states:

Your Submissions will be governed by the terms of the Apache Software License, unless you specify one of our other supported licenses at the time you submit Your Submission.

Does this mean your uploaded content becomes open source somehow? I’m not entirely sure how to read this one, maybe a lawyer could chip in.

Finally, a snippet from one other large cloud storage provider, Apple, and its MobileMe/iDisk TOS:

Except for material we may license to you, Apple does not claim ownership of the materials and/or Content you submit or make available on the Service. However, by submitting or posting such Content on areas of the Service that are accessible by the public, you grant Apple a worldwide, royalty-free, non-exclusive license to use, distribute, reproduce, modify, adapt, publish, translate, publicly perform and publicly display such Content on the Service solely for the purpose for which such Content was submitted or made available. Said license will terminate within a commercially reasonable time after you or Apple remove such Content from the public area. By submitting or posting such Content on areas of the Service that are accessible by the public, you are representing that you are the owner of such material and/or have authorization to distribute it.

This one is probably the one I’d be most comfortable with, as it specifically mentions that the license applies only to content placed in areas accessible to the public, such as your “Public” folder, and that the license is solely for the purpose for which the content was uploaded, eg. sharing it with the rest of the world.

To be honest, this smells of a lawsuit gone bad resulting in bulletproofing a service, maybe someone noticed his files were being served from servers in another country and sued the storage provider on non-permission to copy/distribute grounds. Then, every other lawyer copied the TOS to match. Remember that case with a woman spilling hot coffee on her lap, resulting in all take-away coffee cups showing large “this stuff is hot” labels? Yeah, exactly. There are some great posts on this topic on J. Daniel Sawyer’s blog, and on UtestMe here.

I’m going to keep this short and simple. Apple is going to buy Twitter  – here’s why:

1. There have been very few cases of such a deep level of integration into iOS with a service provided by a company many orders of magnitude smaller than Apple.
2. When such integration has taken place, but Apple didn’t acquire the company, it eventually replaced its service. Example: Skyhook & Google Wi-Fi based geolocation, now replaced with Apple’s own database.
3. Apple needs a secure way to counter-balance Facebook (thanks @om for that one!). If Twitter remains an acquisition target much longer, Facebook or Google could reel it in.

Now I just wonder if @jack will want twtrr.com back… (yeah, out of a freak coincidence, I own that one!).

This post is triggered by a Twitter exchange started last night with Glenn Fleishman on the subject of how heat affects wireless communications. His initial tweet was:

I’m not getting the love. How does high temperature prevent Wi-Fi signal propagation?

followed by others,

Ok, the stupid “temperature affects Wi-Fi” story? I read the report. The report is talking about all tower-based wireless comm (1/2)

and it says that heat could affect transmission distance (implies this), but also that heat might damage towers/backhaul (2/2)

It referenced an article on The Telegraph which quotes Caroline Spelman, UK’s Environment Secretary, saying:

The signal from wi-fi cannot travel as far when temperatures increase. Heavy downfalls of rain also affect the ability of the device to capture a signal.

The first statement is misleading and even FUD-like, while the second is true – I have personally witnessed a statewide TETRA network go down (over 200 base stations) when a heavy thunderstorm sat on top of the SwMI, with rain curtains killing all outbound wireless links (hint: star topologies with a central switching node are a no-no).

Quoting the report itself (click for larger version), four things are notable:

The first being:

Location/density of wireless masts may become sub-optimal as wireless transmission is dependent on temperature.

Cellular service and hot air

The phrase above, in my view, implies wireless services that rely on frequency re-use as part of their inherent design, such as cellular telephony and TETRA, for example. These networks are called cellular for a reason, as they are designed in individual cells with shape and coverage made to fit into a puzzle. A graphic explains this much better:

Here, we are using four frequencies to serve a total of eight cells. As can be seen, no neighboring cells use the same frequency, so the spectrum usage efficiency is doubled in this particular case. In designing cellular networks, one can increase the density of cells by decreasing their coverage, and thus increasing the capacity of the network. In a city it’s common to find cells covering 300m, whereas in rural areas I’ve been registered on cells as far as 27km away.

The coverage of each cell is configured by careful handling of parameters such as power output and sectorization using panel antennas. The following graphic illustrates how sectorization and power management helps shape a cell’s coverage (source: University of Washington in St. Louis)

With all this in mind, how could heat possibly affect the arrangement of cells in a way to make their location and density “sub-optimal”? Take a look at this:

The heat output from the chimney is causing visible light to refract, as the density of air above it changes with temperature. This is an extreme example, but illustrates the idea of the report’s claims. Visible light falls on the high end of the radio spectrum, so if it can be affected by air density, so can lower frequency wireless signals. To make a point clear,

Heat doesn’t affect electromagnetic radiation (wireless signals), density does.

A very interesting observation can be found on Rob Flickenger’s Wireless Hacks, published by O’Reily:

This displays radio data for a one-mile link, averaged over several days. You can see that in the middle of each day, the signal drops by as much as 6 dB, while the noise remains steady … The repeating pattern we see indicates the effect of thermal fade.

What they did was control the signal strength of a one-mile wireless link over several days, and noticed that during periods of higher temperature (and thus lower air density) the signal strength dropped considerably.

Thermal fading could end up being a problem in cellular networks. Refraction by density variations could affect the path of wireless signals, causing interference not by ‘range’ changes but by interference on the same frequency. Secondly, decreased density due to increased temperature could result in coverage ‘holes’ at the edge of cells, which if compensated simply by increasing output power, could then result in interference with other cells when the density decreases.

Let’s go with the second one:

Reduced stability of foundations and tower structures.

Frankly, having studied materials engineering, I fail to see how an increase of even a few degrees could compromise a tower structure.

Third:

Increased damage to above ground transmission infrastructure.

This ties in with the previous one, the only obvious issue being the increased ventilation requirements for wireless infrastructure. They have cellular networks in Dubai, which is way hotter than the UK will ever be…

And finally:

Possible reduced quality of wireless service.

In turn, this ties with the first issue – the fading problems discussed can indeed affect the quality of cellular networks.

However

Your home Wi-Fi will NOT be affected by thermal fading significantly enough for you to notice. Temperature gradients inside a home are not capable of bending your Wi-Fi signal towards the neighbor and away from your laptop.

The report, while mentioning possible issues in wireless services, fails to mention them again, and fails to provide any deeper analysis of the issues listed, or possible solutions.

Finally, Glenn later said:

Range, not re-use.

The problem, in my view, is with systems that re-use frequencies. On a single-site system, you can just increase power to compensate for any losses due to density variations, and you’re done. On a cellular system, you simply cannot do that. I feel Glenn admits to this when he tweets

@alfwatt Anyway, she said Wi-Fi, but the report is talking about cellular infrastructure.

Cheers!

After reading about Sony’s major clusterf… cock-up on their PSP network breach, and how up to 77 million accounts could have been stolen, including credit card data, I propose a method to cure the generic problem of storing customer payment details for recurring billing, such as subscriptions or subsequent purchases.

Step 1. Payment gateway provides business with an individual public encryption key

Upon setting up a payment gateway for processing credit card payments, the business, in this case, Sony, would be issued a public key – be it by the bank if they deal directly with them, or a payment gateway such as RBS.

Step 2. Business encrypts credit card data with public key before storage

PCI DSS specs for storing credit card data securely call for very strong access control, encryption and accountability, but this is not viable against sloppy employees, loss of encryption keys that protect the card data, and so on. Once you have a break-in, if you keep the keys to the safe in the office your valuables are completely naked. With a public key, you are effectively storing the safe’s keys somewhere else. This is how the process works, schematically (click for large size):

Step 3. User makes a purchase

Once the user decides to make a purchase, or has to be billed for the month’s service, the business pulls the encrypted credit card data off its database, combines it with the purchase price and other required information, and sends it to the payment processor for authorization. The payment processor can decrypt the credit card data with its private key, and can thus process the transaction normally:

What does all this solve?

• Users only hand over their credit card data at the start of the relationship, and the data is never stored by the business/merchant.
• Merchant doesn’t keep credit card data that can be recovered, even by a corrupt employee or full-blown data breach.
• Encrypted card data cannot be used in replay attacks in other places, or by other merchants, as the public-key is issued per-merchant.
• If a breach takes place, all the payment gateway needs to do is to revoke the public key and destroy the private key, thus card data cannot be compromised.

All this would obviously cost time and money to implement, but in my view it would be a big step forward in keeping customer credit card data secure.