DHCP over a dd-wrt client bridge.

What's involved: A WRT54G v8, original firmware, hooked to cable modem. Another WRT54G v8, using dd-wrt* acting as a dd-wrt client wireless bridge. DD-WRT v24 RC-4 (10/10/07) micro - build 8151M

The offending desktop is connected to the dd-wrt wireless bridge. It is running an ancient pre-SP1 version of XP Home, which has a nauseatingly incorrect IP stack. Very NT.

What I have found is that this works:

1) Hook up wired to the backhaul router. 2) Do the DHCP thing. 3) Disconnect from the backhaul router. 4) Reboot workstation, connected to the wireless client bridge. 5) Workstation gets the same IP address.

So, we add another (modern) workstation with a USB 802.11G thumb drive which carps the IP address of the old computer.

The workstation does not appear to get a DHCP response back and shrugs, chooses a 169.154.0.0 appropriate address.

I tried this with the horrible old XP version but I also got exactly the same results with a Knoppix boot-from-CD. The DHCP response times out.

I conclude that the dd-wrt wireless bridge does not forward broadcasts* to the main wireless router, and DHCP cannot be made to work properly over this arrangement. Yes, the answer is a fixed IP, and I'll do it as soon as I have backed up all 16 GB of stuff off the offending machine.

*I'm not sure of the layer, but I think it's a clue.

Once I have my story straight, I'll ply the waters of the dd-wrt community again.

-- Les Cargill

Reply to
Les Cargill
Loading thread data ...

Les Cargill hath wroth:

Try DD-WRT v24 RC-6.1

Yeah, that's possible. Meanwhile, do some sniffing with Ethereal or Wireshark to see what's happening.

Under XP, try running a DHCP query tool:

Type literally anything into the "Device Identifier" box. It can't be blank. Check the "request broadcast response" box. Do NOT check the "Use BOOTP" box.

There's also a Linux version at:

What I get is: option PKT:Opcode=2 option PKT:HType=1 option PKT:HLen=1 option PKT:Hops=0 option DHCP message type=5 option PKT:Flags=32768 option PKT:Seconds=0 option PKT:XID=41 option PKT:SName= option PKT:Boot file= option PKT:CIAddr=0.0.0.0 option PKT:YIAddr=192.168.1.100 option PKT:SIAddr=192.168.1.1 option PKT:GIAddr=0.0.0.0 option PKT:Magic cookie=99.130.83.99 option Subnet mask=255.255.255.0 option Gateways=192.168.1.1 option Domain name servers=192.168.1.1 option Broadcast address=192.168.1.255 option Server identifier=192.168.1.1 option DHCP address lease time=7200 option DHCP renewal time=3600 option DHCP rebinding time=6300 option PKT:CHAddr=00

Reply to
Jeff Liebermann

I realize this is not a dd-wrt support forum, but is there a blurb on the website which helps navigate which branch of that release is most appropriate for what platform? I suspect the "generic" is the right answer, but I can't really defend that suspicion :)

Just trudging through the forums is kinda slow :)

FWIW, using KNOPPIX, I get a DHCP timeout. I'm in the process of backing this machine up to reinstall Doze - it won't even allow setting a fixed IP without crashing.

This is an *OLD* version of XP, 2002-2001 vintage. Meh. If all else, I'll rig up a .bat file with a rarp command.

I get nothing on the main machine hooked wired Ethernet directly to the router that is the DHCP server. :( That path does not include the dd-wrt box at all.

The machine that cannot DCHP wirelessly can DHCP wired.

The MAC already has a DHCP supplied IP address, so I don't blame it. Un fortunately, the machine in quesiton is in use. I'll hook Ethereal up later.

Thanks much, Jeff.

-- Les Cargill

Reply to
Les Cargill

Les Cargill hath wroth:

Not really. You can lookup your specific model and mutation in:

but the option of which version to install is often missing.

With your WRT54G v8, you're limited to only the micro version.

I don't have a magic formula for optimizing the firmware release for specific routers. I tend to use the "no-kaid" version, because I don't need to play game server and can use the extra RAM.

Nope. It varies by model number and version. Downloads -> Release Candidates (the lastest) -> Version -> Broadcom -> Linksys -> WRT_54G_v8 -> dd-wrt.v24_micro_generic.bin This organization is new, but is a big improvement over the previous muddle.

Hint: I have no clue what machine you have, or which one is the "main" machine. Try to be less ambiguous.

Is that the "main" machine, Widoze machine, Knoppix machine, or something else? You see the problem?

The DHCP query tool usually works. It even works on my desktop, which is setup for a static IP address, but can query the DHCP server to see if an IP is available. It also works with multiple DHCP servers, will overlapping addresses, but makes a bit of a mess.

Good luck.

Reply to
Jeff Liebermann

Yup.

Understood.

Right. And then there are like... six versions under *that* :) Ah well....

Well, I wanted to stop short of numbering them :)

"hooked wired Ethernet" as opposed to "machine connected only by wireless".

The point is that the second, wireless-bridged WRT54G does not forward DHCP in some direction or another. This primary, Linksys-firmware WRT54G does transmit DHCP, either on the Ethernet switch or over the air.

This conclusion is supported by the indicated DHCP utilities. Thanks for that.

Sure.

Excellent. Thanks much for the pointer.

'Preciate it. I'll do any further research on the DD-WRT forum - it's a much more appropriate place. It's kind of scary in there, though... quite a little subculture.

-- Les Cargill

Reply to
Les Cargill

formatting link
For reference: DHCP does not work unless you use WDS.

-- Les Cargill

Reply to
Les Cargill

Les Cargill hath wroth:

Retch. DHCP *SHOULD* work through a wireless bridge (if it will pass broadcast packets). Using WDS seems like a band-aid or work around for a bug. I have a funny feeling there's some interaction with WOL (Wake on LAN) which also uses an all 1's broadcast packet. If the micro version supports WOL, try turning it on and see if it now passes broadcast packets. You can also use a WOL client to generate broadcasts to 255.255.255.255 to see if they make it through the bridge.

If you get a usable answer from the DD-WRT folks, I would be interested.

Hmmm... I just checked the Bug Tracker and couldn't find anything directly related to v25 RC4 and DHCP. There are a few DHCP bug reports, but I'm discounting any reports without corroberating details (i.e. clueless bug report). I don't see anything on the most recent

50 bug reports:
Reply to
Jeff Liebermann

Les Cargill hath wroth:

Well, I thought it was obvious, but I guess not. I was going to point you to:

but it's old, incomplete, and not very useful.

For your Linksys WRT54G v8: dd-wrt.v24_micro_generic.bin Generic version dd-wrt.v24_micro_olsrd_generic.bin OLSRD Generic dd-wrt.v24_micro_olsrd_we800g.bin OLSRD for Motorola WE800G dd-wrt.v24_micro_olsrd_wr850g.bin OLSRD for Motorola WR850G dd-wrt.v24_micro_we800g.bin Motorola WE800G dd-wrt.v24_micro_wr850g.bin Motorola WR850G

OLSRD:

is an ad-hoc protocol used for mesh wireless networks.

Reply to
Jeff Liebermann

If it's a MAC layer broadcast, that could be a problem. Multicast won't work - the firmware appears to simply hardcode a MAC address for each port. So it's not a true transparent bridge. I don't think plain-old ports on the switch will want to forward promiscuously. We've kind of inverted the original intended topology of the device by making the wireless MAC the backhaul.

Also, when I dump the arp cache on YET ANOTHER workstation :), I get the same MAC assigned to both the IP address for the client-bridge router (192.168.1.2) and a workstation connected to the Ethernet switch on that router (192.168.1.49)

C:\Documents and Settings\Owner>arp -a

Interface: 192.168.1.102 --- 0x10004 Internet Address Physical Address Type 192.168.1.1 00-1c-10-b0-32-eb dynamic 192.168.1.2 00-1c-10-ae-1b-76 dynamic 192.168.1.49 00-1c-10-ae-1b-76 dynamic 192.168.1.100 00-40-ca-90-f1-0b dynamic

C:\Documents and Settings\Owner>

For clarity:

Main machine - connected wired to WAP which has a cable modem on the WAN port. 192.168.1.100 and 192.168.1.1 respectively.

Second machine - wired to client-bridged WRT54G - 1.49 and 1.2

*Third* machine - USB 802.11G adapter elsewhere. The "arp -a" is done from there.

Not sure that this matters. Doesn't seem very bridge-like - a real learning bridge has no MAC address *per se*(1). Might have one in CAM for its own purposes ( inband traffic terminating at a CPU off the bridge... ).

(1) been a while - there may be an exception I'm missing, and it may have been colored by the equipment I was working with.

It does. Will do.

I'll put a little effort into that, then. My workaround for the moment is a static IP, but the least I can do for the guys is due diligence to get it on the scope.

Lemme start a thread on the website. It seems odd that this would go unnoticed - indeed, it hasn't - maybe just not noticed by the right people.

-- Les Cargill

Reply to
Les Cargill

It would be to the trained eye... :)

Ah! That's what I was missing. And that's what I originally meant by "generic", but I was trying to gather supporting data for the guess.

Thanks!

-- Les Cargill

Reply to
Les Cargill

I sit corrected - they know.

formatting link
It's not a transparent bridge.

-- Les Cargill

Reply to
Les Cargill

Les Cargill hath wroth:

Yep. I was going try and find that thread. Note that about half the repies indicate that DHCP should work behind a DD-WRT client. Unfortunately, there are about an equal number of "it works" and "it doesn't work" posting, with little substantiations. Even if there was some complication with assigning multiple IP's to a single MAC (perfectly legal as in multi-homed) you would still get at least *ONE* DHCP assigned IP address to the first client to connect.

Also note item 6 in the first article: ... 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. In other words, DHCP should work.

Look at the 2nd reply in that article... the one that lists the output of arp -a for a transparent bridge and for DD-WRT in client mode. Note that the 2nd apr -a example, for the DD-WRT client, shows multipile IP's for a single MAC. However, also note that all the entries are listed as "dynamic" which means they came from a DHCP server somewhere.

Now, there's a possibility that the author faked the results, or has a DHCP server running on his client, or some other oddity, but it would appear that DHCP worked for him with DD-WRT.

Incidentally, I've never heard of semi-MAC-Address-Translation (MAT) or a MAC proxy. I couldn't find anything on it with Google. Weird.

These might be worth digesting:

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.