sfp and ether1 ports on devices with EN7562CT are still defective. the problem was confirmed by the support team about a year ago. but there is no fix at the moment.
when it's fixed or not fixed. no one knows. there have already been cases of similar malfunctions in history, for example with Wi-Fi and AX devices, AX devices were also actually unusable, but after almost a year and a half they were fixed and now they are one of the best products.
but again, given the focus on apps and new devices, perhaps the EN7562CT series will remain a defective budget solution.
If you are a retailer, your customers can ask for redress under the legal guarantee provided by EU law - if an item:
doesn't match the product description
has different qualities from the model advertised or shown to the client
is not fit for purpose - either its standard purpose or a specific purpose ordered by the customer which you accepted
doesn't show the quality and performance normal in products of the same type
wasn't installed correctly - either by you, or by the customer, due to shortcomings in the instructions
If you inform your customer that the product you are going to sell has quality problems, they cannot then claim redress from you about this particular defect.
The options are:
What can your customer claim?
Your customers have the right to ask you to do any of the following without any charge (for postage, labour, material, etc.):
repair the product
replace the product
reduce the price
cancel the contract and reimburse them in full (in some countries, the sales contract cannot be cancelled if the fault is minor, e.g. scratch on a CD case)
Replace product would not help, because it is a general product issue. Reduce price could work, but good luck with that - you still have 50mbit. Repair product is the thing, “repair buggy software" in this case. It is going to happen somewhen, as MikroTik fixes bugs usually but with undisclosed priority. Until then you have a very limited box benching 50mbit. Cool.
Price reduction or full refund
Another option for your customer is that you give them a price reduction or a full refund, but only if repair or replacement:
is not possible
would be too expensive, given the nature of the product/defect
would be very inconvenient for the customer
cannot be completed by your business within a reasonable time
If MikroTik support responds with “bug acknowledged BUT we can't give ETA” or something like this. Congrats! You have unlocked “cannot be completed by your business within a reasonable time” and “would be very inconvenient for the customer”. You can get your money back under EU law.
I have been so focused on my E50UG (wired ether1 issue) that I did not even think of possible wifi problems. Sorry to hear this.
Would be nice if MikroTik fixes this. I am not in EU unfortunately so all they will tell me is “call distributor”, so I can do what? Tell distributor “sorry all of these products are defective, give me refund and send all of them back to MikroTik” ?
Edit: And I forgot, my “warranty” is probably over for E50UG, so I cannot even get refund, even though this is factory defect, not “warranty” problem. Same thing happened to me before with original hEX-S…. stuck with defective unit.
Which one did you buy?
I tried a 10G GTek and GoodTop and did not recognize them.
The SFP port is connected to the CPU I'm afraid I have the same problem also with wireless.
There is no reason why ether2 should behave differently from ether5.
Yes, but the SFP module itself is not a "passive" device, it is something that acts as a translator from SFPish to ethernetian (and viceversa), so it may well act (like the "dumb" switch) to filter the pause frames (or whatever creates the issue).
When I used ether2, I was connected via wireless and the speed was still limited to 50 Mbps; the same thing is happening now with ether5.
OK, I’ll look for a cheap SFP and give it a try.
With ether2–5, using a cable I reach 940 Mbps upload, but when using wireless there’s always a 50 Mbps limit.
That’s why I’m worried that even with the SFP module I’ll have the same issue with wireless clients.
I beleive that there is something else (cannot say what) that is escaping us.
I mean, if the issue is the ONT sending pause frames once the Ax S is connected to any of ports ether2-5, these frames do not arrive directly to the CPU, and as well interposing the "dumb" switch we have the same effect:
ONT -> pause frames -> ether1 -> pause frames -> CPU
ONT -> pause frames -> dumb switch (pause frames are dropped) -> ether1 -> CPU
ONT -> pause frames -> ether5 -> switch chip (pause frames are dropped) -> CPU
Whether the upload data comes from another ether port or from the wifi interface(s) it doesn't change anythyng (related to the pause frames sent by the ONT).
Could it be (for the wireless misbehaviour) an actual buffers or queues issue?
Thanks for that; this is interesting then. So far I’ve only been focused on wired/ether1 problem, not wifi (since I don’t own any hap AX S and refuse to buy anything else with EN7562CT inside until this problem is 100% without doubt demonstrably fixed).
Perhaps try changing the default wifi interface hardware queue to something else, as Jaclaz suggests, just to see if it has any impact for whatever reason?
Edit: Thank you for all of your efforts. It’s dumb that simply swapping in a hap ac2/ac3 and changing nothing else fixes everything, but it is what it is for now
Final update: the issue is related to the Ethernet path, not WiFi itself.
On the second hAP ax S (cAP), using Ethernet uplink limits WiFi upload (~100 Mbps), while switching to SFP uplink restores full speed. This confirms a problem in the Ethernet → WiFi forwarding path since the same setup works perfectly over SFP.
I tested both ether1 and ether4, and there is a gigabit unmanaged switch between the two hAP ax S devices.
This is the configuration of the hAP ax S used as a CAP, where wireless upload is limited to around 90–100 Mbps.
# 2026-04-22 13:57:06 by RouterOS 7.23rc1
# software id = BH09-XXXXX
#
# model = E62iUGS-2axD5axT
# serial number = HKE0XXXXXX
/interface bridge
add admin-mac=04:F4:1C:CD:8F:86 auto-mac=no comment=defconf name=bridgeLocal
/interface wifi datapath
add bridge=bridgeLocal comment=defconf disabled=no name=capdp
/interface wifi
# managed by CAPsMAN 04:F4:1C:CD:8F:4F%bridgeLocal, traffic processing on CAP
# mode: AP, SSID: MikroTik, channel: 2412/ax/Ce
set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap \
datapath=capdp disabled=no
# managed by CAPsMAN 04:F4:1C:CD:8F:4F%bridgeLocal, traffic processing on CAP
# mode: AP, SSID: MikroTik, channel: 5500/ax/Ceeeeeee/D
set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap \
datapath=capdp disabled=no
/interface bridge port
add bridge=bridgeLocal comment=defconf interface=ether1
add bridge=bridgeLocal comment=defconf interface=ether2
add bridge=bridgeLocal comment=defconf interface=ether3
add bridge=bridgeLocal comment=defconf interface=ether4
add bridge=bridgeLocal comment=defconf interface=ether5
add bridge=bridgeLocal comment=defconf interface=sfp1
/interface wifi cap
set discovery-interfaces=bridgeLocal enabled=yes slaves-datapath=capdp
/ip dhcp-client
add comment=defconf interface=bridgeLocal name=client1
/ip service
set ftp disabled=yes
set ssh disabled=yes
set telnet disabled=yes
/system identity
set name="hAP AX s"
/system package update
set channel=testing
/system routerboard settings
set auto-upgrade=yes
I can’t buy an SFP module for every hAP ax S, it becomes uneconomical…
To sum it up (please correct me where I might be wrong):
SFP<->direct connection<->CPU<->direct connection<->Wifi OK
SFP<->direct connection<->CPU<->via SOC switch <->ether2-5 OK
SFP<->direct connection<->CPU<->direct connection<->ether1 OK
ether1<->direct connection<->CPU<->via SOC switch <->ether2-5 NOT OK
ether1<->direct connection<->CPU<->direct connection<->Wifi NOT OK
ether2-5<->via SOC switch<->CPU<->via SOC switch <->ether2-5 OK
ether2-5<->via SOC switch<->CPU<->direct connection<->Wifi NOT OK
Good, there is also a friend of my cousin that has it OK, but only on wednesday nights.
What gives?
I was trying to sum up the reports by Massinia, to evidence a pattern (if any) connected to the way the device/SOC is connected (according to block diagram).
Me too's or Not Me too's don't add much to the (BTW very scarce) results of the attempt.
: