about The FAQ

These aren't really frequently asked questions. They're they questions we'd ask if we were trying to figure out SWAP. So although it seems silly to say this at the head of a FAQ, if you have questions that you think should be answered here, give us a shout on the swap list and we'll add them.


Put Link list here.



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 and UNOLS 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. These 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 participants.

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 problem.

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.

Whom do I contact for more information?
You should post to the SWAP list: swap@sio.ucsd.edu

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 802.11b antennas.

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 properties.

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.

How much does the equipment cost?
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 for details.

Why not just pickup a Linksys AP for $50.00?
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.

Why do we need all this routing stuff? Why not just use an inexpensive commercial device in AP mode?
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? requirements is "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.

Can I install it myself, or must someone else?
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.

Will you come and install it for me so I don't have to?
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.

So is there no way to connect to my ship's network from my home institution?
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.)

What is Quagga?
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?

What's the difference between Zebra and Quagga?
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 in general.

What is the Aladin daemon?
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 is created.

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 route.

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

Can other ships route to and see the details of my ship's internal network?
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.

How far away will connections be brought up?
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 level.

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.

What can I do to maximize my connection range?
First, you should know we have chosen the most powerful radio cards available that do not require FCC licensing. They operate at a full 200mW.

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.

I noted my radio card has two antenna jacks. What's the other one for?
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.

I can't get a 360 view of the horizon, can I install two antennas on opposite sides of the ship?
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 negoration.

What other antenna configurations are available instead of omni-directional antennas.

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.

Will this equipment interfere with other shipboard equipment/radios?
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 collective experience.

Copyright © 2003-5 swap