Hi Everyone.

Long time reader, first time poster.
I have an issue with the hardware. So before i go back to my re-seller, I figured throw my issue in the group here to see I'm not missing anything.

I recently bought a RBM33 and a R11e-5hact (and 3 acswim antennas) in order to replace my Hap-ac. Since the latter is often overloaded on the cpu-side.

After I received it, it was quite easy to set up. Put in the 5g part of the HAP-ac wifi config, and almost immediately had excellent connection. Actually about 10% faster then on hap-ac.
So I was pretty happy with the result.

But after a few days, clients were starting to constantly disconnect. Moreover, after rebooting the rbm33, they would refuse to connect at all.... (sometimes they did, but starting to disconnect all the time again)

Odd thing was that setting the channel to Ceee and auto-frequency. the clients connected without problem.
But not if manually choosing eCee and a fixed frequency. EVEN if it is the same as what the autoconfig would choose. (like eCee 5200Mhz)

The one error in the log would be the dreaded "unicast key exchange timeout", the one that exists in MT devices since 2007, but the cause was never clearly explained by MT.

Weird thing is that exactly the same 5G config WILL work on Hap-ac, Wap-ac and Hap-ac2 without issues. I tested this.
(Yes, I made sure no two devices were active at the same time )
And also weird is, that it worked fine for a few days on the rbm33, but now is impossible to run.

What I've tested is different power supplies, even PoE. Different Ros's (6.42.5, 6.42.6, 6.43rc32, 6.43rc42 and 6.43rc44).
Swapped around antennas, and changed orientation and location of the RBM33.

Also tested the individual chains.... And this is where it became even weirder....
All three chains work fine individually (turned-off the other 2), even gave excellent throughput (120Mbps on a 150Mbps 802.11n link).
Only chain0 (in winbox) was consistently a little off, about 75Mbps.
EVEN at the frequencies that would not work in 3x3 mode.
So all three seem to be at least "ok".
(Also chain0 in winbox seems to be chain2 on the R11e (silkscreen print), You can test that by removing the antenna, massive speed drop is resulting on that chain)

So, why CAN'T I choose the freq's in 3x3 mode, that I CAN choose on the other 5g MT wifi devices??
E.g. if I choose 5300Mhz eeCe on RBM33, it starts searching for radars (as it should), doesn't find any radars and then starts emitting on 5300Mhz. Inssider on a client-pc actually "sees" this peak come up, but clients do not want to connect.

It's like there is either a freq. stability issue or something alike, so a hardware issue...
Or the radardetection at some point thought it found a radar, and now blacklisted a number of specific options. (and refuses clients on that setting)...
Other possibility would be simply a bug in Ros.

In Ros, I also tried "superchannel" (with and without country), and manually setting power from "default" to 17, 20, 25 and 30 dbm.
Resetting to defaults, and then re-applying the script, and even netinstalling everything was tried.
All of it without any effect.

So... I'm baffled...
Why does it work on "autosetting"? This would seem to indicate that hardware is OK. Although chain0 was a little off....

Also, though the MT antennas are spec-ed 2.4/5g, this is probably just a compromise. 5g antenna's are optimally just a bit smaller (about half the size compared to 2.4g, tuned to wavelenght). Since acswim-antenna's were around since the time there was essentially only 2.4G, they are probably just 2.4g antenna's working "ok" for 5g.
But they work fine with "autofreq", and worked fine for days, so this fact is probably not critical. It just doesn't help either.

And.. if the 3 chains work fine individually but not (anymore) together, would point again to hw-issue (eg chain-interference). But this should be evident on autofreq setting too (???).

The fact that it worked fine a short while seems to point to something that changed inside the device. Either hw-defect, or some internal blacklisting...
But if the latter... Why??? And how do I reset this???
(I dismiss the external factor here, eg an existing radar, since hap-ac etc still connect just fine at exactly the same freq and settings)

Or... it's just some kind of bug that only pops up after a while???

I'm not sure how to proceed anymore. I tested about everything I was able to test.
But maybe someone in this forum has some good idea's...


Anyways... Thanks. Hope to hear from the forum soon.

Really?? No-one in this forum has a rbm33 or rbm11?

Not even a comment from one of the Mikrotik mods or techs?

We use m11g and 2xchain AC PCIe modules
But not 3 chain ones...

One think if you remove the antenna from the PCIe Modul in Operation, it is possible to damage it!
Also Operation without Antennas will damaged it!

Did you try the Xxxx Chanel Config too?

Hi Mistry7, thank you very much for taking the time to answer.

Let me first answer you questions:
I tried all five 20/40/80 channel widths, also the XXXX.
They all had in common that if you "manually" select a frequency, the AP starts scanning for radars, then doesn't find one, and then starts emitting on the selected frequency.
This can be seen by the windows tool inssider, and can also be observed by the freq-usage tool in another Mikrotik AP.
So the AP is transmitting!!! Just NO client wants to connect to it. (as if the AP does not accept connections somehow)
But.... if you select a frequency "auto", it works FINE. More than that, if you would manually select a frequency that was autoselected by the "auto" function, it stops working (!?!?!?!?!)

Also note that the chosen manual settings all work just fine on other Mikrotik 5G ap's, tested on HAP-ac, WAP-ac and HAP-ac2. So they aren't "impossible" settings.

Going to your point of not running without antenna attached.
I agree that running without is usually not recommended, as we do not have info about how the final stage of the wifi poweramp is constructed. Some designs allow for it, others don't.
But I had the problem BEFORE detaching antennas. I started swapping around antennas etc after the issues started, not vice-versa.
Also I did this with AP powered off, not live. They are really tight, so taking them off needs some finesse that isn't really possible "live".
Anyway, it showed some interesting facts.... Chain0 and 2 swapped, and the somewhat lower output of ch0. And I figured: "it doesn't work now, can just as well try this".
Conclusion however was that all three chains work OK individually (also on manual freq), and that the weird behavior was the same before and after tests. (so apparently I didn't damage the powertransistors)
(Normally if you want to test a wifi with only ONE chain active (in Ros), you can just disable the other chains in Winbox/cli. But I needed to exclude a defective antenna etc.)


But now my questions:
-Do you have any issues running at a fixed mode and frequency??
-Especially connection and disconnect issues?
-And what Ros and Routerboot version do you run?


Reason we want (have to) run fixed freq is that at 5G it is mandatory for AP to do a long radarscan. If you run the AP in automode, it can swap frequency at will. (as described in the DFS spec)
But before AP can allocate the new freq it has to scan again for radars, which takes quite long. During which all clients are disconnected. Simply unacceptable.
There is only one 80MHz slot that doesn't require radar scanning. But we need more AP's (and they can still 'see' each other). So the only way to do this is to select frequency manually and scan only once for radars at startup of the AP. (I know, this is not how the regulatory agencies intended)
This seems to work just fine for the AC hap's and wap's, so why not for the rbm33+ac???
Bug? Defect? Previous tests seem to point to the first. But I have only one set RBM+AC. So I can't confirm this

It's again 2 days later again, and still awfully silent....
Apparently this device is not yet a Mikrotik bestseller

In the mean time, I managed to score some other Ros versions to test with (6.43rc6, 6.43rc40 and brandnew fresh 6.43rc45).
And, hinted by viewtopic.php?f=7&t=134690&p=675207&hil ... ge#p675207, I also downloaded 6.41.4, as it seemed to exhibit many of the same problems.

Before I started up/downgrading I was at 6.42.6 (both Ros and Routerboot).
I first downgraded to 6.41.4, and after reboot, the device sprung back to life and clients starting to connect immediately after the radarscan.
But after I also changed routerboot to 6.41.4 too, it was back to an active ap with clients that wouldn't connect
(so ros 6.41.4+Routerboot 6.42.6 seemed to work)

Any other Ros I tried thereafter with it's own matching Routerboot did NOT work.
But what always seemed to work was Routerboot 6.42.6 with EVERY Ros6.43rc version....

Only problem with these combinations however is that sometimes these need a real powerdown to get WIFI going (so really no power to the board).
And sometimes the ether2 and ether3 leds are turned on without reason and without actually having a cable in them....
A simple reboot reboot fixes the leds, but kills the WIFI again....

A total powerdown will fix that too, but that is not how it is supposed to work....

This really needs attention by someone within Mikrotik.
Either the board is still buggy as hell, or I really have a defective one here...

Please Mikrotik, step in and take action.

And also, I again request users that use rbm11/rbm33 boards with wifi to reply to share their experiences and share their Ros/Routerboot (firmware) versions....
Maybe there is a pattern....

Regards

Ports lighting up when there's nothing in them or staying lit after cables are unplugged makes it seem like a more general problem, rather than one to do with the radio. The only time I've seen that behaviour is on an old 493G that was set to a custom CPU clock speed.

If you've purchased this board very recently, then you have a right to limited support by Mikrotik: https://mikrotik.com/support

I'd recommend generating a supout.rif file when the issue is present and sending it their way. See if you can catch that LED problem in the supout.rif too, since that might point directly at a defective board.

Hi,

Thank you again for responding and linking me to support.

It is indeed a recent purchase, but what I didn't know this was limited to only the first 30days after purchase

What I was actually trying to determine first was where the problem may be. Many of us are aware of the somewhat premature release of the HAP-ac2 and the resulting wifi issues.
And that was solved in later revisions of routerOS. Since RBM11/33 is also very new to the market, and apparently not sold that much, it may suffer the same fate.

If I would conclude my tests with "hardware failure", and then send it back to the dealer for replacement, and later it turned out to be a Ros issue, then there is only a lot of shipping back and forth of basically identical devices. I was trying to avoid that.

The Leds are indeed strange... But frankly, I havent tried plugging in a network cable in a port that had the weird leds on. If it just works, I couldn't care less actually.
But it was a clear symptom I noticed when running a Routerboot firmware "version A", combined with Ros "versionB". Although such combination was MORE stable for wifi.

Running a different clockspeed I tried too. But this board only supports "UNDERclocking". But it didn't help at all

Anyway.... I don't know why, but somehow the device is running fine now for 2 days straight... Go figure (?!?!?!?!). And the only thing that changed here is the heatwave we are having...
Maybe the device doesn't like the cold????

I'm going to be dropping the support a mail before it is to late, but I have to say it's kinda sad that no MT-official is monitoring these threads and picked it up along the way.

Thanks for the heads-up Krautzj, because otherwise I would certainly have gone over the 30d limit.

Regards