First off - We have had our primary wireless network up a running for over two years with multiple clients utilizing CB3s, SmartBridges, and standard wifi clients. We utilize MT as the router and SmartBridges as APs.
Now to the issue - We just bought a Tranzeo TR-80 to try out since they are very inexpensive. But, we we deployed it today, the unit did not pass through the DHCP lease for some reason?? When we set a static IP on the end-user's computer, the connection worked just fine - but the MT was utilizing universal client, not DHCP. Has anyone else experienced this? When I called Tranzeo tech support they stated that it may be because their radios only pass through broadcast DHCP, not unicast DHCP. Would this be the problem? I can't imagine the Tranzeo will not work with MT; I am sure that many people on this forum would have already discussed this.
Please let me know your thoughts...Thanks
Tranzeo's MAC-NAT system is not very sophisticated, in that it will only replace the source MAC address in the ethernet header, not further inside the packet.
This causes a problem with DHCP under certain conditions, since DHCP keeps the MAC of the requesting system inside the IP packet. So, once MAC-NATed by a Tranzeo, a DHCP packet will have 2 different source MAC addresses, one (the Tranzeo's MAC) in the ethernet header, and a different one (the device actually performing the DHCP request) inside the actual DHCP packet. Since the DHCP server sends the responce to the MAC inside the DHCP packet, the network as a whole does not know where to deliver it (since at the ethernet level, the real MAC is only seen behind (and at) the Tranzeo.
Fortunately, MT does provide a way around this. In the DHCP server setup, make sure that "always broadcast" is enabled, and "add arp for leases" is disabled. With these settings, we have not had problems with MT+Tranzeo+DHCP.
One other thing: Early Tranzeo firmware (esp CPE/CPE-80) had some really weird behavior, if you aren't running the current version, upgrading would be a good idea.
--Eric
This causes a problem with DHCP under certain conditions, since DHCP keeps the MAC of the requesting system inside the IP packet. So, once MAC-NATed by a Tranzeo, a DHCP packet will have 2 different source MAC addresses, one (the Tranzeo's MAC) in the ethernet header, and a different one (the device actually performing the DHCP request) inside the actual DHCP packet. Since the DHCP server sends the responce to the MAC inside the DHCP packet, the network as a whole does not know where to deliver it (since at the ethernet level, the real MAC is only seen behind (and at) the Tranzeo.
Fortunately, MT does provide a way around this. In the DHCP server setup, make sure that "always broadcast" is enabled, and "add arp for leases" is disabled. With these settings, we have not had problems with MT+Tranzeo+DHCP.
One other thing: Early Tranzeo firmware (esp CPE/CPE-80) had some really weird behavior, if you aren't running the current version, upgrading would be a good idea.
--Eric
Yup, looks like it's 2.9 only.
You may want to try setting the "authoritative" flag, it can _sometimes_ help if there is (or has been, recently) another "rogue" DHCP server on your network.
Also, now that I think about it, we don't actually have anything behind CPE-80s getting DHCP from a MT. All the devices behind CPE-80s on our network get their DHCP from an ISC daemon on unix. The configuration is practically identical (except in form), and I would guess that MT is using ISC-DHCPD under the hood (don't know for sure, but it seems likely). I do know that setting the "always broadcast", and unsetting the "add arp for lease" options works with devices behind TR-CPE200s and the TR-[234]xxx series.
If you can, it would probably be interesting to do some packet sniffing. Comparing the DHCP packets as they enter/leave the MT, as they enter/leave the SB AB, and as they enter/leave the CPE80. See what changes where, and if any of the packets are missing at any point.
A normal DHCP exchange should look like:
1. Client sends a "discover", to 255.255.255.255/ff:ff:ff:ff:ff:ff (broadcast).
2. Server sends a "offer", usually unicast to the MAC within the DHCP packet. Setting "always broadcast" should change that.
3. Client sends a "request", to the server that sent the "offer", as unicast.
4. Server sends an "ack", again usually to the unicast MAC of the client. Again, setting "always broadcast" should change that.
--Eric
You may want to try setting the "authoritative" flag, it can _sometimes_ help if there is (or has been, recently) another "rogue" DHCP server on your network.
Also, now that I think about it, we don't actually have anything behind CPE-80s getting DHCP from a MT. All the devices behind CPE-80s on our network get their DHCP from an ISC daemon on unix. The configuration is practically identical (except in form), and I would guess that MT is using ISC-DHCPD under the hood (don't know for sure, but it seems likely). I do know that setting the "always broadcast", and unsetting the "add arp for lease" options works with devices behind TR-CPE200s and the TR-[234]xxx series.
If you can, it would probably be interesting to do some packet sniffing. Comparing the DHCP packets as they enter/leave the MT, as they enter/leave the SB AB, and as they enter/leave the CPE80. See what changes where, and if any of the packets are missing at any point.
A normal DHCP exchange should look like:
1. Client sends a "discover", to 255.255.255.255/ff:ff:ff:ff:ff:ff (broadcast).
2. Server sends a "offer", usually unicast to the MAC within the DHCP packet. Setting "always broadcast" should change that.
3. Client sends a "request", to the server that sent the "offer", as unicast.
4. Server sends an "ack", again usually to the unicast MAC of the client. Again, setting "always broadcast" should change that.
--Eric