There are reports that ether1 (port directly connected to hte CPU) has issues on some newish devices, but they should have been resolved in recent Ros, try taking (say) ether2 out of the bridge and use it as WAN connection, see if it changes anything.
Maybe in your case it is the ethernet negotiation that is somehow wrong.
Also - with some devices - you need to set a queue on the Wan intrerface, not the default "only-hardware-queue".
Check /queue interface print.
In /queue type print you should see which queues types you have available, try with "ethernet-default".
@massinia Do you happen to have any other MikroTik available (specifically NOT using EN7562CT) at your disposal to try?
If you do, please connect it with the exact same configuration as your hap ax-s, and I bet it will work without any problem….
edit: Also, if you do test with a different model, please check Ethernet rx-stats to see if you are receiving pause frames from ONT by any chance. Thanks in advance.
edit2: I see you already confirmed my suspicion by testing against a hap ac3. Isn’t it funny that the same exact config/ont/cabling works fine there, yet people want you change your config? lol. My ask about pause frames still stands.
@massinia You would have to connect one of your other non-broken MikroTik units to confirm the pause frames sent from provider ONT. This is something else I’ve found suspicious - EN7562CT based routers do not report pause frames received, the field is completely missing in the output, but other models do…
Be advised, per MikroTik documentation flow-control should be OFF by default on all models..
Call it a hunch, but I’m going to take a wild guess that previous ONT (ZTE F601) did NOT send pause frames or use any flow control, and this new ONT (ZTE F6005v3) is.
This should not matter, since flow control is OFF on all MikroTik by default (right?), but for some reason it really seems to matter if you try to use anything with EN7562CT inside connected to anything that send flow control pause frames at you, whether it should or not..
You can find a lot of reports of this exact same problem you and I are seeing (horrendous upload speed for no readily apparent reason) in Amazon reviews, reddit, this forum, etc. MikroTik apparently can’t figure this out for themselves. I have an E50UG Hex Refresh here that does the exact same thing your hap AX S does when I plug it into my Verizon Alcatel-Lucent I-211M-L ONT, which coincidentally, sends flow control pause frames at whatever I connect to it. Funny thing, only the E50UG Hex Refresh has a problem, and I’ve plugged a LOT of other MikroTik routers into my same ONT handoff to confirm this.
Bunch of other forum members tried to tell me it was buffers, queues, or some other such nonsense. I took the E50UG into my work office, plugged it into a Cisco switch (which I control and confirm definitely does not have flow control enabled) and I get 900Mbps+ download and upload using it with the same default config, no problem. Other people have stuck a dumb switch in front of their EN7562CT device and it magically fixes the problem, which is because the dumb switch is receiving the pause frame (and not the MikroTik), and ignoring it, and it never makes it to the MikroTik to cause the malfunction.
Mikrotik also recently closed my not quite one year old support ticket about this without any explanation, too:
Don’t get me wrong, I LIKE MikroTik, and their products, and really want them to succeed. Having said that, this is the dumbest, most frustrating support experience I’ve had in a long time. Like you, I’ve tested it against all versions including 7.23beta5. The problem remains.
Might be an auto-negotiation issue. I have them with the hap ax s with bidi modules on mikrotik switches like the crs112, fiberbox and such. Disable auto-negotiation and use fixed or stop advertising all but 1G-BaseT-full. Hap ax s is going to claim full duplex but like in my case the crs112 and fiberbox are going to say half-duplex and the link will work like shit.
Thank you for posting. Perhaps MikroTik will do something about it and not decide to just let god knows how many hex refresh/hex s refresh/hap ax s units ship with completely broken flow control..
@jaclaz I have a hunch that your proposed experiment might also work - the switch ports don’t appear to behave the same as the ether1 port on EN7562CT, since only the ether1 port is attached direct to SoC per block diagram. Can’t say for sure though. Perhaps I’ll try this with my own E50UG sometime just to see.
@codelogic
I confirm that by using ether5 instead of ether1 as WAN, I achieve full upload speed (940 Mbps) even without a switch between the ONT and the hAP ax S.
Wired clients achieve full upload speed, while wireless clients are still limited to around 50 Mbps.
My guess: ether5 is HW offloaded and therefore not going through cpu for wired clients; or first going through switch as seen in block diagram. wifi/wireless is directly connected to cpu (like ether1) and then you probably see the same issue you had on ether1.
