Community discussions

MUM Europe 2020
 
DirectWireless
Member Candidate
Member Candidate
Topic Author
Posts: 143
Joined: Wed Oct 06, 2004 8:09 am

Bridged ether1/wlan1 (Station mode, no WDS)

Fri Jun 16, 2006 12:47 am

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
 
GotNet
Member
Member
Posts: 436
Joined: Fri May 28, 2004 7:52 pm
Location: Florida

Fri Jun 16, 2006 2:09 am

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

IF I'm following you. :)

Mike

Forum is sloooow tonight.
 
DirectWireless
Member Candidate
Member Candidate
Topic Author
Posts: 143
Joined: Wed Oct 06, 2004 8:09 am

Fri Jun 16, 2006 5:30 am

Well the router has a static IP, and the client connected to ether1 is an XP client in DHCP mode.
 
enrique
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Thu Mar 30, 2006 12:33 pm

Tue Jun 20, 2006 6:39 pm

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.
 
User avatar
Eugene
Forum Veteran
Forum Veteran
Posts: 993
Joined: Mon May 31, 2004 5:06 pm
Location: Cranfield, UK

Wed Jun 21, 2006 11:40 am

station without WDS COULD NOT BE BRIDGED. Go learn IEEE 802.11. Period.
Tout individu a droit à la vie, à la liberté et à la sûreté de sa personne.
 
GotNet
Member
Member
Posts: 436
Joined: Fri May 28, 2004 7:52 pm
Location: Florida

Wed Jun 21, 2006 2:56 pm

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

IF I'm following you. :)

Mike

Forum is sloooow tonight.
I wasn't following you and Eugene is very correct.
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 801
Joined: Tue Aug 03, 2004 9:01 am

Fri Jun 23, 2006 10:28 pm

station without WDS COULD NOT BE BRIDGED. Go learn IEEE 802.11. Period.
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? :)

-- Nathan
 
wildbill442
Forum Guru
Forum Guru
Posts: 1050
Joined: Wed Dec 08, 2004 7:29 am
Location: Sacramento, CA

Fri Jun 23, 2006 10:58 pm

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.
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 801
Joined: Tue Aug 03, 2004 9:01 am

Fri Jun 23, 2006 11:24 pm

Well looking the bridge NAT section, it looks like you could concievably create a 1:1 NAT to the ethernet device.
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. :)
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
 
DirectWireless
Member Candidate
Member Candidate
Topic Author
Posts: 143
Joined: Wed Oct 06, 2004 8:09 am

Sat Jun 24, 2006 6:15 am

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.
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 801
Joined: Tue Aug 03, 2004 9:01 am

Mon Jun 26, 2006 8:08 pm

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
 
in4ni
Member Candidate
Member Candidate
Posts: 187
Joined: Thu Dec 09, 2004 4:22 am
Location: Jax, Fl USA

Wed Jun 28, 2006 12:16 am

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


Thank you
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 801
Joined: Tue Aug 03, 2004 9:01 am

Wed Jun 28, 2006 3:02 am

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
 
goldclick
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Sep 17, 2004 10:48 pm
Location: Nigeria
Contact:

Sat Jul 29, 2006 10:22 am

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.
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.
Sunday Idajili
ITClick Networx Limited
 
User avatar
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Sun Jul 30, 2006 4:22 am

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.
What prevents the pppoe packets from being bridged the normal way?
How does this make it a pseudo-bridge when you are already bridging?
Move along. Nothing to see here.
 
User avatar
tneumann
Member
Member
Posts: 394
Joined: Sat Apr 16, 2005 6:38 pm
Location: Germany

Sun Jul 30, 2006 8:21 pm

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.
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(TM). 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
 
User avatar
BrianHiggins
Long time Member
Long time Member
Posts: 600
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Mon Jul 31, 2006 5:45 am

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)
 
DirectWireless
Member Candidate
Member Candidate
Topic Author
Posts: 143
Joined: Wed Oct 06, 2004 8:09 am

Mon Jul 31, 2006 6:36 am

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.
 
User avatar
tneumann
Member
Member
Posts: 394
Joined: Sat Apr 16, 2005 6:38 pm
Location: Germany

Mon Jul 31, 2006 8:31 am

so what makes sense to me is to simply broadcast the incoming packet to all computers on the wired side of the bridge.
And have all the other guys put their network adapters into promiscious mode and read my traffic? No, thanks :shock:
 
DirectWireless
Member Candidate
Member Candidate
Topic Author
Posts: 143
Joined: Wed Oct 06, 2004 8:09 am

Mon Jul 31, 2006 9:05 am

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?
 
User avatar
BrianHiggins
Long time Member
Long time Member
Posts: 600
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Mon Jul 31, 2006 4:59 pm

but you do realize that it's not exactly the most secure thing sending wireless in the first place, right?
pppoe using 128bit encoding, over a 802.11a radio with nstream, running WPA2 AES encryption with a 10-14 character random character key

and if that's not good enough, you can:
use EAP/TLS
use IPSec
tunnel through a VPN....

do you really ever need it to be more secure then that?
 
DirectWireless
Member Candidate
Member Candidate
Topic Author
Posts: 143
Joined: Wed Oct 06, 2004 8:09 am

Mon Jul 31, 2006 7:18 pm

But my point was regarding MAC broadcast where as a suggestion I had mentioned using MAC broadcast to the internal machines, where another user said that would be more insecure due to promiscuous mode. I was pointing out that it's not much less secure than what most of us use. And if you're tunnelling w/ encryption to each of the machines inside of the network, what difference would broadcasting all the packets make anyhow? If you're only encrypting to the radio, what is to stop a user from simply passively tapping a network wire or whatnot vs having a specified MAC address and relying on a network switch to segment users via MAC address. IF you're encrypting end to end (IPSEC, PPtP) then what difference does it make anyhow?

In addition, if you're not encrypting, if you had a VLAN switch, couldn't the VLAN tags still direct the broadcast packets while it goes through the switch, even with broadcast MAC?
 
User avatar
tneumann
Member
Member
Posts: 394
Joined: Sat Apr 16, 2005 6:38 pm
Location: Germany

Mon Jul 31, 2006 10:28 pm

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.
PPPoE for clients that are placed behind the station that is bridging with WDS? If so, add a simple bridge filter in the forward chain on the WDS-station that only passes pppoe-discovery and pppoe-session frames. That'll stop your customers from communicating directly with each other and force them to go through your central PPPoE server. If you're really careful and want to make sure a customer does not set up his own PPPoE server within your bridged cloud, add a rule that checks the frames destination MAC against your PPPoE server's MAC address so they can only talk PPPoE to your server and no others.

--Tom

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 43 guests