I’ve already tried to activate DHCP without success. That was one of my reasons for assuming it doesn’t work with the RB133c. 
EDIT:
Actually, I am unable to activate ANY of the disabled packages…ppp, hotspot, ipv6, etc
EDIT AGAIN:
Actually, I just noticed the light grey text all the way to the right stating that it is ‘scheduled for enable’. When is this supposed to happen? Does it need a restart? Don’t see anything in the scheduler at least.
Yes, a simple reboot gets them enabled.
After a reboot, the DHCP server certainly does work. Tried it myself about 2 minutes after posting.
Well, my solution so far is this:
I am setting the clients up with routing, and configuring the inside LAN with a suitable subnet from the network. The clients will be setup with a simple NAT configuration until such time that I reconfigure the AP to route to the clients and add the appropriate route for the AP to the core, at which time I can remove the NAT masquerade entries from the clients. After rethinking things, this seems like the best way to go. (At least now that there is a DHCP server working)
Any final suggestions before I get started?
joebush -
The only thing I would suggest is setting all client LAN dhcp servers the same and leaving NAT in the CPEs; client to wlan NAT. Then all you have to do is route your various wireless node IP blocks to the correct APs, and NAT your CPE networks as they go out on the Internet.
We do this becuse then my techs know where to start when doing any troubleshooting. LAN DHCP setup line this: 192.168.5.1/24 LAN IP of CPE. DHCP 192.168.5.100 -192.168.5.200. This gives the client 100 IP addresses to be used internally for DHCP. It also leaves room for static IPs to be assigned as necessary (say a network printer, etc…)
When clients call in we can start troublshooting by asking them their IP address and knowing the answer is suppose to be 192.168.5.XX and if it’s not we know where to go…
Thom
I was considering this, but our network is already NAT’ed at the core, and I don’t like the idea of potential application issues that can occur with double NATs. And since we are NAT’ing at our router, it is convenient to be able to do port forwarding at one place if someone is running something special, instead of needing to implement the same change at the client router as well.
I’ve drawn up a map of the subnets and subsubnets, and have already activated DNS relaying on the MT clients and AP (hierarchial to avoid unnecessary queries). Things are progressing. I will have subnetting documentation finished and information ready soon, and then I can inform everyone of the changes to take place.
Thanks again for the feedback I’ve received. I’m kind of glad that bridged client doesn’t work, since it got me to take the step I’ve thought about a while. And the network will finally be properly documented. That should get me a few stars.
Joe
I can’t seem to find an appropriate thread, so I thought I’d post this here.
While looking for a client bridge solution I upgraded a rb133c to v3.0rc10 for testing. Because I decided to router afterall, and because of CPU load issues with the beta firmware, I want to downgrade back to 2.9.49.
Unfortunately, I’ve had no luck. I have tried the upgrade and downgrade buttons, and in the end it seems v3.0rc10 wins. What can I do?
I’ve always downgraded by uploading the file to the board, then going to system/packages and clicking the “downgrade” button. Is that what you did? Maybe you could try netinstall.
I was using the web interface. It went through the steps, but upon reboot was still the same version.
I can try using the function in packages tomorrow.
I have only scanned over all the posts in this looooong struggle, and have a suggestion that may be what you need:
Should work fine…
Maybe a better way to do it would be to put senao as client, and the mt board as ap. You might be more flexible with that, and get away with any bridge you might need. Also, you get the full mt features at the ap side.
That looks like the ONLY solution in this whole struggle! Buying more hardware. Oh well. 
Well, not exactly. My sugestion was to change the ap to be the MT Box, and put that senao to be the client.
My rb133c cannot run as an AP, wrong licence I believe.
The steps i followed to get Transparent Bridge Working.
Done. Had no issues with instability so far. Got immediate connectivity on all remote PC’s.
I would suggest using station pseudobridge clone that way you can see the MAC of the device behind the connected radio. Could be useful information if you need to block MAC telneting for everyone but yourself.