What is SWAP?
SWAP stands for "Ship-to-Ship/Ship-to-Shore Wireless Access Protocol".
SWAP is a collaborative project to provide wireless networking between
ships within the UNOLS
research fleet and between those ships
port facilities. SWAP has been designed to also facilitate
connections with instrumented buoys.
The active administrators consist of a few volunteer engineers from
varying institutions who have collaborated over several months to
argue about the details and make it all work.
The goal of our labor has been to provide voluntary hardware
recommendations and software configurations to meet the requirements
set forth by the UNOLS
Technical Enhancement Committee RVTEC
requirements were summed up in a series of "StoryScenarios".
To meet that goal we have provided a parts list complete with vendor
information where the items can be purchased, elaborate instructions
regarding construction of the devices and their installation,
preconfigured operating system distributions that can be freely
downloaded and detailed instructions regarding how to install the
software and complete the configuration for your situation. And of
course, we are happy to come and do this all for you.
To necessitate interoperability, we also provide an administrative
role, doling out network addresses, hostnames and other details to
What functionality does SWAP provide?
SWAP provides IP network links between ships or between a ship
and shore facility. No manual intervention is required. When a SWAP
Device sees another SWAP device, a link is immediately brought up and
network traffic can be routed over that link.
SWAP also specifies that each SWAP Device node have it's own local SWAP network, and that the second IP address on that network be the SWAP Host. This network acts like a DMZ, allowing connections to the ship or shore facility via the SWAP Host from other networks without exposing the ship or port facility's internal network in an unsecure way.
What functionality does SWAP *NOT* provide?
SWAP does not provide general Access Point functionality. That is, a
person with a laptop on the fan-tail won't be able to access the
ship's network through a SWAP device. Similarly, someone on the pier
or across the bay from the port won't be able to associate with the
SWAP device. SWAP links are strictly ship to ship or ship to shore -
network links ,but do not facilitate links for individual hosts.
The SWAP devices certainly have the ability to provide this
functionality, but we have disabled it to prevent a particular
Consider the scenario in which two ships are operating nearby and a
SWAP link has been established between them. Assume for the moment
that both are also acting as APs, allowing associations from client
radios in the vicinity.
The SWAP devices on both ships use the same ESSID, and would be
broadcasting that same ESSID for client radio associations. If one
takes a laptop onto the fantail to attempt a wireless connection, there is
no way to predict if it will associate with my own ship's
wireless network, or the distant ship. Both have the same
ESSID. Connections with the distant ship will likely have low
bandwidth and drop frequently. We have found that once this connection
is made, even if it is poor, client wireless devices tend to always
associate with that device. There is no way to hand off the connection
to the closer SWAP Device, and no way force connections to it
either. Any traffic to my own ship's network, will pass to the distant
ship first, before routing back.
To prevent this scenario, we have chosen to allow ships to provide
their own local network access via their own equipment and a different ESSID.
You should post to the SWAP list: firstname.lastname@example.org
What is a SWAP Device?
Physically, a SWAP Device is a single board PC running Pebble Linux,
an 802.11b PCMCIA radio card and one (and sometimes two) outdoor
Logically a SWAP Device is an 802.11b access point that creates WDS
(Wireless Distribution System) links between itself and other properly
configured access points. The WDS portion of the 802.11 standard was
designed, in part, to provide wireless bridges between two segements
of the same wired subnet. They are point-to-point links. Using the
open source Linux drivers we have chosen, these links create a new
pseudo network interface on each device when the link is created. Then
a process assigns network addresses to those interfaces. Now the SWAP
device becomes a router, passing packets between networks, rather than
a switch, passing packets between segments.
As mentioned above, a SWAP Device is also a router. An OSPF (Open
Shortest Path First) daemon operates on each SWAP Device, monitoring
for the creation of new local network interfaces and the status of
other OSPF routers in the area. OSPF adds new routes to the local
routing table when new network interfaces are created, and then
broadcasts those new routes to neighboring OSPF nodes. Each OSPF
daemon calculates the shortest path to any network and creates an
appropriate routing table for itself.
In this way, as soon as a new SWAP Device associates with another, the entire composite wireless SWAP network is immediately available to it. As a SWAP enabled ship pulls into port and its SWAP Device associates with the port SWAP Node, the composite routable network immediately extends to the combined antenna coverage of the port and ship. Add yet another ship, and the effective range of the port facility extends yet again. Think of it like extending a ship's ability to reach another ship or the Internet on shore, one hop at a time.
A SWAP Device is also a firewall and does network address
translation. Shore SWAP devices prevent the public from routing onto
the wireless SWAP networks by preventing connections from the public
internet. Part of this involves translating host ip addresses from
clients on the SWAP network, or even those on a ship's internal
network a single IP address on the public internet. In addition, ship
SWAP Devices prevent hosts on the SWAP networks from accessing the
ship's internal network. Again, this involves translating host ip
addresses from clients on the ship's internal network, to a single
address on the SWAP network.
What is a SWAP Local Network?
Because SWAP Devices prevent connections into a ship's internal
network, it has been necessary to create a kind of DMZ which is
routable from the SWAP network. So we have created a small network of
just 32 IP addresses (a "/27" netmask) called the SWAP Local Network
for each SWAP Device. Owners of each SWAP Device can place computers
in this network to which they want people from other ships to connect.
Within the SWAP Local Network we have designated the first 20
addresses static, and serve up the remaining 10 through DHCP. These
DHCP provided addresses are only served up on the SWAP Local Network
interface (eth0) and facilitate the quick plug-in of a scientist's
computer to the routable SWAP network.
What is a SWAP Host?
Within each SWAP Device's SWAP Local Network we have reserved the
first host IP address for a SWAP Host. The SWAP Host is provided and
administered by the ship or shore facility and can be as sophistocated
or as simple as you want, but must run a web server at a minimum. The
IP addresses of SWAP Hosts will be made publically available, listed
by SWAP Device and associated ship or port facility.
When a link is brought up with another ship, one can quickly lookup the
IP address of their SWAP Host, point a browser at it, and see their
ship's SWAP web page.
SWAP Hosts allow all kinds of cool functionality. Two ships that know
they will be operating together can setup "SEND" and "RECEIVE"
directories on their respective SWAP Hosts. A simple process can look
for the presence of the distant SWAP Host, and push any new files in
their local SEND directory to the RECEIVE directory on the distant
ship. In this way, a two-way conduit is created that allows the
transfer of any kind of data files between ships.
SWAP Hosts might run a DNS server that has been loaded with the IP
addresses and DNS names of the other SWAP Hosts in the fleet which
will facilitate connections between ships greatly.
SWAP Hosts might also contain an SMTP server. Properly configured,
this would allow passage of email between each ship without the need
to first send it ashore via satellite link.
SWAP Hosts can also run things like chat sessions or even IP phone
calls, although we've not yet tested these things out.
Although we've not yet implemented it, the SWAP Host is a natural
place to develop a SWAP Device monitoring application that would
provide indication of the presence of links and their various
None of the functionalty listed above is manditory with the exception of the
web server. We think this is important to facilitate even the most
rudimentary communication between ships. But we leave the other services for
individual institutions to develop and implement as their needs and
inclinations allow. Any software, scripting, configuration and
general documentation should be shared with the community.
Is SWAP Secure?
Yes and No.
We think of SWAP Wireless Networks much like an extension of the Public Internet from shore. Security measures must be made on each ship protect the ship's internal network. Similarly, each shore SWAP Device should be installed OUTSIDE institutional firewalls to prevent an unwanted user on the SWAP Network from gaining access to an instution's private net.
Just the same, we've taken great measures to build security features right into SWAP. We have chosen a tiered security approach that mitigates the ability of unwanted users to participate in SWAP networks and prevents them from
routing to unwanted places. Security mechanisms inherent in the 802.11 wireless standard have been
notoriously insecure, and new security standards are pending. In the meantime we have implemented standard WEP
encryption between wireless nodes. This prevents the casual wireless user from associating with our SWAP Devices. We are quite aware that sophistocated users have been known to break WEP encryption. None-the-less, WEP provides a reasonable amount of security to restrict the majority of users from gaining access to the SWAP network. "Since we can't effectively lock the door, we at least pull it shut."
Moreover, each SWAP Device is a firewall in and of itself. We use this firewall to prevent packets from passing into a ship's internal network from the SWAP Network, and similarly from passsing into the SWAP Network from the Public Internet.
For the person who does break our WEP Encryption they would gain access to SWAP Hosts and the shore side of any Shore SWAP Device (the Internet). For this reason we recommend the following:
1) Each SWAP Host should be made reasonably secure, as though exposed to the general public.
2) Shore SWAP Devices should always connect directly to the Public Internet and NEVER to an instituion's private (i.e. behind the firewall) network.
With the above measures in place, compromised WEP Encryption will never provide a back-door into an ship's internal network or an institution's private network.
We have created SWAP Devices with two separate single board PC
hardware selections. Including all the peripheral details - 802.11b
radio card, compact flash card, antenna cabling, one antenna,
enclosures, mounting hardware, cable glands, etc. the total comes to
about $1000.00, with a difference between the two single board PCs of
about $10.00. See the Cost Summary
At the time of our research and work, few commercially available access
points were capable of creating WDS links and none could provide
routable IP networks on top of them. Moreover, none provide for any
interoperability between vendors. The WDS portion of the 802.11b
standard is still under development to make things "more standard" but
until that work is complete we have opted for an open source solution.
WDS links and the networks built on top of them allow true Mesh networking. Mesh networking allows the stringing of new nodes together each routable to and from the others.
Plus, while the cost of a residential AP is attractive, our experience
is that the reliability of these devices is unpredictable. Moreover,
half of the expense of a SWAP Device as we've designed them, is due to
the antenna, cabling, mounting hardware and enclosure - all things
that would be required with a commercial AP as well.
Finally, creating a system ourselves allows us the abilty to customize
the solution and bring great functionality that our research has shown is
unavailable in most commercial implementations.
Consider three ships A, B and C operating together.
First, for an AP-client topology, one ship, and only one ship must be
an AP. Using this topology requires each ship to coordinate with the
others in advance to decide who will be the AP, then a reconfiguration
of each ship's equipment. However one of our StoryScenario?
"no user interaction", so this won't do.
Second, suppose ship A is the AP, and the three ships A, B and C are
operating in a line such that ship B can make a link to ship A and
while C can see B, ship A is over the horizon. With an AP topology,
each and every node must be able to "see" the AP for packets to pass
between them. Even if ship C is within clear communicating distance
with B, it is a hidden node, because it can't associate with the AP.
This is called the "hidden node problem". This won't do.
However using the SWAP Device/router topology we have adopted, every
device can connect with every other in a mesh network, and every
device learns about all the routes. Moreover, the addition of new nodes,
increases the reach of the entire network. So a ship operating close
enough to shore to see a port facility node, effectively extends the
reach of that port facility to that of the combined coverage of the shore
and ship. Add another ship more distant, and the reach becomes the
composite coverage of the three.
Best of all, this happens without user intervention.
We have made every effort to document the hardware, software,
installation and configuraiton details so you can do just that.
You only need to contact us via the SWAP list so that we can assign
you appropriate networks and host addresses that make your ship or shore installation unique within the UNOLS SWAP network.
Alternatively, you can purchase and install all the hardware and then
give us a shout via the SWAP list. We will then customize a compact
flash card complete with operating system and and all your
configuration details, test it a bit to make sure it works, and then
ship it out to you. All you have to do is insert it into your SWAP
device, and power it up.
Absolutely. We'll provide you with a list of items to purchase. We'll
work with you to schedule a time that the ship is available and
ship/shore personnel are available to provide the necessary support.
Then we'll come out and piece the details together and work with you
to install it in an appropriate place. Finally we'll install the
operating system and configure it properly and provide your technical
support staff with as much training as you would like.
Funding for time, travel and all the details will be worked out
through the respective marine offices and NSF.
Can I route from my institution/the Internet onto the SWAP network and to a ship?
(GAD: ^^^^^ To clarify, you can use Network Address Translation (NAT) to connect from your shore institution to the SWAP network if you choose to do so, but this is something that experienced network administrators will need to arrange, and care must be taken to ensure that the public internet cannot get access to the SWAP network via this NAT gateway. Routing directly onto the SWAP network is not possible, and routing to a ship's internal network is also not possible.)
Why can't I route from my institution or the public Internet onto the SWAP network?
Many, indeed most, ship networks are not designed to be part of the
public Internet. They are private networks, often quickly extended to
meet some research purpose, with sensitive instruments sending and
logging data. Few, if any firewalls exist on individual machines - it
is a blissfully open space unconstrained by the harsh realitities of
a malicious public. For these reasons we prevent all connections from
the public Internet onto Swap Networks.
No, there is a way. A sophistocated network administration staff might
create a VPN or IP-Sec tunnel between their home institution's network
and their ship's internal network. A tunnel of this sort creates an
encrypted virtual link between the end networks, the effect of which
is to simulate a direct link between them. A pseudo network interface
is created on each side of the link over which traffic is routed to
the distant network.
IT IS EXTREMELY IMPORTANT that the shore side of the tunnel be within
a private, firewalled network. Otherwise, the tunnel will create an
insecure back door into the ship's private network that will, in turn,
provide public access to the linked SWAP networks. All our security
efforts will be effectively thwarted.
Please note, a tunnel of any kind would have to be initiated from the ship.
(GAD: ^^^^^ this is debateable. Theoretically, if you provided a NAT from your shore-side public connection to the SWAP network, and then had the ship's VPN end-point dual-homed onto the SWAP network and the ship's internal network, you could initiate the connection from shore.)
Quagga is an open source implementation of
several routing protocols, of which OSPF is one. Quagga is based on a
no longer active open source effort, Zebra. Quagga is used to pass
routing information between SWAP Devices.
What are WDS Links?
Zebra is a no longer active effort to create open source
implementations of common routing protocols. Quagga is a currently
active follow on effort, effectively picking up where Zebra left
off. Although Quagga is used on our SWAP devices to provide OSPF, a
separate Zebra daemon is also present which manage routing protocols
The Aladin daemon is an open source software package that looks for
the creation of new WDS network interfaces, negotiates with the host
on the distant side of the link, and provisions ip addresses and
network masks for both the local and distant network interfaces from a
pre-established pool. All this happens automatically when a WDS link
It is the Aladin daemon that turns the WDS links into unique routable
networks. Consider for a moment the network topology if WDS links
were not unique networks. In this case, the SWAP Device would act like
a switch rather than a router, and the connection between two SWAP
Devices would be analagous to a wired connection between two switches;
a point to point link between two portions of the same subnet. Both
networks on the wired side of the SWAP Devices would have to be on the
same subnet to pass packets between them. This would create a
completely flat network space that would neither scale, nor facilitate
the passage of packets through mulitple hops using intermediate SWAP
Devices to get to a final endpoint.
What is OSPF?
A routing table consists of a list of known networks, the interface on
which those networks should be found, and optionally a "via ipaddress"
entry when the network is not local (attached directly to the router).
The "via" entry specifies the IP address of a peer router for the next
hop. Peer routers exchange routing tables such that they may learn
how to route packets beyond their local networks.
OSPF works somewhat differently than a simple exchange of routing
tables between routers. Rather, OSPF daemons exchange "Link State
Advertisements" which designate the location and weighting of local
networks. Each router then calculates a "shortest path tree" from the
complete Link State Database with itself as root. The shortest path
tree, in turn, is used to create the routing table.
This level of complexity is important, as it allows for quick
convergence of new network paths when nodes are lost. It also allows
one to designate multiple paths to the same network, with differing
weights. One can envision a scenario in which two links to shore
exist, and one would like to specify a preference for the least cost
When a router receives a packet, it looks in a "routing table" to determine where to send the packet. The
destination network might be directly attached to the router, in which
case the table will provide the interface out of which the packet
should be sent. However the destination network might be attached to a
distant router some place else in the network. If the distant network is
under the same administration as the local network, the table will list the network, and
No. We prevent the passage of packets from the SWAP networks into your
internal network unless the connection was initiated from within your
network - the common NAT functionality. We believe it is important for
the security and smooth operation of your research networks to be
unencumbered by unwanted network traffic from the SWAP networks.
Good question. This of course all depends on your choice of antennas,
their placement, the weather, your luck, etc. We have made good
quality connections at distances up to 5 nm. [CONDITIONS]
The 802.11b spec allows for maximum connection rates at 11Mbps (mega
bits per second). These are the normal connection speed when there is
sufficient signal eccess. However, as signal to noise (SNR) ratios
decrease, connection speeds are renegotiated at lower speeds down to
1Mbps. These lower speed connections have much longer range.
Renegotion of connection speeds is done automatically by the radio
card to prevent the quality of the link from degrading below a usable
We are very interested in the performance seen by users in the fleet and welcome posts to the swap list providing antedotal experience with these devices.
First, you should know we have chosen the most powerful radio cards
available that do not require FCC licensing. They operate at a full
Chose an antenna with a high gain. An Omni-directional passive
antenna with 15dB of gain was installed at our first test
installation. This seems to have worked well, although new devices
are constantly becoming available.. Do some research.
Antenna placement is everything. In so far as possible, the antenna
should be mounted with a clear 360 degree view of the horizon and
should be as high as possible. As a rule of thumb, multiply the
square root of the height (in feet) of the antenna off the water by
1.14 to get the number of nautical miles to it's horizon. Therefore,
an antenna mounted 100 feet off the water line has a view to the
horizon of about sqrt(100)*1.14=11.4nm. Two ships in which both
antennas are mounted 100ft off the water have a theoretical maximum
line of sight distance of about 23nm. Actual connection distances
will be less however based on signal attenuation.
Antenna should be mounted well out of the line of sight of radar
equipment. We have run antenna cabling down through the line of sight
of radar equipment with no discernable effect.
Diversity Antennas. Note, when holding the card with the top side labeling up, and the socket down, the primary (non-diversity) jack is on your left. If you only have one antenna, that's the one to use.
You can install two antennas on opposite sides of a small obstruction,
a mast for example. In this rare case, we believe you can install
these antennas as "diversity antennas," and the radio cards we've
selected have a second jack to support this setup.
HOWEVER you should read more about how diversity antennas work before
doing this. [INSERT URL]. Diversity antennas do not increase the
coverage provided by a radio, but rather increase the quality of the
link. They must be placed such that their coverage is nearly
identical. The radio monitors the reception from both antennas and
then choses only one to listen on. It does not listen to both at the
same time. Diversity antennas allow selection of the best antenna on
one side of a mast or another, but if any individual antenna has
severaly limited coverage, the converage of the entire system may be
limited to that antenna when if it is chosen during the intitial link
First, remember, you cannot install two directional antennas facing
opposite directions as diversity antennas. Nor can you install two
omni-directional antennas as diversity antennas whose coverage area,
perhaps because they are installed low on opposite sides of the ship,
is significantly different.
That said, it is possible to purchase low loss antenna cable
splitters. These would allow multiple antennas to be connected to a
single jack on the radio card. This is NOT a diversity antenna setup.
We have limited experience with this setup, but it is conceivable, for
example, that two 180 degree high gain antennas could be installed
facing opposite directions and that the additional gain of the
directional antennas would outweight the losses incurred by the
antenna cable splitter. If you decide to go this route, let us know
how it goes. We're very interested.
To date, we have experienced no interference between 802.11b radio
equipment and any other shipboard communication systems.
We are very interested in antedotal evidence of any suspected
interference from users in the fleet. The proof will be in our