Aug 04, 2020 You must know the MAC address of each access point in the bridge network. The 2.4Ghz and 5Ghz radios have unique MAC addresses. You can use either the 2.4 GHz band or the 5 GHz band for the wireless bridge, but the 2.4 GHz and 5 GHz bands cannot be bridged together. Bridge – This option allows the WAP to function as a network bridge and establish a network link to other WAP access points. Wi-Fi clients cannot connect. Phy Mode – Select the Phy Mode the WAP should use to dictate the maximum size of packets during data transmission. Apr 14, 2004 Be careful if you use this method, because some products show the MAC addresses for both the Ethernet and wireless portions. If this is the case, make sure you record the wireless MAC address.
This document explains how to configure MAC filters with wireless LAN controllers (WLCs) with a configuration example. This document also discusses how to authorize lightweight access points (LAPs) against an AAA server.
Ensure that you meet these requirements before you attempt this configuration:
Basic knowledge of the configuration of LAPs and Cisco WLCs
Basic knowledge of Cisco Unified Wireless Security Solutions
The information in this document is based on these software and hardware versions:
Cisco 4400 WLC that runs software version 5.2.178.0
Cisco 1230AG Series LAPs
802.11 a/b/g wireless client adapter with firmware 4.4
Aironet Desktop Utility (ADU) version 4.4
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
When you create a MAC address filter on WLCs, users are granted or denied access to the WLAN network based on the MAC address of the client they use.
There are two types of MAC authentication that are supported on WLCs:
Local MAC authentication
MAC authentication using a RADIUS server
With local MAC authentication, user MAC addresses are stored in a database on the WLC. When a user tries to access the WLAN that is configured for MAC filtering, the client MAC address is validated against the local database on the WLC, and the client is granted access to the WLAN if the authentication is successful.
By default, the WLC local database supports up to 512 user entries.
The local user database is limited to a maximum of 2048 entries. The local database stores entries for these items:
Local management users, which includes lobby ambassadors
Local network users, which includes guest users
MAC filter entries
Exclusion list entries
Access point authorization list entries
Together, all of these types of users cannot exceed the configured database size.
In order to increase the local database, use this command from the CLI:
Alternatively, MAC address authentication can also be performed using a RADIUS server. The only difference is that the users MAC address database is stored in the RADIUS server instead of the WLC. When a user database is stored on a RADIUS server the WLC forwards the MAC address of the client to the RADIUS server for client validation. Then, the RADIUS server validates the MAC address based on the database it has. If the client authentication is successful, the client is granted access to the WLAN. Any RADIUS server which supports MAC address authentication can be used.
Complete these steps in order to configure local MAC authentication on the WLCs:
Note: Before you configure MAC authentication, you must configure the WLC for basic operation and register the LAPs to the WLC. This document assumes that the WLC is already configured for basic operation and that the LAPs are registered to the WLC. If you are a new user trying to set up the WLC for basic operation with LAPs, refer to Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC).
Note: There is no special configuration needed on the wireless client in order to support MAC authentication.
Complete these steps in order to configure a WLAN with MAC filtering:
Click WLANs from the controller GUI in order to create a WLAN.
The WLANs window appears. This window lists the WLANs configured on the controller.
Click New in order to configure a new WLAN.
In this example, the WLAN is named MAC-WLAN and the WLAN ID is 1.
Click Apply.
In the WLAN > Edit window, define the parameters specific to the WLAN.
Under Security Policies > Layer 2 Security, check the MAC Filtering check box.
This enables MAC authentication for the WLAN.
Under General Policies > Interface Name, select the interface to which the WLAN is mapped.
In this example, the WLAN is mapped to the management interface.
Select the other parameters, which depend on the design requirements of the WLAN.
Click Apply.
The next step is to configure the local database on the WLC with the client MAC addresses.
Refer to VLANs on Wireless LAN Controllers Configuration Example for information on how to configure dynamic interfaces (VLANs) on WLCs.
Complete these steps in order to configure the local database with a client MAC address on the WLC:
Click Security from the controller GUI, and then click MAC Filtering from the left side menu.
The MAC Filtering window appears.
Click New in order to create a local database MAC address entry on the WLC.
In the MAC Filters > New window, enter the MAC address, Profile Name, Description and the Interface Name for the client.
Here is an example:
Click Apply.
Repeat steps 2-4 in order to add more clients to the local database.
Now, when clients connect to this WLAN, the WLC validates the clients MAC address against the local database and if the validation is successful, the client is granted access to the network.
Note: In this example, only a MAC address filter without any other Layer 2 Security mechanism was used. Cisco recommends that MAC address authentication should be used along with other Layer 2 or Layer 3 security methods. It is not advisable to use only MAC address authentication to secure your WLAN network because it does not provide a strong security mechanism.
Complete these steps in order to configure MAC authentication using a RADIUS server. In this example, the Cisco Secure ACS server is used as the RADIUS server.
Complete these steps in order to configure a WLAN with MAC filtering:
Click WLANs from the controller GUI in order to create a WLAN.
The WLANs window appears. This window lists the WLANs configured on the controller.
Click New in order to configure a new WLAN.
In this example, the WLAN is named MAC-ACS-WLAN and the WLAN ID is 2.
Click Apply.
In the WLAN > Edit window, define the parameters specific to the WLAN.
Under Security Policies > Layer 2 Security, check the MAC Filtering check box.
This enables MAC authentication for the WLAN.
Under General Policies > Interface Name, select the interface to which the WLAN is mapped.
Under RADIUS servers, select the RADIUS server that will be used for MAC authentication.
Note: Before you can select the RADIUS server from the WLAN > Edit window, you should define the RADIUS server in the Security > Radius Authentication window and enable the RADIUS server.
Select the other parameters, which depend on the design requirements of the WLAN.
Click Apply.
Click Security > MAC Filtering.
In the MAC Filtering window, choose the type of RADIUS server under RADIUS Compatibility Mode.
This example uses Cisco ACS.
From the MAC Delimiter pull down menu, choose the MAC delimiter.
This example uses Colon.
Click Apply.
The next step is to configure the ACS server with the client MAC addresses.
Complete these steps in order to add a MAC address to the ACS:
Define the WLC as an AAA client on the ACS server. Click Network Configuration from the ACS GUI.
When the Network Configuration window appears, define the name of the WLC, the IP address, the shared secret and the authentication method (RADIUS Cisco Aironet or RADIUS Airespace).
Refer to the documentation from the manufacturer for other non-ACS authentication servers.
Note: The shared secret key that you configure on the WLC and the ACS server must match. The shared secret is case sensitive.
From the ACS main menu, click User Setup.
In the User text box, enter the MAC address in order to add to the user database.
Note: The MAC address must be exactly as it is sent by the WLC for both the username and the password. If authentication fails, check the failed attempts log to see how the MAC is reported by the WLC. Do not cut and paste the MAC address, as this can introduce phantom characters.
In the User Setup window, enter the MAC address in the Secure-PAP password text box.
Note: The MAC address must be exactly as it is sent by the WLC for both the username and the password. If authentication fails, check the failed attempts log to see how the MAC is reported by the AP. Do not cut and paste the MAC address, as this can introduce phantom characters.
Click Submit.
Repeat steps 2-5 in order to add more users to the ACS database.
Now, when clients connect to this WLAN, the WLC passes the credentials to the ACS server. The ACS server validates the credentials against the ACS database. If the client MAC address is present in the database, the ACS RADIUS server returns an authentication success to the WLC and the client will be granted access to the WLAN.
This document previously discussed how to use the WLC GUI to configure MAC filters. You can also use the CLI in order to configure MAC filters on the WLC. You can use these commands in order to configure the MAC filter on WLC:
Issue the config wlan mac-filtering enable wlan_id command in order to enable MAC filtering. bEnter the show wlan command in order to verify that you have MAC filtering enabled for the WLAN.
config macfilter add command:
The config macfilter add command lets you add a macfilter, interface, description, and so forth.
Use the config macfilter add command in order to create a MAC filter entry on the Cisco Wireless LAN controller. Use this command in order to add a client locally to a wireless LAN on the Cisco Wireless LAN controller. This filter bypasses the RADIUS authentication process.
Example:
Enter a static MAC-to-IP address mapping. This can be done to support a passive client, that is, one that does not use DHCP and does not transmit unsolicited IP packets.
config macfilter ip-address command
The config macfilter ip-address command lets you map an existing MAC-filter to an IP address. Use this command in order to configure an IP address into the local MAC filter database:
Example:
You can configure a timeout for disabled clients. Clients who fail to authenticate three times during attempts to associate are automatically disabled from further association attempts. After the timeout period expires, the client is allowed to retry authentication until it associates or fails authentication and is excluded again.
Enter the config wlan exclusionlist wlan_id timeout command in order to configure the timeout for disabled clients. The timeout value can be from 1 to 65535 seconds, or you can enter 0 in order to permanently disable the client.
Use these commands in order to verify if the MAC filter is configured correctly:
The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.
show macfilter summary—Displays a summary of all MAC filter entries.
show macfilter detail <client MAC Address>—Detailed display of a MAC filter entry.
Here is an example of the show macfilter summary command:
Here is an example of the show macfilter detail command:
You can use these commands to troubleshoot your configuration:
Note: Refer to Important Information on Debug Commands before you use debug commands.
debug aaa all enable— Provides debugging of all AAA messages.
debug mac addr <Client-MAC-address xx:xx:xx:xx:xx:xx>—In order to configure MAC debugging, use the debug mac command.
Here is an example of the debug aaa all enable command:
When a wireless client is not present in the MAC address database on the WLC (local database) or on the RADIUS server tries to associate to the WLAN, that client will be excluded. Here is an example of the debug aaa all enable command for an unsuccessful MAC authentication:
Wireless Clients that Try to Authenticate by MAC Address are Rejected; Failed Authentication Report Shows Internal Errors
When you use ACS 4.1 that runs on a Microsoft Windows 2003 Enterprise server, clients that try to authenticate by the MAC address are rejected. This occurs when an AAA client sends the Service-Type=10 attribute value to the AAA server. This is because of Cisco bug ID CSCsh62641 (registered customers only) . AAA clients affected by this bug include WLCs and switches that use MAC Authentication Bypass.
The workarounds are:
Downgrade to ACS 4.0.
or
Add the MAC addresses to be authenticated to a Network Access Protection (NAP) under the internal ACS DB MAC address table.
Not able to add a MAC filter using the WLC GUI
This can happen becaue of the Cisco bug ID CSCsj98722 (registered customers only) . The bug is fixed in 4.2 release of code. If you are running versions earlier than 4.2, you can upgrade the firmware to 4.2 or use these two workarounds for this issue.
Use the CLI in order to configure the MAC Filter with this command:
From the Web GUI of the controller, choose Any WLAN under the Security tab and enter the MAC address to be filtered.
Silent client not placed in run state
If DHCP required is not configured on the controller, the APs learn the IP address of wireless clients when the wireless clients send out the first IP packet or ARP. If the wireless clients are passive devices, for example, devices that do not initiate a communication, then the APs fails to learn the IP address of the wireless devices. As a result, the controller waits ten seconds for the client to send an IP packet. If there is no response from the packet from the client, then the controller drops any packets to the passive wireless clients. This issue is documented in Cisco bug ID CSCsq46427 (registered customers only)
As a recommended workaround for passive devices like printers, wireless PLC pumps and so forth, you need to set the WLAN for MAC filtering and have AAA override checked in order to allow these devices to be connected.
A MAC address filter can be created on the controller that maps the MAC address of the wireless device to an IP address.
Note: This requires MAC address filtering to be enabled on the WLAN configuration for Layer 2 Security. It also requires Allow AAA Overide to be enabled in the advance settings of the WLAN configuration.
From the CLI, enter this command in order to create the MAC address filter:
Here is an example:
You are here: DD-WRT wiki mainpage / Linking Routers / Wireless Bridge
This is an older page on how to set up a client bridge. It is being kept as there might be info that some find useful, but ***THESE INSTRUCTIONS SHOULD NOT BE USED*** Use the more complete and up to date guide to do the same thing that can be found here:
http://www.dd-wrt.com/wiki/index.php/Client_Bridged
In the case in which we are interested, a wireless device running DD-WRT such as a WRT54G is configured as a Wireless Bridge between a remote wireless router (of any make/brand) and the Ethernet ports on the WRT54G.
Contents
|
(Editorial Note: Also see Example further down this page for a better documented but lengthier procedure with some unnecessary steps.)
To enable wireless bridging between two WRT54Gs, one WRT54G has to be in AP-Mode (Wireless > Basic Settings). The following assumes it has the default IP address 192.168.1.1. Let's call this WRT54G the primary. The other WRT54G is connecting to the primary in 'Client-Bridged' mode. Let's call that WRT54G the secondary.
Instructions update for V24:DHCP does not work between the DHCP server in the primary and the DHCP clients in computers connected to the secondary in this configuration with V24. You will have to assign static IP addresses like 192.168.1.10x to the computers connected to the secondary, a different one for each computer of course. Then it works fine. Annoying! -- This doesn't seem to be a problem with the currently recommended V24 SVN builds as of 2/22/09.
That's all.
You can now access the primary at 192.168.1.1 or the secondary at 192.168.1.2 if you want to configure either of them. -ECNY 2008-10-09
Important: If you want to use WPA encryption on your client bridge, make sure your key is no longer than 63 characters, even if you are using a HEX key. Not all IEEE 802.11 devices support long keys; older ones, in particular, are limited to short keys. In order for all devices in your network to communicate, they must not use a key longer than the least capable device in the network supports.
Don't use SP1. It has DHCP throughput issues. Use one of the Beta builds. Svn11296 is a reliable build for G routers.
[The following instructions only worked for me if the Setup/Advanced Routing was changed from gateway to router]
While the router is on, press the reset button for 30 seconds, then unplug the power supply for thirty seconds, continuing to hold the reset button, and then plug the power supply in for 30 seconds, continuing to hold the reset button.
Network connection configuration (Windows XP sp 3)
Plug the network cable in the client router and into your computer.
In Firefox or Explorer, type 192.168.1.1 in the address bar. (If form data is not saved correctly in Firefox, try another browser.)
Note: The default IP address of the client router is most likely the same as the host router (192.168.1.1), so it needs to be changed, usually to 192.168.1.2
> Note that if you give the router an IP of 192.168.1.2 it may cause IP conflicts if the primary router 'sees' another item, such as a computer, connected to it before it sees your bridged router 192.168.1.2. It will assign the first thing it sees the first allowable IP address (this range is set in your primary router admin page). If this range starts right at 192.168.1.2, it will assign the first thing it sees 192.168.1.2, which would thus make connecting to the bridged router impossible. Thus you should set secondary/tertiary routers to something NOT near the beginning of the allocatable IP address range of your primary router, such as 192.168.1.50. Or just simply use an IP outside of the primary router's assignable range. It is possible that all routers default to start assigning IP's at 192.168.1.100, which mine actually did originally but I thought I needed to sync up that range with the other routers - it would have prevented many problems for me by leaving well enough alone.
Important note: You will now need to type “192.168.1.2” in the address bar to access the client router.
15/Sep/2010 using a Dlink DIR615 D2 and V24 preSP2 build 14896 there is NO Client bridge mode - the options are AP,Client,adhoc,repeater,repeater bridge. I used Repeater Bridge and had sucess following the rest of these instructions.
If your router does not connect, disable security on both the primary router and the client router and try again. If you are able to connect with no security, check your settings. This is a common problem.
Network connection configuration (Windows XP sp 3)
Plug the network cable into the computer.It will detect the “network”, connect to the client router and obtain an IP address.Try accessing the web from your computer. It should now work
To see your new IP address:
To confirm that your are hooked up to the wireless network
I personally found all of these instructions confusing, so I've compiled an exact list of what I did to get the 'Client Bridge' working with the 'V23 SP1' version of the firmware.
Instructions update for V24:DHCP does not work between the DHCP server in the 'main' AP and the DHCP clients in computers connected to the secondary 'client-bridged' WRT54G in this configuration with V24. You will have to assign static IP addresses like 192.168.1.10x to the computers connected to the 'client-bridged' WRT54G, a different one for each computer of course. Then it works fine. Annoying!
My motivation: I wanted to get my XBox online (and on-LAN) from another room, without running Ethernet to it. WDS was out of the question unfortunately because one of my routers was a late-model WRT54G and as such wasn't (at the time) easily modified. I had an extra WRT54G lying around that could run DD-WRT. Alternatively I could have bought a proper Linksys or Microsoft solution to connect the XBox to the existing WiFi, but what's the fun in that?
My network is as such:
(I'm guessing that the Primary Router could be any make and model of wireless router as we're not doing anything to it!)
Slambert71 adds: I set this up today using a Linksys WRT54G V.3 with DD-WRT V23 SP2 firmware as the secondary, and a D-Link DI-624 with factory firmware as the primary and it works great.
My Primary Router has 128bit WEP Encryption enabled. It does NOT have Wireless MAC Address Filtering enabled. We will assume you want your Secondary Router to become 192.168.1.2.
Mailmanx adds: It worked successful for me with 2 WRT54GL Routers (Router with original firmware, Client Bridge with DD-WRT v23 SP2). WPA-PSK with AES enabled AND MAC Address Filtering (Be sure to set the the correct MAC address! The router provides a LAN, WAN and the needed Wireless MAC address of the Bridge). The MAC addresse can be found on the Status->Sysinfo tab of the DD-WRT webinterface.
Jerrytown adds (Sept. 28, 2008): I followed all the steps below and DHCP and DNS did not work. When I installed v23 SP2 (which is quite old at this writing) on the secondary router everything worked fine. Primary: WRT-54G2, Secondary: WRT-54GL.
I have my Secondary Router in another room, connected only to my laptop via an Ethernet cable to Port 1. The laptop has an IP from the Secondary Router's DHCP to begin with. Neither the laptop nor the Secondary Router are connected to anything but each other. I will be doing all of my setup from this laptop. If you have problems with DHCP or losing your IP address in the midst of these instructions, you may need to statically assign an IP to your Ethernet card. (I was running Knoppix Linux on the laptop and I didn't have to do that, but YMMV!)
I've done this procedure three times to test it, and I've reset the router to Factory Defaults every time. It may not be the optimal way of accomplishing the task, but it did work for me and I was able to repeat it with the same results each time!
walterg74: I tried this with success. My config is> Primary: old DI-524, client router DIR-300. Worked fine as is, and also, DHCP enabled on the PC worked perfectly for me.
djshorty: These instructions did not work using Buffalo WHR-HP-G54 as the host, WRT54GS v2.1 as the client, and v24. It only worked when I used v24 SP1 on both routers. As a side note, my Authentication Type is set to Auto.
lrp note: I did setup the wireless security mode to 'disabled' in the 'Wireless Tab — Wireless Security Subtab', I had NOTHING to change in the 'Wireless Tab — Advanced Settings Subtab' for this setup to work (DD-WRT v23 SP2 (09/15/06) std). lrp
darthn note: I connected an Asus WL500W and a WRT54GL v1.1 together with WPA2 Personal and it works flawlessly. The only problem I ran into is password length. I used 64 Random Hexidecimal and it failed. I retried with about a 25 character password and it works now.
I followed the 'practical example' instructions and when I attempted to connect to the primary router, it would not connect. I followed the instructions at the top and those worked. This 'practical example' set of instructions is overly superfluous. There's no need to turn off DHCP or disable STP, etc, because when you set the router to client-bridge, those options automatically go away. That being said, the basic instructions are to just set the IP address of the client router to something different than the host router, set the router to client-bridge mode and set the SSID, encryption and password all the same. If you want to connect to the internet, set the gateway and Local DNS IPs to your main router (setting the WAN port to switch and turning off the firewall are also good). For the record, I used a WRT54GL v1.1 as the host and a WRT54GS v2.0 as the client. Both were using DD-WRT v24 w/ sp1 Kakomu 17:30, 15 August 2008 (CEST)
I seconded these settings. Tried it on 2 WRT54G with v23SP2 and they work.
I third these settings. I succesfully linked a Dlink DI-524 (primary, not dd-wrt) and a Buffalo WHR-G125 (secondary, with dd-wrt). The secret here is that you need to change the firewall settings in the Dlink to allow all traffic from the source (ie 192.168.1.2) to all destinations (in the Dlink webbased router setup under advanced-->firewall) -dapple
These settings verified working on a WRT54Gv8. I couldn't ping my gateway before (on the far end router). I'm curious if a factory reset is what did it. Setting the auth type between shared and auto seems to make no difference. --IamBren 07:40, 28 December 2007 (CET)
Verified working with two WRT54Gs (v2 with DD-WRT as the secondary; v5 with Linksys as the primary) with 128-bit WEP and MAC address filtering. It didn't work at first, because I forgot to add the DD-WRT's wireless MAC to my filter list. After I did that, it worked perfectly. I have two devices plugged into the secondary - one is an HP LaserJet with JetDirect and a static IP; the other is a machine with DHCP, and both appear to work fine. I'm going to assume SSID broacast is required for this to work, which is unfortunate... ---shifuimam 2008-05-09
If you have an apostrophe in your SSID you will not be able to click the 'Join' button on the 'Site Survey' page. I also needed to switch from gateway to router in the Setup->Advanced Routing tab before it finally connected (DD-WRT v23 SP2 (09/15/06) std).
These instructions were perfect! I have a Linksys WRT54GL as the primary and a Motorola WR850G v3 as the secondary both with DD-WRT v24 Beta (05/02/07) std. I can now access both routers' configuration and files behind both routers. The only addition to the instructions is that you need to disconnect the cable for 10 seconds after the last step and reconnect to fully access all features. - PeterE 8 March 2008
This worked perfect for me with a Motorola/Netopia 3347W as primary router. However for some reason I had to force the wireless mode to G only on the WRT (I kept 'mixed mode' on the Netopia). WPA is working fine but WPA2 support would be nice. Also DHCP messages do not reach the primary router. Using DD-WRT v24RC6.2 - Googleg 29/Mar/2008
Edit: I could not get v24 RC6 or RC7 to pull DHCP, but manual IP worked. Flashed with v23 SP2, got DHCP on the first try. WRT54G v3. After joining the wireless network, DD-WRT took me back to the Wireless tab (where Mode selection is) and I had to click Apply Changes to actually get online. Other than that, flawless instructions. 4/25/08 - CK
Second on DHCP not working with v24 release. Also DNS is not available. Works fine if I manually configure both (using primary as the DNS server). WRT54Gv8, 128-bit WEP - diginorm 16-Jul-08
WPA2 is working fine for me using v24 RC7 on both the client and the access point. - stlpaul 5/17/08
I've tried this procedure on a ASUS WL-520GU using v24-SP1 as the secondary router, and connecting to a Planex router with unmodified firmware as primary. The PC connected to my secondary router could not obtain an DHCP from my primary router. After I assigned an IP to my PC, the clinet bridge worked smoothly. It is not a big problem for me to assign an IP manually to my device, so far, I am happy with my v24-sp1 on ASUS. - barry chum 9/22/08
For those of you that are using MAC filtering (on the primary router), it will work, but you need to add the MAC addresses (from the second router) for the Router, LAN, and wireless (these will be consecutive hex numbers). - HT 12/26/08
I was successful with this setup using WRT54GS (v1) running v24sp2 mated with an Actiontec MI424-WR (FIOS router). The single caveat I had was that I could not make it work with WPA2. It will work with WEP & WPA, but not WPA2. - uSlackr 12/28/09
I was successful with the setup using WRT54GS2 running v24sp2 after switching to WPA Personal on the FIOS Actiontec MI424-WR. Could not get WEP to work. William with sabaitechnology.com 02/21/10
Using a Belkin router belkin fd7230-4 v1444 I managed to get this work (after many attempts and using many different methods). I was initially using a micro SP1 build but I later found out that a updated build is required (so for people having trouble make sure you have a SP2 build because apparently there is a bug that doesn't allow client bridging and such to work AT ALL!-->check forums for info/links to these builds). I also found out my router took a few minutes to actually get things to work or notice changes so it is possible I had it working before but I just didn't give it the time it needed. I was very frustrated until I noticed this. Also, I couldn't always get my network to display under status -> wireless tab right away. But waiting a bit and rebooting the router did eventually get it to be listed there so don't fret if it isn't there instantly like the directions make it to seem. But after this, I was having problems getting the internet to work and I couldn't ping to the router. Again, maybe if I waited a bit more it might have worked but I tried it without any security (just to test it). It worked and after that I put some security back on the main router and then I simply added the same security information on the dd-wrt flashed router. That is all I did and I did NOT use the site survey to join my network again. - npdabest 5/22/10
johnytwobax: These instructions worked for me using a Airport Extreme as my primary AP and a WRT54G v.6 as my secondary. I was having trouble getting it working when using the IP 10.0.1.15 for my WRT54G, but when I changed that to 10.0.1.50 it worked smooth as butter.
With this setup, I have full access to both routers — which runs contrary to a lot of the notes concerning Client Bridge mode. One router is http://192.168.1.1, and the other is http://192.168.1.2. I can access both from either side of the bridge. There is no need to change any settings or IP addresses or the like with this setup in order to do so! Note: if you want to be able to access the Client Bridge router externally, you need to set its gateway address to point to the address of the router that has external access (192.168.1.1 in this example).
If you don't have a matched pair of routers like I did, I would recommend changing step 3.3 from 192.168.1.2 to an unused IP that matches your Primary Router. For example, if your primary router was set to 10.0.0.1, set this to 10.0.0.2 (assuming 10.0.0.2 is not already in use!). This way everything should be on the same subnet with unique IP addresses — and both routers should be accessible for configuration from anywhere on your network.
I was unaware at the time of writing this of any easy way of flashing a WRT54G V5 (and above) router with DD-WRT. This is not the case anymore, but there may still be lots of reasons to go with this setup rather than WDS. While WDS allows both ends of the connection to accept wireless clients, there is less bandwidth to go around, and there could be more latency. I'm guessing that this setup is still the best way to attach Ethernet devices to a wireless network with DD-WRT.
LRP note: I used this setup because I could not use WDS anymore (My initial setup was WAG54G-WDS-WRT54Gs ... I had to replace my broken WAG54G by a WAG200G, my setting became then: WAG200G-wirelessbridge-WRT54GS). At first, I attributed the speed increase to the ADSL2 capability ... I was really amazed when I could reduce a file transfer in between a wired machine behind the WRT54GS and a wired machine behind the WAG200G from about 55 minutes to 26 minutes (more than twice as fast). The only difference was the absence of WDS and the updated firmware. LRP
Please note that there are technical limitations to wireless bridges, but that you can connect multiple clients to a bridged router and they will have both lan and wan access. The average user will not likely notice any of these limitations.
BrainSlayer Forum Answer [1] : 'Client Bridge mode will only recognize one mac address on the bridged setup, due a limitation in the 802.11 protocol, even if there are multiple clients (with multiple mac addresses) connected to the client router. If you want to bridge a full LAN you must use WDS. The problem is that the 802.11 protocol just supports one MAC address, but in a LAN there is the possibility for more than one MAC address. It may cause ARP table problems, if you connect more than one computer on the far end of a Client Bridge mode setup. You will not be able to, for example, block mac addresses of client of the bridged routers or set access restrictions based on mac addresses in the bridged router.
bobn: Multiple devices on the wireless bridge seem to work fine, including using DHCP to the 'server' AP. Although multiple devices on the client bridge (wireless bridge) appear to have the same MAC address in the arp tables of devices on the 'server' AP, something in the wireless bridge translates that MAC address on return traffic back to the correct one for a given device's IP address behind the bridge. (I suspect that there is enough of the routing function still turned on in the client bridge mode to maintain an arp table local to the client bridge and make the translations.) Most protocols (ICMP, UDP, TCP) seem to work fine for multiple devices on the bridge, based on some quick testing. I would not want to count on multiple devices using non-IP protocols, and would be suspicious of things using special MAC addresses such as multicast addresses (eg OSPF routers, multicast apps).
smalldrummer2: If your primary router is running with SSID broadcast disabled, be sure to get the correct information about the network name and key everywhere else. You may have to go back and forth between 'Auto' and 'Shared' key in the Wireless/Advanced Settings tab. Once everything is set correctly, hit the 'Site Survey' button on the Status/Wireless page and then exit. After a few seconds, the SSID broadcast disable network will show up as what you are connected to. The signal strength meter will also appear and light up. (Note that I did this with WPA-Personal encryption only.)
The following thread goes furhter more in detail concerning this discussion [2]
WaS:DD-WRT's 'client bridge' mode' is not a transparent bridge. Only one single ethernet device is properly supported behind the router running in 'client bridge' mode. (It should have been baptized 'client adapter mode' instead!) In the old forum we already had endless discussions about this subject. Note that this is a technical limitation of the 802.11 standard, rather than a deficiency of DD-WRT. To create a true transparent bridge, with multiple ethernet devices at both sides, use WDS.
tlj2:My opinion is that DD-WRT does not properly support even a single device on behing the DD-WRT 'client bridge' mode radio. Here is my reason for my opinion:
1) Every network (subnet) should have unique IP addresses. All IPs in the network (subnet) should have a unique MAC address.
Question: How does this work with one network card with multiple IP addresses? (One MAC-address that has multiple IP-addresses.)
2) In a network (subnet), all devices talk directly to eacy other and do not use the gateway (default route). Each network card in the local network actually talks MAC address to MAC address - not IP address to IP address.
3) When you place a DD-WRT 'client bridge' mode radio in the local network (subnet), a unique IP address and unique MAC address is added into the network (no devices connected behind the DD-WRT 'client bridge' mode radio yet). At this time, every device in the network still has a unique IP address and a unique MAC address. Everything works and all devices in the local network (subnet) can talk to all devices in the network (without using a gateway or default route).
4) When you place a device behind the DD-WRT 'client bridge' mode radio, the network infront of the DD-WRT 'client bridge' mode radio sees the new device behind the DD-WRT 'client bridge' mode radio as having the same MAC address of the DD-WRT 'client bridge' mode radio. Every MAC address passing throught the remote DD-WRT 'client bridge' mode radio is re-written to the MAC address of the DD-WRT 'client bridge' radio. - - - - - Here are some steps you can perform to confirm what I am stating. A) On your PC computer, go into the DOS CMD (or COMMAND) prompt. ((START - RUN - CMD)).
B) Ping devices in your local subnet. Do not ping devices outside of your subnet. Also, ping devices behind your remote located DD-WRT 'client bridge' mode radio and also ping the radios.
C) Still in your CMD window, type in 'arp -a'. You will get an output like the one I show below:
C:>arp -a Internet Address Physical Address Type 192.168.10.1 00-14-1b-e6-78-f0 dynamic 192.168.10.2 00-0d-56-ba-36-a1 dynamic 192.168.10.3 00-0d-56-ba-36-b2 dynamic 192.168.10.4 00-0f-1f-66-ca-c3 dynamic 192.168.10.10 00-a0-c9-fc-14-d4 dynamic 192.168.10.89 00-01-e6-a6-6d-e5 dynamic 192.168.10.150 00-10-83-73-53-96 dynamic 192.168.10.254 00-11-21-64-3c-87 dynamic
D) Note that every unique IP address has a unique MAC physical address.
E) If you have a DD-WRT 'client bridge' radio, ping your radio and ping any remote devices behind your DD-WRT 'client bridge' radio. Now type in 'arp -a'. You may get an output like what I am showing below:
C:>arp -a Internet Address Physical Address Type 192.168.10.1 00-14-1b-e6-78-f0 dynamic 192.168.10.2 00-0d-56-ba-36-a1 dynamic 192.168.10.3 00-0d-56-ba-36-b2 dynamic 192.168.10.4 00-0f-1f-66-ca-c3 dynamic 192.168.10.5 00-0f-1f-66-ca-c3 dynamic 192.168.10.6 00-0f-1f-66-ca-c3 dynamic 192.168.10.7 00-0f-1f-66-ca-c3 dynamic 192.168.10.10 00-a0-c9-fc-14-d4 dynamic 192.168.10.89 00-01-e6-a6-6d-e5 dynamic 192.168.10.150 00-10-83-73-53-96 dynamic 192.168.10.254 00-11-21-64-3c-87 dynamic
F) Note that you have duplicate MAC addresses showing up in your 'arp -a' output. (your mac addresses and IP addresses will not be exactly the same as my sample above). The duplicate MAC address are the clients behind the DD-WRT 'client bridge' radio. And these duplicate MAC addresses will be the same MAC address as your DD-WRT 'client bridge' radio. - - - Summing up Although DD-WRT 'client bridge' radio connected devices may talk through the bridge, it is not reliable for all traffic and protocols. For those who are using DD-WRT 'client bridge' radios. Try this simple test while your network is active and passing traffic. Have all devices in your network perform a 'ping -t a.b.c.d' to all devices in your network. Include the ping to your radio. If you have 10 devices in your network, open up 9 CMD screens on each computer and have each screen 'ping -t' the other 9 devices. While the 'ping -t' is running, every device is forced to know the current MAC address and IP address of all other devices in your local network (subnet). Test and see if things still work. If you are running an advanced network which includes routing through the bridge, things go wrong pretty quick. Cisco CDP and Spanning Tree gets confused. Routers on both sides of the bridge fail to route to each other. There are large delays in the network. UDP traffic starts get lost. I really do like and use DD-WRT 'client bridge' radio configurations. I just suggest that anybody using this bridge mode have a grasp on potential issues. If the remote network behind your remote DD-WRT 'client bridge' radio is simple, you may not ever encounter a problem.
In the V23 firmware, you can set up the bridge from the Wireless->Wireless Mode menu. Just select 'Client Bridged'. This will automatically turn off DHCP. Note that only the Network Mode (b/g) and SSID settings are used in Client Bridged mode.
See notes on a 2.3 attempt at Client Bridged with a Belkin A/G AP in Bridge Install
I am also linking these in Client Bridged - updated for V24-Final redhawk
Here's some extra information about client bridging and some, perhaps unexpected, side effects. (If you're a wireless networking wizard, you'll know this already.)
When you've switched to Client Bridge mode you won't be accessing the remote AP until your IP changes unless your box and the remote network are on the same subnet. For example, say you have:
Once you've made the configuration changes in your router, you'll need to get a new address to access the remote network. A simple way to do this with most computers is to unplug the network cable, count to 10, and plug it in again. When the cable is plugged in again, it will get a new lease, but this time from the remote computer. For example, it will get an address in the 10.0.0.x range, e.g., 10.0.0.100. Now you'll be able to use the Internet over the wireless link as you expect.
However, you won't be able to access your Linksys to administer it. The solution is to turn off DHCP and use a static IP (e.g., 192.168.1.99), or, alternatively, assign an address for your Linksys from the remote subnet (e.g., 10.0.0.2). Be careful, however, not to pick an address already in use.
(Editorial Note: According to the introduction, 'Wireless Bridging is used to connect two LAN segments via a wireless link. The two segments will be in the same subnet and looks like two Ethernet switches connected by a cable, to all computers on the subnet.' From this info we can gather that you should be assigning an unused, unique IP address to your bridge router from your remote subnet, otherwise your bridging router will become inaccessible, and that's not optimal! Please see A Practical Example for a fully documented example of making this work.)
So I just bought a WRT54GL Ver 1.1 and I'm new. Anyhow, so I was trying and trying for two days straight to get Client-Bridge setup to work in V23sp2, followed the instructions as set out above in the practical example. However a lot of people have posted that WPA-Personal Security Protocol has not been able to work, not true, because I've done it by God's amazing grace! So here's the HOWTO
1. Follow the above practical example
2. Set Wireless Security > Security as WPA-Shared Key > TKIP
3. Enter the shared key ID
4. Go to Status > Wireless > Site Survey > Should probably find your 1st router and then click join, the next thing you should see is that its MAC address will appear on the Wireless AP at the bottom of the Wireless Status page.
5. Unplug your Ethernet connection from your PC and wait 20 seconds
6. Undo the TCP/IP setup to connect to the router (assuming you set the IP manually, you need to undo this)
7. Plug in the Ethernet connection and let it refresh! It should work!
Do not choose mixed mode (WPA+WPA2) on the Client-Bridge: the AP and the bridge would not be able to auto-negociate an encryption scheme, the bridge would not be able to connect to the AP.
Pick up one scheme (WPA or WPA2) on the bridge side: both schemes work nice - as long as the AP is configured for -, but you cannot let the bridge to make the decision.
I had a difference experience, I used a buffalo AP as a client bridge to a Linksys WAG60N. I was trying to use it to connect my Xbox360 (as well as other devices). If I set the security to WPA or WPA2 personal I would get about 6 packets through before the connection hung for a couple of minutes. If I set the security to WPA Mixed on BOTH DEVICES the connection works fine.
As a side note the Linksys management software looks like it's just a re-branded DD-WRT.
For those of you who have enabled MAC filtering on your Primary router, you need to add the WLAN MAC address of your Secondary router to the permitted MAC filter list of the Primary router. This is different than the MAC address printed on the bottom of the case, you can find it by going to Status->Wireless and the top line will list the internal MAC address. Of course, you will want to add the MAC filter list to the Secondary router. This should be setup prior configuring your WPA, WPA2, etc. settings otherwise you will spend some time pondering why the bridge isn't working.