RedBull -
Drop me an email off forum. We are just ‘cluttering’ up the forum right now. You can post the results of what we did when we are done. See my email address below…
Thom
I have just received two rb133c boards and am trying to configure them as clients (station mode). Speaking to someone in support at the supplier I purchased these from, I was told that “In the Mikrotik work” (he said this several times…very irritating), client bridge mode doesn’t work. That I would need to use WDS or set up routing and NAT.
Now, being the optimist I am 
I have trouble accepting this. It doesn’t seem logical that bridging the interfaces would not work, since the rb133 we are using as a triple access point works flawlessly as a bridge with all 3 wireless and ethernet interfaces.
Then again, they did place code in the firmware that prevents the use of the rb133c as an access point, so maybe they truely are capable of crippling the device further like this.
But if there is anyone that has any information on how to get this device to function as a normal bridged client, please let me know. I have no use for this device as a router and am not interested in running WDS mode.
In this FAQ, at the very bottom is the following:
Wireless Questions:
Can I bridge wlan interface operating in the station mode?
No, you cannot.
Now, this is an answer to my question, but it still seems quite abrupt and unnecessary. Is there any way around this? Maybe Mikrotik has a version of their firmware that removes this restriction? I really like the Mikrotik boards, but their ‘world’ where WDS rules supreme is just not the world in which I live. I’d hate to have to return these boards for not being true clients.
joebush -
What is the deal with you and bridging? I know ‘back in the day’ we used bridging exclusively…but that was more a lack of choices than desire.
So the real question becomes - what is it you are try to accomplish? Are you trying to tie a couple of dispersed networks together, don’t know how to use routing, need some sort of security that you think you can only get in a bridged system or what?
There are a couple of ‘bridging’ methods you could use - you already have an MT AP. The AP mode is AP/Bridge so I don’t know why you couldn’t put the client Wlan in bridge mode instead of client. Then add the Wlan and the ethernet port to a bridge interface that you create on the MT client and have a perfectly good bridge. I have not done this as we use routing all the way around, works better, better control, less overhead on the network, but it seems to make perfect sense…
Since you don’t want to use WDS there is always EoIP…we use this for when we bond lines for failover and bandwidth considerations.
Ok - well that’s my ‘two cents’ worth…
Thom
Wireless bridging is not true bridging, so it is in some way good that MT doesn’t allow it without a lot of trouble. If you really must use the MT as a bridge, v3.0 routerOS has “station-pseudobridge” mode. If you prefer to use v2.9, you can achieve bridge-like IP connectivity to the remote network but without being in the same broadcast domain with proxy-arp.
I have tried many times to put the RB133c in bridge mode and bridge wlan1 and ether1. Whenever I configure it to bridge mode it permanently disconnect from the AP until I put it back in station mode.
This is point to multi-point. Bridge is the easiest wasy to go to get things running. Also, this is a network that already exists. It’s best if adding nodes or replacing older equipment is a matter of tossing in the new box without too much hassle. WDS can be hassle free in dynamic mode, but the network is too big for WDS to be efficient. EoIP will quickly cause a mess on the main AP with an EoIP interface for each connection device. Routing is an option I’ve considered, but would require me to completely start from scratch with subnetting, configuration at our main router, MT AP and clients, and the clients don’t support DHCP server. There is also the matter of going to all the remote locations to configure the old equipment.
EDIT:
When I attempted normal bridge mode, I have the correct SSID and channel chosen. I did find a reference to needing to the the root AP MAC address, but that was in version 2.7. I can’t find it for 2.9, and can’t find a proper setting to use it in.
I don’t see a 3.0 version that supports RB100 series devices.
http://www.mikrotik.com/download.html
Click on rb100.
The download says rb500xxx.npk, but it is the correct one.
joebush -
I understand your position about having a network configured and not wanting to change - but I can tell you from experiece that your bridged setup will cause you no end to issues if you don’t switch to a routed solution. At least from your distribution point(s) out to you APs. I had a bridged network, all nicely configured, running great, then I went over the magic number (I don’t remember the actual number that really put us over the top) and I (tech support folks) started getting phone calls that they could reach this page or that, and a page refresh or reboot the radio fixed it for the time being… Then there was the trying to reach the CPEs to update the firmware…that became impossible from 0400 to about midnight… Leaving darn little time to do it, and an unholy hour to do it in.
So what I did was incremently create routed solutions. One of my ‘business’ class areas had a Alvarion AP - these are strictly bridge units, but I had a backhaul or two between it and my core router. I set up a network on the core, routed it to the first Backhaul. Same in the second backhaul which was located in the same physical location as the Alvarion AP. Here in this backhaul I src-nat’ed all the AP/CPE bridged IPs. Now I have a routed solution… The Alvarion (formerly Breezcom) don’t care about IP addresses but the routers behind them did. But I now had a routed solution to the AP, so I could go and reconfigure my client CPEs and in-house routers on my schedule as the ‘old’ bridge IPs worked just fine with the src-nat at the backhaul. I immediately stopped getting calls from that area… Within two months I finished reconfiguring all the CPEs/routers in this area, I killed the src-nat and was able to now route all the packets by IP to the core router. Updating firmware was a snap anytime of the day or night, ssh, http, telnet right in to the CPE from anywhere within my network was easily accomplished…
joebush - you do what you want to of course - it’s your network - I am just passing on my two cents worth - I’ve been doing this a long time - before there was wireless this inexpensive and before that when it was mostly military applications…
Thom
I already gave this a try and it’s working. Should have edited my reply. Thanks.
Another issue is the the fact that some of the users need access to the Windows-based networks file servers. This is not very fun with routing.
I just found a thread that claims that wireless client bridge mode works as I desire with the rb133 boards. If this is correct, then the rb133c just has most of its wings clipped. In that case, it is a matter of simply returning the rb133c and replacing it with a rb133. Can anyone confirm that this is true?
I do have NAT working fine on one of the boxes though. MT claims that it does indeed have a DHCP server, but I can’t seem to get it working, and they haven’t actually answered any support questions directly (just refer to some document here and there that I’ve already read and found not too helpful). Maybe I can get some help here?
The lack of pseudo-bridge is in software (RouterOS), not the RouterBoard. You need v3.0 for pseudo-bridge mode. Understand that true Ethernet bridging is impossible with 802.11, there can be only one MAC per associated client - pseudo-bridge (and any other 802.11 devices that claim to bridge) use a MAC-NAT technique, this may cause issues with certain applications on the LAN you are connecting to, especially for things like multicast.
I understand that, but are you saying that when using the rb133 it will still not allow IP communication over the ether1/wlan1 bridge? In that case, the person that posted that was incorrect.
I am asking because I know the software is limited depending on the hardware it is installed on. Pseudo-bridge is good enough, and is of course how all the other clients are connected, and it works perfectly for our use. v3.0 of RouterOS is running on one client I am testing and is configured as a pseudo-bridge, but the CPU load is constantly at 100%, so I won’t be using v3.0 until the issue is fixed.
Also, clients behind the speudo-bridge seem to be unable to obtain an IP address over the connection. Is this because of the MAC restriction? Can DHCP requests be forwarded correctly over a pseudo-bridge connection?
Yes, the person who posted that the 133 could do it is incorrect. The 133 and 133c are identical except the removed hardware. The bridging is a software thing and has nothing to do with the difference between the boards. I have abandoned version 3 on any 1xx series boards because of the cpu issues you mentioned. It just doesn’t work right.
I have done bridging with 133c boards before and the only reliable method I know of is to use WDS. I don’t know if the Senao AP will support WDS in the fasion that you need it to or not. Simply bridging the wlan1 and ether1 port on an standard “AP to Station” pair will never work because of the 802.11 protocol.
Follow this procedure and it should work: Replace the AP with a Mikrotik board. On your new AP, create a bridge and set arp to “proxy-arp”. Add the ethernet ports to it. Go to the wireless card (which should be set to “ap bridge”)and on the WDS tab set wds mode to dynamic and the default bridge to the bridge you just created. Now, on the client, do exactly as you were doing before (create a bridge, set arp to proxy-arp, and add the ethernet and wireless interfaces to the bridge). In the wireless card properties, change the mode from “station” to “station wds”.
I have a RB532 board for the AP and a 133c for the client end, although a 133 for the AP should work (not a 133c because they usually don’t come with a level 4 license).
If you Senao supports all of this, that’s great, but I have no experience with them and it will be hard to get support here for them since this is a Mikrotik forum.
Joe
If I decide to even attempt this, I am concerned that the software might not allow normal client access while in WDS mode. I also don’t like the loss of bandwidth using WDS, which is why I haven’t really considered this option seriously. We have a fairly large wireless network, and the plan was that eventually a lot of the clients would be replaced by MT clients.
Why can’t proxy-arp work in station mode? 
Joe
Honestely, I have switched back and forth between routed and wds bridging, and I’m not seeing any loss.
Regular clients can still connect to the AP as they normally would. This is a simplified version of how I use it: On our tower, we have a backbone connection coming in which goes to a RB532 on our tower configured like I mentioned above. There is a 2.4 ghz card in the RB connected to a 12 dbi omni antenna. All of clients that are in range (some are routerboards, some are linksys, and some are connecting right from a laptop) can connect right to the tower.
We have a group of clients a couple miles away that can’t connect right from the tower, so I have a 133c connected to an 18dbi antenna in station wds mode with all the bridging like above. This 133c connects to the same antenna/radio as the clients near the tower. Then I have a cable running from the 133c to another 532 which rebroadcasts the signal and essentially extends the range of the tower and makes it look like one big happy network.
Is there a reason you couldn’t leave the existing network alone and just add to it? If you did that, you could get away with a 133c on each end and on the AP, setup everything the same except instead of “ap bridge” just set it to “bridge” and the only thing that connects to that is the 133c on the other end, which in the end just creates a point to point bridge. (bridge mode is the same as “ap bridge” except only one client can connect to it, and it’s supported on a level 3 licence where “ap bridge” needs level 4.
joebush -
Geez this is getting to be a LONG thread…
Why don’t we start ‘over’ again and define your requirements;
-
You want to bridge everything because of client connection to applications - can your client applications connect via IP or must they use multicast (wins, net-bios, etc)? You understand that ‘internally’ (the client’s internal network) doesn’t need a router for clients to connect to their own internal file server - right?
-
You want to bridge because you have a rather large network and it is inconvenient to ‘change’ now - I have 1000+ wireless and I consider this a medium, do you have more?
-
Bridging is easier - if you are just doing a few clients otherwise the overhead created by a bridged network could amount to 30% or more ‘overhead’ traffic which means less overall throughput for the entire network.
I am not ‘putting you down’ here - I am trying to get a feel for what you are doing, why you find it necesary to do it that particualr way, what are your requirements to have a what you consider a workable network solution.
Some of your other questions;
RB133 vice 133C, same exact system with a few hardware pieces removed. Software - the software knows the difference between a 133 and a 133c and prevents you from having a license above level 3 (RB133c) so there is no possiblilty that a 133c can become an AP. It can only be a client - otherwise it is identical to the 133.
The 133c was meant to be an inexpensive client - it can do this very well, and if configured correctly in a routed environment can easily sustain 10Mbps throughput. A 133 looks to be more like an inexpensive hotspot/micro-pop solution where you have a ‘central’ controller (hotspot use) or a small area of 10 - 20 clients (micro-pop) as an AP, possibly a backhaul with almost no ‘duties’ except to pass data (in a routed solution we have seen 15Mbps passed through a 133).
WDS mode - you only lose a very little 10 - 20% over a routed solution, if you go on to WDS/repeater (sort of a pseudo mesh) then every leg loses by about 40% of throughput. If you are just using WDS to connect to WDS stations then just the 10 - 20% lose and no more. By comparison a bridge can cost you 30% or more depending on the configuration… WDS does require substantial CPU resources but could easy work on a RB133 provided there are not too many WDS stations out there connecting to it.
DHCP - did you get that working yet? If not, post your DHCP config and let’s see what the issue is…
Ok - that’s about it for now…
Thom
I was refering to a server on the inside of the network these clients connect to…passed the AP. WINS would be a solution, but I am looking for avoid the need to configure clients. (DHCP server setting for WINS covered further down)
Not even close. Einstein was certainly right. Everything is relative.
I have about 40 clients connecting to our triple-headed AP. Overhead isn’t an issue with bridging.
Support at MT aren’t the best at answering questions directly, unfortunately. When they finally did, they refered to ‘ip dhcp-server’ shell. But the RB133c doesn’t have such a menu, although he has previously told me that the RB133c has a small DHCP server. So, still have no idea about this, one way or the other.
Near the top I refered to my later comment about the DHCP server. My point was that, if the DHCP server is supported in the RB133c, and it allows the configuration of a WINS server, that could be a solution. All clients can be routing clients with identical setup, other than IP. I think this could work fine. I am in no way against setting up a routed network, and have considered it myself. One entry at the core for the wireless network and all remaining entries on the main AP should cover everything, with clients getting rolled out with same config. A separate subnet for each head of the AP would be nice. This all depends on a box that has a DHCP server though to simplify client connection inside the clients network and setting for the WINS server, though.
Go to system/packages and make sure the dhcp package is enabled. If it isn’t, that would explain why the menu is missing in winbox.
joebush -
jcremin is correct - /system packages, look at enabled packages. In the RB133c the DHCP server package is ‘shipped’ as disabled.
With 40 clients you’re just getting to that place where bridging will become an issue soon.
We have our APs setup to handout DHCP addresses so we can use a ‘common’ config for our CPE units. The only ones that differ are our ‘commerical’ units which are normally connected to different APs, much higher bandwidth allocations, and many require public IPs and server access / network access via VPN or other such application(s). We do 24/7 support for the commerical guys - most pay $200.00 to $4000.00 a month so a seperate network for commercial use was pretty much a ‘no brainer’.
Hmmm.what the heck could you have all your clients connecting to that requires a WINS server… Odd…
Ok - well I hope you find this helpful.
Thom