Nothing wrong with DLINK switches if configured properly, same goes with the MT.
If the OP, or in this cast the PERP being guilty of using vlan1 for data vice leaving it alone as a background native vlan just doing its thing, is gonna have problems.
So first things first, lets assume we stick with vlans 200,300, and 400.
Going from etherX (trunk port on MT router) to Dlink switch.
EtherX (at MT)
/interface bridge ports
bridge=bridge interface=etherX ingress-filtering=yes frame-types=admit-only-vlan-tagged
/interface bridge vlans
bridge=bridge tagged=bridge,etherX vlan-ids=200,300,400 { if 200,300,400 have no other assignment, otherwise as applicable }
bridge=bridge tagged=bridge,etherX, unknown untagged=unknown vlan-ids=200
bridge=bridge tagged=bridge,etherX,unknown untagged=unknown vlan-ids=300
bridge=bridge tagged=bridge,etherX,unkown untagged=unknown vlan-ids=400
Now we have to figure out what is the trusted subnet, lets say it vlan200…
At DLINK switch.
Lets assume ether1 is from the MT, ether2 is going to a dumb AP for vlan 200, ether3 is going to a dumb AP for vlan 300 and ether4,5 are going to dumb computers on the trusted network, ether6.7 are going to dumb wired media devices vlan400. and ether8 is going to another smart switch but only carrying vlan trusted and medial vlan400
First off, the switch needs an IP address on the trusted VLAN 200.
THere should be ipv4 LAN settings somewhere on that switch!!
…

…
(1) ALL ports come default untagged with native VLAN1
(2) Trunk ports should have a native untagged vlan1 and this should be left alone. All trunk ports should be tagged with all the vlans required.
(3) Access ports to dumb device should have PVID assigned to the port which removes the default untagged vlan1, and the port should be untagged for the new VLANID
Based on the above facts, your DLINK should look something like
…
