Hello All,
The SFWEM team have sadly discovered that MikroTik's Basebox has been updated to a new board revision (r2) which breaks compatibility with AREDN firmware. Until this compatibility issue is resolved, do not order a MikroTik BaseBox 5 - you won't be able to use it.
There's an OpenWRT thread tracking the issue here - if affects both the 2GHz and 5GHz models: https://forum.openwrt.org/t/add-support-for-mikrotik-rb912uag-2hpnd-r2/4...
The TL;DR is that the new unit appears to add a GPIO or other mechanism that keeps the WiFi radio powered off until it's flipped - and no one can find it, yet. There are also some minor changes to the flash layout as well.
Here's hoping it's fixed soon - we just ordered a bunch of these and it would suck to have to return and pay restocking fees on them.
I'd speculate the problem is the r2 board can't find information the ath9k wireless driver needs to properly start up. Mikrotik might have shifted this on flash to a different location. The comparison of system logs in the openwrt forum thread shows the ath9k driver is not getting to the step after finding the 'ART' (Atheros Radio Test) data it needs. This is data determined in the manufacturing process used to calibrate and ensure a quality signal for each individual device. For those interested, some details here:
https://archive.org/stream/AR93xxART2ReferenceGuideMKG15527/AR93xx_ART2_Reference_Guide_MKG-15527_djvu.txt
After it finds this data, we see the driver reporting this information in system log (which is not showing on the r2 boot up logs):
[ 9.956025] ath: EEPROM regdomain: 0x0
[ 9.956036] ath: EEPROM indicates default country code should be used
[ 9.956040] ath: doing EEPROM country->regdmn map search
[ 9.956057] ath: country maps to regdmn code: 0x3a
[ 9.956063] ath: Country alpha2 being used: US
[ 9.956066] ath: Regpair used: 0x3a
[ 9.969793] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 9.974704] ieee80211 phy0: Atheros AR9340 Rev:3 mem=0xb8100000, irq=47
I'll put the idea in the openwrt forum post...
Joe AE6XE
As per subject. I don't know how to tell which board version I have. Can anyone offer advice?
Thanks
Stan KR6CV
From my experience, the easiest method is to TFTP boot the node and see if the radio interfaces show up. If they do, great! You have a V1. If not, you have a V2 and are gonna have a bad day.
I should have a BaseBox 5 in my hands on Wednesday, assuming UPS delivers on schedule. Once that's arrived I'll see if I can't get you a full boot log, if that'd help?
The openwrt forum post had the dmesg boot log captured on a basebox with both r1 and r2 devices -- this available log should be sufficient.
Joe AE6XE
I have 2 Ver r2 units and I got them to flash and it seems to be working. Do I possibly have an earlier Version r2? Do the newer versions just not flash? I think my friend on Maui has this problem.
Jim NH6HI
The recent upgrade to openwrt 19.07.0, now in the nightly build probably addressed this issue? Did you install the nightly build image?
I have 1234-dcdd217 on mine but not sure what one my buddy used. I saw the post on the newest nightly build.
Any progress on this? The nightly builds are not finding the radio and have the missing _setup.default error.
There is a proposed fix for this issue in the openwrt community. It is a non-trivial fix. An author tried to submit on an old branch, was asked to submit it on the latest branches. Then it was discovered a general purpose fix for all newer Mikrotik devices was added in Nov. I need to check where this is at and what it would take to put in openwrt 19.07 branch that we are using.
The good news is the root problem is understood, the bad news is the fix takes time to work it's way in to our images. Openwrt latest is the new ath79 target architecture for mikrotik this has been added. It looks like the fix needs ported back the ar71xx target images that 99% of the entire openwrt community are still using. Let me investigate a little more to see if there's a way to accelerate pulling this into AREDN images.
Here's some of this history if interested: https://github.com/openwrt/openwrt/pull/2729
Joe AE6XE
Thanks for the background and some hope this device will be usable. My Bullet M2HP is unusable due to corrosion, so I bought this because of the power and detachable antennas. The Arizona Mesh is a long ways away, marginal even with a 24dB dish.
Sometimes there are multiple issues with new hardware revisions and confusion. I see another fix for the r2 basebox devices related to flash memory, created in January. Can someone try the images found here to see if there are less errors at boot (or get lucky and everything works)?:
"kernel: add support for GD25D05 SPI NOR. This chip is used on newer RB912UAG-5HPnD r2 boards"
[after edit] images removed at this link, see next post.
https://drive.google.com/drive/folders/1UCQDfaZ7de9e0Ga9921IUHRAuystpjTP?usp=sharing
Joe AE6XE
Looking for someone with a basebox Rev2 device to test the latest changes. The AREDN nightly build images as of Feb 26, 2020 or later should be used.
Specifically, a fix is now included to define a new flash chip in this device. The question to answer is if this device now works or there are still more issues to address. Please load the currently nightly build image, then attached a support data download (link at bottom of Administration page), if able, to this forum thread.
It is possible, the RF radio did not start up, because the calibration data necessary is in vendor data on this new NOR flash chip. The AREDN firmware and file system is installed on the NAND flash, a 2nd flash chip on this device. So it appeared the flash storage was intact, but it was not.
Joe AE6XE
I tried the 2/26/20 nightly (and the one yesterday with your call in the name) but found no happiness. So attached is the support file. I appreciate the work you and everyone else is doing to solve this.
Joe,
I have 2 international versions (934/r2). I got it to flash....The NOCALL-XXX-XXX-XXX is blank and the MESH RF is 10.0.0.0 & LAN 10.0.0.1 ... I tried entering in my own IP address, trird to save changes and then got the message CONFIGURATION NOT SAVED" "parameter in 'MAC2' in the '_setup.default' Does not exist
Not sure to go from here. I can send 1 if you like.
Jim NH6HI
With a Basebox 2, I have the same condition upon final flash as Jim describes, with no precomputed Mesh IP address (10.0.0.0) and LAN of 10.0.0.1. I used the nightly images from 2/27: 1366-5d672f5.
It's a new Basebox2 and the serial number has the suffix "/r2", so presumably it's the rev 2 board.
Steve, NU7B
If you can capture the support data (link at bottom of Administration page), I'll see more details. There may be multiple issues to resolve for this new hardware rev. Yes, ideally I need to get my hands on one to speed up the process to get the frimware working.
Joe AE6XE
Joe,
I have 2. Do you want 1 or both?
Jim NH6HI
only need 1. address in QRZ.
Joe AE6XE
You should have gotten a tracking number plus tracking for SASE to get it back to me.
Jim NH6HI
package received. Will be several days before I can look at.
Joe AE6XE
Have fun! ;>)
Just wondering if there's any update on this Joe. Hope that light at the end of the tunnel isn't a train.... ;>)
Always a matter of time, just how much time. I'm closing out a few things on the 3.20.3.0 release that will eventually get into a 3.20.3.1. Starting to look at a tplink issue, this basebox issue, a SXTsq-60 device, and some other things now that the release is out.
Joe AE6XE
This is the support data file from the nightly build dated 2/27, 1366-5d672f5.
Much Thanks,
Steve NU7B
Not surprisingly, this issue seems to have found it's way on to the RB911G-2HPnD-12S as well. I'm attaching the supportdata file from that, from the 1394 nightly build.
The root cause for newer Basebox devices has been found in the OpenWrt community. Mikrotik has changed how the WiFi calibration data is stored on the flash, so the data can't be interpreted. A fix has been submitted, however it is not accepted, because it was created on an old branch 18.06. When I apply the patch on the last AREDN build with openwrt 18.06, the image doesn't boot. There is reported work to put into 19.07.
https://github.com/openwrt/openwrt/pull/2729
getting closer, but not quite there yet.
Joe AE6XE
Appreciate your work on this. I can test it out here on my BB2_r2 when/if you need beta testers.
Steve, NU7B
Does anyone know if there is the same issue with the CURRENT Basebox5 units or is this just a problem with the New Basebox2 units. We are looking to purchase a quantity of Basebox5 / MTAD5G30D3PA MANT30 for here in the Hawaiian Islands. Don't want to spend a lot of money if it is going to be a headache.
Aloha & Mahalo
Jim NH6HI
If you are talking the RB912UAG-5HPnD, I'd presume so. Here in NW OH, we ordered and tested the RB911G-2HPnD well after this was a known issue on the 912 Basebox, and when we ordered a few more to actually install on a building, we were shocked to discover a new hardware revision. So, I would expect this being an issue with the 5GHz version is only a matter of time (unless the fix beats the hardware distribution channels of that version)
Mahalo for the quick reply.... Yes, RB912UAG-5HPnD are the ones I'm asking about.
Anyone bought one really recently?
Jim
Images now available
Thanks to the loaner hardware from NH6HI, I have successfully tested a patch that is working on a BaseBox 2. Mikrotik has changed the encoding method of the wireless calibration data stored on flash at manufacture time in newer firmware releases (it's not a hardware issue).
Because this patch affects all mikrotik hardware, this needs tested on a variety of hardware to confirm nothing else is broken before we moving the fix in to the nightly build. If you are able to help out, please post back the results for the model tested.
The images can be found here:
https://drive.google.com/drive/folders/19_PjuulNIcmPZed0hRWpBYbr6Z6FIBeI...
Joe AE6XE
Except for the tunnel client that do not connect to the server (more tests will be done this week when the unit is to be deployed at my friend's house), Everything seems to be working.
Support data joined just in case.
With further testing, it seems the WAN ip do not answer if DtD are active and Internet can not be reached for packages.
This is a private built image, there are no packages available for the moment, expected to fail trying to install. As soon as this code is put into the nightly build, then tunnels and other packages can be installed for further testing. At this point, we're just doing a "it's not dead on arrival" test to get into the nightly build. We need a quick check on hap ac lite and an LHG or LDF device -- the 3 image flavors.
Joe AE6XE
Just tried your firmware on my new version of the RB911G-2HPnD-12S and it ran fine. Also tried it on my previously working (last tested with 1234-dcdd217) from the nightly builds raw RB911G-2HPnD. Both pieces of hardware took a few reboots to load, and needed a hard powercycle after uploading the new firmware in order for them to actually boot. Without the hard reboots, they seemed to be stuck in an infinite boot loop. Attached are supportdata files for both. The new mANTBox is W8HHF, the old raw board is KC8UFV.
As far as my testing, I only did a quick test to make sure it could see another node on 10MHz -2. Didn't test DtD, or internet connectivity, and only used an uptime of 5-10 minutes each.
I suppose we should add the antBox to the support matrix :) . Apparently, the firmware can't distinguish between a basebox, antbox, or raw board.
Joe
We did add the RB911G-2HPnD a few months ago (I'm thinking Nov-Dec-ish) when me and MWS were working on getting that tested, because at first, we weren't getting the extra ham only channels. I'm not certain if it was in the production release, or just the nightly builds, though. The basebox is the 912. It does pick up these as a 911, the only differences I've seen between the two being no pci-e slot, and not usb port on the 911 (though solder points for both, along with space for supporting hardware are present)
When you say antbox to the support maxtrix, do you mean these? And do you think both 2.4GHz and 5GHz?
https://mikrotik.com/product/RB921GS-5HPacD-19S
https://mikrotik.com/product/RB921GS-5HPacD-15S
https://mikrotik.com/product/mantbox_2_12s
Just the 2.4 GHz - https://mikrotik.com/product/mantbox_2_12s
The 5GHz version uses the AC chipset which currently doesn't have a workaround to change the bandwith, and gain access to the ham-only frequencies.
And I just realized, I was thinking the support file in the firmware, not the hardware matrix on the website. Still could use being added there.
Received separate results of testing on hAP ac lite and an SXTsq lite 2. All 3 image flavors are working and sufficient to go into nightly build. The code has been committed. Look for new images on May 11, 2020 in nightly build.
Joe AE6XE
Joe,
Do you still need the Basebox2 for testing? If so, let me know and I can pick up another one for my project.
Jim NH6HI
see email sent spearate-direct.
Joe AE6XE
Big Mahalo Joe,
I successfully flashed my other basebox2 and it's on it's way to Maui. Thanks for figuring this out.
Jim NH6HI
I just thought that I'd put another update in here, I just received another mANTBox, and they're now on /r3. Current nightly build appears to work fine on it, though.
Aloha from the garden Isle of Kauai.
We just got a shipment of Basebox5 units that seem to have the same issues. They were shipped to the Big Island directly so I don't have one to send in. They don't work with the current stable build or the nightly build. Hope they aren't going to make a habit of this!
Guess I need to be a little more specific. The problem is the same as the basebox2's. After flashing you only get "NOCALL" and nothing following.
Any suggestions on where to go from here?
Jim NH6HI
Capture the support data download file and upload here. Let me also check the nightly build on the hardware I have and used to get working previously. I applied an early patch to aredn firmware that worked, then when we received the patch included in openwrt, had removed ours. The fixes are all supposed to be there... :) . let me confirm.
Joe AE6XE
Here's the file from Tony WH6DVI
Jim NH6HI
Jim, I confirmed, all the expected fixes are in the nightly build images for mikrotik -- tested upgrade to latest nightly build image on the basebox on the newer Mikrotik hardware.
In this data file I see an initialized host with name "WH6DVI-6-Ainaloa". it has tunnels installed and a couple of connections. it appears the node is setup and working. Were you able to get around the symptoms in basic setup to make the node functional? or maybe need this data from a different node?
Joe AE6XE
The guy sent me the wrong file ... Was from his Hap. The correct one is attached.
Jim
Pages