hAP be³ Media Ethernet ports not working on stable RouterOS

Hardware
1

Hi,

I recently purchased a brand-new MikroTik hAP be³ Media router.

After the initial setup, as recommended, I updated the router to RouterOS 7.24.2 (stable channel). After the update, the Ethernet network stopped working completely. I could no longer connect to the router or access the network through any of the Ethernet/switch ports. The only way I could still connect to the router was via Wi-Fi.

I tried resetting the router and testing with different Ethernet cables and devices, but the Ethernet ports still did not work.

Eventually, I used Netinstall and installed RouterOS 7.25 beta 3. Surprisingly, after installing the beta version, the Ethernet ports started working. However, they are not fully stable or reliable. The network randomly disappears from the Ethernet ports, and when this happens, a router restart is required to get the Ethernet connection working again.

So, while the beta version does make the Ethernet ports work, it does not appear to be a stable solution for a home/production router.

Has anyone else experienced the same issue with the hAP be³ Media?

I would prefer not to run a production/home router on a beta version. I would like to use a stable RouterOS release, but currently the Ethernet ports do not work at all on the stable version I tested, while on the beta version they work only intermittently and can randomly stop working.

There is also something else I find strange. In /system routerboard print, the minimum firmware version is shown as 7.25 (or 7.25_ab170 on my device). Why is the minimum firmware version newer than the available stable RouterOS versions?

What is particularly concerning is that after installing the 7.25 beta firmware, I can no longer downgrade the device back to the previous stable RouterOS version, because the minimum firmware version has been updated to 7.25. This effectively leaves me running the beta version, even though it is not stable.

Does this mean that this particular hardware revision requires a newer RouterBOOT/firmware version that is only available in the beta release? Is there a recommended stable RouterOS version for this hardware revision?

Any information or advice would be appreciated. I would really prefer to keep this router on the stable channel rather than running a beta version.

Thanks!

2
3

Unfortunately, I had the same problem, also there was a FW mismatch, and only 7.25beta3 works right now.

I didn't netinstall, I just transferred files to the device by wifi.

For now be3 is for testing only, i want to see how it will behave, especially wifi. Also I hope that supply chain will stabilise soon.

4

It's sort of a running joke that newly released Mikrotik devices have bugs and peculiarities that usually need fixes, and these only come out after people get their hands on them.

It's sort of expected.

The only advice that can be given is to run the beta for now, and wait for the stable version that incorporates these fixes to come out.

5

What troubles me a bit in this case is that a nightly build was used in regular production process ( indicated by fw version).

I wonder what ISO audit ( or whatever is applicable nowadays) would make of that.

I have been working for quite a while in a electronics manufacturing plant for a worldwide telco company and I can not recall this was ever an OPTION when shipping material to customers.
Never !
FW/SW always had to follow the release process or goods did not leave the plant.

6

And probably it wasn't an option to ship essentially half-working devices to customers.

7

What boggles me more is the fact that the ROS version mismatched the installed firmware in a newly shipped device.

It means they flashed a nightly/beta fw, and separately installed different ROS from a stable release.

And why they bumped the minimal fw version all of a sudden, especially to a beta version is another question that needs to be asked.

8

My old RB750Gr3 also has an alpha build as Minimum Version. So this practice is not new.

image
image351×126 2.2 KB

9

New behavior or not, it is something which should not be done IMHO.

10

6.40_ab3840. Very high ab number. I remember when mt.lv/nightly-build was still available, the numbers did not much exceed 3xx or 4xx.

When I look at the https://mikrotik.com/download/changelogs?channelFilter=testing&versionFilter=6.40-6.43 there apparently was a time where - at least it looks like - stability really mattered most to MikroTik. Up to 66 RC builds! RC phase over many months. Now we see beta to stable reaching within appx. 3 months.

11

Welcome to RAD ... or, as the more modern acronym goes, to CI/CD. Mikrotik way :wink:

Regarding large ab number: I don't know how exactly ab versions map to the released ones, sometimes I get feeling that ABs are attributed to already released version rather than the upcoming one. In this particular case that would mean that 6.40_abXXXX were done after 6.40 was released to stable and were preparation for 6.41(beta). And 6.41 came with breaking change in bridge implementation ... and I can imagine that MT devs took some time to get that implemented as good as possible (I remember there were hiccups ... but mostly due to significant changes in configuration rather than bugs in implementation).

12

Allow me to disagree.

A line needs to be drawn somewhere.

One thing is - say - a whatever not properly whatevering in a BGP when there are also two Macvlan connections on a VRRP setup with mismatched devices.

That is obviously one of those bugs that honestly the developers can (and will) miss.

But ethernet connection not working? :astonished_face:

That is the second thing (after verifying that the device actually boots) that should be checked.

13

I think they did verify that 7.25b3 works, and likely fixed some of the problems peaple had, and decided to preinstall it.

It is still a quality control issue though, because they managed to install the correct firmware, but with mismatched ROS which caused an even worse problem than the bugs they tried to fix in the first place.

14

I'm pretty sure it worked for them and they didn't decide to yeet them out aware of this.

With all the upsides of designing devices around SoCs there come some negatives as well. The hardware is often buggy and undocumented.

This and the experience of others point straight to there being some unanticipated state that the driver-ethernet combo can get itself into. Maybe related to some sort of timing, or (more likely) dependent on what the other device is.

There are reports that Google Fiber has a warehouse-sized testing facility with every conceivable consumer device, and includes things like microwaves and washing machines (large phase-controlled brushed motors). Maybe Mikrotik needs to go shopping?

15

Remember the CRS310s with non-working Ethernet ports after booting into SwOS? This isn't new, and it points to a serious management issue that's leading to declining standards. We all make mistakes, but making the same mistake twice in so short period of time? It looks like they're not learning from their mistakes or drawing any conclusions about what needs to improve. This is sad.

16

Who knows how many devices will be returned to Mikrotik as defective because of this...

Wifi 7 release is not going too well for Mikrotik... Delays, delays, delays and then, half finished product...

I didn't test it but does microSD card support is working in beta3 ?

17

Even looks like the "we now use vendor wifi driver" did not work so well. Lots of wifi issues the last few years.

18

For me this goes beyond a simple quality issue.
This is a giant hole in the process.

They probably installed that FW without properly retesting.
And I am not talking about simply looking if it boots and emits wifi. Ethernet ports also need to be checked, rather basic for such a device !
Otherwise they would have noticed it !
From the limited responses we see here, we know applying 7.25b3 "fixes" that mismatch. And then it works.
So it has not been properly tested.
That's for me as a former test engineer a HUGE RED FLAG !

19

The only quality control MikroTik has is this forum.

I challenge anyone to prove otherwise.

And even if there were only one, or for some miracle more than one...
They should all be fired.

Releasing a peripheral onto the market where ethernet stops working at first reboot...
That really isn't normal...

20

I agree with you.

I tried to make a distinction between testing fw/ros by the R&D team and making sure it fixes existing bugs vs validation on the production line to make sure a device is leaving the factory in a working condition, which would have inevitably resulted in catching this issue early on.