HOWTO: Use Linksys WRT54G as a wireless ethernet bridge

[user1234]

This howto is intended to help people who currently use a wireless router in their house, and also have additional PCs or devices without wifi cards which cannot be connected to the wireless router using a cable because they're too far from it (like in another room).

This howto will explain how to use the wrt54g a to connect these remote PCs to the internet and your home network, without using wifi cards. This is possible using 3rd party firmware (sveasoft) which allows the wrt54g to operate in "client" mode, where it forwards packets from its connected devices to the main wireless router, using a wireless link.

I got my wrt54g running in client mode - that is, it serves as a bridge between a PC attached to it and the main wireless router. Here's my complete setup, starting with the wired connections (markeded by "<===>"):

Room 1: Cable Modem <===> D-Link DI-624 Wireless Router <===> PC-1
Room 2: WRT54G <===> PC-2

The DI-624 and the WRT54G connect to each other wirelessly. I also have a mobile laptop which connects wirelessly to the DI-624.
So in this case, the WRT54G let me use PC-2 without having a wifi card in that PC. In fact, I could connect up to 4 PCs to the wrt54g, and save the price of 4 wifi-54g pci cards, plus I don't have to install drivers for wifi cards (a pain in Linux). The wrt54g acts like a "wireless ethernet bridge", which in fact is another product sold by linksys (WET54G) for around $150. This is also useful when you have devices (in a room which doesn't have ethernet connections) which can only connect using a ethernet cable, but cannot connect wirelessly - like XBOX !

So how do you do it ? Here's the list of steps - you should be doing these steps (except step 1) from a PC attached to the wrt54g (e.g. PC-2 in my setup). Physically attaching a PC to the wrt54g is required only for this initial set up phase, because we need to login and set up the various options. Note that this doesn't require any changes to your main router's configuration, so it's quite safe with regard to not messing up your current networks' setup.

1. Download the "wrt54g alchemy firmware" (google this, or go here) version 6rc5 from the internet (it is the only one compatible with the new models wrt54g V2.2 & wrt54gs V1.1).
2. Upload the firmware to the wrt54g via the "Administration->Firmware Upgrade" option in the router's web interface.
3. Reset the device (press reset button until power led flashes - this could take 20 seconds or more). In the following steps, leave all settings which are not mentioned in the description at their default (only change the ones specifically mentioned in the step).

Note: We will use addresses that end in 128-255 for the wrt54g router and it's attached PCs. To make sure there is no overlap in the addresses assigned by the two routers, we have to make sure that your main router only assign addresses below 128 to its own clients. For example, if your main router address is 192.168.0.1, its DHCP address range could be 192.168.0.50 - 192.168.0.120. Another important note regarding the main router: some routers allow you to disable the broadcast of the SSID, but for this setup to work properly the SSID broadcast MUST BE ENABLED (which is usually the default behavior).

4a. In "Setup::Basic setup" screen, set Internet Connection Type to "Auotomatic Configuration - DHCP".
4b. Set the local IP to 192.168.0.129, assuming your main router is 192.168.0.x (in general, if your main router is a.b.c.d set the wrt54g to a.b.c.129).
4c. Set the Subnet Mask to 255.255.255.128.
4d. Set the "Gateway" to the IP address of your main router (e.g. 192.168.0.1).
4e. Set the DHCP Server to Enabled, and starting IP Address to something above 129 (e.g. 140).
4f. Save the settings on this page. You should reboot the attached PC, since the subnet mask has changed. Note: from now on you have to use the new local IP you set in step 4b (e.g. http:// 192.168.0.129) to connect to the router from your PC.

5. In "Setup::Advanced Routing" screen, make sure operating mode is "Gateway".

6. In "Wireless::Basic Settings" screen, set Wireless mode to "Client", wireless network mode to "mixed", and SSID to your main wireless router's SSID.

7. In "Wireless::Security" screen, set yor WEP/WPA settings which match the main wireless router. You should now be connected to the main wireless router. Note: if you have MAC filtering set up on the main router (which allows only specific clients to connect), then obviously you have to add the client router to the list of allowed clients.
To verify that you've established a connection to the main router, you can check the "Status::Router" screen, which should show an IP Address assigned by the main router (which would end with a number below 128), and the "Status::Wireless" page should show the AP Signal strength together with the mac address of the main router. Also you should now be able to ping the main router and even log in to it (using h ttp://192.168.0.1) from the PC attached to the client router (the wrt54g).

8. In "Security::Firewall" screen, disable firewall protection, as this subnet is already behind your main router's firewall. Also make sure that "Block Anonymous Internet Requests" is unchecked.

9. In "Administration::Management" screen, you can leave all settings at their default. You may want to enable remote management and Telnet or SSHD, especially if you want to be able to log in to the wrt54g from a computer which is not directly attached to it.

10. To enable PCs attached to the main router to be able connect to PCs attached to the wrt54g: Login into the wrt54g using telnel or ssh by running the command "telnet 192.168.0.129" and use same root/passwd as for the web interface. Then type this command (copy it exactly):

# echo 1 > /proc/sys/net/ipv4/conf/`route | grep default | awk '{print $NF}'`/proxy_arp

Now you should be able to ping/telnet to any PC attached to the wrt54g from any PC attached to the main router. Btw, this assumes that the subnet mask of the main router is the default 255.255.255.0.

Important note about the last step : The last step (which is an optional step) allows PCs attached to the main router to be able to connect to PCs attached to the client router, by specyfing the IP of the destination PC, for example "telnet 192.168.0.150". But they are still on two different subnets which do not share their broadcast messages, therefore when browsing PCs on the local network you will not automatically see the PCs attached to the other router. But you can always connect to them by explicitly specyfing the IP. Btw, this step was added after the initial posting of this HOWTO and solves a lot of the issues people discussed later in this thread, so don't worry if you read posts in this thread about problems with communicating between PCs attached to different routers. Also note that this proxy_arp setting is not saved in the WRT54G non-volatile memory like all the other settings, so when the router is rebooted (like after a power outage), it will be cleared and you will need to repeat step 10 to set the proxy_arp back on.


Done !!! That's it !!!!

So in summary, you don't need two wrt54g routers, nor do you need WDS capable routers. A single wrt54g (with the right firmware) can operate as a "client" of any other wireless router, and create a bridge so any device connected to it will be able to access your network and the internet. The above works great for me, even with 3-4 PCs attached to the wrt54g (verified that it works).

 

[Oakenfold]

I'll have to give this a shot, not that I need it but it sounds pretty interesting.
I'm currently using the sveasoft fw and can't remember if these options were in it or not.

 

[user1234]

The setup I explained above creates two networks in a hierarchy. The first one is created by the main router, which uses NAT to translate betwen the local addresses and the main address it gets from the ISP. The second network is created by the client router (the wrt54g) which translates the address in its client network to the address it gets assigned by your main wireless router. So it's a double NATed configuration, with packets originating in the client network doing one extra hop.

This setup has some a small limitation when a PC connected to the main router needs to connect to a PC on the client router's subnet. This will not work, since the main router will just forward it to the WAN (internet) because it's not really aware of the client router's subnet (the devices attached to the wrt54g). On my D-Link DI-624 there is no way to teach the router that it has a client router with its own separate subnet, which all datagrams addressed to 192.168.1.xxx should go to, because the DI-624 is not programmable like the wrt-624 is, so you can't change its routing tables. So to enable computers attached to the main router to connect to computers attached to the client router, I have to add a rouing table entry to each of the computers on the main subnet.

For example, in my case the main router (DI-624) is 192.168.0.1 and PC-1 attached to it is 192.168.0.101. The wrt54g is 192.168.1.1 and its attached PC-2 is 192.168.1.100. Also the wrt54g gets a dynamic IP from the DI-624 which is 192.168.0.112 (DI-624 allows static DHCP, so I can make sure it always gives the same IP to each physical device). So I can always access the wrt54g using this address (e.g. http: //192.168.0.112), from any PC attached to the main router (e.g. PC-1), assuming remote administration is enabled on the wrt54g, like I suggested in the steps above. But to get PC-1 to access PC-2, I have to instruct it to route requests addressed to 192.168.1.xxx thru the wrt54g, like this:

# route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.112

I have to do the above on every PC attached to the main router, if I want it to be able to talk to PCs on the client network. If your main router is also a wrt54g, you could try adding this entry on the main router, and it should then route request to connect to the client subnet correctly, for all its attached PCs.

 

[VirtualLarry]

Sorry, I replied to the other thread, without seeing this one first. A couple of questions:
1) I would be very interesting to know if it works to connect multiple PCs to the wired ports of the WRT54G while operating in Client AP mode, and whether/how this works with NAT disabled. Last I knew this wasn't currently possible, but was being worked on.
2) From what I understand, there is a limited set of other routers that will interoperate wirelessly (Client AP mode and/or WDS) with the WRT64G running Sveasoft firmware. The D-Link is one of them. You might not be so lucky with other brands/models.
3) I was under the impression that doing Client AP mode, or perhaps just WDS, was limited to only using WEP, not WPA. Has this changed? WEP is easily crackable.
4) Why use "Gateway" mode on the WRT54G when in Client AP mode? Why not use "Router" mode, and set up the subnets and routes?

It's really cool that you got that all working, I admit. I had similar plans, with a LinkSys 'b' router (Realtek 8181 OEM platform), and a WRT54G (running Sveasoft), but when I found out how dodgy Sveasoft was, and that I couldn't find an easy way to get updated Realtek firmware onto the other box, I decided against my original plan, and picked up a WUSB54Gv1 for my main PC to use as a client NIC, and use a switch and run ICS on my main PC to allow my laptop access to the net via WiFi as well.

 

[user1234]

1) Yes, I just connected another PC to the wrt54g and writing this from it, while the other one is playing ut2004 online !
2) Who told you that ? there is nothing special about what the main router has to do. In fact the main router (d-link di-624 in my case) treats the client router as just another wireless client with an address on it network (usually assigned via dhcp). The client router (wrt54g) translates between that address and the computer attached to it on its own client network (this is NAT, you know). So using this NAT, the wireless link between the main router and the client router is shared by all the PCs attached to the client router. As I said, the main router does not know or care about this, just like your ISP doesn't know how many computers share the address it assigns to your home.
3) Since the client router (wrt54g) acts just like any wireless client of the main router, it can connect in any way which is supported for wireless clients, including WPA, etc (haven't tried it though).
4) Gateway mose is the standard mode where the router performs NAT and forwards packets to its gateway router, which is the case in this configuration. I'm not sure what router mode does, maybe it doesn't do NAT ? Theoretically, I guess it could be possible to set this up as a single network, that is the PCs attached to the main router and and PCs attached to the wrt54g to be in the same netwrok, and possibly even use only one DHCP server. In that case, the second router (wrt54g) will not have to perform NAT. But I'm not sure that there's any addvantage to doing it this way (single network) compared to my client network solution. And it's not clear if this could actually be done using any available firmware. I do know that some people got WDS mode to work, but this requires two programmable routers like the wrt54g. My solution should work with any other router.

Maybe other configurations could also work, but I think my solution works quite well.

 

[user1234]

bump

 

[skyking]

I would be very interesting to know if it works to connect multiple PCs to the wired ports of the WRT54G while operating in Client AP mode, and whether/how this works with NAT disabled. Last I knew this wasn't currently possible, but was being worked on.

Larry,
user1234 has it working with nat enabled.

 

[VirtualLarry]

Thanks for the reply user1234. (Hope I got the caps right this time. )

The reason that I was asking about running multiple wired PCs behind a WRT54G running in Client AP mode or WDS mode, without NAT, was because of how the other wireless router would see things in terms of MAC addresses. (It will only see the MAC address of the Client WRT54G's wireless NIC, not the MACs of the machines connected to it via the wired ports, at least not without running in wireless bridge mode or WDS mode) NAT obviously solves that problem, at the IP level, but that would prohibit running things like Windows' file-sharing over the wireless-to-wireless link between machines connected to the two wireless routers. (Something that I would want to do, if I could get it working.) So perhaps leaving NAT enabled, is key to getting multiple wired PCs working, at the cost of a double-blind NAT setup. I wish WiFi just simply worked, like Fast Ethernet does and has for years.

However, you wrote:

So to enable computers attached to the main router to connect to computers attached to the client router, I have to add a rouing table entry to each of the computers on the main subnet.

How is that possible to implement, if the wireless router in Client AP mode is running NAT? There's no way to route to a machine behind a NAT, their addresses simply aren't visible on the "public" side of the NAT, period. (The side facing the "main" router.)

Did you actually test that that works? Can you ping the PCs connected to the wired ports behind the client AP-mode router, from PCs attached to the wired ports on the "main" router? If so, then I suggest that either NAT is not operational, somehow (perhaps it doesn't apply to the wireless link, only to the wired "WAN" port on the client router), or the two wireless routers are actually talking to each other in WDS mode, which as I mentioned before only works between a limited subset of devices, since WDS-mode protocol is not fully standardized, but your D-Link is one that I've read mentioned that will operate in WDS mode with a WRT54G running Sveasoft firmware. So I'm wondering how much of this is replicable with other-brand routers, or if you sort of happened to "get lucky" with your choice of hardware, and it turned out to be compatible.

I really do appreciate your posts and info though, I'm trying to learn as much about this as possible, and your experience is valuable.

 

[user1234]

Well, first of all NAT is enabled in the client network, since the machines in that network have a different network address (the prefix) then the network address of the main router. And second, it is working, as I can ping, ssh, sftp, VNC, http, and even use freeNX (remote X-windows) between the machines in the two networks in both directions.

I agree that normally it's not possible for outside packets to be directed to PCs behind a NAT router, but I guess it doesn't apply for this special "client" mode. I think that allows requests for the NATted addresses to be forwarded by the wrt54g to the PCs in its network without doing any translation.

So to route a packet from the a computer (e.g. PC-1) in the main network (attached to the D-link di-624), to a computer (e.g. PC-2) in the client network (attached to the wrt546), all I have to do is tell the PC-1 to send the packet to the wrt54g, using the wrt54g address on the main network.

My complete network setup is like this:

Main network: PC-1 192.168.0.101 <=wired=> DI-624 192.168.0.1 <--wifi--> wrt54g 192.168.0.112

Client network: wrt54g 192.168.1.1 <=wired=> PC-2 192.168.1.100

As you can see the wrt54g has an address on both networks (thanks to NAT), but it forwards requests addressed directly to computers in its network without doing any translation. This is probably the idea behind sveasoft's client mode, which is a different mode then AP/WDS, so I don't think any of the routers are operating in WDS in my setup.

 

[user1234]

Originally posted by: VirtualLarry
Thanks for the reply user1234. (Hope I got the caps right this time. )

This is not a laughing matter. My user name is case sensitive. Tell me, how many times you arrive at your computer in the morning, half asleep probably, and type in your password, only to get "access denied, please try again" response ? and after trying it a couple more times, banging on the keyboard and ready to smash it into bits, or call IT and vent your anger on them... only to find out that the caps lock key is on ?

 

[VirtualLarry]

Originally posted by: user1234
Well, first of all NAT is enabled in the client network, since the machines in that network have a different network address (the prefix) then the network address of the main router. And second, it is working, as I can ping, ssh, sftp, VNC, http, and even use freeNX (remote X-windows) between the machines in the two networks in both directions.

I agree that normally it's not possible for outside packets to be directed to PCs behind a NAT router, but I guess it doesn't apply for this special "client" mode. I think that allows requests for the NATted addresses to be forwarded by the wrt54g to the PCs in its network without doing any translation.

So to route a packet from the a computer (e.g. PC-1) in the main network (attached to the D-link di-624), to a computer (e.g. PC-2) in the client network (attached to the wrt546), all I have to do is tell the PC-1 to send the packet to the wrt54g, using the wrt54g address on the main network.

But that means that the IP addresses of the PCs on the wired side of the client wireless AP are routable over the LAN - therefore NAT isn't being used there. It may be enabled, but it's likely not being actively used for those connections.

Originally posted by: user1234
As you can see the wrt54g has an address on both networks (thanks to NAT), but it forwards requests addressed directly to computers in its network without doing any translation.

Well, NAT doesn't give out IP addresses nor configure them, if the router has an IP address on both interfaces (one connected to each network), then either you've configured them manually, or it's getting them (or one of them) from a DHCP server (which you've mentioned that the front-facing wireless interface does get one from the main router), or the firmware auto-sets one. Nor is NAT actively being used if there is no address-translation going on.

Originally posted by: user1234
This is probably the idea behind sveasoft's client mode, which is a different mode then AP/WDS, so I don't think any of the routers are operating in WDS in my setup.

Well, I'm just trying to point out that with only Client AP mode and NAT being used, what you claim is possible with your current setup (bi-directional pinging), should not be possible. So there must be some hidden magic going on here, and I'm suggesting that that "hidden magic" is what is really allowing this all to work, so it would be useful to find out what that is.

Can you do us all a favor, and set the client AP wireless's IP to a static IP in the same subnet as the "main" AP, and then configure the PCs connected to the wired ports on the client AP to use DHCP, and see if they are able to request and obtain an IP from the "main" router's DHCP server? That would be proof-positive that layer-2 broadcast frames are sucessfully negotiating the wireless link in both direction between the APs, which would likely indicate that either "wireless bridge" or WDS is active, whether you've explicitly configured them to be or not.

Another possibility, would be to assigned static IPs on the same subnet to every machine, disable NAT, and see if you can still connect bi-directionally and ping between wired PCs attached to each wireless AP.

I suppose that it's possible, that what Sveasoft's Alchemy firmware calls "Client AP mode", may not actually be that at all.

From what I understand, the way that WDS and wireless bridging mode works, is by having *two* source and destination MAC addresses in the wireless frames. Essentially, it works almost like addressing letters with a "C/O" ("care of") name on them. There is the immediate source/destination MAC address, and then a sort of sub-address. So in that way, an ordinary wired ethernet frame, coming from a PC on a wired port on the client AP, would have a source MAC from its ethernet card, and a destination MAC.. well, assume a broadcast frame (DHCP request) for now, so all 0xFF's. All of the PCs on the local wired ethernet switch fabric would recieve the frame and discard it, as well as the AP, which wouldn't discard it, and would either answer with a DHCP reply if it was running a DHCP server, or forward the broadcast frame over the wireless link if so configured. It would likely "wrap" the frame, containing the wired PC's source address, and send it over the wireless link with a source MAC of the AP's wireless interface, with a destination MAC of the other AP's wireless, or a broadcast, I'm not sure which. The "main" AP would recieve the frame over it's wireless interface, and if it was running a DHCP server, then it would send a reply back, with a primary destination MAC of the client AP's wireless interface, source MAC being the main AP's wireless interface, and a sub-destination MAC of the original wired PC that initiated the broadcast DHCP request frame. Whew.

 

[user1234]

Hmm... ok, I think you're confusing things, and I'm getting a little confused as welll.... no wait, I do understand how my setup works, maybe I need to explain it again. But first, let me clarify again that it works 100% right now, and I'm pretty sure it would work with any router as the main one, and the wrt54g as the client. Second, wrt54g is operating in a special "client mode" which is not AP mode - these are two different modes you can choose between with this firmware. Lastly, DHCP is completely optional - you could set up the same configuration by specyfing static addresses for each computer.

Ok, now for the clear and simple explanation. The main router is the default gateway for all the devices attached to it, wether wired or wireless. That means that any packet addressed outside the local network (192.168.0.xxx in this case) is sent to the main router, which then performs address translation on it, and forwards it over the WAN connection to the internet, . All the devices attached to the main router have addresses in this private local network, including the client router (wrt54g - its address is 192.168.0.112) which connects to the main router wirelessly.

Things work pretty much the same way in the client's router private network (the wrt54g and its attached devices - all have addresses 192.168.1.xxx). The client router is the gateway for all its attached devices, which means that all packets addressed outside the client private network are sent to the client router, which performs NAT and forwards them to the main router. So the main router doesn't know about all the devices in the client network, it only sees the client router with the address 192.168.0.112.

So with this setup the computers in the client network can contact any computer in the main network or the internet, because all externally addressed packets are forwarded by the client router to the main router (192.168.0.1). Now the tricky part is how to route packets originating in the main network to computers in the client network. This is tricky because the main router doesn't know about these computers and their addresses. In fact, it doesn't even know that the 192.168.1.xxx network exists (except maybe somewhere on the internet). That's why I need to manually add a routing table entry which says - "send all packets addressed to 192.168.1.xxx over to local device 192.168.0.112 (the wrt54g), instead of sending it over to the WAN interface". Now, normally the wrt54g should not accept packets addressed directly to its local private network, because all the packets it sends are NATed, so all replies should come addressed to its external address. But the special magic of "client mode" is that the wrt54g accepts packets addressed to its own private network, and forwards them to the appropriate attached PC. I hope you understand it now.

If you want to understand better, here's the routing tables of PC-1, PC-2 and wrt54g. Unfortunately, I can't dump the routing table of di-624, but it's quite obvious what it would be):

Routing table of PC-1:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 192.168.0.112 255.255.255.0 UG 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Here's the routing table of the wrt54g:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth1

Here's the routing table of PC-2:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Study the above and you will get it how it works.

 

[VirtualLarry]

Originally posted by: user1234
Second, wrt54g is operating in a special "client mode" which is not AP mode - these are two different modes you can choose between with this firmware.

Hmm, that seems a bit unclear then. I have no idea what Sveasoft's "client mode" is or does then, if it is not the same thing as what is commonly referred to as "Client AP mode", which is when a wireless access-point that negotiates/communicates with another wireless access-point running in infrastructure AP mode, as if it (the first wireless AP) was a simple wireless client NIC instead of an AP. (Which is what I thought your original description was about.)

Generally, "wireless bridging mode", operates point-to-point between two wireless APs, and requires manually configuring both APs with each other's MAC addresses as the two endpoints of the "bridge". However, I've heard reports of LinkSys WRT54 devices (running stock firmware), being able to operate in "bridge mode" in conjunction with a LinkSys WET54 wireless bridge device, without requiring manual configuration. (But not between two WRT54G's.) I'm not sure how that works.

The third is WDS mode, which allows multiple wireless APs to talk to one another, and also bridge ethernet frames from any connected wired devices. I don't know a lot about it, but as I understand it, it is not a standardized part of the 802.11 spec, and different mfgs implement it differently, so interoperability is rather hit-or-miss with WDS. Supposedly.

Client AP mode is not bridging, and the remote wireless AP in infrastructure mode will only see the MAC of the wireless interface of the client AP operating in client AP mode, AFAIK.

Maybe I'm missing something here, and perhaps the Sveasoft firmware when operating in client AP mode (sorry, "client mode") will proxy-arp and MAC-translate for the other devices attached to the wired ports. I guess that would allow for IP packets to pass and get routed between each wireless AP, but it wouldn't allow things like ethernet DHCP request/reply broadcast frames to pass, I don't think.

That sort of makes sense then, and means that NAT actually isn't applicable here, since the "translation" is happening at layer-2, not layer-3.

In other words, from the point-of-view of the "main" wireless AP in your example, all of the IPs assigned to PCs attached to the wired ports behind the client AP belong to the client AP and have the same MAC as the wireless interface on the client AP. However, when IP packets arrive at that interface, the client AP bridges them individually to the proper device's wired ethernet ports, using that device's MAC address that is known only to the client AP, not to the remote "main" AP.

It then makes sense, if the PCs behind the client AP are on a different IP subnet than those PCs connected to the wired ports on the "main" AP, then by default IP packets sent out from the "main" AP would get routed to the default gateway, which is the WAN interface, and they wouldn't go anywhere, so you have to manually configure the routing to assign the gateway for the client AP's local subnet to be the IP of the client AP's wireless interface, so that the packets will reach there. (Or I might have that slightly wrong, maybe the gateway for that subnet would be the "main" AP's wireless interface.)

Now this is starting to make some sense.

In fact, it would seem that the above probably would not work at all, if all of the devices, both the ones wired to the "main" AP, as well as ones wired to the client AP, were all on the same subnet. They have to be different subnets. But NAT has nothing directly to do with anything either, since no layer-3 address-translation seems to be needed nor happening.

What would be interesting then, to test this out, would be to ping from a PC attached to a wired port on the "main" AP, to a PC attached to a wired port behind the client AP, and then dump the ARP table ("arp -a" on Windows, I think), and see if the MAC address associated with the IP of the machine behind the client AP is the same as the MAC of the client AP's wireless interface.

In fact, ping several different PCs behind the client AP, from a PC on the "main" AP, and see if all of the MACs are the same, and that that MAC is the same as the client AP's wireless interface. If so, then my theory fits. If not, and those MACs are in fact the real MACs of the ethernet interfaces of each of the PCs wired behind the client AP, then something else is going on, and it is likely that WDS mode is enabled and running.

Edit: In case it wasn't totally clear, what I'm suggesting is really going on here is slightly different than NAT. Normally, all machines behind a NAT are on a local subnet with private IPs, and from the outside, there is only a single public IP address. In this case, it's a little different, from the outside, there is only a single MAC address visible, that of the client AP's wireless interface, but it appears to have multiple IP addresses, in fact all of the IPs of the machines behind it. The client AP recieves the frames with its own wireless MAC as the destination address, containing an IP packet with a destination IP that actually belongs to another machine, but to the outside, it appears to belong to the client AP. So it re-sends the ethernet frame containing that IP packet, except over the wired interface, with a destination MAC of the correct PC that corresponds with that destination IP on the local wired ethernet segment.

This is all the same basic sort of proxy-ARPing that goes on, with a dial-in RAS server on a local office LAN, etc. From the point-of-view of the other machines on the ethernet LAN, the RAS server has multiple IP addresses, and it proxy-ARPs on the ethernet interface for all of the dialed-in clients, which obtain their IPs via PPP or similar from the server.

Now if only one could convince LinkSys to implement this in the stock firmware, everything would be totally groovy. (I'm not really sure what this would be called, perhaps "Client AP mode with proxy-ARP and bridging"? "Enhanced Client AP mode"? "Multi-client client AP mode"?)

 

[user1234]

Originally posted by: VirtualLarry


It then makes sense, if the PCs behind the client AP are on a different IP subnet than those PCs connected to the wired ports on the "main" AP, then by default IP packets sent out from the "main" AP would get routed to the default gateway, which is the WAN interface, and they wouldn't go anywhere, so you have to manually configure the routing to assign the gateway for the client AP's local subnet to be the IP of the client AP's wireless interface, so that the packets will reach there. (Or I might have that slightly wrong, maybe the gateway for that subnet would be the "main" AP's wireless interface.)

Now this is starting to make some sense.

Bingo !!! Houston, we have lift off !! You are finally getting it, what you said in tha paragraph is exactly right (except what you said in parenthesis at the end).

In fact, it would seem that the above probably would not work at all, if all of the devices, both the ones wired to the "main" AP, as well as ones wired to the client AP, were all on the same subnet. They have to be different subnets. But NAT has nothing directly to do with anything either, since no layer-3 address-translation seems to be needed nor happening.

Yeah, I did try a few other settings which didn't work, before setting this configuration, but maybe there is a way to make it work as a single network. Maybe I'll try fiddling with it later.

I still think NAT is being done by the client AP, as the PCs in the client network are on a different (private) subnet, which the main router doesn't know about. So I think the client router is translating between those private network addresses (e.g.192.168.1.xxx) and its external address (192.168.0.112) which is the one it uses to talk to the main network and its AP. This is called NAT (n-to-1 mode which linux kernel performs natively).

What would be interesting then, to test this out, would be to ping from a PC attached to a wired port on the "main" AP, to a PC attached to a wired port behind the client AP, and then dump the ARP table ("arp -a" on Windows, I think), and see if the MAC address associated with the IP of the machine behind the client AP is the same as the MAC of the client AP's wireless interface.

In fact, ping several different PCs behind the client AP, from a PC on the "main" AP, and see if all of the MACs are the same, and that that MAC is the same as the client AP's wireless interface. If so, then my theory fits. If not, and those MACs are in fact the real MACs of the ethernet interfaces of each of the PCs wired behind the client AP, then something else is going on, and it is likely that WDS mode is enabled and running.

Not sure how to do this on linux, but I can check the logs on the main router (yep, the DI-624 is quite a nice router, for sure) which show all the connected wired and wireless clients by MAC address, and the only wireless client listed as currently connected is the client AP (wrt54g) mac address. Actually, I also have mac filtering set up on the main router, and I never needed to allow the MACs of PCs in the client network, I only allowed the (wireless) MAC address of the client router. Does that answer your question ?

Edit: In case it wasn't totally clear, what I'm suggesting is really going on here is slightly different than NAT. Normally, all machines behind a NAT are on a local subnet with private IPs, and from the outside, there is only a single public IP address. In this case, it's a little different, from the outside, there is only a single MAC address visible, that of the client AP's wireless interface, but it appears to have multiple IP addresses, in fact all of the IPs of the machines behind it. The client AP recieves the frames with its own wireless MAC as the destination address, containing an IP packet with a destination IP that actually belongs to another machine, but to the outside, it appears to belong to the client AP. So it re-sends the ethernet frame containing that IP packet, except over the wired interface, with a destination MAC of the correct PC that corresponds with that destination IP on the local wired ethernet segment.

This is all the same basic sort of proxy-ARPing that goes on, with a dial-in RAS server on a local office LAN, etc. From the point-of-view of the other machines on the ethernet LAN, the RAS server has multiple IP addresses, and it proxy-ARPs on the ethernet interface for all of the dialed-in clients, which obtain their IPs via PPP or similar from the server.

I think you can call this a double NATed configuration, which is how skyking correctly described it all along. The only non-standard behavior, which your questions made me notice, is that the wrt54g allows pass-thru of packets addressed directly to its private network, which is why my explicit main->client routing scheme works. I would think that normally these packets should be blocked by a NAT router, but maybe it lets them thru due to disabling the firewall and unblocking of anonymous requests as I described in step 8 of my setup guide above.

I believe this is how sveasoft intended for this client/bridge mode to work (except for my main->client routing enhancenment). The links below describe essentially the same thing as what I did, but in a little less clear and concise fashion. I just wanted to give people a simple one-stop-shop guide so they don't have to chase around bits and pieces of information, or try out an endless number of configurations, which could be quite daunting to people with little networking knowledge.

The docs below also clarify that this mode is not really a client/AP mode because the wrt54g doesn't act like an AP at all, it acts like a wireless client of another AP (the main AP) :

FAQ
Documentation

 

[user1234]

I already heard from at least two other people that got it to work, but anyone else which does it, please post your experience here. I have no doublt it will work with any existing wireless router (that is, the wrt54g will serve as a wireless bridge), but would still like to hear if it worked for you without problems.

 

[VirtualLarry]

Originally posted by: user1234
Bingo !!! Houston, we have lift off !! You are finally getting it, what you said in tha paragraph is exactly right (except what you said in parenthesis at the end).

Yes, I understand routing fine. What didn't make sense, is that you claimed to be able to route packets to private IPs behind a NAT. Which is not ordinarily possible, so something else is going on here, exactly what is what I'm trying to understand and pin down here, with your help, since what you have managed to get working, is pretty darn useful.

Originally posted by: user1234
I still think NAT is being done by the client AP, as the PCs in the client network are on a different (private) subnet, which the main router doesn't know about. So I think the client router is translating between those private network addresses (e.g.192.168.1.xxx) and its external address (192.168.0.112) which is the one it uses to talk to the main network and its AP. This is called NAT (n-to-1 mode which linux kernel performs natively).

If that's true, then the private IPs of the machines behind the client AP should not be visible, nor routable to, from anywhere else on the network. Only the "public" IP address of the client AP should be visible to the rest of your LAN. If you've been able to ping from a machine behind the main AP to a machine behind the client AP, then this cannot be true. That's all I'm trying to point out here. NAT is not being applied to those connections.

Originally posted by: user1234
Not sure how to do this on linux, but I can check the logs on the main router (yep, the DI-624 is quite a nice router, for sure) which show all the connected wired and wireless clients by MAC address, and the only wireless client listed as currently connected is the client AP (wrt54g) mac address. Actually, I also have mac filtering set up on the main router, and I never needed to allow the MACs of PCs in the client network, I only allowed the (wireless) MAC address of the client router. Does that answer your question ?

Unfortunately, no. If WDS mode is in use, it's concievably possible that the MAC-filtering only applies to the "primary" MAC addresses, not the secondary encapsulated ones. Could you please ping from a PC behind the main AP to a PC behind the client AP, and then dump the ARP table of that same PC behind the main router? Is the MAC shown for the IP of the PC behind the client AP, the same MAC as the client AP's wireless interface? If you ping multiple PCs's IPs behind the client AP, are the MAC addresses for all of them the same? In other words, from the point-of-view of a PC behind the main AP, are all of the IPs supposedly belonging to the PCs behind the client AP, matching to the MAC of the client AP's wireless interface? Is the client AP "spoofing" (proxying) ARPs on the network, on behalf of the PCs behind it?

Originally posted by: user1234
I think you can call this a double NATed configuration, which is how skyking correctly described it all along. The only non-standard behavior, which your questions made me notice, is that the wrt54g allows pass-thru of packets addressed directly to its private network, which is why my explicit main->client routing scheme works. I would think that normally these packets should be blocked by a NAT router

Yes. So therefore, that's not NAT. What I'm suggesting may be happening, is a sort of layer-2 NAT-like behavior. NAT itself is layer-3. Or WDS mode is running already.

Originally posted by: user1234
I believe this is how sveasoft intended for this client/bridge mode to work (except for my main->client routing enhancenment). The links below describe essentially the same thing as what I did, but in a little less clear and concise fashion. I just wanted to give people a simple one-stop-shop guide so they don't have to chase around bits and pieces of information, or try out an endless number of configurations, which could be quite daunting to people with little networking knowledge.

I agree, and I thank you for this thread, but your initial description of the behavior can't be correct, there's something more actually going on here. (Not to mention, "client AP mode" is something different than "wireless bridge mode". There is no such thing as "client/bridge mode".)

Originally posted by: user1234
The docs below also clarify that this mode is not really a client/AP mode because the wrt54g doesn't act like an AP at all, it acts like a wireless client of another AP (the main AP) :

Uhm, that is what "Client AP mode" is... an AP configured not for "infrastructure mode" (acting as a "server" for other wireless clients), but as a client of another AP (with the other AP configured for "infrastructure mode"). Since normally, two APs both configured for "infrastructure mode" cannot talk between each other wirelessly - which is what WDS mode was essentially supposed to allow.

I will agree with your original premise, that if this can somehow be proven to not be running in WDS mode, then indeed it must be entirely due to some "tweaks" that Sveasoft added to their implementation of "Client AP mode" in their Alchemy firmware, and therefore should indeed work in conjunction with any other normal wireless AP, since the WRT54G is doing all of the work.

I think that there is a way to dump the state of the DI-624's NAT tables, I'm not sure if there's a way to dump whether or not it's running WDS mode or not, that might give a clue as to whether WDS mode is active or not.

 

[user1234]

Did you catually read the first paragraph of this sveasoft documentation page ? The wireless mode list box shown has 3 options - AP, Client, and Ad-hoc. I've been using Client mode, not AP mode. And it clearly says "Client mode: This mode is used when we want the WRT54G to be connected to an AP (Access Point) like a client device (i.e. emulate a PCMCIA card or a PCI card). In this mode you cannot connect to the WRT54G that is in client mode using another wireless client device". And "AP mode: This is the default mode. It acts like a half-duplex HUB in the wired networks". I've been using client mode not AP mode !

And btw, NAT is "network address translation", which is happening here. Don't get confused by the routing entry I added. In fact, it would be simpler to understand the setup without it. In that case, the hosts in the client network are indeed unreachable from the main network, but the main network is reachable from the client network. So this is classic NAT, right ?

To work around this limitation, I had to add an entry to tell a compuer in the main network to route packets addressed to the client network addresses to the client router's address on the main network. So even though a PC on the main network can't directly send to a PC on the client network, it can send to the client gateway which I added to its routing table (I hope you understand routing tables, because that's what's used to implement all these high level policies). So obviously, the main network PC never sees the mac address of PCs in the client network. And for the last time, there is no WDS - in fact, I changed nothing in the configuration of the DI-624 when adding the wrt54g and its attached devices - that's part of the simplicity of this solution - no chance to mess up your existing configuration.

Here's the output of "arp" after pinging a PC in the client network:

Address HWtype HWaddress Flags Mask Iface1
192.168.0.112 ether 00:12:17:xx:xx:xx C eth0

As you can see it shows the mac & IP of the client router (MAC masked for security reason). Of course, this only works after I add the routing table entry:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.112

 

[dildar]

Thanks for all the good work user1234!
I think you might be able to help me with this one.
I have limited network experience so need your help with this.
I have both of the ap and the bridge talking getting an ip from the dhcp.
here is the setup
External----192.168.1.1 dhcp Firewall Firebox-----192.168.1.20(wrtg54G)ap mode------->
<-------(192.168.1.5)Client Mode (192.168.2.5)-----(192.168.2.x)192.1PC1/PC2/PC3/PC4

I have the dhcp turned off on the (.20) ap mode and would like to have the other router also have the dhcp turned off.
If not is there a way for the computers in the two subnets to see each other? Maybe throught the different subnets?
If so would I also make the routes in the Firewall or in the router or both to connect the two differnet subnets?
This is so we can connect the computer from both sides of the network to see the windows domain and connect to it using windows xp pro.

 

[skyking]

dildar, do you have 2 wrt54g's?

 

[Nutdotnet]

user1234- I have the same setup as you.

My question is, and after reading this thread seems possible, but how exactly does one go about allowing PC1 and PC2 to speak to each other?

I have a modded Xbox that I am able to FTP into. The problem is, and why I'm currently not using the 54g in client mode, is that the DI-624 sees the WRT54g (192.168.0.112) but does not have a specific IP for the Xbox, since the Xbox's IP is being assigned by the WRT54g. So, is it possible to FTP into the Xbox with this setup? Basically the Xbox is just like any PC connected to the client. And if so, how exactly would I configure it? If you don't mind explaining, thanks!

 

[JackMDS]

Let first thank you ser1234. You are the first one to put the effort to actually explain this process after hundred of posts that amount to one short phrase? Get a WRT54 and hack it.

How ever can you explain to me the advantage of the usage of the WRT54?

The Buffalo and the Belkin Routers can do WDS without all of this Hoopla.

The Belkin is Cheaper and Buffalo is better.

So what is the Story?

:sun:

 

[VirtualLarry]

Originally posted by: user1234
Did you catually read the first paragraph of this sveasoft documentation page ? The wireless mode list box shown has 3 options - AP, Client, and Ad-hoc. I've been using Client mode, not AP mode. And it clearly says "Client mode: This mode is used when we want the WRT54G to be connected to an AP (Access Point) like a client device (i.e. emulate a PCMCIA card or a PCI card). In this mode you cannot connect to the WRT54G that is in client mode using another wireless client device". And "AP mode: This is the default mode. It acts like a half-duplex HUB in the wired networks". I've been using client mode not AP mode !

I just wanted to point out, that it seems that the reason that you don't understand what I've been saying, is that I've been using the "industry standard" terminology for these things. Now that you've pointed out what it shows in the firmware, I'm not surprised, because Sveasoft made up their own names for these things. No wonder we aren't communicating clearly here.

Here's a translation table:
(Sveasoft) - (industry standard)

"Client mode" - "Client AP mode" (or "AP client mode")

Meaning: When an AP operates in a mode as if it were a client wireless NIC, capable of associating with another AP running in infrastructure mode.

"AP mode" - "infrastructure mode"

Meaning: A wireless AP running in infrastructure mode, usually with a wired connection to the rest of the LAN. Allows wireless client NICs to associate with it, in order to wirelessly access the wired LAN.

"Ad-Hoc mode" - "Ad-Hoc mode"

Meaning: Sort of a peer-to-peer, free-for-all broadcast-packet mode. (I think.) Normally does not allow direct access to a wired network. There is no "association" that takes place. Effectively a wireless-only collision domain. (Correct me if I'm wrong there.)


You will clearly note, that there are no provisions in the above, to allow stations on the wired portion of a LAN, connected to an AP, to talk wirelessly to another AP, connected to another wired LAN segment. Thus the creation of a couple more wireless protocols.

"wireless bridge mode"

Generally, this operates between two specifically-configured APs, which will talk wirelessly to each other, and bridge ethernet frames from their attached wired ethernet segments over the wireless link to the other AP's attached wired ethernet segment. Essentially just like a normal ethernet bridge, except the frames are encapsulated and transmitted wirelessly between two APs. Depending on implementation, the APs may or may not allow other wireless clients to connect to them at the same time. (IOW, running in wireless bridge mode may disallow simultanious operation in infrastructure mode.)

"WDS mode" (Wireless Distribution System)

Generally considered to be more flexible, but also not standarized, so compatibility is implementation-dependent.

Kind of like bridge mode, but functions as a many-to-many wireless connection between APs with the same SSID. (I think.) In some implementations, it may not even require any specific configuration like "wireless bridge mode" does. (Is that what "lazy WDS mode" is? I'm not entirely certain yet how that is different from "normal WDS mode". I think that the Sveasoft firmware does implement "lazy WDS mode".)

At least, that's what I understand about 802.11 general protocols thus far. If I'm wrong, then I welcome any and all corrections.

Originally posted by: user1234
And btw, NAT is "network address translation", which is happening here. Don't get confused by the routing entry I added. In fact, it would be simpler to understand the setup without it. In that case, the hosts in the client network are indeed unreachable from the main network, but the main network is reachable from the client network. So this is classic NAT, right?

So you are saying, that there is essentially a uni-directional NAT operating, that when PCs behind the client AP want to talk to the main AP or PCs behind it, then the client AP NATs those connections, but you can also trivially bypass NAT in the other direction, by setting up a routing-table entry? That seems like kind of a wierd setup, if you can route, then why not route both ways?

Originally posted by: user1234
So obviously, the main network PC never sees the mac address of PCs in the client network. And for the last time, there is no WDS - in fact, I changed nothing in the configuration of the DI-624 when adding the wrt54g and its attached devices - that's part of the simplicity of this solution - no chance to mess up your existing configuration.

It may be that both firmware already implement a compatible form of "lazy WDS" - there may not be any configuration needed. But I'm speculating there, based on a seeming recollection that the DI-624 was one of the few routers that was WDS-compatible with the Sveasoft-modified WRT54G's.

Originally posted by: user1234
Here's the output of "arp" after pinging a PC in the client network:

Address HWtype HWaddress Flags Mask Iface1
192.168.0.112 ether 00:12:17:xx:xx:xx C eth0

As you can see it shows the mac & IP of the client router (MAC masked for security reason). Of course, this only works after I add the routing table entry:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.112

Hmm, I don't remember what I was originally trying to discern there, but.. ARP is a layer-2 broadcast protocol, is it not? So therefore, it shouldn't matter what the layer-3 routing tables say, if something responds to an ARP-request broadcast or not. So that doesn't make total sense either. Was that ping-request and ARP table dump, from the main router itself, or from a PC behind the main router?

 

[user1234]

Originally posted by: JackMDS
Let first thank you ser1234. You are the first one to put the effort to actually explain this process after hundred of posts that amount to one short phrase? Get a WRT54 and hack it.

How ever can you explain to me the advantage of the usage of the WRT54?

The Buffalo and the Belkin Routers can do WDS without all of this Hoopla.

The Belkin is Cheaper and Buffalo is better.

So what is the Story?

:sun:

The story is that you don't need two routers which can operate in WDS mode. If you already have a non-WDS router and you want to connect remote devices (which are not wifi-enabled) to your network , you need a wireless bridge, which usually costs $100 or more. With this solution you can add a wrt54g router with modified firmware, to operate as a wireless bridge, so you can place it next to your remote devices and attach it to them, and it will connect to your existing main wireless router. I guess WDS is a more comprehensive and/or general solution, but I believe it's slower and may be hard to setup due to compstibility problems. If you know exactly how to do it, and which routers are compatible, please post that information, so people can decide for themseleves which solution is more reliable, easier to set up and cost effective.

 

[user1234]

Originally posted by: dildar
Thanks for all the good work user1234!
I think you might be able to help me with this one.
I have limited network experience so need your help with this.
I have both of the ap and the bridge talking getting an ip from the dhcp.
here is the setup
External----192.168.1.1 dhcp Firewall Firebox-----192.168.1.20(wrtg54G)ap mode------->
<-------(192.168.1.5)Client Mode (192.168.2.5)-----(192.168.2.x)192.1PC1/PC2/PC3/PC4

I have the dhcp turned off on the (.20) ap mode and would like to have the other router also have the dhcp turned off.
If not is there a way for the computers in the two subnets to see each other? Maybe throught the different subnets?
If so would I also make the routes in the Firewall or in the router or both to connect the two differnet subnets?
This is so we can connect the computer from both sides of the network to see the windows domain and connect to it using windows xp pro.

I understand you have two wrt54g with the sveasoft firmware ? if so, it would be simple to do it, since you could easily add entries to thier routing tables. Your PC1/2/3/4 should already be able to contact the main ap (192.168.1.20) and its attached devices (to verify that, try to ping the main ap from PC1, for example). Now for the other direction, to be able to connect from a PC attached to the main AP, to a PC attached to the client router. To do so, you need to tell the main AP to route packets addressed to 192.168.2.x to the client router, so telnet into the main router as root, and type this:

route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.5

Tell us if this work.....

 

[user1234]

Originally posted by: Nutdotnet
user1234- I have the same setup as you.

My question is, and after reading this thread seems possible, but how exactly does one go about allowing PC1 and PC2 to speak to each other?

I have a modded Xbox that I am able to FTP into. The problem is, and why I'm currently not using the 54g in client mode, is that the DI-624 sees the WRT54g (192.168.0.112) but does not have a specific IP for the Xbox, since the Xbox's IP is being assigned by the WRT54g. So, is it possible to FTP into the Xbox with this setup? Basically the Xbox is just like any PC connected to the client. And if so, how exactly would I configure it? If you don't mind explaining, thanks!

You have to add a routing entry to each PC in the main network, because you can't change the routing tables of the DI-624. You can use the statement I mentioned in the thread "route add..." if the computer in the main ntwork is running linux. For windows, I'm not sure how to do a similar thing, but it should be possible.....