DHCP Requests not "forwarded"

surumadurum · Fri Jan 23, 2015 12:19 am

Hi,

I am playing aroung with a new deployment and stumbled upon following (rather basic) problem:

I configured a SXT2 as Station, connecting to an AP(FritzBox)=DHCP Server. I set up a DHCP Client on the SXT, works perfectly. But as I connect via Ethernet to the SXT with my laptop, I cannot get a DHCP IP...

What did I miss?

Here's the config:

[admin@MikroTik] > export
# jan/02/1970 00:10:28 by RouterOS 6.25
# software id = 4G26-IMMI
#
/interface bridge
add name=bridge2
/interface wireless security-profiles
set [ find default=yes ] eap-methods=""
add authentication-types=wpa-psk,wpa2-psk eap-methods="" group-ciphers=\
tkip,aes-ccm management-protection=allowed mode=dynamic-keys name=\
profile1 supplicant-identity="" unicast-ciphers=tkip,aes-ccm \
wpa-pre-shared-key=XXX wpa2-pre-shared-key=\
XXX
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n disabled=no l2mtu=1600 mode=\
station-pseudobridge security-profile=profile1 ssid=PEACE \
wireless-protocol=nv2-nstreme-802.11
/interface bridge filter
add action=drop chain=input disabled=yes dst-port=68 in-interface=!w
ip-protocol=udp mac-protocol=ip
/interface bridge port
add bridge=bridge2 interface=wlan1
add bridge=bridge2 interface=ether1
/interface wireless cap
set discovery-interfaces=ether1 interfaces=wlan1
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=bridge2
/system leds
set 0 interface=wlan1
[admin@MikroTik] > inter wire cap
[admin@MikroTik] /interface wireless cap> pr
enabled: no
interfaces: wlan1
certificate: none
lock-to-caps-man: no
discovery-interfaces: ether1
caps-man-addresses:
caps-man-names:
caps-man-certificate-common-names:
bridge: none
[admin@MikroTik] /interface wireless cap>

First I thought it would be the drop rule from the bridge filter, but no change after I disabled it...

Fri Jan 23, 2015 8:24 am

What is the reason for the bridge firewall drop rule? Why you used station pseudobridge instead station bridge?

surumadurum · Fri Jan 23, 2015 12:15 pm

The drop rule was some left-over from the default config, but as you can see in the config, it's not active.
And as I am connecting to a FritzBox I cannot use station bridge, because it's MikroTik specific (http://wiki.mikrotik.com/wiki/Manual:Wi ... tion_Modes).
So, my question is: Do I really need L2 connectivity for DHCP? Or could it be it has something to do with multicast/unicast on L3?

NathanA · Fri Jan 23, 2015 1:31 pm

In my experience, DHCP is not MAC-NAT friendly, and MAC-NAT is essentially what is happening when you use station-pseudobridge. It's not just MikroTik's implementation...it's the nature of the beast. The source MAC of the ethernet header of the DHCP request will be changed by the MikroTik's pseudobridge feature, but the original MAC address will remain inside the payload of the DHCP request; they will be mismatched. Many (most?) DHCP servers don't respond well to this, and as far as I know, the station-pseudobridge feature does not have any kind of "NAT helper" for DHCP. (Problem could be either that DHCP server sends response to the MAC on the inside of the DHCP payload, in which case the AP has no idea which client to send that to because it doesn't match the MAC of any associated stations, or that DHCP server sends response to the MAC in the ethernet header, in which case it gets to the MikroTik but the MikroTik doesn't know who to bridge that unicast reply back to.)

The reason the SXT can get an IP no problem is because it is originating its DHCP request from the same MAC address that it is associated to the base station with.

If the AP supports it, you could try enabling WDS, and then associating to it as "wds-slave". Then bridging will be truly transparent. Alternatively, if your DHCP server has an option to always transmit all responses as a broadcast instead of unicast, try enabling that.

-- Nathan

surumadurum · Fri Jan 23, 2015 2:25 pm

Ok, that sounds very reasonable... Thanks for the enlightening this matter... I was just wondering because I had also other MikroTik APs behind the bridge (so there were not directly associated as well) and the DHCP client worked perfectly there. But as you said, probably you will encounter >some< problems.
Thanks a lot!

DHCP Requests not "forwarded"

DHCP Requests not "forwarded"

Re: DHCP Requests not "forwarded"

Re: DHCP Requests not "forwarded"

Re: DHCP Requests not "forwarded"

Re: DHCP Requests not "forwarded"