Bridged ether1/wlan1 (Station mode, no WDS)

RouterOS Wireless Networking
1

I was playing around with a 2.9.23 router today, with ether1 and wlan1 bridged. The wireless interface was set to station mode (not WDS). On the station connected to ether1, the station was assigned an IP address from the wireless AP. Now I’m more of a 2.8 kinda guy, but I was always under the impression that that did not work.

Well, it kinda didn’t work. I got an IP from the wireless DHCP server on the wired station, but can’t ping out. Do I need to set something under bridge/NAT or bridge/Route?

Thanks

RouterOS v3.0beta2
2

Does work! Make sure the ports are setup in bridge and the DHCP client is to the bridge interface.

IF I’m following you. :slight_smile:

Mike

Forum is sloooow tonight.

3

Well the router has a static IP, and the client connected to ether1 is an XP client in DHCP mode.

4

Hi DirectWireless,

So you have the Xp pc via DHCP client connected to ether1 and wlan 1 in DHCP client mode associated to wireless AP. please be more especific.

5

station without WDS COULD NOT BE BRIDGED. Go learn IEEE 802.11. Period.

6

I wasn’t following you and Eugene is very correct.

7

Well, yes, if we are talking about “bridging” in the traditional sense, you are correct. Without WDS, this is not possible. In fact, that’s the whole point behind the existence of WDS in the first place.

However, there are a myriad of devices on the market (made by companies like this one and this one, for example this device) that do what you claim cannot be done. In my experience, they typically tackle the 802.11 bridging problem in one of two ways:

  1. They latch on to the first MAC address they see on their ethernet port, and “pretend” to be that MAC on their wireless interface (when associating to the AP and such). Typically, devices that do it this way can only bridge ONE ethernet device over the wireless connection.

  2. They associate to the AP using their own MAC, and rewrite the source MAC address in any ethernet frame generated by the device(s) connected to its ethernet port to match its own MAC. (Read: MAC-NAT) These devices generally can bridge to a (fixed) number of ethernet devices over the wireless connection. These kinds of “bridges” are able to sort out what inbound traffic on the wireless interface should be sent to what MAC on its ethernet interface by maintaining internal tables for different kinds of traffic. For example, most maintain a IP → MAC table (maybe learned by watching the ARP responses from the devices connected to its ethernet port?) for inbound IP traffic, and I know some devices that maintain a PPPoE Host-Uniq → MAC table that keys off of the Host-Uniq tag sent in the PPPoE-Discovery packets in order to allow for the bridging of multiple PPPoE tunnels between the 802.11 interface and the ethernet interface.

When I first saw the new MAC-NAT option under the Bridge Firewall section of 2.9, I figured that I would be able to use this feature to reproduce the functionality of 802.11 ↔ ethernet bridges like the ones described above, but I have not been able to get this to work. Theoretically, it should be technically possible to do this with MAC-NAT, unless MikroTik decided in their code to ignore any and all traffic originating from or destined for a wireless interface set to “station” mode.

If they did do this, I would politely request that they remove this artificial restriction in their bridge code so that those who would like or even need the ability to construct a MAC-NAT “bridge” across an 802.11 link without WDS can do so.

If they didn’t do this and someone else has been able to successfully create MAC-NAT rules on their MikroTik bridge which includes an 802.11 interface in “station” mode, would this someone be kind enough to post, as an example, their working configuration? :slight_smile:

– Nathan

8

Well looking the bridge NAT section, it looks like you could concievably create a 1:1 NAT to the ethernet device. However its a static NAT rule, and if the device changed you’d either have to clone the MAC to keep the configuration or change the MAC in the Mikrotik bridge NAT rule…

There is no “masqureade” action in the bridge NAT action list. And if there was it doesn’t create a true bridge, all packets would get NAT’d behind a single MAC.

It just seems easier to use WDS.

9

That’s what I was trying to do (unsuccessfully). Just MAC-NAT bridge one MAC.

There is no “masqureade” action in the bridge NAT action list.

Yeah, well, MikroTik has stated (though I can’t remember where…maybe I saw it in the documentation) that MAC-NAT is completely stateless because their implementation lacks any sort of connection tracking.

And if there was it doesn’t create a true bridge, all packets would get NAT’d behind a single MAC.

I already acknowledged this limitation when I said that it isn’t a true bridge. :slight_smile:

It just seems easier to use WDS.

…except when you’re trying to connect a MikroTik CPE to an AP that DOESN’T support WDS and/or isn’t under your control, and you (for whatever reason) don’t want to route at the MikroTik CPE itself.

There are legitimate reasons for needing this feature. The fact that it isn’t a true bridge doesn’t mean that it doesn’t have its place and it doesn’t limit its usefulness under those types of circumstances.

– Nathan

10

But why was my workstation able to get an IP address THROUGH the bridge (no WDS) yet not able to ping, or pass IP? It says to me that MAC layer was bridging but maybe it was an ARP issue - I tried PROXY-ARP but no avail (which I figured would “NAT” the internal MAC).

It doesn’t make any sense, I got an IP from the AP - not the CPE. But nothing else worked after that. DHCP is a request and response, and it bridged that, but nothing else.

My workstation did not have any kind of connection to the net except the single ethernet port connected to the bridged CPE in station mode. The conn track shows packet attempts with ping / tracert but no actual data was going. To help, DHCP wasn’t even installed on the RB112 I was using at the time.

11

DirectWireless, is it possible that your DHCP server was set up to always send replies to the broadcast MAC? Maybe broadcast traffic passes through the station-mode bridge just fine…

– Nathan

12

Directwireless- Did you ever figure out if there is a way to do this bridge with mikrotik?


Thank you

13

Okay, I finally got a 1-to-1 MAC-NAT to work almost completely successfully. I’m not really sure what I did differently this time as I could’ve sworn I tried exactly the same thing before, but whatever.

The only stipulation is that at the same time, I was able to verify my theory about DirectWireless’s DHCP question as well…your DHCP server must have “always-broadcast” set to “yes” (if this is a MikroTik DHCP server…use the equivalent option on whatever it is you use if it is not MikroTik) if you want DHCP to cross the “bridge” successfully, even with the MAC-NAT rules in place. When I turn that “always-broadcast” option off, the DHCP server sees the REQUEST, sends an OFFER, but the client never sees the OFFER and so just sits there, sending REQUEST after REQUEST ad infinitum. (I’m not actually sure why this is, though…maybe it’s because the MAC of the DHCP client is included in the payload of the DHCP packet in addition to the ethernet frame header, and in a MAC-NAT situation these values will not match because MAC-NAT changes the source address in the frame header only. The DHCP server is probably sending the reply back unicast to the MAC that was embedded in the DHCP request instead of the source MAC address according to the ethernet packet header. Just a guess.).

Furthermore, ARP does not seem to get bridged correctly, either. There is a patchwork way around this which I will demonstrate in my example (below), but you will have to know the MAC address of your gateway and statically program it into the MikroTik CPE. If the MAC of the gateway changes, then you will need to change the NAT rule in all the clients that you have set up this way.

Also, as has already been discussed, there is no “masquerade” option, so you can only “bridge” one ethernet MAC over the wireless link with this technique. So all that this will allow you to do is to offload your routing from the MikroTik to whatever is plugged into the ethernet of the MikroTik. You will not be able to plug a switch in with a bunch of devices on it.

Okay, on to the example. Here’s what I did:

/ interface bridge
add name="bridge1"

/ interface bridge port
add interface=wlan1 bridge=bridge1
add interface=ether1 bridge=bridge1

/ interface bridge nat
add chain=srcnat src-mac-address=00:11:22:33:44:55/FF:FF:FF:FF:FF:FF \
    action=src-nat to-src-mac-address=00:55:44:33:22:11
add chain=dstnat dst-mac-address=00:55:44:33:22:11/FF:FF:FF:FF:FF:FF \
    action=dst-nat to-dst-mac-address=00:11:22:33:44:55
add chain=dstnat mac-protocol=arp arp-opcode=request \
    arp-src-mac-address=00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=arp-reply \
    to-arp-reply-mac-address=00:77:77:77:77:77

Where:
00:11:22:33:44:55 == the MAC of the ethernet device you wish to bridge
00:55:44:33:22:11 == the MAC of the wireless interface in “station” mode
00:77:77:77:77:77 == the MAC of the gateway for your IP subnet that lies beyond the AP you’re connecting to

The first two rules should be pretty self-explanatory. The third MAC-NAT rule says that if the ethernet device sends an ARP request that gets broadcast over the bridge, then automatically generate the reply to that device locally on the MikroTik CPE. If you elect not to do this, you will have to end up adding a static ARP entry on the device connected to the MikroTik via ethernet (which also works fine).

Interestingly, PPPoE works perfectly fine over this pseudo-bridge, even though unicast DHCP and ARP do not. Go figure. Obviously, if you’re using PPPoE, you don’t need a NAT rule to auto-generate replies for ARP requests.

Hope this helps,

– Nathan

14

I noticed this same issue with my RB112 that was setup in routing mode. No DHCP, and I did not bridge any interface. Mac Addresses of devices on the ethernet side were discovered by my hotspot server [in /ip hotspot hosts]. Normal I should only see the mac address of the wireless interface, since it was routing. Not sure what was going, we reset the configuration, upgraded to 2.9.27 and started all over. didn’t bother to investigate further.

15

What prevents the pppoe packets from being bridged the normal way?
How does this make it a pseudo-bridge when you are already bridging?

16

Yeah, well, this will sort of work. For small values of “work” :wink:

Let’s admit it, the implementation possiblities you described are ill-conceived and not The Right Way™. So the MikroTik implementation of MAC-NAT is completely stateless, OK, can’t blame them for that, because the possible number of upper layer protocols being transported through a bridge is potentially endless. You described a few ideas on how to derive artifical state by analyzing the packets that go through the bridge and look beyond the MAC header, for example into the IP header or into a PPPoE frame. That solves it for IP and PPPoE, maybe. Now I want to transfer IPX over that bridge. Does it know how to look into IPX packets as well and do the right thing? Would there even be a right way for those packets? What about SNA? DECnet? My own custom implemented layer 2 protocol? Maybe these protocols just dont have a field that you can conveniently look for to derive state from, or it would be very complex to analyze.

Possibilities are endless, you cant foresee all problems of all protocols and work around them.

If I want a bridge, I want it to be damn transparent or not the exist at all. Not on any of my equipment at least.

I fail to see why so many people would want such crap.


–Tom

17

I fail to see why so many people would want such crap.

because there are times when it is the best way to accomplish the task at hand. what if you simply wanted to create a “signal repeater” to rebroadcast signal for 2 or 3 computers… this can easily be done with a Tranzeo CPE hooked into any off the shelf AP, but not with mikrotik…

I am using WDS on my network to accomplish the station bridge for PPPoE clients, but it has significant downsides. with a regular (non-wds) station, you can disable forwarding on the AP preventing people from easily creating their own networks inside of your AP. with using WDS you have to add the station to a bridge, which bypasses the isolation created by disableing forwarding, and thereby increases the impact that broadcast traffic can have on your network. it also uses additional CPU power on the AP, and when you’re running RB500’s or WRAP boards for your APs, you don’t have much CPU power to waste…

so WDS may be the right way to bridge through the station to the AP, if you are only trying to bridge to the AP for PPPoE traffic, it’s not the “right way” as you are actually degrading your network performance by allowing additional and completly unnecessary broadcast traffic, as well as exposing your customers to potential attacks from other customers on the same AP.

we know that bridgeing doesn’t work under the 802.11 standards without WDS, but WDS isn’t exactly the best solution to every situation out there Z(and as many people pointed out, sometimes it isn’t even an option)… breaking the standard to allow bridging to even a max of 1 machines on the ethernet port most definitly has it’s place and should be added as an option, without going through a series of complex bridge-nat rules that have to be manually re-wrote any time the MAC address of the customer changes. what should be added is a bridge-nat-srcnat that dynamically uses the first MAC address to get NAT’d, AND will re-map if it doesn’t not see any traffic from that MAC in X number of minutes (to prevent having to re-boot after changing the device being MAC-NAT’d)

18

So the big question from me, for all of those who say WDS is the “right way”, why is it that I can connect 32 or 64 computers with a CB3, which “MAC-NATs” all the machines automatically without hurting any high level protocols whatsoever, yet the wireless AP only shows a single MAC address. Also duplicated with AirEpoch equipment, WET11’s, and others.

The best I can figure that avoids a “NAT” forwarding issue is that it simply rewrites the incoming destination as a broadcast to all (FF:FF:FF:FF:FF:FF) so all 32 or 64 machines recieve the packet as it if were their own, and decide at that point what they would do with it (like a standard 10 mbps hub would do). I have not confirmed this though, but that’s the only thing that makes sense to me - otherwise, how would it know if (formerly unknown) SRC A were talking to both DST B and C, how would the bridge know which DST to send the packet to, a standard IP NAT issue. We dont want to have to have “MAC port forwarding”, so what makes sense to me is to simply broadcast the incoming packet to all computers on the wired side of the bridge.

19

And have all the other guys put their network adapters into promiscious mode and read my traffic? No, thanks :open_mouth:

20

So what is it that every other wireless bridge vendor is capable of doing with the simplest of hardware platforms, with no configuration, no compatibility problems, no need for “MAC NAT port forwarding”, and all using a single MAC address? All without WDS?

Why doesn’t Mikrotik do the same? The broadcast thing was only an idea, but you do realize that it’s not exactly the most secure thing sending wireless in the first place, right?