Byzantium v0.5b (Hybrid ISO image) released!

Since switching to a new BitTorrent tracker on this website (WP-Trader kept taking our site down), the link to the direct download of the hybrid ISO image for Byzantium Linux v0.5b (which is getting passed around a lot more than the other ISO image) broke.  So, here’s a replacement post:

The hybrid ISO image (which can be written to a USB drive and booted directly by Macs and PCs alike) can be downloaded from the following locations:

Here are magnet links for downloading it using BitTorrent:

Share and enjoy!

Byzantium v0.5b – Sleep Deprivation!

If you’ve been keeping an eye on our RSS feed or following hashtags on Twitter, you’ve no doubt seen a couple of badly formatted posts about the latest release of Byzantium Linux being made available.  Now that we’ve had some time to catch our breath, consider this our official announcement of the new release.  We’ve decided to call this one Sleep Deprivation because we incurred a significant amount of it while working on this release.  Life and things being what they are, it took us a little while to hit our stride because we’re operating at reduced capacity right now due to the unique summer environmental of the Washington, DC metroplex.  You’ve also probably seen a couple of new tabs on the website, among them a changelog depicting major alterations or upgrades to the distribution.  We haven’t forgotten ByzPi, the RaspberryPi port of Byzantium Linux either.  The packages and configs for ByzPi have been updated to match those in the x86 version, ensuring complete compatibility.  As always, this release is available from our download page.

At this time, we’d like to request assistance from experienced Debian packagers to help us maintain ByzPi.  Debian packaging is very new to us and we’re probably not doing a couple of things correctly.  We would like to help the Debian community by our work, but we’d like to do it in such a way that we’re compliant with Debian’s policies for packaging (which will also no doubt make our package repository easier to maintain in the future).  ByzPi changes as fast as Byzantium Linux for x86 does, which is to say, major releases only, but it’s still a very important part of the project.

After much trial and a lot of error we decided to set up our own BitTorrent tracker to make it easier to distribute Byzantium Linux.  The Pirate Bay, while very stable, helpful, and with a great community draws a lot of fire (in the form of net.censorship) and we’d like our work to get into the hands of as many people as possible.  The other trackers were problematic in one way or another, and in the interest of getting things done we decided to take matters into our own hands.  The tracker software we installed is called WP-Trader, and it implements a relatively simple yet powerful BitTorrent tracker as a function of our CMS.  It also automatically posts new releases to our news feed whenever a new torrent is added.  For additional redundancy we’ve also activated a couple of auxilliary trackers on some of our mirror sites using BitStorm, an ultra lightweight BitTorrent tracker implemented as a single PHP script.  In addition to the BitTorrent DHT, we are fairly confident that we have a robust distribution system.  We know, the formatting on our torrent descriptions is wonkky.  Unfortunately, WP-Trader doesn’t seem to have a way of editing them at this time.  As with any torrent, if you torrent Byzantium Linux please help the swarm and seed for a while so other people can download it more rapidly.

As always, if you have any suggestions or want to report any bugs, please visit our bug trackers on Github (Byzantium Linux, ByzPi).  You are also cordially invited to join our e-mail discussion list or join us in #byzantium on Freenode IRC.

Byzantium Linux v0.4b – now with packet radio support and distributed messaging!

As of this afternoon, we’ve completed the integration of amateur radio support into Byzantium Linux.  We’ve added the necessary executables and libraries to the base build, so licensed ham operators with the correct equipment can begin experimenting with packet radio and mesh networking.  We realize that support for this is a little thin right now, and after conferring with colleagues in the community we feel that the best course of action is to provide tools to facilitate further experimentation and development by both the ham radio and hacker communities.  This constitutes the third milestone of our ISC development grant.

Also, at long last, we’ve found a distributed chat application for Byzantium Linux.  It’s called Groundstation, and it uses a gossip-like broadcast protocol which aims for the eventual synchronization of datastores over high latency links.  Data is stored in Git repositories on the back end and a daemon called Airship provides a web front-end to the service.  It works a lot like Twitter or Facebook‘s comment threads, and the nice thing about it is that whatever you post on one node will show up on other nodes within a few seconds, so users don’t have to be on the same node to hold conversations.  We have a few threads set up by default which should help organize people’s messages.

These are some pretty major changes, so we’re calling this release v0.4b – yes, we’re finally in beta!  We’ve come a long way since the initial development cycle of the grant, and we’ve added some pretty major functionality to Byzantium Linux, so we think it’s worth a major version release.  We decided to name this release “No sleep ’till Brooklyn!”, after the song by the Beastie Boys as well as our marathon road trip to New York City late last year.  When considering how little sleep we got while working on this milestone it sort of makes sense.

As before, if you are a Mac user, we recommend downloading this hybrid ISO image.  Write it to a USB key with the ‘dd’ command and reboot while holding down the Option key.  Select the ‘Windows’ device to boot Byzantium Linux.  That doesn’t mean that you can’t use a hybrid ISO on a PC, some of us do and we’re quite pleased with it.

The new version can be gotten from our downloads page, where we have links to both official distribution mirrors and BitTorrent.  We’ve decided after some deliberation to only offer BitTorrent support through Terasaur, a side project of iBiblio.org.  To be honest, trying to juggle five different trackers with every release was a big job and we don’t think it was very effective.  We advise that, after downloading Byzantium Linux and its associated .asc file, that you verify the PGP signature to ensure that it’s an official release and that it hasn’t been tampered with.  After importing our public key (gpg –import byzantium.pubkey) you would do so like this (adjusting appropriately for the regular or hybrid image): gpg –verify byzantium-v0.4b.iso.asc.  If the signature checked out, you would see the following output:

gpg: Signature made Sun 30 Jun 2013 07:15:43 PM EDT using DSA key ID D6975C17
gpg: Good signature from "Project Byzantium (Byzantium Development Team) <byzantium@hacdc.org>"

ISC Milestone Three: Amateur Radio Integration

The intended goal of our third development milestone was to integrate amateur radio functionality into Byzantium Linux.  A persistent technical limitation of our network architecture is inherent in consumer 802.11 wireless chipsets – their transmission range is limited due to the design of their associated antennae, relatively short battery life, and limited radiated power (200mW).  In practice, this means that wireless mesh networks may become segmented if one or more nodes are farther apart than the maximum theoretical range of 802.11 wireless.  Signal attenuation results in the inability of radios to detect one another’s traffic.  This limits the effectiveness of the network and hampers the ability of nodes to route traffic and synchronize. The higher transmission power allowed under amateur radio rules, superior transceiver quality, lower frequencies available, and greater antenna flexibility would help ameliorate these problems by providing increased range for independent nodes in the mesh.  Fewer nodes would then be required to prevent mesh segmentation, and usable broadcast sites would be less scarce.  Re-purposing existing amateur hand-held transceivers (HT’s) would be especially helpful, as most amateur radio operators already have several of these.

After doing some research we discovered that amateur radio could be used for data transmission.  Licensed amateur radio operators can use linear amplifiers, specialized antennae and other techniques to boost the effective strength of broadcasts on the 2.4GHz band, persuant to Part 97 rules.  There are also transmission modes which can be used to transmit text and binary data over a number of amateur radio bands (such as 70cm and 2m).  Our stated use case of temporarily repurposing portable devices as mesh nodes implied that investigating the use of hand-held amateur radio transceivers (HT’s) might be fruitful.  We concentrated on HT’s capable of accessing parts of the amateur spectrum earmarked for data communications to see if we could send and receive mesh traffic and break the distance barrier.

Digital radio transmission is typically accomplished by connecting an audio output device (such as a computer’s sound card) to a radio’s microphone jack. The audio output device supplies tones (for example, a 1kHz signal switched on and off in morse code or a similar carrier with phase modulation).  In the case of single-sideband (SSB) radios this audio is frequency-shifted directly to radio frequency and transmitted without further modulation.  For frequency modulation (FM) radios, a carrier is modulated by the audio input, but the original data can still be recovered by another FM radio.  Thus, connecting a sound card to a radio with simple audio cables allows the computer to transmit data using arbitrary modulation schemes and protocols.

Packet radio, the transmission of packetized binary data over the airwaves, was invented in the mid-1960’s but was first attempted by amateur operators in the late 1970’s in Canada.  The techniques to accomplish this soon spread to the United States and then to other countries.  The first amateur TNC (terminal node controller – a device analogous to a dialup modem for radio) was invented in 1980 and perfected by 1985 with the commercial manufacture of a device named the TNC-2. Many different modes, or methods of encoding data as sound were developed over the years; each mode works well under certain conditions and worse under others, supports a range of speeds (measured in bits per second), and are most usable in certain bands but not in others.  Most data modulation schemes and protocols can be divided into slow, specialized protocols for sending text messages, and packet radio protocols, which existing support for networking.  Morse code, PSK31, OLIVIA MFSK, and similar belong to the former category. Their functionality is equivalent to instant messaging, Internet Relay Chat, and serial console. Some of these protocols also offer great resilience to interference.  In contrast, packet radio protocols (such as AX.25) tend to be faster and offer software with full networking support.  Our research focused on the AX.25 protocol, which seems the most ready for practical application in our network architecture.

AX.25 is a network protocol which roughly maps to the first three layers of the OSI network model (Physical, Data Link, and Network) and enables the transfer packets of information between nodes.  AX.25 is capable of operating in virtual circuit mode (supporting IPv4); in other words, it functions akin to Ethernet or 802.11.  We experimented with a software implementation of the protocol which is available as part of the Linux kernel since 1995. We tried an open source application called Soundmodem which uses the sound card of a computer to modulate and demodulate packets so that the Linux kernel can process them.  Due to the fact that Soundmodem is an emulation of a TNC certain limitations are unavoidably imposed.  First, for optimal functionality a fairly recent (newer than 2003) computer must be used due to how computationally intensive the encoding and decoding processes are.  Second, Soundmodem is highly sensitive to the volume levels of the sound card; if the volume or microphone sensitivity are too low the radio may not trigger when a packet is sent, or packets may not be detected correctly.  Conversely, if the sound levels are too high distortion and clipping may corrupt packets and interfere with operation.  Third, many audio cables are unshielded, and radio frequency interference from the internals of the computer itself may cause packet corruption.  Signal transients will definitely occur.  Fourth, noise from the computer’s power supply or hamonic noise from many of the computer’s components can make their way into the audio output before it even leaves the machine. Additionally, not all radios have voice activation circuits (VOX) which switch fast enough for more than casual use of packet radio, so Soundmodem includes a number of drivers for activating external PTT circuits.  This means that additional interface devices must be built, tested, and debugged ahead of time.  This is not unusual for the amateur radio community as a whole, but for some prospective users it poses a nontrivial problem.

We acquired several HT’s manufactured by Baofeng (UV-3r+, UV-5R) which are fairly inexpensive ($30-$50us) and readily available online.  These qualities have made them reasonably popular in both the amateur radio and hacker communities for daily use and experimentation.  These radios do not have dedicated Push-To-Talk (PTT) jacks for triggering the transmitter when packets are sent but that functionality is accessible by patching into the external audio jacks.  We also used several of our own HT’s in this effort, a Radio Shack HTX-200 and a Kenwood TH-D72 (which has a built-in TNC).  Research uncovered documentation of the pinouts of the units’ microphone and headphone jacks (http://www.miklor.com/uv5r/UV5R-Technical.html), reproduced here:

http://www.miklor.com/uv5r/images/dualplug.jpg

Haxwithaxe and several other members of HacDC worked to develop a suitable circuit which would permit a computer’s sound card to be connected to the HT’s in such a way that the transmitter would automatically trigger the PTT and broadcast outgoing traffic.  The development effort began with a search for PTT circuits which are already used and well understood, on the hypothesis that we could reimplement these known-good circuits and add support for them to Byzantium Linux.  Several possible solutions were found, constructed, and tested (reproduced here):

Kenwood HT external connector pinout.

http://web.archive.org/web/20000815205024/http://www.packetradio.org/0imgs/5026yv.jpg

2pttopto

http://www.soundcardpacket.org/1cableptt.htm#isolation

Our attempts to use these circuits were unsuccessful for a number of reasons.  First and foremost, we had to adapt the circuits to the pinouts of the Baofeng HT’s which unavoidably changed the dynamics of the circuits, possibly in a way that lead to their malfunctioning.  Secondly, the circuits were designed between ten and twenty years ago for radios which were common at the time.  Distressingly, we discovered that much of the documentation and software for packet radio are just as old and have not been updated in the same length of time.  Haxwithaxe took what we learned from our research and experimentation and designed a new series of PTT circuits for our work, culminating with this schematic:

HacDC's HT PTT schematic.

https://github.com/HacDC/AudioToResistance

Simultaneously, we engineered an additional software stack for Byzantium Linux which includes the necessary utilities and systemware for interfacing with amateur radios and configuring the resulting network interfaces.  The software packages (ax25-tools, ax25-apps, and libax25 (http://www.linux-ax25.org/wiki/Main_Page)) have existed since the early days of the Linux kernel and many distributions of Linux include the necessary device drivers as loadable modules by default.  We reconfigured several of the services running atop Byzantium Linux to avoid sending traffic over AX.25 or cellular interfaces to more efficiently use available bandwidth.  A little experimentation revealed how to properly configure and test Soundmodem and the AX.25 network interfaces.  We discovered that AX.25 interfaces are similar to Ethernet and 802.11 interfaces in most but not all respects.  Protocol analyzers like tcpdump are not capable of interacting with AX.25 network interfaces, but the ax25-apps package includes its own (called listen or axlisten, which is paired with a packet generator called call or axcall).  IPv4 works normally over AX.25, but implementations in recent Linux kernels (v3.8.7 and v3.9.4) are still not IPv6 enabled.

Additionally, we were approached early in the R&D effort by another member of the open source community who has developed a software package called Groundstation, which is designed for synchronizing datastores over high latency and unreliable network connections – perfect for amateur radio.  It also presents a responsive web front-end which permits users to read and post messages.  We are working closely with Richo, Groundstation’s chief developer, to integrate it into Byzantium Linux and develop it into an application which will fulfill several of our design goals.

We first attempted using the standard FSK (Frequency Shift Keying) mode which would have afforded us maximum bandwidth for the medium (9600 bps).  We were unsuccessful in almost all of our attempts.  We subsequently tried transmitting at successively lower speeds (4800 and 1200 bps) using FSK modes and were also unsuccessful.  We then attempted and succeeded at bench testing using the PSK31 and Olivia transmission modes for sending and receiving plain text messages.  We  were even able to acoustically decode text sent using Olivia with a third laptop’s integral microphone across the room.  When we disconnected the radios and connected two laptops together by cross-wiring their microphone and headphone jacks we had some success sending and receiving packets.

In the end, we were forced to continue without working PTT circuits and used the VOX feature of our radios instead. This imposed a significant increase in latency and reduction in throughput.  However, the technique was successful at initiating connections with other nodes and exchanging packets. During testing we were able to maintain TCP connections and transfer data in both directions, albeit slowly. There seems to be evidence that others in the amateur radio community have managed to achieve better results with similar hardware, so we believe that with additional work the techniques could be refined and tuned to improve throughput and reliability.  In a later attempt, we used the built-in TNC of the Kenwood TH-D72 as the reference implementation against which to tune Soundmodem and were able to achieve a stable 1200 bps AX.25 link. This was sufficient to allow us to profile the network performance and characteristics so that we could establish a baseline for later testing over emulated network links.  This strongly suggests that hardware TNCs seem to perform significantly better than Soundmodem, and we have ordered some common models to test with, however they have not arrived in time for use on this milestone.

The most common problem we encountered was unidirectional connections.  We were able to successfully transmit network traffic but were unable to receive it until near the end of the development effort.  An AX.25-specific protocol analyzer (listen) showed that network packets were traversing the AX.25 network interfaces.  A significant amount of ARP traffic was detected (approximately 25% of the traffic volume), as were a number of UDP broadcasts identified as originating from other applications running on our test machines (Avahi and Skype service announcements).  The contents of these UDP packets were decoded correctly.  ICMP traffic (generated by ping and traceroute) was problematic and incurred latencies measured in the tens of thousands of milliseconds.  We were unsuccessful at establishing interactive TCP connections over AX.25 during most of the development effort.  Test services were set up using NCat (in UDP server mode) and Python’s built-in HTTP server (TCP); the former was accessible only over a direct connection, the latter not at all.  We are certain that packets were being broadcast because we used a third HT as a scanner and could hear the packets on the air.

It is our recommendation that we leave amateur radio hardware support to the ham community but provide them with software and systems to enable effective support of non-licensed people in the mesh.  We know that this technology is viable because the amateur radio community has been deploying it in a much more limited fashion for several decades with spurts of activity similar to what we would expect in a disaster situation.  Some of the experiments we performed which followed in their footsteps were successful.  Project Byzantium, however, lacks the skills and experience to bring this aspect of the project to fruition in the time allotted by the grant.  To that end, we are making contacts in the amateur radio community who are working on similar projects and proposing interoperability and collaboration.  Doing so will, unfortunately, have to wait until after the grant development cycle is done.

In summary, a great deal of amateur radio-related documentation for Linux is outdated at best and nonexistent at worst.  For example, the AX.25-HOWTO was last updated in September of 2001 and has not tracked the evolution of Linux in the intervening years.  FAQs and documentation for associated software packages have suffered similar fates.  Some commonly used software packages still require early versions of Windows or even virtualized MS-DOS environments.  We may have independently rediscovered solutions to a number of problems encountered by the amateur radio community years ago without our knowledge.  We would like to thank everyone in the amateur radio community whose hard work and research we studied and tried to replicate.  Without their work this project would simply not have been possible.  We would like to take this time to express our gratitude to everybody in the amateur radio community who answered our questions, demonstrated their projects and made suggestions every step of the way.  We could not have achieved as much as we did without your assistance and patience.  We would also like to thank everybody who helped us design and troubleshoot circuits and contributed corrections and text to this document:

  • Martin Rothfield (KB3UJQ)
  • David Bern (W2LNX)
  • Philip Stewart
  • Alex Smith (K4RNT)
  • Bill Babson (WA1IVD)
  • Dan Barlow
  • Matthew Hines (AB3PI)
  • Vic Nardo (WB2U)

ISC grant milestone achieved – v0.3.2a runs on Macs!

As of this afternoon, Project Byzantium has achieved its second milestone of the ISC grant – porting Byzantium Linux to Intel Macs.

We ran into three significant problems in this effort, the X desktop and wireless drivers for certain Broadcom wireless chipsets.  When trying the last major release (v0.3a) on the Macbooks we purchased, we discovered that the X desktops were squished to the top of the screen, making it very difficult to get anything done.  We discovered that this was due to a bug in X.org – in our earlier release, the X server correctly detected the graphics chipset (Intel i915), loaded the proper driver into the X server, and then swapped the driver out for the VESA graphics driver.  We tried the latest version of our build platform (Porteus v2.0) and the bug was fixed.  We confirmed that everything still worked after further testing on different hardware.

The Broadcom wireless drivers posed a more difficult challenge.  I had no trouble with the wireless chipset in my Macbook, but the Broadcom BCM43224 (PCI ID is 14e4:4353) in Haxwithaxe’s Macbook Air refused to work with any drivers that we tried (and in fact, refused to respond to quite a few of them).  We checked out the latest version of the Linux kernel’s firmware repository and added it to the 000-byzantium.xzm module alongside the Broadcom firmware images, and that didn’t help, either.  What we wound up doing was recompiling the Broadcom kernel drivers with the CONFIG_B43_BCMA_EXTRA option turned on, and that extra option got wireless working on the Macbook Air.  We then did regression testing on our other test equipment, ensured that the new build was still interoperable with ByzPi, added some branding to the build, and there you have it.

The third problem, which was how to boot a Macbook from a USB key was paradoxically the easiest to solve.  Macbooks that still have optical drives can boot from CDs or DVDs normally.  Macbooks that don’t, on the other hand, are limited to booting from flash drives, which has historically been a dicey proposition.  We found a solution to this problem in the online documentation for TAILS, another live distribution of Linux.  Hybrid ISO images are images which can be burned to an optical disk as usual, or they can be written directly to a flash drive because they have standard partition tables.

Windows users can use a utility like the LinuxLive USB Creator, Unetbootin, or Win32 Disk Imager.  MacOSX, BSD, and Linux users can use the dd utility to write the hybrid image to a USB key.  For example, if your USB key is plugged into your machine and has the device name /dev/sdb, you would run one of the following commands:

sudo dd if=~/byzantium-v0.3.2a-hybrid.iso of=/dev/sdb bs=1048576

or,

sudo cat ~/byzantium-v0.3.2a-hybrid.iso > /dev/sdb && sync

When the file is finished writing, boot from the USB key.  PC users should hit whatever key will allow them to select the boot device at power on (ESC, F12… consult your manual or POST screen for specifics).  Mac users must power down completely and hold down the Option key while pressing the power button.  When the Mac firmware displays the hard drives in the system, pick the icon on the far right labeled ‘Windows’.  All users will then see the black-on-silver Byzantium Linux boot loader.

Additionally, you can unpack the .iso image onto the USB key and run the Porteus-installer-for-Windows.exe (Windows) or Porteus-installer-for-Linux.com (Linux) utilities as detailed here.

As always,  you can download the .iso images direct from us or one of our mirror sites, or you can torrent them.  If you torrent them, please seed for a day or two to keep the torrents healthy..

ISC Grant milestone number one achieved!

Project Byzantium would like to announce the accomplishment of the first milestone of our ISC Development Grant, the successful port of Byzantium Linux to the RaspberryPi!
We considered using the Arm port of Porteus Linux for the RaspberryPi version of Byzantium but decided to examine other options available first.  A little research revealed that there are two Linuxes in common use on the RaspberryPi right now, Raspbian (which is Debian Wheezy for the Arm platform) and Arch Linux for Arm.  These distributions are already in wide use by the RaspberryPi community so we felt fairly sure that this was a sign of both stability and flexibility.  We opted to use Raspbian because it seems to be the more popular of the two.  Also, the packaging process for Debian was better understood than that for Arch Linux by the Project Byzantium team.  We’re in a rapid development cycle so we wanted to hit the ground running and accomplish as much as possible in the available time before the first milestone.
We created a separate Git repository for ByzPi so that we could patch our code to account for Debian’s idiosyncracies without interfering with the main code tree.  We modified our initscripts to be Debian compatible and worked out the service dependencies in the existing installation image.  We also ported our customized configuration files to Raspbian where necessary.  Early in this development cycle we organized our code in such a way that building Debian packages would be easier as well as maintainable for the future.  We created packages for the captive portal daemon, service directory, and autoconfiguration daemon.  There were a couple of things that weren’t available in the Debian repositories that we had to package ourselves, like QwebIRC and etherpad-lite.  We also created a public Debian repository for the packages we created so they could be installed with APT.
Puppet is used to manage the installation of our customized configuration files, and we used Blueprint to generate the initial manifests.  We also use Puppet to manage whether or not a system service runs at boot-time on Byzantium nodes.  The autoconfiguration daemon controls the states of some services and we need to exercise greater control over them to avoid functional conflicts.  To automate the process of turning a running copy of Raspbian into a Byzantium node, we wrote an all-in-one installation script that is executed with a single cut-and-pastable command.  It takes some time to run because the script does an apt-get upgrade so all of the systemware will be up to date, but by the end of the process the only thing you will have to do is plug in a USB 802.11 interface and reboot the RaspberryPi.  Here’s how to do it once you’ve logged into a RaspberryPi:
curl -s http://byzantium.github.io/ByzPi/install.sh | bash
ByzPi has all of the features of the latest stable release of Byzantium Linux.  It will automatically configure itself at boot time, and is automatically interoperable with existing Commotion Wireless networks.  If plugged into an Ethernet network (even at boot-time) it will configure itself as a gateway to the global Net for the mesh network.  It will even run completely headless, which makes it ideal for semipermanant infrastructure installation.  Due to the fact that ByzPi is a ‘real’ installation and not a live distribution, we’ve also made it sensitive to its internal state and it will account for configuration changes that may potentially cause confusion, such as the existence and later non-existence of network gateways.

Announcing the release of v0.3a (codename: Beach Cat)

For the moment, we’ve won the battle against normal workaday life and fixed the final bug preventing us from publishing the latest release of Byzantium Linux, which we codenamed Beach Cat after our time in New York City late last year.  v0.3a is now available via BitTorrent and direct download on our distribution page.  Please help us distribute this release announcement far and wide.  The official text is below:

Continue reading ‘Announcing the release of v0.3a (codename: Beach Cat)’

Project Byzantium was invited to the FEMA Think tank in February.

This update is extremely late – well over a month overdue – but that whole workaday thing’s really got us down right now.  We’re working on that, promise.

Every quarter FEMA holds a think tank in a different part of the country to discuss after-action reports and plan for what may come in the medium to long term.  For our work in New York City late last year we were invited to attend the meeting when it was held in the Executive Briefing Chamber of the White House on 6 February 2013.  Project Byzantium was also asked to set up a wireless mesh network in the room for attendees to use during the day-long event for communications.  Unfortunately only one person was able to attend but they were well equipped indeed.  Three laptops running the latest Release Candidate build of Byzantium Linux were deployed and a hacked Android phone was used as an uplink to the global Net for the duration of the meeting by attendees.  We lost track of the volume of traffic the mesh handled when it hit the eight gigabyte mark around 1300 hours EST5EDT that afternoon.  We didn’t go snooping around to see if there were any other wireless networks in the area due the White House being one of the most heavily restricted areas on the planet, but it is our optimistic belief that we built the first wireless mesh network at the White House in history that day.

FEMA has posted a video recording of the meeting to its website along with a transcript and a downloadable MP3 of the audio.  It’s over five hours long so you might want to listen to it in the background until something catches your attention.  We think that the #femathinktank hashtag will also be of interest.

Project Byzantium is an ISC grant recipient.

In late 2012, Project Byzantium applied for a technology grant from the Information Security Coalition.  We were informed earlier this week after the selection process was over that Project Byzantium has been given a $10,000us grant to continue research and development for the next six calendar months!  We will be putting the money toward additional equipment to test and debug Byzantium Linux on as well as hardware to experiment with integrating Byzantium Linux into various and sundry amateur radio-related data communications networks.  Our final milestone will be v0.4 of Byzantium Linux somewhen in August of 2013.

We know, v0.3 isn’t out yet.  Workaday life ambushed us, and we have one final bug left to fix before we can release it.  We’re hacking as fast as we can, we promise!

Project Byzantium is an Access Innovation Prize finalist!

Earlier this year, Project Byzantium submitted an entry for the 2012 Access Innovation Prize, an initiative to award five $20,000us grants to accelerate projects working in several problem spaces. These problem spaces are defined as making networks resilient to blackouts (including power and connectivity disruptions), making strong crypto easy to use by everyone, a bounty on a working fix for a vulnerability that affects software used by activists and/or defenders of human rights, a system for making Facebook an easier to use platform for the social good, and the Golden Jellybean Award for advancing communication technologies to promote and enable human rights.  Project Byzantium’s application was for the Blackout Resilience category.  We were recently notified that we are a finalist in this category, and have been invited to New York to attend the awards ceremony on 10 December 2012.  We are honored to have been selected as finalists, and will be in attendence.