1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WET bridge - All devices show as same MAC address

Discussion in 'Tomato Firmware' started by Radestock, Apr 8, 2008.

  1. Radestock

    Radestock Addicted to LI Member

    Recently invested in a WRT54G and flashed with Tomato 1.17.

    I was hoping to use it to bridge a couple of PC's to my main router which holds my ADSL connection (a Netgear DG834G).

    Now everything works fine, both PC's connect to the internet and are given IP addresses by the Netgear Router. The only trouble is that the two PC's and the WRT54G all have the same IP address on the Netgear router.

    Having had a look around first and seen this I had thought that WET mode compared to client bridge mode would allow the Netgear router to see all the connected devices and their MAC addresses. Obviously it's a pain with port forwarding etc when they all share the same MAC address.

    The WRT54G is set up in Wireless ethernet bridge mode and the Netgear's IP address is set as the gateway in Tomato. I've tried having the WRT54G on the same subnet (192.168.0.xx) as the Netgear to see if that made a difference.

    Is it a limitation of bridging in general here? I did think that WET would do what I'm after. Are there some other setting that I need to change on the WRT54G? Obviously I'd rather not have to invest in another WRT54G, but it would seem doing so and using WDS would also solve my problems.

    Any help would be great.
  2. Kiwi8

    Kiwi8 LI Guru Member

    Firstly, I assume u are using DHCP server on your main Netgear router. If that's the case, then do exclude the IP that u are using for your WRT54G, from the settings in your Netgear router. This will prevent your main router from issuing out the IP address that is used by your WRT5G.
  3. Radestock

    Radestock Addicted to LI Member

    Yeah, I gave the WRT54G an IP of, the Netgear being The Netgear is the DHCP server.

    The WRT54G is far enough up the range so that the Negear doesn't give out it's IP to anything else. Like I said though it didn't seem to make any difference compared to when the WRT54G was on a different subnet (

    All three devices connected to the Netgear (Two PC's bridged through the WRT54G, and the WRT54G itself) are showing the same MAC address on the Netgear (That of the WLAN of the WRT54G). Everything else 'works'.
  4. Kiwi8

    Kiwi8 LI Guru Member

    Please exclude the range explicitly instead of just selecting the IP that is far enough up the range, see if the problem is still there. For example, if your WRT54G is using, set the Netgear router to issue out only addresses excluding it, say from to
  5. RonWessels

    RonWessels Network Guru Member

    My understanding is that this is the fundamental difference between WET mode and WDS mode. In WET mode, the access point sees only the one client (your WRT54G) that happens to "magically" connect to multiple machines. The WDS protocol, however, is specifically designed to seamlessly bridge networks across a wireless link, including preservation of the MAC address.

    And, just to be clear, WET mode differs from Client Bridge mode only in how the router (your WRT54G) deals with packet forwarding. In WET mode, your router simply bridges the wireless and LAN networks together without any NAT. In Client Bridge mode, however, your router's LAN is logically a separate network from the wireless network (including having/needing a separate IP network address). But both of these look identical to your access point (your Netgear).
  6. HennieM

    HennieM Network Guru Member

    You are doing something wrong - there's no "...limitation of bridging...": Using a wireless router as a bridge is just like sticking another switch or hub somewhere in your network - traffic from PCs behind the Tomato bridge just flow seamlessly through Tomato - all still within the same network.

    Your Tomato must be set to Wireless Ethernet Bridge. AFAIK, Wireless Client implies routing on Tomato, which is not what you want (and may be causing the DHCP problems).

    Tomato must have an (excluded from the DG's dynamic range) IP address AND NETMASK on the same subnet as the DG. (If DG is netmask, Tomato can be anything through, but must have netmask (Your is fine).
    It's not necessary for Tomato to have a gateway specified, but if so, no worries.

    Importantly, on Tomato, your WAN must be turned off, and all DHCP and DNS parameters also off.

    Only plug PCs into the LAN ports of Tomato (nothing plugged into WAN port).

    Edit: I see Ron and I posted simultaniously. Wireless Client and routing would most certainly create a problem i.t.o. DHCP, as the wireless interface is turned into the WAN interface, and PCs behind Tomato is therefore assumed to be (and should be) on a different subnet, and (i) your DG would not know that the DHCP requests came from a different subnet as it sees it as requests from Tomato, and (ii) even if it did see DHCP requests from another subnet, it would not know what addresses to dish out to those PCs.
  7. Odin-60

    Odin-60 LI Guru Member

    It is a general limitation of WET mode.
    With other words: WET is not really a "bridge".
    Use WDS mode instead.
  8. Kiwi8

    Kiwi8 LI Guru Member

    Limitation of Wireless Ethernet Bridge mode? I have not encountered any such limitation from my usage. Are u guys sure that the limitation exists? :confused:
  9. HennieM

    HennieM Network Guru Member

    As mentioned before - no such limitation exists.
  10. Kiwi8

    Kiwi8 LI Guru Member

    That's why. Those of u who do not know anything, please do not spread false info when there is no limitation with Wireless Ethernet Bridge mode. :mad:
  11. bigclaw

    bigclaw Network Guru Member

    What's the difference between WET and WDS then?
  12. HennieM

    HennieM Network Guru Member

    Fot a WRT type router:

    WET (aka Wireless Client Bridge) = The router is a wireless client of only one AP (at a time). Wired LAN ports work normally, WAN port don't work AFAIK, but could be made to work normally.
    Thus, the wireless interface of our router makes a wireless link to an AP, so forming a wireless ethernet bridge between our router's LAN ports and the AP. The term "bridge" implies that all parts of our router are on the same subnet - no routing.

    Our WET router's radio also adapts to-, and talks-, on whatever channel the AP talks on, and is seen the same way as any other PC or wireless client by the AP.

    Wireless Client = As for WET, but the wireless interface of our router is treated LIKE a WAN interface; i.e. the LAN ports and radio are not bridged as in WET mode, but they are on different subnets, with routing between them.

    WDS = The router becomes the wireless peer of one or more other WDS nodes. LAN ports work normally, WAN port works normally (routing between WAN and wireless+LAN).
    In WDS mode only, only peer WDS nodes can talk to one another wirelessly, so only wired devices can be connected to a WDS node (via the LAN ports).
    In WDS+AP mode, the router's wireless interface also functions as an AP to which wireless clients can connect.

    In WDS, all connected WDS nodes talk on the same wireless channel. For WDS+AP, all the WDS nodes, PLUS the wireless clients talk on the same wireless channel.
  13. bigclaw

    bigclaw Network Guru Member

    Here is my current setup:

    Primary Router (AP+WDS): Serving two wired PCs and ALL wireless clients
    Secondary Router (WDS only): Serving an IPTV Set-top box and an XBox 360; does not serve wireless clients.

    Right now, all devices are able to see any other device on the network, I believe.

    In my case, will WET offer an equivalent setup with better bandwidth? Thanks.
  14. jsmiddleton4

    jsmiddleton4 Network Guru Member


    In my experience WET seems to be a bit faster. However as the original poster noted, I too have a problem where my main router/ap/connected to cable modem router/router 1, duplicates MAC addresses. It will assign the MAC of my WET/router 2 to the IP addresses the DHCP server of router 1 hands out that are connected via wired ports on router 2. So I will have multiple IP's assigned with one MAC address. It goofs up some of my other uses, static IP assignments, etc.

    If I use WDS+AP on one, WDS on the other, I don't get the duplication of MAC addresses.

    It seems to me that WET should not be duplicating the MAC of the WET/router 2 in the main router.
  15. Odin-60

    Odin-60 LI Guru Member

    Indeed, all devices "behind" a WET do show up with the same MAC address,
    i.e., with the MAC of the WET. This is an inevitable bu^H^H feature of WET mode.
  16. bigclaw

    bigclaw Network Guru Member

    How does that work with static DHCP from the primary router then? Static DHCP is based on MAC addresses; surely all devices behind a WET should not get the same IP...

    In the meantime, I've found my current setup to be most transparent and flexible, but I keep wanting to explore what WET is really all about...
  17. HennieM

    HennieM Network Guru Member

    @bigclaw: In your setup your 2nd router is functioning near-identical to WET mode. You might have a marginal speed gain if your 1st router is just AP, and your 2nd just WET.

    However, as mentioned, the speed gain will be marginal only (the difference between a 4 address header and a 3 address header) because you don't have wireless clients connect to your 2nd router. With WDS, you start losing real speed when a single radio needs to retransmit an incoming signal - you don't have that.

    @other: I don't understand why some people have trouble with WET mode. I have Tomato v1.10 on a WRT54GL, WET, WPA Personal/AES, all DHCP/DNS options off, WAN disabled, router mode, and all wired clients connected to it gets the correct IP addresses as per individual MAC addresses. The wired clients work just like if the WET isn't there.

    A possibility might be: your WET must be in router mode; in gateway mode, it may somehow be confused and trying some routing/firewalling (although it shouldn't, as the radio and LAN switch are bridged), and your DHCP server is seeing the DHCP request from the wired-to-WET-client as if from another subnet.
  18. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Now I'm confused. Do the clients attached to the WET end up with the same MAC address, the MAC of the WET, assigned to the devices IP's in the primary AP router or not?

    So the DHCP server hands out IP addresses, all different, to the one MAC address, the MAC of the WET?
  19. HennieM

    HennieM Network Guru Member

    JS, I now I don't understand, but this is the way it should (and does) work:

    The MAC of the WET device should never show up or feature anywhere w.r.t. DHCP. Every DHCP client, at a particular time, should have its own unique MAC and its own unique IP address assigned to it.

    The WET device, in the case of Tomato WET on a WRT router, should have a static IP, and this IP is only used for configuring that WRT - the WET device's IP and MAC address play NO ROLE whatsoever in terms of DHCP.

    It does not matter whether a DHCP client is a wired client connected via WET device, or a wireless client connected directly to an AP, or a client connected through 10 wired switches with 5 WDS nodes and 20 fiber-to-UTP/UTP-to-fiber converters in between, AS LONG AS THE DHCP SERVER AND THE DHCP CLIENT IS ON THE SAME SUBNET, i.e. BRIDGED THROUGH ALL SWITCHES.
  20. TexasFlood

    TexasFlood Network Guru Member

    Currently my main gateway router is a WRT54G running Tomato 1.18 serving up static DHCP, IP associated by MAC address. I have one Tomato and one DD-WRT router with WDS and a DD-WRT router set up as a repeater bridge. On both of the WDS routers, the MAC of each device is always the correct MAC belonging to that device. If I do an arp command or look at the GUI on the main router, these always look correct. I see a different behavior on the repeater bridge. When connected to the bridge, I see the correct MACs for all devices on both sides of the bridge router. However from the other side, from the perspective of the gateway and WDS routers, all devices connected to the bridge router have the same MAC, the wireless MAC of that router. Devices connected to the bridge router do get the correct static IP assignments though. Not sure if this is how it's supposed to work but it's what I'm observing on my network today.
  21. jsmiddleton4

    jsmiddleton4 Network Guru Member


    Maybe its a bug? But the wired devices connect to the WET router show in the main dhcp router each with seperate IP but the WET's MAC address.

    Multiple IP addresses and one MAC, the WET devices.
  22. HennieM

    HennieM Network Guru Member

    Where on the main DHCP router do you see these "wrong" MACs? Is it under the "Device List" (assuming a Tomato main DHCP router)?

    If so: Yes, it could be a bug, but it's a cosmetic bug. I don't know how Jon gets the device list, but that list has nothing to do with DHCP, nor with the correct functioning of the router/AP or the WET connected to it. Jon probably reads some ARP-like entries that list the first switched hop, which would be consistent with a WET device's MAC showing up.

    I just ssh'd into a Tomato AP, and the ARP entries shown by 'cat /proc/net/arp' is not consistent with devices shown in the "Device List". Jon must therefore get the "Device List" entries from somewhere else.

    The proof of the DHCP pudding is: does the right device, by MAC address, get the right IP; i.e. if you use static DHCP entries, does device A, having MAC address MACA always get IPA, and device B, having MACB always get IPB. If so, the your DHCP is working correctly.

    Even if you don't use static DHCP entries, but you have proper PCs (something with a writeable hard drive) behind the WET, those PCs should, most of the time, get the same IP address after a reboot. That is because the PC should save the IP address it was handed by the DHCP server, and ask for the same address after rebooting.

    I don't use a DHCP server on a router at current, so I can't check if the scaled down DHCP server in Tomato would actually honor the client's requested IP; i.e. if the DHCP client asks for IP x, the DHCP server may decide "to hell with you, here's IP y". Honoring the client requested IP is optional only, but most DHCP servers I have come across do so.

    Edit: WHOOPS, a blunder: I checked the arp table on one device, and the "Device List" on another - It seems the Device List and the ARP table are indeed consistent.
  23. TexasFlood

    TexasFlood Network Guru Member

    In my case running an "arp -a" the clients attached to my primary routers show the "wrong" MAC for all devices on the "remote" side of the bridge. The tomato "device list" shows two entries for each device on the "remote" side of the bridge, one showing the "wrong" MAC and one with the correct MAC and static DHCP assignment.

    My devices are all getting the correct static DHCP assignments.
  24. HennieM

    HennieM Network Guru Member

    I can't think why it would be so as the WET device is "just another switch in the network", but here a possibility:

    As the WET device registers with the AP as a wireless "client" or "end point", it may be that the WET has to proxy ARP for the devices wired to it; i.e.

    When some host on the network says "who-has MAC 00:11:22....", and device 00:11:22.... is wired to the WET, the WET answers "I have it", and supplies its own MAC address. Any host on the network then gets fooled into thinking that the WET actually IS device 00:11:22...., and sends any ethernet frames (containing IP packets) to the WET. The WET in turn then just forward the frames to the right wired client.

    If so, the layer 2 traffic (ARP and the likes) would "see" the WET device, while layer 3 and higher traffic (IP, etc.) would not see the WET. As the ARP list is layer 2, the WET's MAC address is seen in the "Device List".

    Proxy ARP is common in cases where "same subnet PPP links" are made, i.e. 2 network segments using the same subnet are bridged via a PPP link.
    Come to think of it, a WET-to-AP link probably IS the wireless equivalent of a PPP bridge....

    Somebody that knows out there...??
  25. jersully

    jersully LI Guru Member

    Please pardon my ignorance. I'm not a network newb, but I am far from proficient. I've been reading some DD-WRT information because it appears to be better documented (currently.)

    Is what's being discussed here essentially a client bridge/wireless bridge? If so, this si from http://www.dd-wrt.com/wiki/index.php/Wireless_Bridge


    BrainSlayer Forum Answer [1] (edited to enhance): Client Bridge mode will only work well with just one connected computer on the far end, due a limitation in the 802.11 protocol. 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. Use standard AP mode, if using WDS.

    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). ​
  26. TexasFlood

    TexasFlood Network Guru Member

    FYI, put one of my PCs on across a bridge to show you what it looks like. Images have a lot of MAC and IP info redacted because, well, I'm paranoid, :-D But there should be enough remaining to get the idea. One is the tomato device screen on the primary gateway router showing the two entries for 192.168.1x.161 with wrong MAC, then with right and associated infinite static lease. Also you can see, I hope, the PC showing up with the "wrong" MAC from an arp command "inside" the network. The MAC ending in 92 is the real MAC of the PC assigned IP address 192.168.1x.161, the one ending in 00 is the wireless MAC of the bridge router. I tried to manually remove the "wrong" MAC from the arp table and insert my own arp entry with the "right" MAC and that certainly didn't work, but I had to try just to see, ;-)

    Attached Files:

  27. TexasFlood

    TexasFlood Network Guru Member

    While some of the material there might apply, not certain, the mode I'm running is actually described here, under the v24 Repeater Bridge section. In my case I don't have any wired clients on the "remote" side of the bridge at this time, only wireless.

    I'm always playing around with my network. This is kinda what it looks like at the moment, but it will probably be different tomorrow, :-D

    Attached Files:

  28. HennieM

    HennieM Network Guru Member

    Well, it seems the only problems with WET mode are ARP table problems. In my book that's not a limitation, but just a cosmetic hitch. The IP traffic is flowing freely, and that's what we are after...
  29. RonWessels

    RonWessels Network Guru Member

    Unless, of course you happen to be connecting to a network with a DHCP server that relies only on the MAC address from the Ethernet packet itself to assign IP addresses. Then you wind up with multiple clients assigned the same IP address.
  30. jersully

    jersully LI Guru Member

    TexasFlood, what did you use to make that drawing?
  31. TexasFlood

    TexasFlood Network Guru Member

    I think you're right, I was thinking it was sort of like a NAT for MACs. I googled and found RFC1028 - "Using ARP to Implement Transparent Subnet Gateways" but really don't have time to finish it right now. As you say in a later post, it seems to work so perhaps I shouldn't worry about it.
  32. TexasFlood

    TexasFlood Network Guru Member

    I used Visio. The DD-WRT wiki diagrams sure look like something produced by Visio as well. At least the shapes and connectors look the same to me. Maybe I'm wrong. Some of those diagrams didn't list the software used to create them, but this diagram seeming lists paint.net as the software used to create it under the file details. I found a list of "open source alternatives for Visio" and paint.net is on it. Well I think it is, I'm finding that page a bit confusing to read. Maybe it's just Kivio, ArgoUML, StarUML, Dia and OpenOffice Draw. Go check it out for yourself if interested. If indeed something besides Visio was used to create those DD-WRT diagrams then it's pretty good as it fooled me. I've looked at a couple on that list but not paint.net yet. Maybe soon, time permitting.
  33. jsmiddleton4

    jsmiddleton4 Network Guru Member

    where see single MAC for multiple IP's

    I see multiple IP's for single mac in the device list for the main router, the dhcp server. Everything thing seems to work fine except and why I noticed it, in static dhcp assignment. I kept getting the message the MAC was being duplicated.

    Do not see this with WDS.

    I am of the opinion that it is cosmetic, since everything works, and has to do with what the main router is picking up as the MAC address.
  34. jsmiddleton4

    jsmiddleton4 Network Guru Member

    I just doubled checked, went back and forth, booted routers to make sure entries were cleared out, etc., and with WET the main router/the dhcp server, duplicates the MAC address of the WET router but assigns individual IP's as stated. With WDS, all MAC's of devices connected to the "slave" router, their MAC's stay intact.

    All devices work correctly either way. Just can't assign static IP's is about only feature that doesn't work correctly.

    MAC filtering, which I don't do, probably wouldn't either. Kinda obvious.
  35. HennieM

    HennieM Network Guru Member

    My static DHCP assignments work just fine through a WET. Everytime, all the time. I can't test/sniff now, but it may be because:

    i) I'm not using the DHCP server on the router (dnsmasq), but an oldish DHCP server ISC DHCPd V3.0pl1 on a Red Hat Linux 9 box, which somehow uses the "right" MAC address.

    ii) It may just be that my hosts behind the WET sends the IP address it had before to my DHCP server, and the DHCP server honors this client requested IP.

    I tend to think it's (i)....

    For systems using dnsmasq as DHCP server, such as Tomato, a workaround MAY be to, in the static DHCP table, leave the MAC address as 00:00:00:00:00:00 or blank, but specify a host name. From the man page (http://linux.die.net/man/8/dnsmasq see -G) it seems dnsmasq can allocate addresses by client supplied host name. So, as long as the host requesting an IP address knows its own name, and sends that in the DHCPREQUEST, dnsmasq should give it the statically allocated IP.

    Dunno if the Tomato web based setup for the static table would translate into the correct entry format for the -G option in the dnsmasq config file though.
  36. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Tried it with turning off the dhcp/dns server option, the internal one. No difference. All devices connected to the WET router work. Its not like they aren't getting connected, etc.
  37. Morac

    Morac Network Guru Member

    This will answer the questions about WET, mac addresses and DHCP. I tried to give the details in layman terms, but it is still a bit technical.

    To explain why all devices behind a WET show the WET's MAC address, you have to know something about the OSI networking model. It is a top down model going from software down to hardware as the layer number decreases. IP addresses are part of layer 3 (the Network Layer) while MAC addresses are part of layer 2 (the data link layer). The MAC address is usually hard coded into the network adapter (though some allow it to be changed).

    When data is sent out, it "travels" down through the layers which each layer adding more information to the data until finally the data gets sent out. So when data is sent out from a device behind a WET, the device adds an ip address to the data and then a MAC address and finally stuff needed to send the data out of ethernet.

    When the data reaches the WET, the WET strips off both the layer 1 and layer 2 data, while keeping everything from layers 3 and above. This means that the device's MAC address is removed from the message data it sent out. The WET then adds it's own MAC (of the wireless adapter) and finally the 802.11 protocols to send out the message wirelessly.

    This is why all devices behind the WET show the MAC address of the WET. The WET knows the MAC addresses of the devices behind it so it can talk to them and forward all data that should go to them.

    So if all devices behind a WET show the WET's MAC address, how does DHCP work behind a WET? Well the reason DHCP works is because DHCP is a level 7 (application) layer protocol. The DHCP request contains the MAC address of the requesting client in the actual level 7 data.

    So here's how a DHCP request works behind a WET (I omitted some steps since they aren't relavent). The client creates a request for an ip address and puts it's MAC address in the request. The request travels down the OSI layers with each layer adding more data. No IP address is added since the client doesn't have one, but it does add it's MAC address. At this point the request contains the MAC address twice. The request is then broadcast out over the network.

    When the request reaches the WET, the WET replaces the layer 2 MAC address of the client with it's own, but it doesn't touch the MAC address inside the actual DHCP request data. This way when the request gets to the DHCP server (the router), the router assigns an ip address to the MAC of the client. The router then sends the DHCP offer back out with an IP address and the client's MAC in the DHCP data and the WET's MAC in the layer 2 wrapper. The WET then forwards this on the the client.

    So that's why (static) DHCP works, even though the router can't "see" the MAC addresses of devices behind a WET.
  38. bigclaw

    bigclaw Network Guru Member

    Very neat explanation! I think I actually understood it. :)

    Now can you explain in a similar way why WDS seems to be immune to this anomaly? :)
  39. HennieM

    HennieM Network Guru Member

    @Morac: You are quite correct IMO, but I don't think DHCP is layer 7 - it's link layer stuff, and that is layer 3 I think.

    However, as I understand the thread, people are saying that the correct IP is NOT assigned to the device behind the WET by the Tomato DHCP server.
    Did I understand the posts in the thread wrong?

    My question still is: why does the WET replace the MAC address of the originating device on layer 2? If this DHCP request passed through a normal wired network switch, or through a WDS node, the DHCP request would NOT have contained the MAC of the switch or WDS node.
    Answer: IMO, because the WET is proxy ARPing.

    Anyway, if it worked the way you described, there would be no problem with static DHCP assignments. I say that you are correct, and that the problem possibly is with dnsmasq, which uses the layer 2 MAC address, or the "client identifier" in the DHCP message, and not the CHADDR as it should.

    This would be consitent with dnsmasq's ability to assign IP addresses based on client name; i.e. the DHCP client puts its name in the "client identifier" space in the DHCP packet, and dnsmasq uses that.

    From RFC2131:

     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
       |                            xid (4)                            |
       |           secs (2)            |           flags (2)           |
       |                          ciaddr  (4)                          |
       |                          yiaddr  (4)                          |
       |                          siaddr  (4)                          |
       |                          giaddr  (4)                          |
       |                                                               |
       |                          chaddr  (16)                         |
       |                                                               |
       |                                                               |
       |                                                               |
       |                          sname   (64)                         |
       |                                                               |
       |                          file    (128)                        |
       |                                                               |
       |                          options (variable)                   |
                      Figure 1:  Format of a DHCP message
       DHCP defines a new 'client identifier' option that is used to pass an
       explicit client identifier to a DHCP server.  This change eliminates
       the overloading of the 'chaddr' field in BOOTP messages, where
       'chaddr' is used both as a hardware address for transmission of BOOTP
       reply messages and as a client identifier.  The 'client identifier'
       is an opaque key, not to be interpreted by the server;
  40. HennieM

    HennieM Network Guru Member

    I finally got to sniff a DHCP request through a Tomato WRT set up as a WET, like this:

    PC(WinXP) --wired-- WET --wireless-- AP --wired--DHCP_Server

    00:1c:pCwired = MAC of PC (eventually to get
    0:18:WRTwless = MAC of WET wireless interface (
    0:8:DHserver = MAC of DHCP server (

    My DHCP server contains a static DHCP entry
    MAC = 00:1c:pCwired -- IP =
    no host name or any such clues in the static DHCP table.

    This is the DHCPDUMP packets:
    PACKET 1 TIME: 21:06:48.377350
        IP: (0:18:WRTwless) > (Broadcast)
        OP: 1 (BOOTPREQUEST)
     HTYPE: 1 (Ethernet)
      HLEN: 6
      HOPS: 0
       XID: a810e6f3
      SECS: 0
     FLAGS: 7f80
    CHADDR: 00:1c:PCwired:00:00:00:00:00:00:00:00:00:00
     SNAME: .
     FNAME: .
    OPTION:  53 (  1) DHCP message type         1 (DHCPDISCOVER)
    OPTION: 116 (  1) DHCP Autoconfiguration    01               .
    OPTION:  61 (  7) Client-identifier         01:00:1c:PCwired
    OPTION:  50 (  4) Request IP address
    OPTION:  12 (  7) Host name                 HennieM-PC
    OPTION:  60 (  8) Vendor class identifier   MSFT 5.0
    OPTION:  55 ( 11) Parameter Request List      1 (Subnet mask)
    					     15 (Domainname)
    					      3 (Routers)
    					      6 (DNS server)
    					     44 (NetBIOS name server)
    					     46 (NetBIOS node type)
    					     47 (NetBIOS scope)
    					     31 (Perform router discovery)
    					     33 (Static route)
    					    249 (MSFT - Classless route)
    					     43 (Vendor specific info)
    PACKET 2 TIME: 21:06:48.386704
        IP: (0:8:DHserver) > (Broadcast)
        OP: 2 (BOOTPREPLY)
     HTYPE: 1 (Ethernet)
      HLEN: 6
      HOPS: 0
       XID: a810e6f3
      SECS: 0
     FLAGS: 7f80
    CHADDR: 00:1c:PCwired:00:00:00:00:00:00:00:00:00:00
     SNAME: .
     FNAME: .
    OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
    OPTION:  54 (  4) Server identifier
    OPTION:  51 (  4) IP address leasetime      518400 (6d)
    OPTION:   1 (  4) Subnet mask     
    OPTION:  15 (  6) Domainname                mydom.net
    OPTION:   3 (  8) Routers         
    OPTION:   6 (  8) DNS server      ,
    OPTION:  46 (  1) NetBIOS node type         8 (H-node)
    Note that the 2nd line of PACKET 1, the BOOTPREQUEST from the PC to any DHCP server on the network, contains the I-don't-know-my-IP "", and the MAC of the WET (I think this is the layer 2 data of the packet)
    IP: (0:18:WRTwless) ....

    but the CHADDR line contains the MAC of the PC
    CHADDR: 00:1c:pCwired:....

    and the OPTION 61 line also contains the MAC of the PC
    OPTION: 61 ( 7) Client-identifier 01:00:1c:pCwired

    and my PC is requesting IP (incorrect IP for this subnet)
    OPTION: 50 ( 4) Request IP address

    The YIADDR line of PACKET 2, the BOOTPREPLY from the DHCP server to the PC, contains the correct IP address for the PC

    Bottom line: The DHCP request from my PC contains the correct identifiers in both the CHADDR field, AND the Client-identifier field, so my DHCP server assigns the correct IP address. This DHCP request is no different from a request that came through a wired network switch or a WDS node.

    Question remains: does dnsmasq perhaps use the layer 2 MAC address in the 2nd line of PACKET 1? Would be interesting if somebody could sniff that.
  41. bigclaw

    bigclaw Network Guru Member


    This page does list DHCP.

    The original poster was sort of ambiguous in that s/he later on mentioned "everything else worked". Maybe s/he meant to type "MAC addresses" instead of "IP addresses" when talking about identical addresses for different machines.

    I don't think I see anybody else mentioning WET was not working for them as intended. That leads me to think it's just a cosmetic problem.

    I wouldn't be surprised that the firmware is (correctly) using CHADDR in the DHCP packet to assign IP addresses , while at the same time using layer-2 MAC addresses to list connected devices.

    If that's the case, it's simply a cosmetic flaw.
  42. TexasFlood

    TexasFlood Network Guru Member

    I can't speak for anyone else, but in my setup (illustrated in the earlier bitmap attachment), my PC(s) are getting the correct static DHCP assignments.
  43. jsmiddleton4

    jsmiddleton4 Network Guru Member

    "just a cosmetic problem."

    Since all connected devices to the slave WET router do work perfectly I tend to agree. Only problem comes when trying to add or update a static dhcp address and I can't due to the inaccurate information being captured or if someone wanted to use MAC/IP filtering. Existing static dhcp assignments work quite well.

    Its capturing the wrong data, capturing the correct data and displaying the wrong data, something like that. Fundementally WET is working fine. However something needs to be tweaked and whatever that "something" is, its not a big deal.

    At least it seems/feels that way.

    I've gone back to WDS for now. It does seem to me however that WET is a tad faster. I know its not suppose to be that way. But with WET pages load snappier, email d/l just a bit faster, etc.
  44. bigclaw

    bigclaw Network Guru Member

    You have a good point there. It's a pain to not be able to automatically select the "unknown" MAC and perform a static DHCP assignment right there.
  45. Kiwi8

    Kiwi8 LI Guru Member

    I finally see jsmiddleton's point. It would be good if the router that issues the DHCP would display the actual MAC address of the PC that has the IP address, even if the PC is connected to another router in WET bridge mode.
  46. HennieM

    HennieM Network Guru Member

    JS, the WET should be a tad faster than WDS (but just a tad), as the wireless dealings are with 3 addresses, not 4 like in WDS. In a normal frame/packet this does not constitute a huge percentage, but perhaps just that tiny bit.
  47. jsmiddleton4

    jsmiddleton4 Network Guru Member

    That's right kiwi. And it is obviously working correctly on some level. The dhcp addresses are being assigned individually to connected lan devices on the WET/Slave router. All devices connected to the WET/Slave router work correctly. Just seems like some piece of information isn't being captured correctly, is and then isn't being passed to the right place, something like that.

    The main router/dhcp server device list should reflect the IP address and MAC of the devices to which it is handing out a DHCP address or handing out a static IP address correctly. The only way to do that now is with WDS. Could be a limitation of WET. I don't know. Since all attached devices are working and obviously have an individual ip assigned, it doesn't seem like its a limitation of WET. The WET router is not acting like dhcp server in anyway.
  48. Kiwi8

    Kiwi8 LI Guru Member

    Yeah I understand. But it's still really a cosmetic limitation. There are still ways to grab the MAC Addresses of remote PCs without Tomato's help. :)
  49. Morac

    Morac Network Guru Member

    Sorry it took me so long to reply. I forgot I posted this. :redface:

    WDS is immune because of the way it was designed. It was designed to pass the MAC addresses. I'm having trouble finding info on how it works exactly (probably because there is no official standard yet), but based on how it's set up, it appears to act like a tunneling protocol. Similar to VPN, but at the layer 1 (802.11) level.

    I prefer normal bridging to WDS (bridge/repeater) since WDS doesn't allow for more advanced forms of encryption (I use WPA2) and it results in a drop of throughput. Where WDS really shines is that it allows a device to bridge/repeat both wired and wireless clients simultaneously.

    Also I believe whoever said that Tomato is listing the wrong MAC (ie: cosmetic issue) is correct. Tomato appears to display the last MAC/ip address received in normal traffic instead of the one from the DHCP request. My guess is it gets it from the ARP cache which is the easiest place to get it, but will be wrong for bridged clients. You can see the same thing on windows by pinging each device behind the bridge and then issuing an "arp -a" command.

    One last thing, there really is no difference between a normal DHCP request and a static DHCP request. The only difference is that the router will always return the specified ip address for a static request, where as a non-static can return any ip address. From a network perspective though, there's no difference. If the router didn't know the client's MAC address, it would either give it a different IP address every time it asked or give every device the same ip address.
  50. jsmiddleton4

    jsmiddleton4 Network Guru Member

    Glad you posted. I came by to check to see if we had any additional information. I'm not sure why it doesn't work. All I know is it doesn't when using WET/Bridge mode and it does using WDS. It may not be important enough and since WDS is working for anyone to address it. It would be nice if it did work but clearly NOT a big deal nor a critical issue. I'm not trying to make it bigger than it is in any way.

    The device list in the main dhcp server router should show the right information as it is the router in which you are also trying to configure MAC filters, static dhcp, etc. The second "slave" router is just that, stupid bridge doing nothing. Somehow the logic for what is being picked up and displayed maybe wrong? That piece is right but its looking in the wrong place? Who knows. I understand the main router "sees" the information from the slave router but shouldn't the main router since its handing out the ip's, etc., as the dhcp server also know what devices are getting what that are hardwired to the slave router? Or is that not how it works?
  51. Morac

    Morac Network Guru Member

    I don't know how Tomato is coded since I haven't looked at the source, but it probably only "knows" enough to work.

    The true MAC would be in the DHCP cache needs to be stored somewhere so that the router doesn't assign the same ip address to different devices, but the DHCP cache is only used for DHCP requests.

    The "spoofed" MAC address would be in the arp cache, because it is needed to forward packets from the WAN to the device on the LAN. Tomato probably uses the MAC in the arp cache because it should always be up to date and valid.

    To fix the display issue Tomato would need to look in the DHCP cache instead of the arp cache to determine ip address/MAC pairs. The problem with doing so though is that any device on the network that isn't using DHCP would not show up on the device page, since it wouldn't be in the DHCP cache. Even devices with hard coded ip address's would show up in the arp cache.

    To fix that, the router would have to use data from both the DHCP cache and the arp cache with the DHCP cache being preferred in the case of any conflicts. The downside to this method is that since the DHCP cache can have an expiration time of up to seven days, you could see devices listed that used to be connected to the network, but aren't currently.

    So the "real fix" would be to display 2 different lists. One for the DHCP leases and one for the active devices. Tomato actually appears to do this, but intermixes the result. I have a WET54g and the devices behind the WET that use DHCP appear twice: once with their actual MAC (and displayed lease time) and the other with the WET's MAC (and RSSI value).

    Just a FYI about the arp cache:
    The Address Resolution Protocol (ARP) is what networked devices use to map ip addresses to MAC addresses. Devices on the network address each other by their MAC address which is why this is needed. Think of the MAC address as a mailing address.

    It works like this. If the router gets a packet for an ip address and knows the MAC address associated with that ip address (stored in the arp cache), it just takes the packet and plops on the MAC address associated with the ip address and sends it on it's way.

    If the router gets a message for an ip address that it's never seen before (and isn't filtered out by the firewall), it broadcasts an arp request out over the LAN asking every device if they are using the specified ip address. The device that is using that ip address responds with its MAC address. The router store the ip address/MAC pair in the arp cache and then forwards the message on to the device.

    When a bridge is involved, the MAC address in the arp cache for every device behind the bridge will be the bridge's MAC address, for the reason I mentioned in my first post in this thread. The bridge has it's own cache so it knows the ip address/mac pair of all devices connected to it, but it works differently than a router in that it doesn't actually route packets.
  52. jsmiddleton4

    jsmiddleton4 Network Guru Member

    "....probably only "knows" enough to work."

    And it does work. It may not display the information correctly but all devices wired to the bridge unit work fine. So at some level everything is working as designed. That's why I'm not trying to make it bigger than it is and suspect its an issue with where its looking for and displaying the data. Fundementally its working. I've stayed with WDS for now as I need the ip/mac thing to be consistent.
  53. Kiwi8

    Kiwi8 LI Guru Member

    I think using WDS is fine as long as u are using it like a normal wireless ethernet bridge (ie without the extra hops). :)

Share This Page