I recently completed a project involving a wireless P2P bridge and wanted to share it.  Mikrotik built the hardware and wrote the RouterOS control software we’re using for this project.  First I received a pair of Mikrotik R411 units which have 300 MHz processors and 32 MB of RAM as well as a Mini-PCI slot into which I am attaching R52 general purpose 802.11abg antennae.  Each R411 device has an AC-interface, an Ethernet interface which supports PoE and a serial interface.

You should abandon all hope that these devices are going to snag a DHCP address locally and will be configurable via a web GUI – you’ll have to go in on the serial console and get into the RouterOS CLI.

To access the RouterOS you need to get yourself an RS232 female-to-female serial console cable and plug into the serial port on the R411 router board.  You’ll need to set your baud to 115200, 8-n-1 and no flow control.  If your device is brand-new, like my own, you’ll want to enter “admin” as the user with no password.  You should see a nice little ASCII-art welcome screen and you’ll see your RouterOS version.  Mine is 3.16.  If you are unfortunate enough to have purchased a device and have lost the password you are going to need to read this document and follow the instructions which I have absolutely not tested and cannot guarantee won’t toast your device.  Execute at your own risk.

The RouterOS is flexible, feature-rich and can be complicated so I am going to avoid what I consider non-relevant command line information.  We’re going to stick with the task at hand.  Before starting you should be aware that the RouterOS, while similar to the Cisco IOS, is not quite the same and you’ll want to be note that the RouterOS CLI is kind of broken into areas.  For example the command “interface” will change the prompt and “move” you to the interface sub-section where interface-specific commands may be executed.  Similar to the IOS’ command “interface FastEthernet0/0″ which will put you into the FastEthernet0/0 sub-interface you could execute the following in the RouterOS:  “interface ethernet1″ which would place you in /interface/ethernet1/ and have specific commands.  There is plenty of documentation here for the curious.

Unlike the IOS there’s no privileged mode – once you authenticate for the first time you’re in control – so we’re going to begin with the basics:  wiping any configuration and setting the hostname.

From the initial command prompt enter the word “setup” – this command enters a general configuration dialog which is only useful at this point because it lets us choose to remove all commands by entering the letter “r” – once the configuration is wiped the router will reboot and you can log in again.  An aside:  you can also use the “setup” command to assign IP and gateway information as well as to setup certain protocols.  Now, we assign a hostname and, like a good administrator, I want to name these devices in an intuitive way which will help others understand it’s purpose if I’m not around.  For this reason I am going to call one device “Client” and the other device “Server” which adequately describes their roles – lets focus on Server for now.

To assign a hostname:

system identity set name=”Server”

you could do the same thing on the other unit:  system identity set name=”Client” some examples of good naming conventions might be DeviceLocation_Role[Number]: R411EastAve_AP9 which tells me the physical device is an R411 routerboard at East Avenue identified as AP9.  The client might be assigned a corresponding name like R411MainAndFirst_SU9 which identifies the device type, an intersection where you can assume the device is as well as that it is Subscriber Unit 9.  In a P2P configuration each AP is paired with an SU, so this would demonstrate a pair of devices.  In a point-multipoint situation things undoubtedly get more complicated and you might use the following convention:

R411EastAve_AP9 for the AP

R411MartinBlvd_SU9a, R411WillowRd_SU9b, R411EastLakeDr_SU9c for SUs

Moving on you’ll notice your prompt has changed to reflect that you are admin@Server – one step down and a couple more to go.  On to the networking side of things.

For this project we’re going to need to have 2 distinct subnets which I’ve decided will be 192.168.0.0/24 and 10.254.0.0/24.  We’ll use the latter for the connection between wireless units and the former will be the bridged network.  Note that this is a transparent link and the units on either side will behave as if they were all local to each other.  Also be aware that for P2P links, which have only 2 devices, you should really be using a /30 subnet which only allows for 2 hosts.

Configure the IP for Server’s ethernet interface:

ip address add address=192.168.0.251/24 interface=ether1

this defines the IP with CIDR notation and sets it on the ether1 interface, an action which will also set it’s own default gateway which you can see if you enter “ip route print” – you will see a default gateway of 192.168.0.1/24 is there.  Note that this is automatic and the device performs it’s own subnet calculation, so don’t go using a non-standard gateway IP or you may need to add some complicated static routes.

Let me interject:  you should also define a default route like so:  ip route add src-address=0.0.0.0/0 gateway=192.168.0.1

We can now begin the process of configuring the wireless bridge, though it’s going to be a little one-sided for the time being.  First we define the bridge, itself:

interface bridge add name=”new_bridge”

this command initializes the bridge interface as well as defining the name property, new_bridge.  You can view the interface info using “int bridge print” which will spit out some info about the bridge.  There’s nothing to see quite yet, though.

We now must associate an interface on the device known as Server with this bridge:

int bridge port add interface=ether1 bridge=new_bridge

the next step in preparing Server is to setup the wireless interface:

int wireless set wlan1 ssid=”DescriptiveSSID” frequency=5805 mode=bridge disabled=no

this command first assigns the SSID, which should be descriptive, to wlan1, the wireless interface, it also defines it’s frequency and sets the mode value to “bridge” which is critical because this AP is going to be accepting remote connections and processing them in a master-slave kind of relationship.  Finally the interface is enabled in a manner much like the IOS would.

Now that we’ve got our bridge named and our wireless enabled we should finish configuring the wireless interface:

interface wireless set wlan1 wds-mode=dynamic wds-default-bridge=new_bridge

this sets the WDS protocol mode to dynamic, which it will be, and defines the default bridge as the one we’ve created.  This command is what really creates the wds interface to which we now must assign an IP address.  Remember that the wds interface is going to use the 10.254.0.0/24 network:

ip address add address=10.254.0.251/24 interface=new_bridge

this command also creates a new route entry in the device’s route table and initializes the bridge.  See the symmetry I’ve used for the ethernet and bridge IPs?  Finally, to ensure speedy traffic, we’re going to disable the ip firewall:

ip firewall connection tracking set enabled=no

This concludes the configuration of Server.  Onto the device formerly known as Client.

Let’s quickly wipe this device’s configs using the setup method described and set a hostname using the following:

system identity set name=”Client”

we add an ip address and gateway as with the server, too

Next we create the bridge, as we did above, and this time we add BOTH the ethernet and wireless interfaces to the bridge:

int bridge add name=”new_bridge”

int bridge port add interface=ether1 bridge=new_bridge

int bridge port add interface=wlan1 bridge=new_bridge

Then we configure the wireless interface:

int wireless set wlan1 mode=station-wds ssid=”DescriptiveSSID” disabled=no

Note that you must use the same SSID and that the mode indicates the device is in client or subscriber mode.  The wds interface on this device must also be enabled now that wireless is configured so let’s add an IP to this side of the bridge:

ip address add address=10.254.0.252/24 interface=new_bridge

we also disable the firewall:

ip firewall connection tracking enabled=no

from this device the command “int print” should display 4 devices:  ether1, wlan1, wds and bridge.

you should be able to configure a device on the 192.186.0.0/24 network and ping across the wireless bridge to another device on that same network.  You can see signal strength with the command “int wireless monitor”

Be aware that, as a transparent bridge, your subnets on the ethernet side of these devices must be the same – but you could always assign a /28 subnet and just use a NAT device on the other end.  Where the R433 might be able to handle NAT and some QoS, I’m not sure the R411 can.  I’m seeing transmission rates of 16Mbps out and 9Mbps in and from what I’ve read this is a hardware limitation.  If I wanted to boost my Tx and Rx rates I could

• upgrade to an R433H routerboard (680Mhz & 128MB RAM)
• upgrade Mini-PCI antenna from R52 to R52H
• install an in-line signal amplifier
• replace flat antenna with parabolic dish

I hope this has been informative and I hope it’s provided you with some ideas.  Note that upgrading to the R433H would increase the number of Mini-PCI slots from 1 to 3 which means we’d have a real point-multipoint operation going on.