Client bridged mode can be worth the effort if you know how to do it properly. Client bridged mode is more transparent than regular client mode in the sense that all devices, both in front of and behind the router in client bridged mode, are all on the same subnet. In client mode, it's more of a double-nat setup, where you have one nat (the client) behind another nat (the regular router).

Getting certain network things to work (like hosting something behind the 2nd client router) can be more of a hassle in client mode because you'd actually have to setup port forwards for devices/services behind the 2nd client router.

If you can get client bridged mode to work, then that would be best. Let me think if I remember how to do client bridged mode:

1. Get everything setup the way you'd like it on your 1st router (designated main or host router), such as IP schema, SSID name, encryption - basically things that would break the client bridged system after setting it up. As far as encryption goes, if you're up for some experimentation, you can try doing client bridge with no encryption on the wireless network, then modifying it for WPA-PSK. This allows you to "practice" the setup without having to worry about WPA going jank on you. The last time I tried it with WPA it didn't work properly (it did work, however, properly with the Thibor release of hyperwrt, but I'd much rather use dd-wrt), but that was probably 6 months ago.

2. Head on over to your 2nd router (designated client router) and reset it to the factory defaults so that you have a clean base with which to start.

3. Set the 2nd Router's "Router IP" (in the Basic Setup tab) to an IP that falls within your existing LAN subnet. For example, if you use the 192.168.0.0/24 schema that the majority of home users do, then set your 2nd router's IP to 192.168.0.2 and disable DHCP at that screen. Apply that and let it reboot.

4. Now, the issue that arises is that you're plugged into your 2nd router, except that DHCP is off, so your computer may not have an ip address at this point. That's ok - all you need to do is set one statically for the time being. Pick something in the 192.168.0.0/24 subnet just as you did above (obviously don't pick the same ip address) and then you can resume working with the 2nd router.

5. Once you've done that and you're back at the router config pages, head over to the wireless section. Mimic the wireless settings on your 1st/main router. I actually start with the encryption page FIRST, as this seems to work better (not sure why). Once you've entered the proper WEP/WPA key (you are using encryption, right?!), apply that, and set the SSID of the existing network, AND set the wireless mode to client bridge, and apply that too.

6. After a little while (it does take a little bit of time, up to a minute I would guess), the 2nd router should connect up to the first one and everything should work fine! The main router will handle DHCP for any and all devices connected, whether it be on the normal wlan or behind the client bridge - it won't matter which.

Give this a shot and let me know if you have troubles - this can be a rather tricky setup if it gives you problems.

Client bridged mode is more transparent than regular client mode
in the sense that all devices, both in front of and behind the
router in client bridged mode, are all on the same subnet.

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.

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.

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.

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:

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._________________******************************************
Tom Jones
North Idaho - USA
******************************************

I'm grateful for this discussion on client bridge mode.
First, it may answer a lot of questions before they're asked.
Second, I've been interested in the difference between DD-WRT client bridge mode and the Thibor 15x WET mode.

My experience is that the client bridge GUI is unaccessible while serving its function, but a WET box GUI can be accessed under use.

Are these different implementations of the same concept, or are they completely different solutions?

In my experience they behave differently, but I'm going to try the arp commands myself and see what happens._________________DD-WRT<--Have you contributed to DD-WRT yet?

My opinion is that DD-WRT does not properly support even a single device
on behing the DD-WRT "client bridge" mode radio.
[...]
If the remote network behind your remote DD-WRT "client bridge" radio
is simple, you may not ever encounter a problem.

Huh?

Again: It does work with one single ethernet device -- normally.
Only the MAC address of the router itself is substituted for the one of
the ethernet device, and even this can be avoided by "MAC cloning" on
the router. And the address of the router itself should not be in the
same subnet where the bridging is performed -- but that's a general
problem of any "transparent" device.

My opinion is that DD-WRT does not properly support even a single device
on behing the DD-WRT "client bridge" mode radio.
[...]
If the remote network behind your remote DD-WRT "client bridge" radio
is simple, you may not ever encounter a problem.

Huh?

Again: It does work with one single ethernet device -- normally.
Only the MAC address of the router itself is substituted for the one of
the ethernet device, and even this can be avoided by "MAC cloning" on
the router. And the address of the router itself should not be in the
same subnet where the bridging is performed -- but that's a general
problem of any "transparent" device.

try this very simple test

make a bridge

place 1 router in front of the bridge
Use a 2 port ethernet router - 1 port facing the bridge

Re: And the address of the router itself should not be in the
same subnet where the bridging is performed -- but that's a general
problem of any "transparent" device.

what ?

I have configured hundreds of bridges to support 100,000 + customers in 5 North Western states (USA).

I have configured ethernet bridges, dsl bridges, frame realy bridges, t1 bridges, ds3 bridges, fiber optic bridges, microwave bridges, ATM bridges, vpn bridges, dial-up bridges and this is the first first bridge-like device I have encountered in my 25+ years of networking that re-writes MAC addresses.

All bridges in the past I have worked on, I could number the IP address of the bridge in the actual network being bridged or outside the bridged network. However none of the bridges has ever re-written the MAC device identifier.

Anything that re-writes the MAC address is a PROXY. - And it is not really a true PROXY arp device at that.

The DD-WRT client bridge mode is actually a semi-PROXY bridge. It is not transparent - it is actively changing the MAC.

Transparent bridging means totally transparent - nothing changed. The DD-WRT bridge mode is not transparent - it is acting as a semi-proxy bridge.

-EDIT -- I think it actually acts more like a semi-MAC-Address-Translation (MAT). Kind of like the way NAT is for IPs, this MAT is to MACs.

I have an advanced question for anybody in the deep knowledge and understanding and wisdom of advanced TCP/IP networking ....

Because the DD-WRT bridge mode actually can run several devices behind the bridge (for some not correctly and for some no problem), I have gotten to thinking what must be going on...

Is the bridge mode actually acting as a PAT device inside the subnet? - a PAT/MAT device? - a proxy PAT? - a proxy MAT?

Is it changing MAC address at the layer 2 or 3 level of networking? -or- is it changing ports at the layer 4 or 5 level of networking? (I syspect this bridge is operating in the layer 4 or 5 level of networking.

(Note - most bridges I know of are strictly layer 2 devices and only use layer 3 only for management)_________________******************************************
Tom Jones
North Idaho - USA
******************************************

Client bridged mode is more transparent than regular client mode
in the sense that all devices, both in front of and behind the
router in client bridged mode, are all on the same subnet.

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!)

I've got a WRT54GL in "Client Bridged" mode with four devices behind it, and they all work fine...

We are lacking an authoritative description of what BrainSlayer intended
to implement in fact -- regardless of the name he used. Without any
documentation of the intended behavior, however, nobody can know
whether the actual behavior does or does not meet these specifications.

All we know so far is that the promises implied by the word "bridge" are
not fulfilled. Any further discussion is useless, IMHO, as long as we can't
read BS' mind. Full stop.

I'm glad to see so much discussion of my humble HOWTO. What this thread is not for, however, is troubleshooting individual client bridged problems, only the howto, theoretical discussions of how we think client bridged mode was implemented, and how both of these items can be tweaked to better serve the community.

If you're personally having a client bridged issue, like those who posted in this thread from the old forum: http://forum.bsr-clan.de/ftopic8364-0-asc-0.html
then go ahead and start a new thread. Someone will be more than happy to assist you.

EDIT: I've gone ahead and deleted Pilo's post (not to single you out, Pilo) so that this thread will only contain the discussion that has taken place - If Pilo or others are having client bridged issues, they are advised to start their own thread.

My opinion is that DD-WRT does not properly support even a single device on behing the DD-WRT "client bridge" mode radio.

<cut out to save space>

If the remote network behind your remote DD-WRT "client bridge" radio is simple, you may not ever encounter a problem.

Great job showing that DD-WRT's client bridged mode using MAC address proxying in some way (I apologize if this explanation is incorrect, but what we do know is that it's not working in the manner most of us expected).

Have any of us tried using client bridged mode from another firmware, like thibor's hyperwrt releases? I know that BS said a long time ago that our and their client bridged modes were implemented very similiarly. I had a hard time accepting this because I could never get ( client bridged mode using WPA-PSK working on DD-WRT, but always could using hyperwrt this discussion took place probably 8 months ago).

The reason I ask is because I'm curious to know how these other releases do it, and if they do it better, how best to mimic it. Sometimes a little competition can help overall quality, and by doing reasearch, maybe we can improve ours to where people are more generally satisfied with how dd-wrt's client bridged mode operates.

So if anyone is willing to do a few tests on hyperwrt just like tj2 did in his above post, I think that would benefit us a lot, and provide us a good idea of how another firmware is implementing it. I dare not mention Sveas****'s name around here, but if anyone's up for testing that one, be my guest - I won't touch it._________________WPA2-RADIUS AP: DD-WRT v24 SP1 std on WRT54GS v2.1
Spare AP: DD-WRT v24 SP1 std on WRT54G v3

I did test the Linksys WET54G bridge. It has problems with the MAC also. I assume that the WET bridge mode is what the WET54G is/does.

I tested the WRT54GS with Linksys firmware, it also does not work properly.

Using DD-WRT on the client side, it does appear that WDS will pass the MACs. However it is also acting as a remote AP also - this is not what is really desired. A WDS network of 100 clients would pretty much jam the airways.

I beleive we may be looking for a "non-root bridge" mode. That is what Cisco calls it in their 1300 radios for the client bridge side. This radio does pass MACs without re-writing them._________________******************************************
Tom Jones
North Idaho - USA
******************************************

Do you think you'd be able to try out a release of Thibor's HyperWRT..
-cut-to-save-space

I have never used it and don't know how to configure it. I will look, try and see what I can do._________________******************************************
Tom Jones
North Idaho - USA
******************************************

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou can attach files in this forumYou can download files in this forum