The 2nd bridge was added to keep the hotspot isolated from the other networks.
I can fix up the firewall rules but I dont see how they are relevant to throughput between a laptop connected to ether 2 and the WAN.
So, yes, the security on the router can be better but nothing we have found so far explains the huge difference in throughput.
...
I gathered that much for the two bridges.
Correct, I used the wrong command -
/interface/ethernet/print stats where name=ether2
/interface/ethernet/print stats where name=ether5
On the laptop, if you are using MS Windows,
netstat -e should display the interface statistics to see if the errors are on that side.
For good measure, can you also check the following? That will show whether hardware switching is done.
/interface/bridge/port/print
The firewall rules won't explain the slowness, or they would have to be really messed up to do so. I pointed at them as something I noted when I read the configuration. I don't think the 2 bridge setup explains it either.
millenium7 suggested a possible driver issue, worth exploring. If you have a different laptop, or the same laptop with a different OS, that would be something to test. I would also suggest to update it to the latest version in the 6.49 train, though I didn't see anything in the release notes that look even remotely close to this issue being fixed.
This isn't correct. RouterOS frustratingly puts this line into the config by default but it doesn't mean anything. It's essentially saying "if you untick auto negotiation, then i'm going to choose 100mbit by default" but whilst auto negotiation is enabled, the speed= parameter does absolutely nothing
Yes, already pointed out. As I said, I got bitten by a poor choice of terminology.
That router doesn't need fasttrack to easily exceed 100mbit/s so that wouldn't have anything to do with it either, infact i'd disable it for now as it might be hiding log messages which might indicate a problem
Fasttrack is still there. What I was referring to is that the configuration doesn't show the usual, default rules for the
input chain. Not going to cause that issue either but might come back later to bite the OP.