Putting your device on our network

From Artisan's Asylum

Jump to: navigation, search

Contents

Types of connections

If you're trying to put a laptop on our network, or anything else with built-in wifi, just read Acceptable use of our public network and you're done---once you have a desk staffer tell you our wireless passphrase.

If, on the other hand, you're trying to add something that does not already have wireless to our network, read Acceptable use of our public network anyway. Then read the below. If you have questions, ask for help.

If your device is some major piece of Asylum equipment that we own (or lease long-term), and that is too big to ever move, it may be possible to give it a hardwired connection. This applies for things like large milling machines and so forth. It's almost always easier to give it a wireless connection instead, however, unless it needs high bandwidth or happens to already be near a hardwired drop.

If it's none of these, then what to do primarily comes down to whether your device acts more like

  • a general-purpose computer, which can take USB or PCI (or PCIe) hardware, or
  • something else, which can only use hardwired Ethernet and thus requires the use of a wireless access point operating in client-bridge mode.

The sections below give further guidance in how to set up either of these options.

Asylum network characteristics

Terminology

We talk about two different kinds of access points on this page:

  • Infrastructure APs are those run by the Asylum, mounted in the ceiling, and which can send packets to the Internet.
  • Client or client-bridge APs are those connected to your own equipment, and which talk to the infrastructure APs.
    • Your device is in client mode if its wireless serves that one device specifically. For example, most laptops operate in client mode.
    • Your device is in client-bridge mode if its wireless serves to route packets from some wired Ethernet interface, through your device's wifi, and out to an infrastructure AP. For example, if you're using a Linksys WT54GL to put some Ethernet-only device on our network, it's operating in this mode.

In general, when we talk here about "setting up an AP," we're talking about setting up your own device in Ethernet-to-wifi client-bridge mode. If we're talking about one of the Asylum-owned wifi devices that you'll be talking to in order to get to the Internet, we say "infrastructure AP."

Supported protocols and bands

Our wireless APs are Apple Airport Extremes, which speak 802.11a/b/g/n at 2.4 and 5 GHz. They are configured to allow roaming, and use WPA2 Personal in AES-CCMP mode. We do not use WPA Personal in TKIP mode. This means that if your device can only speak WPA and not WPA2, it will not work. If you are setting up an AP in client-bridge mode, also see below for more details about the setup.

Infrastructure AP locations and channels

Our current infrastructure APs are placed as follows:

  • Helium. Sits above the intersection just outside of the woodshop. 2.4 Ghz channel 11; 5 Ghz channel 157.
  • Neon. Sits above the social area. 2.4 Ghz channel 1; 5 Ghz channel 149.
  • Argon. In the kitchen/building 10 classroom. 2.4 GHz channel 6; 5 GHz channel 153.
  • Krypton. In the computer lab/building 13 classroom. 2.4 GHz channel 8, 5 Ghz channel 153.
  • Xenon. In building 8. 2.4 GHz channel 11, 5 GHz channel 157.

Connecting wireless hardware directly to your device

If you have something like a desktop computer, there are several ways to easily get it on the net. This section will accumulate suggestions for devices you might use. Many others are possible. One good strategy is to go to Newegg, look for the category "Wireless Adapters", and read the reviews, many of which will talk about whether your device is supported in (for example) non-Windows operating systems, or might require particular OS versions, or downloading a kernel module from the manufacturer, or blacklisting Linux kernel modules. Since Windows is generally the OS that vendors are sure to cater to, the descriptions below only talk about other OS's, and only those that people here have tried the devices with.

USB

Edimax EW-7811Un USB 2.0 Wireless nano Adapter Works out of the box in Ubuntu 11.10. Earlier Ubuntus require downloading and compiling a kernel module. Speaks B/G/N. Tiny! Barely sticks out from the USB port, so unlikely to get snapped off.

PCI

Edimax wireless PCI adapter Apparently works in any Ubuntu from the last few years at least. This is a tiny PCI card with an antenna jack; it plugs into a small external antenna with a 2-meter-ish cord. Speaks B/G.

Connecting wireless to your device via Ethernet

If your device needs to think it's on a hardwired Ethernet, you'll have to configure a wireless AP operating in client-bridge mode. This is not the default ("infrastructure") mode. Not all APs can do this out of the box; however, many can have new firmware flashed into them to enable it.

You must talk to IT before configuring a client-bridge AP. In particular, you'll need an IP address statically assigned to the AP itself in our host tables. Please send mail to get this set up.

If your device can't do DHCP and also needs an IP address statically assigned to it, please also send mail to get this set up.

If you need a stable name for your device, but it can do DHCP, please don't ask for a static address. Instead, tell your device its own name, and when it acquires a lease from us, you'll be able to talk to your device by using yourdevicename.tyler as its name. Yes, we're using tyler as a toplevel domain; this toplevel domain is only valid inside the building, but you can't reach your device from outside anyway (see Acceptable use of our public network).

APs in client-bridge mode also generally need their infrastructure AP channel to be configured in advance. You have a choice of several APs. Pick whichever one gives you the best signal or seems to be closest to you. See above for a list of locations and channel assignments.

Sharing connections

If you'd like to share a single client-bridge AP across several machines or several users, that's perfectly fine with us, and in fact we encourage it: not only does it save money and setup effort, it also saves on static IP addresses. If you and your neighbors would like to amortize the cost and effort of getting non-natively-wireless devices on our net by sharing an access point, please do. Just keep in mind these common-sense provisos:

  • If something breaks, you should talk to the owner of the AP first, and IT second, since IT may not even have the password to the AP (although we encourage you to give it to us so we can help debug).
  • Don't run any cables across any part of the floor, ever; they're a tripping hazard. It is absolutely forbidden to cross a firelane with any cable unless it's in the ceiling.
  • Don't run cables on permanent (cinderblock) walls, metal beams, or into the ceiling without finding out first what our code requirements are with the city of Somerville about how wires get run.

The upshot is that neighbors in the same block of rental spaces can easily share a single AP by running cabling on top of the red and white partition walls, or otherwise attached to them, but they can't span firelanes to other neighborhoods. On the other hand, you probably wouldn't want more than a few people sharing one AP anyway, for bandwidth and reliability reasons.

What AP should you use?

We've had excellent results using Linksys WRT54GL APs. There are several currently in place at the Asylum. These require new firmware to be flashed into them to operate in client-bridge mode. They're relatively cheap either new or from eBay, and speak 802.11b/g. Note that the GL at the end is important, the G routers are different. You want version 1.1 of the router; this is the kind with only 8 LEDs (not 20) and will have a sticker on the bottom saying it's version 1.1. (Version 1.0 is quite old and only likely found used.)

There are no doubt many other APs that will work just fine, many of which can probably use client-bridge mode out of the box. Feel free to recommend some to be listed here.

Using a Linksys WRT54GL

If you decide to use a Linksys WRT54GL, here are specific instructions for setting it up.

What firmware?

Use DD-WRT. Specifically, do not use Tomato. Tomato is a fine piece of firmware, and is easier to set up than DD-WRT, but unfortunately even its most-recent version as of this writing (version 1.28) can only do client-bridge mode in WPA, and we speak WPA2, so Tomato won't work. (Tomato can do infrastructure mode in WPA2 just fine, but that won't help here, because you need client-bridge mode.) There are anecdotal reports that OpenWRT doesn't work either, but this hasn't been confirmed; if you have a success story, please let us know.

If you're using a Linksys WRT54GL and DD-WRT, do not use build 13064! This build does seem to work, and is unfortunately the build that's actually recommended by the the router hardware database, but that database is apparently years out of date, has not been maintained since sometime after it was set up, and consequently recommends bad builds. As discussed in the so-called Peacock thread, build 13064 has bugs that make it not recommended (even though we do have at least one AP using that build and haven't (yet) noticed any problems).

The recommended build is currently 14929. You can find that build for a variety of hardware here. For the Linksys WRT54GL, we used the dd-wrt.v24_std_generic.bin build, after first preflashing with dd-wrt.v24_mini_generic.bin [that latter from the 13064 build because we didn't know any better at the time, but the 14929 build should also work just fine].

How to flash?

Unfortunately, the DD-WRT ecosystem is a terrible mess---there is lots of years-old advice mixed in with more-recent advice, and it tends to contradict itself and yet claim that following any other advice will brick your router. However, starting with the Peacock thread is a reasonable way to go, if somewhat lengthy and alarmist.

Pay careful attention to the instructions in the Peacock thread re 30-30-30 resets before and after each firmware upload, and (if you're starting from stock Linksys firmware) about loading a mini build first, and then a std build. [The issue here is that old-enough stock firmware for the WRT54GL can't load firmware more than 3MB in size, so you need to load the under-3MB mini build, and then load the over-3MB standard build. Wikipedia claims that firmware revision 4.30.11 in the v1.1 unit enables uploading 4MB firmware images directly, and in fact I had several pre-4.30.11's that I upgraded to 4.30.15 and then directly loaded Tomato onto them. However, just in case DD-WRT does something peculiar with its flashing, I followed their instructions and loaded mini builds on each WRT54GL I reflashed, then loaded the standard builds; this is easier than recovering a bricked router.]

If you've never done this before and want help, ask for help. If you're willing to take the (relatively small) chance that we'll brick your router and want us to do it for you, that's possible with suitable (small) bribes.

How to configure?

Once you've flashed the generic build 14929 into the router and done all the necessary resets along the way, you can configure it using the steps here.

The security type is WPA2 Personal (AES-CCMP). The key is the passphrase for our wireless network; talk to the desk staff to get it. Pick whichever channel corresponds to the AP that gives you the best signal (see above). The SSID is Artisan's Asylum, in exactly that capitalization, including the space and the apostrophe.

Note: DD-WRT is not necessarily smart enough to know what crypto your hardware supports! In particular, we had a report of a non-54GL AP with the latest build for that hardware (which was not as recent as 14929) that allowed choosing WPA2, but in fact the hardware didn't support WPA or WPA2 at all---only WEP. That's just not going to work. Check the specs on your router's crypto support carefully.

You'll need to have already sent mail to get a static IP address; this is the "local IP address" referred to in the documentation. (Their example uses 192.168.1.6, but that won't be your address; it's not even on the right network for us.)

Your gateway will be 192.168.10.1. (Not 1.1, but 10.1.)

Host settings

Assuming you've properly set up your router, plug your device's hardwired Ethernet into one of the router ports. (Use one of the 4 ordinary ones unless you've set "Assign WAN port to switch", in which case you can use that one, too.) Your host should acquire a DHCP lease, which will be something in net 192.168.10.x. You're done.

Making your device available to others

So you have some nifty device. Can others use it? How? Should others not use it?

Names

If your device typically gets used from some controls physically attached to it (like a keyboard, or a control panel, or whatever), and only needs to talk to the network like a client, you're done. If it acts more like a server (say, some piece of embedded hardware that controls a piece of equipment), and you'd like people to be able to talk to your device over the network, you have one more step.

That step is to enable people to get to your device using its name, and not its IP address. This is not only friendlier for people, but it's more likely to work long-term. If you're just doing some short-term hack and you're the only user, it doesn't matter, but if this is something that other people need to know about, or if you think it'll be around for a while, it pays to do it right.

Exactly how this works depends on whether your device speaks DHCP. If it doesn't, it'll need a static entry in our host table so you know what IP address to use to configure it. If it does, it will get an address dynamically, via DHCP.

Note that we make no guarantees that any DHCP-assigned address will be stable over long periods---it might change when the device renews its lease, and the probability of that increases as our network gets larger and more crowded. Furthermore, if for some reason all DHCP leases must be flushed due to some sort of software or configuration change, even if your device asks for the same IP address it had last time, there's no guarantee that the DHCP server will honor that request---someone else may have gotten that IP address first. So depending on fixed IP addresses for DHCP leases is unwise, even though it'll probably work for months and then break when you least expect it---if you absolutely need a fixed IP, you should have a static assignment.

On the other hand, even if your device is a server, you don't need a fixed IP as long as you can name it. If your device offers up its name to the DHCP server when it asks for an address (as most laptops, printers, and other commercial devices do, for example), then that name is automatically added to the local DNS when your DHCP lease is assigned. Since the DHCP server is also responsible for serving DNS requests, the two will always be in sync.

If your device can possibly use the "supply its own name" mechanism to identify itself, please do that. Having to add static entries to the host table is less flexible, chews up addresses permanently (since no one ever bothers to say, "Hey, I'm done with this address now"), and requires human intervention to accomplish. But if you can't make that work, ask for a static assignment.

Someone who wants to connect to your device can then use either yourdevicename or yourdevicename.tyler as its name. (Yes, there's no .com or any other string after tyler---inside the building, tyler is a valid toplevel domain. Outside the building, it doesn't exist.) This depends on the client honoring the DHCP-supplied list of DNS servers, but unless someone has deliberately configured their client not to do so, that's automatic.

Be aware that DHCP-supplied names are not guaranteed unique! (After all, two different computers could both claim to be named my-laptop, and how would the DHCP server know who doesn't get their choice of names?) So you should make sure that, if you're putting your device on our network for others to use, you should pick a name that describes the device and won't be confusing to others. Don't pick printer or even 3dprinter; pick something like (at least) its location and/or model number. (If you pick a name like Fred, be prepared to answer a stream of questions about what your device is called and/or what Fred is.)

Inside vs outside the building

In general, we don't allow servers that can be reached from the outside. If your device can make its own outbound connections, that's fine, but inbound connections that require port- or NAT-specific hole-punching are almost always the wrong idea.

However, from inside the building, we're happy to have you run server-like things. Just don't do something that will swamp all of our network bandwidth while you're doing it.

Security

Do not assume that your device is safe from attack just because it's not reachable from outside the building. Remember, attacks may come in many forms:

  • Deliberate attempts by other members to compromise machines
  • Deliberate attempts by malware, when the owner doesn't even know the machine is infected
  • Deliberate port-scanning (such as from nmap) to track down buggy or misbehaving clients
  • Accidental connections from people mistyping names and/or IP addresses
  • Bugs in other things on the network

The chances of most of these this happening from inside the building are far lower than from outside, but they're not zero. If your device will misbehave if someone pokes at it the wrong way from the network, it's your responsibility to harden it against such problems. Please feel free to ask for help if you'd like some suggestions. [Note that deliberate attacks from members are grounds for termination, and that nmap portscans, while rare, are occasionally employed by IT to track down problems or figure out which device is what if we need to try to figure out who owns it to get it reconfigured.]

Robots, and things that cost money

If your device is a robot or something that might take spontaneous action because of a network command, it is a very bad idea if a network command might cause it to move in a way that might startle or injure someone nearby! Such devices should either only take local commands, or they should default to OFF unless an operator turns them on and is monitoring it at all times---and even then, an errant network command might come in at exactly the wrong time.

It's also a bad idea to depend on the network always working, without fail, for things that have life-safety implications. For example, people have occasionally floated the idea of using either 802.11 or Bluetooth as CNC machine pendants. Since one of the uses of a pendant is to tell the machine to STOP in an emergency, depending on a wireless link is a very poor idea from a safety perspective. We do have lots of welders and other big RF/EMI/RFI noise sources in the space, and suddenly being unable to stop your machine because a welder has jammed the radio spectrum is a recipe for disaster. Just don't do it.

If you have something that costs money to run, such as a large plotter, or a 3D printer, or something like that, it's not a great idea to put it on the network unless you have some sort of access-control built in. This isn't just a matter of trust in other members---many organizations with (say) large plotters have discovered to their dismay that people can and will get confused about default printers and accidentally print their 10-page memo to someone else's plotter loaded with very expensive 6-foot-wide glossy paper. Unless you can put in reasonable access control, it's probably a better idea to leave such devices off the net.

Improving your signal

Frequencies

We operate simultaneous dual-band infrastructure APs; this means you can use 801.11b/g at 2.4 GHz, and 801.11a/n at 5 GHz. People sometimes force their devices to use the 5 GHz band because they've heard from all the marketing hype that "it's faster." Unfortunately, that speed advantage depends both on being close to the AP and having a good line of sight to it. Unfortunately, here in the Asylum, that assumption is often violated:

  • It's a large space
  • The nearest AP is sometimes on the other side of a metal-reinforced cinderblock wall
  • There are random metal obstacles, such as tall renters' shelves, all over
  • The ceiling is a giant metal grid of scattering multipath reflectors
  • Welders, which are essentially spark-gap wideband RF transmitters, are frequently in use

In general, the higher the frequency, the more poorly RF will propagate, and wifi is no exception. You may often find that you get the best performance by turning off 5 GHz and using 2.4 GHz instead. If you find you're getting poor performance at 5 GHz, and you happen to be located far from an AP or where there are obstructions to your line of sight, try switching bands.

Our 2.4 GHz network is identified simply as "Artisan's Asylum", while the 5 GHz network is "Artisan's Asylum 5GHz", so often the simplest way to accomplish this is to not enter the passphrase for the 5 GHz SSID, or to bash the password if you've already configured it, or at least to select the 2.4 GHz band and tell your operating system to use that as your default SSID.

Laptops

Laptops usually get very good reception anywhere inside the Asylum. One big reason relates to the way they're constructed: most laptops wrap a fairly large antenna around the display bezel, giving a very large loop area for the antenna and high RF gain.

However, if you close the lid, you'll often greatly impair your wifi performance, because you're putting that antenna close to lots of other metal in the case, plus near all the RF noise from the CPU. Thus, if you're using your laptop as a client-bridge tether for other devices, open the lid and aim the screen so its surface normal points approximately at an infrastructure AP. This is especially important if you're also using 5 GHz on the wrong side of a cinderblock wall---doing both in that situation can cut your bandwidth to 1% of what you'd get with an open laptop aimed at an AP and operating at 2.4 GHz.

USB wifi devices

It's important to understand that small plug-in wireless USB devices, in particular, do not usually have the sensitivity of laptops, and that you'll likely see lower performance unless you take additional steps. Even those with external antennas often get lower RF gain than a laptop, and those with tiny little internal antennas have to fight physics even harder.

An even more important problem concerns how they're usually used--- while laptops usually have built-in wifi, using a large loop antenna in the display bezel, most desktops don't, and adding wifi via USB typically involves plugging the USB device directly into the case. Unfortunately, the case is a large grounded metal object, and that acts as a groundplane---effectively shorting out the RF field nearby. While not as effective at blocking the signal as a complete Faraday cage, it's not good. Small USB wifi devices, especially those without external antennas, simply can't get far enough away from this groundplane to receive any appreciable signal, and the odds are also excellent that the entire case itself is blocking the line of sight to the AP. Asking the wifi device to see through two sheets of grounded metal, with high-frequency RF noise inside of them, is asking a bit much; at best, the wifi might see signal via reflections off nearby walls and the ceiling, but very few 802.11 transceivers are any good at reconstructing a signal made up entirely of multipath reflections, and your USB wifi device isn't one of them.

Fortunately, there's a cheap and easy fix, and that's to get your USB wifi a reasonable distance away from the case---like one or two meters. Ideally, you'd like to get it higher up than your case is likely to be, with a clear line of sight to the nearest AP. While it probably makes little sense to put it near the ceiling (for one thing, the ceiling is both a multipath reflector and a groundplane of its own), getting it above people (RF absorbers), metal filing cabinets (RF absorbers and reflectors) and so forth will help.

The easiest way to do this is just to buy a USB A-male/A-female extension cable, such as this 6' or this 10' cable, each for around $1.30 to $1.40, plus under $3 shipping for either or both together. Note that USB 2.0 has length limit of 5 meters, so don't spring for the 15' cable unless you're sure a shorter one won't do---you may get flaky performance for some combinations of devices.

PCI wifi devices

PCI wifi adaptors, such as the Edimax, often come with an external antenna on a little base, and a couple meters of cabling. This is a good choice. You should avoid models that have an antenna sticking directly out of the back; these are difficult to extend (either no connectors, or you'll need to find suitable cable & connectors, and every connection point and meter of length will introduce additional RF losses), and put the antenna in the same unfortunate location as would plugging a USB wifi directly into the back of the case.

Other APs in client-bridge mode

Linksys WRT54GLs typically come with fairly good external antennas, and since you're connecting to them with Ethernet, it's usually trivial to place them high enough and out of the way enough that they can see a good signal. You can also get higher-gain external antennas, but we haven't found that to be necessary. Since they have no 5 GHz band, you also don't have to worry about 5 GHz propagation issues.

A bit of history, for the curious

The current placement of our infrastructure APs is something of a historical accident. When we originally moved into building 10, the theory was that we would not be expanding for quite a long while, and the placement of Helium and Neon reflected the best compromise for good performance in all of building 10.

However, only a few months later, we acquired our half of building 8, and Neon's placement is not ideal for that. (Nonetheless, building 8 gets an acceptable signal all the way to the back wall, for laptops and suitably-positioned USB wifi devices.) Rewiring or moving APs is quite difficult in our space, due to obstacles and requirements from our building inspector, so these APs are unlikely to move, and an additional AP in building 8 is unlikely unless the performance improvement warrants the level effort required do the requisite cabling. (This seems unlikely.)

The AP in the building 10 kitchen/classroom was installed shortly after we put the computer lab there; even with USB extenders, wifi adaptors on those computers saw too much scattering off CPU cases and LCDs when trying to speak to Neon, whereas Argon allows a much shorter path and a line of sight 180 degrees around from Neon, improving the chances that any given wifi adaptor is not blocked by an LCD.

When it was decided---within a year of our initial move to building 10---that we would acquire building 13, and later that the computer lab would move to the building 13 classroom, Krypton was installed there, for similar reasons. (Building 13 otherwise has reasonable 2.4 GHz performance just using Helium, though its 5 GHz performance is negligible because 5 GHz doesn't propagate through steel-reinforced cinderblock very well.)

Getting help

If you need help or advice on getting yourself set up, or if you need a static IP address allocated for your fixed wired device or your client-bridge AP, the best approach is to send mail to networkREMOVETHIS@artisansasylum.com.

Personal tools
Wiki Maintenance