RB951Ui-2nD, versions 6.42rc56, 6.41.4, 6.40.7, 6.39.2, 6.38.5, winbox to MAC server on ether5.

(1) On a clean system (after a full config reset without defaults) do: Address successfully acquired.

(2) After rollback do it with bridge: And... Fail. No address. Server-side Mikrotik wrote "offering lease without success".

Torch in (2) on ether5 shows both client request and server answer. Torch on bridge1 shows client request only.
The situation was repetable on several versions of software.

Does your bridge have an IP address assigned to it? Does the bridge have ARP enabled? (by default it should be)

On your bridge, change to protocol-mode=none. The default is RSTP and I think it is broken!

All tests are performed on a clean configuration, i.e.:
- there are no IP address on the bridge and ARP is "enabled";
- bridge setting is default "protocol-mode=rstp". The "stp" and "none" protocol-mode also probed without success.

DHCP client should be set for bridge1 itself.
When any interface is assigned to bridge then it losts its identity and becomes just pure "electrical socket" of bridge interface. All funcionalty then should be set for bridge.

I have a same issue. DHCP client on Vlan100 - got IP. But if Vlan100 is a part of Bridge1 and DCHP client on Bridge1 - no IP. arp enabled stp disabled. Bridge1 has only one interface - Vlan100 nothing else

I have the exact same problem on many devices using latest ROS
Default config + ports in bridge = doesn't accept IP from DHCP server. Tried non MT DHCP server too, same result.

Hi
Does your bridge have an IP address assigned to it? Does the bridge have ARP enabled?

Hi
Does your bridge have an IP address assigned to it? Does the bridge have ARP enabled?

The DHCP client interface is the bridge yes. Everything is default and by default ARP is enabled everywhere. How come it works for some hours and then doesn't work for some hours? If I hard reset the device it gets an IP immediately.

Go to the bridge and try untick fast forward.

I waste so many hours and finally found this thread. @2frogs solution works for me - just disabled RSTP!

I waste so many hours and finally found this thread. @2frogs solution works for me - just disabled RSTP!

How did you exactly do this ?
protocol-mode=none in bridge setting ?
Loop-protect in interface ?
Something else ?

Fast Forward depends on many other setting to be active. See the manual.

https://wiki.mikrotik.com/wiki/Manual:I ... st_Forward

Try to disable stp on the bridge, if you don't need it, othervise you shall set it up correctly.

Maybe WAN port in bridge should be marked as "Trusted" ?

It's very unclear why STP and RSTP stop DHCP client from functioning on the bridge itself, and everything behind that bridge.
Fact is that setting the protocol to "none" fixes the problem in many occasions, for Mikrotik but also other DHCP servers.
The STP is slow, and waits quite long (30s?) after an interface on the bridge becomes active to start transmitting. The DHCP handshke may be over yet.
However later renew attempts also fail.

It is known that some reserved MAC adresses are blocked when STP or RSTP is active (https://wiki.mikrotik.com/wiki/Manual:L ... _addresses).
Is there anything else that is triggered by this being compliant with IEEE 802.1D and IEEE 802.1Q ???

HI guys, I'm having the same issue, my Mikrotik is connected to the main router via wifi (wireless bridge (pseudobridge mode).

Wlan and all ethernet ports are moved to the bridge.
I do see a lease in the client section of the ros for the brdige, there is internet available for the router - I can ping google dns from there.
However that IP lease is not passed over to the ethernet ports, so clients connected to the router via cable don't have access to the Internet ( ipconfing shows windows 169.x.x.x. IP)
I have tried a few things:
Removing Rstp
make interfaces trusted
Nothing works, is it a fault or work as designed?

try set new priority.
/interface bridge add name=bridge1 priority=0x9000

It's very unclear why STP and RSTP stop DHCP client from functioning on the bridge itself, and everything behind that bridge.
Fact is that setting the protocol to "none" fixes the problem in many occasions, for Mikrotik but also other DHCP servers.

try set new priority.
/interface bridge add name=bridge1 priority=0x9000

Same issue here on a bridge with activated DHCP client.
Setting protocol mode to 'none' or setting the priority to '9000' both fixed it.

Does anyone have further bachround information regarding this behaviour?