To recap a bit, the problems are random reboots of the keyboard, disconnections of keyboard and mouse, erratic mouse behavior (including spontaneous motion of the cursor), and repeated keystrokes after the keyboard has not been used for a few minutes (resulting in things like “aaaaaaaafter the news…”). In all, a very frustrating and annoying experience, for a rather expensive combo. Logitech seem to acknowledge the problem, but I have not yet seen any form of update that could fix this, and my theory is that the problem cannot be fixed with a simple software update.

Declaring the keyboard and mouse defunct, I performed an autopsy, which revealed a few interesting facts (details after the jump):

• The Bluetooth dongle has a very very strange RF design – it uses a normal groundplane meander PCB antenna, but then it has a copper-wire loop antenna on top.
• Dongle and keyboard use Bluetooth chipsets from different manufacturers (CSR and Broadcom), in theory interoperable, in reality…well.
• The touchpad uses a very crappy sensor design, which explains the lack of responsiveness and uselesness of the scrolling controls.

Let’s start with the dongle. Below are a couple of photos of the opened device, the first with the loop antenna in place, the second with it removed, showing the meander. If someone with better RF knowledge than me can explain why this makes sense, I would be grateful. The design of the loop itself is wrong for 2.4GHz, having a wire length about 10 times larger than what would be required given its size.

The dongle uses a Broadcom BCM2045 chipset, with a 4Mbit flash memory onto which the firmware is loaded. The meander is a PCB track designed for 50ohm impedance, coupled to the chipset via a normal inductor-resistor-inductor matching network. Noticeable is the lack of baluns or filters, I’ll have to check the datasheet (if it’s publicly available) on this aspect.

Let’s take a look at the keyboard, starting with the touch controls. These are built into the keyboard as a separate module, linked to the main control board with a flat ribbon cable, and consist of three main pieces – the PCB and touch sensors, external case with printed cover, and a plastic support with built-in LED light pipes. The controls are made with a layer of gold-plated copper, printed on the underside of the PCB, and on the top side lives the control chip, made by Synaptics (who also makes touchpad systems and other stuff).

The principle by which these type of controls work is capacitance changes. When you place your finger near the sensor, a capacitive effect takes place (using the air and any other material in between as dielectric), which can be measured. It is very small, but enough to give an indication that a finger is present. There are a few rules that one must follow when designing such touchpads, as any interference in the capacitive effect can have negative results on the ‘feeling’ of the controls. Namely, ground planes have to be carefully controlled, and usually placed away from the sensor area, the sensors have to have a minimum size in order to be effective, and any trace routes from the sensor pad to the control IC have to be kept tight, avoiding cross-overs and other disturbances.

I am not familiar with the Synaptics chip, but I have worked with Quantum Research QProx devices, and I cannot see how the physics of capacitance could be avoided in either case. The MX5000 design violates all these rules. The sensor areas are irregular, with a gaping hole in the middle to allow for LED light to pass through, there are ground planes all over the PCB, the tracks meet and part at various spacings and passing right next to ground planes. The biggest joke seems to be the ’sliding’ sensors for the volume and zoom. These are depicted on the face of the keyboard as smooth analog paths, as if one could go from minimum zoom or volume to maximum by sliding the finger to each end of the vertical scale. The truth is that to change the volume in any significant way, one has to repeatedly slide the finger along the whole path of the scale several times, and in some cases, the detection doesn’t work. You end up looking demented, rubbing away the side of your keyboard repeatedly! As is shown on the photo, the sliding scale has only 7 distinct sensors, thus giving you a maximum of six detectable steps in either direction (each step is signaled by the triggering of one sensor, then the one adjacent, determining direction of finger travel). It would be a bad idea to place the whole volume or zoom range on a scale of six steps, and so they settled for the crazy-monkey-rubbing-keyboard action instead.

The next two pictures show the PCB inside the plastic assembly that houses the faceplate. Notice how the cutouts allow for light from the LEDs to be piped towards the labels and icons.

And finally, the last part of the broken equation – the Bluetooth module on the keyboard. It uses a CSR BlueCore3 ROM, which is cheap but cannot have its firmware modified after the die has been printed, meaning whatever bugs you had in the device will be there forever. Again, the module uses a meander antenna. Now, I am not too familiar with the Broadcom chipset, but I have worked with CSR chipsets quite a bit, and know they provide a balanced antenna output, this means that to use an antenna such as a meander or chip, you have to go through a balun. I don’t see a balun on the MX5000’s module, and so it appears they have attempted to balance the antenna with another set of meanders, which can be seen between the chip and the large main meander in the picture below:

Again, this design doesn’t seem to be the best in terms of RF performance, specially when you have a large inductor nearby (L1).

Conclusion? Don’t buy one of these, if you want to go wireless, get one of the non-Bluetooth (some also work at 2.4GHz) keyboard/mouse combinations, and I would still say get a Logitech, as they make some very good ones, such as the MX3000. I’ve always used Logitech, but the MX5000 has been a real lemon.

Spotted the problem yet? Radio antennas are affected by any element that is present around them, even non-metallic elements, such as the ground. In this particular case, kanijo, a Fonero, has attempted to provide more “range” to his FON hotspot, which is in itself commendable, however, the means may not result in the desired end – original FON forum thread here.

You can see that the vertical omni antenna, a carefully tuned radiating element, has been strapped to a metallic pole, which also runs a coaxial cable into a TV antenna right on top. The router is inside a sealed plastic box, with power and Ethernet going into it from below. There is no way that this antenna is radiating correctly, as the pole that supports it is probably grounded (if it has been installed according to regulations), and even if it is not, it is inducing an imbalance into the tuned element, causing a large amount of RF to be attenuated. The user reports good results with it, which are most likely due to good luck.

The second problem with this type of setup is that vertical antennas don’t emit downwards, and thus will provide very limited coverage to users below the antenna. There is some downwards bleed of course, but it will only reach lower users that are some distance away from the antenna.

Recommendations for these sort of setups: install the antenna right at the top of its own pole, and ground the pole. If you have no choice but to use an existing pole, get a T arm fitting and mount the antenna at least 1 meter (3 feet) away from the pole. A perfect example of such as setup, in this case with two supports as the antenna is rather large and care for wind load is needed, is this (credit to Roger Halstead):

Check out Roger’s page, it is a very good read if you are interested in radio installations.

• Riding the train or bus home.
• Getting a lift from a friend in his/her car.
• Opening your laptop at a random location (cafeteria, bar, etc. that you haven’t before scouted for open WiFi).
• On a plane, waiting for the next free takeoff slot that you hope the pilot won’t miss because he was checking the fatness of his wallet.

Let’s be honest – free open WiFi is great once you have identified the locations where you can get connected, such as a friend’s house or the local coffee shop. Other solid commercial alternatives make it easier to find WiFi, as they tend to be present at well-known locations. Walk into any Starbucks or hotel, and you’re bound to find at least for-pay wireless.
For me, on the 30 minutes to 1 hour it takes to get home on the train or bus, being able to get connected is great. The convenience of simply opening the Mac and getting online beats the guesswork of WiFi. I tried getting the Mac working with my Nokia N93 over Bluetooth, but it was just too unstable – one day it worked, the next simply refused to even connect. A more in-depth review of the device is coming, once I get a chance to roam about with it for a while.

So far, installation on the Mac was pretty straightforward, download the setup package from Vodafone’s site (they don’t tell you this in the manual), which then enables the modem as a networking device. If you don’t follow this step, it can get recognized as a storage device, which is not particularly useful for a modem. The one thing I don’t understand is why it comes with a miniUSB cable that ends in two USB connectors, my guess is it’s power-related (some USB ports don’t provide the full 500mA they are supposed to provide).

The only course of action? To open it up even more. So, the aluminium chassis came off, and that’s when I realized I had seen this before. The WiFi section, which includes the Atheros AR2315, crystal, filters, power amplifiers and ancilliary circuitry are housed inside this casing, and correspond to a reference design provided most likely by Atheros themselves. Check out the Meraki Mini router. For reference, I provide a side-by-side picture below (click for large image).

This is further confirmed by looking closely at the Atheros website section on the AR2315, where we find the following picture:

There is nothing wrong with using reference designs per se, as it is the fastest and easiest way to bring a product to market. If you don’t need to customize your design much, simply use what the manufacturer suggests, and you will be playing on the safe side. A perfect example is Bluetooth headsets, where CSR dominates the market. Virtually all headsets in the market use their reference design, with very little changes between them, other than physical placement of LEDs and buttons.

Block-by-block, here is an overview of the Fonera.

Power

Power is supplied to the Fonera via jack SK1, and is fed through a rapid fuse (Polychem type) to a simple drop-down regulator, which drops voltage from around 5V (4.85V as measured on the wall power supply, using a Fluke 179 multimeter) to 3.3V. The regulator appears to be an AME1117 (though the package markings read AME117), in its CCCT configuration, TO-252 form factor. The regulator is stabilized using three electrolyic capacitors. In these types of regulators, ESR (equivalent series resistance) of the input decoupling capacitors is very important, and this can usually be controlled nicely with tantalum capacitors. These are very expensive compared to electrolytic, however.

There is a second stage of regulation, this time done by an Anpec APL1117, which further drops the voltage to 2.5V. This supply appears to be used by the wireless subsection. Two ceramic capacitors stabilize the regulator.

Without the Atheros chip in place, the PCB drew 90mA at 5V, or 450mW. Since the device was not functioning, the total supply current with WiFi active could not be determined.

Memory

Two memory ICs are available on the Fonera, the first is an ST M25P64 serial flash, with a 50MHz SPI bus and 64Mbit capacity (8MB), in 300mil SO16 format. The fact that SPI has been chosen has the advantage that extra memory devices could be attached to the bus, but it has the caveat that it is slower than a parallel bus. Thus, flashing a new firmware could take a rather long time. Interestingly, there are two footprints on the PCB, presumably to fit a different size and format memory IC, one SO16 and one SO8.
The second memory IC is a Hynix HY57V281620E synchronous DRAM, with a capacity of 128Mbit organized in 16bit blocks. In practice, this results in 16MB of RAM available to the processor.

Ethernet

At the heart of the wired ethernet subsystem is an Altima AC101 ethernet transceiver, capable of 10/100 full duplex operation. The IC is placed on the bottom layer of the PCB, and runs off a 25MHz crystal, strangely placed next to the main power regulator, where it could absorb electrical noise. Usually, crystals are placed well away from sources of interference. Nothing else too exciting here, the transceiver is connected to a standard RJ45 socket, TP1.

Wireless

The wireless section is the most interesting. This is where the Atheros AR2315 single-chip WiFi processor lives. Little public information is available about this or any other Atheros chipset, so it is hard to figure out exactly how it is put in place, but a few details are clear.

First, the chip gets hot. This is why a double heat-conductive adhesive tape bonds the surface to the metal cover, and in turn to the heatsink placed on top. The processor runs from a 40MHz clock source. After the Atheros core, come a couple of filters, and a power amplifier stage. This then runs off to the two antenna tracks. The first antenna exits the aluminium cage and runs up to a test connector. This connector breaks the antenna track when the right mating plug is inserted, which is then fed into a dedicated RF analyzer, which validates that the device is within constraints.

After the antenna test point, there is a split, which can be configured using a zero-ohm resistor, to run to an internal solder pad, or to a PCB-mounted right-angle SMA connector. It is unclear why they chose to use the solder pad, as an in-place soldered connector needs less handling than soldering a pigtail by hand. Besides, my intuition tells me the losses would be lower – I will test this when I get a working Fonera. Both tracks run through an impedance matching network, consisting of two capacitors to ground from the RF track, and an inductor between the capacitors . The purpose if this small circuit is to get the impedance of the PCB track as close to 50 ohms as possible. If the track impedance is mismatched to the antenna, losses take place.

The second antenna runs straight to a PCB pad, where a pigtail may be soldered, also passing a matching network. Below is a picture showing the details of this subsection.

Interfaces

There are two IDC-style connectors on the PCB, one 2×5, and one 2×7 but unpopulated. The 2×5 looks like a serial connector, as only power, ground and two tracks lead out from it. The layout has to be studied in more detail to confirm this assumption.
It can be speculated that this is in fact a serial port, but without the AR2315 pinout, this cannot be determined for sure. The 2×7 header seems to be a JTAG interface, possibly compliant with MIPS EJTAG 2.6. The mapping of the header pins to the AR2315 BGA balls is shown below (thanks for adding a row/column silkscreen for the Atheros chip, and thanks to the OpenWRT project wiki for the JTAG information!):

Between the Ethernet jack and the empty SMA footprint, there is a footprint of 6-way header, which needs a bit more study to determine where it leads internally [I will update the post when I find out –Mike].

Conclusion

This is a very compact and simple WiFi router, designed not for being easy to hack, but for lowest cost. The cheap power regulator, use of large SMDs and choice of pigtail rather than board-mounted SMA connector point in this direction. There is only one port which could be used for something useful, if it is indeed a serial port, the only two GPIOs available being the WLAN and Ethernet LEDs – as long as the Ethernet LED is not controlled by the Altima but by the Atheros. The power LED is on as long as there is power applied to the device, so there is no control over this by the Atheros processor. Power consumption is a bit high, considering the wireless device was not present. The PCB layout is very professional, except in a few particular cases such as the large crystal, but overall, quite nice.

In all, a very small device which could have a lot of potential, had it not been for its lack of I/O. It is unclear whether the router will accept custom firmware, as there are rumors that an encryption & signature system is used. The Fonera is probably OK for regular use by Foneros, but it does not have the hackable edge of the Linksys WRT54Gx. The only suprise could come from the edge connector, as of yet of unknown usefulness.

References

Atheros AR2315 chipset website section and product brief.

A full review is coming, but first impressions:

• The plastic casing looks and feels very nice, the molds must have been expensive, as the different parts mate very well.
• Inside lives a single PCB, with components on both sides. The top holds the bulkier components, such as power regulator, RAM and WiFi section, inside an aluminium RF shield.
• The PCB looks professional and well laid out on first inspection.
• Components used (I haven’t opened the aluminium chassis yet) are older SOIC and TSSOP, thus cheaper to handle and solder. Balled components require from special handling, such as baking in hydrogen for 24 hours to dry them before soldering, etc.

Here are some pics (click each photo for bigger views on Flickr) I have taken with a Nokia N93 (really nice phone btw, mini-review coming):

The underside of the case, with screws off.

Perspective view of the top PCB.

Bottom side of the PCB.

Sticker on the flash IC showing the firmware version.

Me and a friend installed the FireFox plugin, and fired it up. To start with, the buddy search mechanism is terrible. I actually typed my friend’s name, got a result, and added it to my roster – turns out it wasn’t even his profile. You cannot see details about the search results, which is a problem. With Skype, for example, sometimes you can turn up a dozen of hits on a buddy search, but at least you can get an idea of who is behind each result.

Once added a friend, it was time to share some files. I added a couple to my shared folder, and the files showed up there. My friend could not see them. I refreshed, and the files dissapeared. By the time I ended the test and decided to remove the plugin, I still hadn’t managed to get the files to stay put. My friend shared one file. It showed up twice on my screen (?!). The actual download of the file went well, but after that, the files also dissapeared from his screen.
There are a lot of bugs as it stands – at one stage, I had a buddy selected, but the screen showed “When ABC shares some files, you will see them here”, where ABC was my nickname. When I removed a buddy from my list, I could still see his shared files until I changed the folder view!
Frankly, platforms such as Pando work much better in terms of stability and ease of use. I am sure AllPeers will eventually iron out the issues, but right now, the service is a non-starter. This post also talks about the system being built upon a bug in FireFox, which when fixed will kill its ability to work as a P2P endpoint – any confirmation on this?

There was plenty to see and do, from conferences as interesting as war-rocketing to an insight into the US-VISIT program, and it’s plans to implement RFID tags into the green visa waivers, or the 2D barcode receipts given out at airports.

I participated in the wardriving events, organised by Thorn, and which consisted of the Running Man and Fox Hunt competitions. Our team was led by Renderman, and we had some backup that put up some noise (fake APs, floods, etc.) to make the contest more interesting.

The Running Man started well, but unfortunately the other team tripped casino security by walking past their booth with a magmount omni antenna on each shoulder, a laptop, several WiFi cards dangling from their belts, a YellowJacket, and other gear – apparently, the IT guys freaked out, and they wanted the contest shut down. After the intervention of Ross and Priest, we were allowed to carry on, but limiting the search area to the venue, and not the whole casino. After the contest resumed, we found the Running Man in around 15 minutes, and won!

The second contest, Fox Hunt, consisted of a hidden WRT54G that was only on for 15 seconds every minute. One was supposed to locate the fox, connect to it, and change the SSID after brute-forcing admin account. 15 seconds to do all that is not a lot! So, our plan was to locate the fox….and make a run with it to a safe place, so we could kill the 15 second timer circuit, reduce the amount of RF leaking out and have a go at changing the SSID. The first part of the plan went well, but then the other team got slightly miffed, called Thorn, who in turn called us to go back to the contest table with the WRT so the other team could also have a go at it.

Interestingly, Thorn had taped the admin password to the bottom of the router, but neither team noticed it! In fact, the other team ended up brute-forcing the AP and changing the SSID. We contested that since when we removed and reapplied power to the AP, the SSID went back to its default, we had in fact won, but Thorn wasn’t having any of it. The contest was a tie, which was decided by the question “Who owns the OID 00:00:00?”, the answer to which is Xerox. We got it wrong, and so we lost. Next year we will be better prepared for sure.

Here are a few pictures from the event:

Thorn and Renderman giving their presentation on the Church of Wifi, with CoWPatty, the WPA rainbow table generator, and the WRT54G mods, which included my WaRThog.

The war-rocketing guys, and their awsome rocket. I wonder how they got that thing past airport security.

The WaRThog on the left, with two more of CoWF’s modified WRT54Gs.

If you used DEFCON’s wireless network to check your email, access your corporate network, etc., but didn’t use any form of security (VPN, SSH…), you are bound to be in the Wall of Sheep. It displays captured user names, passwords, domains and access methods – I actually had the two colleagues travelling with me show up here, even though I told them to not even open their laptops while at the con.

See you next year!

[DG+01] M.C.A. Devillers, W.O.D. GriAEoen, J.M.T Romijn, and F.W. Vaandrager. Verification of a leader election protocol — formal methods applied to IEEE 1394. Technical Report CSI-R9728, Computing Science Institute, University of Nijmegen, December 1997. Also, Formal Methods in System Design, 2001.

This model describes a leader election protocol used in Firewire, an IEEEstandard for connecting consumer electronic devices. The model is a straightforward translation into Alloy of a model [DG+01] developed in Lynch’s IO Automata which has been analyzed using PVS, a theorem prover, but which, as far as we know, has not been subjected to fully automatic analysis. We are able to express the key correctness property — that exactly one leader is elected — more directly, as a trace property rather than a refinement property, and can check it without the need for the 15 invariants used in the more traditional proof. And the analysis does not hardwire a particular topology, so would be tricky to do with a standard model checker.

The network is assumed to consist of a collection of nodes connected by links. Each link between a pair of nodes is matched by a link in the other direction. Viewing a link and its dual as a single, undirected edge, the network as a whole is assumed to form a tree. The purpose of the algorithm is to construct such a tree; in the model, this is achieved by labelling some subset of the links as parent links (each pointing from a node to its parent), and by marking a single node as the root.

The algorithm, described in detail elsewhere [DG+01], works briefly as follows. When a node detects that all of its incoming links (or all but one) has been marked as a parent link, it sends a message on each outgoing link, either an acknowledgment (indicating its willingness to act as parent), or a request (indicating its desire to be a child), according to whether the dual of the outgoing link has been marked or not. Leaf nodes (with only one incoming link) may thus initiate the algorithm by sending requests to their adjacent nodes. Performing this action changes a node’s status from {\em waiting} to {\em active}. A node that is still waiting, and which receives a message on a link, may label that link a parent link. Once active, a node that receives an acknowledgment on a link may also label the link, but if it receives a request, instead changes its node status to {\em contending}. The resolving of contentions is modelled simplistically by a single action that arbitrarily
labels one of the two links a pair of contending nodes. Finally, a node all of whose incoming links are parent links designates itself a root.

The specification is given below. Each signature introduces a basic type and some relations whose first column has that type:

\begin{itemize}

\item {\em Msg} represents the type of messages. {\em Req} is the request message and {\em Ack} is the acknowledgment message; these are actually declared as singleton (keyword {\em static}) subsets of {\em Msg}, the set of all messages, that form a partition (keyword {\em part}).

\item {\em Node} represents the nodes of the network. The relations {\em to} and {\em from} associate each node with a set of incoming and outgoing links
respectively.

\item {\em Link} represents the links. The relations {\em target} and {\em source} map a link to its end nodes; {\em reverse} maps a link to its dual. The
facts in the signatures {\em Node} and {\em Link} ensure that all these relations are consistent with one another: that the incoming links of a node are those whose target is that node, etc.

\item {\em Op} introduces a set of names for the operations of the protocol. This is merely for convenience; it allows us to ask for an execution in which named operations occur, or example.

\item {\em State} represents the global states. Each state has a partition of the nodes into one of four statuses: {\em waiting} to participate, {\em active} (having sent messages on outgoing links), {\em contending} (having sent a request on a link and received a request on its dual), and {\em elected} (having designated itself as a root). A set of links are labelled as parent links. There is a message queue associated with each link. Finally, the state is associated with the operation that produced it.

\item {\em Queue} represents the message queues. Each queue has a slot that optionally contains a message; the relation {\em slot} is a partial function from queues to messages. In our first attempt at a model, we represented a queue as a sequence (a partial function from a prefix of the integers to messages), but having checked that no queue ever contained more than one message, we simplified the model. The {\em overflow} field is included just in case this was a mistake; a write to a queue that already contains a message puts an arbitrary value there, which is easily detected.

\end{itemize}

The {\em facts} record the assumptions about the topology. The one named {\em Topology} says that there is some partial function on nodes and some root such
that (1) every node is reachable from the root ({\tt *r} being the reflexive transitive closure of the relation {\tt r}); (2) there are no cycles (expressed by saying that the transitive closure has no intersection with the identity relation on nodes); and (3) the relation obtained by following the {\em source} relation backwards (from a node to the link for which it is a source), and then the {\em target} relation forwards (from the link to its target) is this relation, plus its transpose (so that each tree edge becomes two links). Although the quantifier appears to be higher-order, it will be skolemized away by the analyzer.

The {\em functions} of the model are parameterized formulas. The function {\em Trans} relates a pre-state {\tt s} to a post-state {\tt s’}. It has a case for each operation. Look at the clause for the operation {\em WriteReqOrAck}, for example. If this operation is deemed to have occurred, each of the constraints in the curly braces must hold. The first says that the labelling of links as parent links is unchanged. The second constraint (the quantified formula) constrains with respect to the node at which the operation occurs. The subformulas, from first to last, say that the node belongs to the waiting set before and the active set afterwards; that there is at most one ({\em sole}) link that is incoming but not a parent link in the pre-state; that there are no changes to node status except at this node; that a message is queued onto each outgoing link; and that queues on all other links are unchanged.

An ‘invoked’ function is simply short for the formula in its body with the formal arguments replaced by the actual expressions. {\em WriteQueue}, for example, says that if the queue’s slot is not filled in the pre-state, then the new queue in the post-state (given the local name {\tt q}) contains the message {\tt m} in its slot, and has no message in its overflow. Otherwise, some message is placed arbitrarily in the overflow, and the slot is unconstrained. In {\em WriteReqOrAck}, the arguments {\tt s} and {\tt s’} are bound to the {\tt s} and {\tt s’} of {\em Trans}; {\tt x} is bound to one of the outgoing links from the set {\tt n.from}; and {\tt msg} is bound either to the acknowledgment or request message.

The function {\em Execution} constrains the set of states. It makes use of a library module that defines a polymorphic ordering relation. The expression {\tt Ord[State]} gives an ordering on all states. The two formulas of the function say that {\tt Initialization} holds in the first state, and that any pair of adjacent states is related by {\tt Trans}. The function {\em NoRepeats} adds the constraints that there are no equivalent states in the trace, and that no stuttering occurs.

The three assertions are theorems for which the analyzer will search for counterexamples. They assert respectively that: in every state of the trace, there is at most one node that has been elected; that there is some state in which a node has been elected; and that no queue overflows.

The rest of the model is a collection of commands executed to find instances of the functions or counterexamples to the theorems. We started by presenting a variety of functions as a sanity check; here, only one is given, that asks for an execution involving 2 nodes, 4 links, 4 queues and a trace of 6 states. The standard semantics of these {\em scope} declarations in Alloy is that the numbers represent an upper bound, so an instance may involve fewer than 4 queues, for example. The ordering module (not shown here), however, for technical reasons, constrains the ordered set to match its scope, so a trace with fewer than 6 states will not be acceptable.

We then established some bounds on the diameter of the state machine for various topology bounds. For 2 nodes and 2 links, for example, there are no non-repeating traces of length 4; checking traces of length 3 is thus sufficient in this case. The number of queues was limited to 5, to accommodate the empty queue, a queue containing an {\tt Ack} or {\tt Req}, and each of these with overflow. For 3 nodes and 6 links, a trace length of 8 suffices.

We then checked that for these various topology bounds, the queues never overflow. Finally, we checked the correctness properties, taken advantage of the earlier results that justify the short traces and queues. We are thus able to verify the properties for all topologies involving the given number of nodes and links, without any assumptions about trace length, queue size or the particular topological structure.

*/

module firewire_leader_election
open models/ord

sig Msg {}
static part sig Req, Ack extends Msg {}

sig Node {to, from: set Link} {
 to = {x: Link | x.target = this}
 from = {x: Link | x.source = this}
 }

sig Link {target, source: Node, reverse: Link} {
 reverse::source = target
 reverse::target = source
 }

– at most one link between a pair of nodes in a given direction
fact {no disj x,y: Link | x.source = y.source && x.target = y.target}

– topology is tree-like: acyclic when viewed as an undirected graph
fact Topology {
some tree: Node ?-> Node, root: Node {
 Node in root.*tree
 no ^tree & iden [Node -> Node]
 tree + ~tree = ~Link$source.Link$target
 }
}

sig Op {}
static disj sig Init, AssignParent, ReadReqOrAck, Elect, WriteReqOrAck,
ResolveContention, Stutter extends Op {}

sig State {
 part waiting, active, contending, elected: set Node,
 parentLinks: set Link,
 queue: Link ->! Queue,
 op: Op — the operation that produced the state
 }

fun SameState (s, s’: State) {
 s.waiting = s’.waiting
 s.active = s’.active
 s.contending = s’.contending
 s.elected = s’.elected
 s.parentLinks = s’.parentLinks
 all x: Link | SameQueue (s.queue[x], s’.queue[x])
 }

fun Trans (s, s’: State) {
 s’.op != Init
 s’.op = Stutter => SameState (s, s’)
 s’.op = AssignParent => {
  some x: Link {
   x.target in s.waiting & s’.waiting
   NoChangeExceptAt (s, s’, x.target)
   ! IsEmptyQueue (s, x)
   s’.parentLinks = s.parentLinks + x
   ReadQueue (s, s’, x)
   }}
 s’.op = ReadReqOrAck => {
  s’.parentLinks = s.parentLinks
  some x: Link {
   x.target in s.(active + contending)
    & if PeekQueue (s, x, Ack) then s’.contending else s’.active
   NoChangeExceptAt (s, s’, x.target)
   ! IsEmptyQueue (s, x)
   ReadQueue (s’, s, x)
   }}
 s’.op = Elect => {
  s’.parentLinks = s.parentLinks
  some n: Node {
   n in s.active & s’.elected
   NoChangeExceptAt (s, s’, n)
   n.to in s.parentLinks
   QueuesUnchanged (s, s’, Link)
   }}
 s’.op = WriteReqOrAck => {
  – note how this requires access to child ptr
  s’.parentLinks = s.parentLinks
  some n: Node {
   n in s.waiting & s’.active
   sole n.to – s.parentLinks
   NoChangeExceptAt (s, s’, n)
   all x: n.from |
    let msg = if x.reverse in s.parentLinks then Ack else Req |
     WriteQueue (s, s’, x, msg)
   QueuesUnchanged (s, s’, Link – n.from)
   }}
 s’.op = ResolveContention => {
  some x: Link {
   let contenders = x.(source + target) {
    contenders in s.contending & s’.active
    NoChangeExceptAt (s, s’, contenders)
    }
   s’.parentLinks = s.parentLinks + x
   }
  QueuesUnchanged (s, s’, Link)
  }
}

fun NoChangeExceptAt (s, s’: State, nodes: set Node) {
 let ns = Node – nodes {
 ns & s.waiting = ns & s’.waiting
 ns & s.active = ns & s’.active
 ns & s.contending = ns & s’.contending
 ns & s.elected = ns & s’.elected
 }}

sig Queue {slot: option Msg, overflow: option Msg}

fun SameQueue (q, q’: Queue) {
  q.slot = q’.slot && q.overflow = q’.overflow
 }
 
fun ReadQueue (s, s’: State, x: Link) {
– let q = s’.queue[x] | no q.(slot + overflow)
 no s’.queue[x].(slot + overflow)
 all x’ != x | s’.queue[x'] = s.queue[x']
 }

fun PeekQueue (s: State, x: Link, m: Msg) {
 m = s.queue[x].slot
 }

fun WriteQueue (s, s’: State, x: Link, m: Msg) {
        let q = s’.queue[x] |
 no s.queue[x].slot =>
  ( q.slot = m && no q.overflow),
  some q.overflow
 }

fun QueuesUnchanged (s, s’: State, xs: set Link) { 
 all x: xs | s’.queue[x] = s.queue[x]
 }

fun IsEmptyQueue (s: State, x: Link) {
 no s.queue[x].(slot + overflow)
– let q = s.queue[x] | no q.(slot + overflow)
 }
 
fun Initialization (s: State) {
 s.op = Init
 Node in s.waiting
 no s.parentLinks
 all x: Link | IsEmptyQueue (s, x)
 }

fun Execution () {
 Initialization (Ord[State].first)
 all s: State – Ord[State].last | let s’ = OrdNext(s) | Trans (s, s’)
 }

fun NoRepeats () {
 Execution ()
 no disj s, s’: State | SameState (s, s’)
 no s: State | s.op = Stutter
 }

fun NoShortCuts () {
 all s: State | — remove this to speed up analysis – Ord[State].last – OrdPrev (Ord[State].last) |
  ! Trans (s, OrdNext(OrdNext(s)))
 }

assert AtMostOneElected {
 Execution () => all s: State | sole s.elected
 }

assert OneEventuallyElected {
 Execution () => some s: State | some s.elected
 }

assert NoOverflow {
 Execution () => all s: State, x: Link | no s.queue[x].overflow
 }

run Execution for 1 Ord[State],  7 Op, 2 Msg,
 2 Node, 4 Link, 4 Queue, 6 State

– solution for 3 State but not for 4 State
run NoRepeats for 1 Ord[State],  6 Op, 2 Msg,
 2 Node, 2 Link, 2 Queue, 4 State

– solution for 8 but not 9 State
run NoRepeats for 1 Ord[State],  6 Op, 2 Msg,
 3 Node, 6 Link, 6 Queue, 9 State

– only 5 queues needed: just count
– no solution: establishes at most 3 queues needed
check NoOverflow for 1 Ord[State],  6 Op, 2 Msg,
 3 Node, 6 Link, 5 Queue, 9 State

check AtMostOneElected for 1 Ord[State],  6 Op, 2 Msg,
 3 Node, 6 Link, 3 Queue, 9 State

check OneEventuallyElected for 1 Ord[State],  6 Op, 2 Msg,
 3 Node, 6 Link, 3 Queue, 9 State

For some obscure reason which they don’t make public, but one can guess emanates from the RIAA, Apple does not allow you to purchase music or other content in their iTunes stores, unless you are from the country that the store belongs to. So, a UK citizen cannot buy music in the US iTunes store, and so on. Fine. Whatever DRM was for…

It is very frustrating to see that in your music store, Bowling for soup only has some 70 songs available, whereas the US music store has 150 songs.

Being based in Barcelona, Spain, I was stuck in the spanish iTunes store. The Office videos (both seasons), were however stuck in the US iTunes store. I would have been quite happy to pay the $2 they asked for each show. I firmly believe in paying fair prices for good, reliable content, and so I set about trying to break down the barriers set against being a satisfied costumer.
Round 1: Direct attempt

My first attempt was to create a US-based account, using a good friend’s address, and my own credit card. This is an address where I have actually lived for some time, so I consider it in my heart as ‘home’ – it’s not just an address of someone I met on the net.

The attempt failed completely, as the iTunes signup process checks the address of the credit card, matching it against the address you say you live at. I was quite amazed that the system also checked the zip code, state and address – it wasn’t going to take any rubbish you threw at it.

Round 2: The back door

iTunes gives you two basic payment methods: credit cards and PayPal. So, I thought about creating a PayPal account with the US address, add my credit card and verify it, then try to get iTunes to accept it. Maybe the process would somehow dilute the geocoding wrath of Apple’s DRM.

The first part seemed to work – I created the PayPal account, and it allowed me to verify my credit card. I will probably deal with PayPal’s verification methods in a sepparate post.

Next step was to create the iTunes account, choosing PayPal as your payment system. The iTunes client then opens your web browser, and points it to PayPal, where you are asked to confirm you want to accept charges coming from the music store.

The iTunes account was finally created, and it allowed me to browse content in the US music store. Searching for The Office videos, I saw both seasons were available, and clicked the purchase button for the pilot episode of season 1. Success! iTunes downloaded the episode, which I added to my iPod’s library, and watched it great satisfaction.

A while later that evening, an email from iTunes arrives – they have a problem charging my purchase of a single $2 video to my PayPal account. So, I log into the PayPal account to see what’s wrong, and I’m greeted with a flurry of disputes to be resolved. The most devastating one is that I have to “confirm my identity” by adding a US-based bank account, something you can only have if you physically open it at a US branch, thus needing to confirm your identity and address, and so on.

After this, I received another couple of emails from both PayPal and iTunes, one saying iTunes had cancelled their invoicing agreement, the other saying they had frozen my account, in all, total defeat.

Round 3: The alternatives

After the disconcerting experience with iTunes, I looked around at alternatives, and was pointed by a friend to allofmp3.com. This is a service very similar to iTunes, but with a twist. First, they are based in Russia, where a loophole exists on the trade of music in electronic rather than physical format. Secondly, they don’t use any form of DRM, and let you encode the tracks you buy in a number of formats and bitrates. And thirdly, the average album will cost you less than $2, as they charge by volume rather than quantity.

They don’t have videos, but checking sites such as TorrentSpy shows you that if iTunes won’t serve them, someone else will…