Nanostation M5 Xw Firmware

[Niobe Hennigan]

Please always review the supported hardware matrix, we do not currently support XW 2 GHz devices.

Please see the following (very recently created, only within the past week) ticket requesting we add support for NSM2 XW [LINK REMOVED]

All discussion should take place on the ticket to move this forward.

Once an XW version of a hardware is available you should naturally expect all hardware you buy from that point out to be XW. It's a hardware refresh, you wouldn't expect to be able to buy a brand new 2014 model car rolled out of the factory fresh in 2017 you would expect it to be a 2017.

Perhaps reading the ticket you might understand a successful test image has been generated and you could followup with the dev team there to get a copy to help ensure they work flawlessly for the next person. Hardly sounds like the hardware is "useless".

Hi Bob,
Well, easy to "fix"... not as easy find the info without some bookmarks (we are working on that)

[LINKS REMOVED]

With these nightly builds: (no AirOS downgrade required)
You can load the AREDN nanostation xw "factory" firmware directly over AirOs 6.0.4 and below via the AirOS GUI.
You can load the AREDN nanostation xw "factory" firmware directly over any version of AirOS via the TFTP procedure.

If the flash does work properly for some reason, a TFTP load will usually work to recover it. (99% of the time)
However, with nightly builds be prepared to do TFTP and possibly use a serial console (attached to the circuit board) to do a serial recovery. (rare)

FYI: The nightly builds DO NOT WORK for the Bullet and PowerBeam 620 devices yet, IF YOU SKIP THE AIROS DOWNGRADE STEP. We are working on the fixes for those now. If you have a Bullet and PB620 AND want to use nighly, you must downgrade AirOS to 5.x FIRST (as you have been).

since you applied AirOs 6.0.3, that has a "signed" bootloader and will only load Ubiquiti firmware. You need to look on UBNT downloads site and find an "UNSIGNED" firmware (which will load any firmware) and load it. Then, start the AirOs downgrade.

Alternatively, you can load the AREDN nightly build on any version AirOS, as long as you load via the TFTP method.

Just go to Tools > Software Upgrade in the Elevated radios GUI and upload the Ubiquiti firmware file. After it finishes the flashing process, it will come back up just like it was before being elevated.

Upon, simply loading the UBNT firmware into the Elevate UI under the software upgrade window (as you would normally upgrade the firmware on a Cambium device), I have lost access to the device. Neither discovery tool will find it, and I cannot ping the IP at all.

It sounds like something went wrong flashing it... I've had that happen with quite a few ubnt radios recently (not just going between Elevate and ubnt firmware, but more so just updating the ubnt firmware to newer versions).

Observed for a NanoStationlocoM2 (model SWX-M2L, XM firmware).Recent OpenWrt compilations, on basis of kernel v5 , enumerate the ethernet interfaces differently.In /etc/config/network the iface name of the LAN port is eth1, not eth0 !When using the standard network setting the LAN port will appear active from a serial console but it relates to the passthrough port that is not present as a connector.So make sure that eth1 is used in the configuration files to reference the LAN connector.

There is (as of 2023/05) a unresolved problem with builds for Ubnt units with ONE ethernet port. Flashing a OpenWRT ath79 version after 19.07.10 will brick the unit. The last working version is 19.07.10 AR71xx. As mentioned in Ubiquiti Airmax M install the latest working buld and check your CPU with:

In my particular case this question relates the UniFi AP v2 but has more general implications.
One would imagine this to be a simple question to answer with a yes or no answer but not for Ubiquiti it seems.
I have been asking this question of Ubiquiti for about a month now after having problems loading OpenWRT 15.05.1 into a number of UniFi AP v2 units. The answers from Level 1 support (via their forums) has been, "It shouldn't be blocked" (hoping for a Yes or No), "It's ok in the latest release" (it wasn't), "I'll have to check with Development" (still waiting for that), "We don't support Third Party Firmware" (wasn't asking for support) or (the most honest) "I don't know". So I pressed for an answer, they escalated it to the next level but were very vague about what that meant. Oh and it seems Level 1 support at Ubiquiti have no SLA what so ever with the team they escalate to. They also have no way to communicate with them after an escalation. So the question has gone some where in Ubiquiti to be answered at some unknown time.
My own feeling is that they are avoiding answering the question as they took the excuse of the FCC rules relating to unauthorised changes to Wireless parameters that could be part of Third Party Firmware, to do this. Of course the FCC rules only applied to 5Ghz not 2.4Ghz Wireless and, as the FCC have stated, was not intended to be used as a reason for blocking Third Party Firmware. TP-Link got caught up in this too. So they cant say they are blocking.
I also think they are actively blocking. Firmware Images for the UniFi AP v2 have a different device type in their header but this is easy to cater for by either making changes in the OpenWRT firmware builder to generate a correct header (sorry not going to go into derail on that here) or by using a binary editor to change it manually. The real issue is that the Ubiquiti Firmware images have a new RSA signature section at the end. The U-Boot loader, already on the device and included in Ubiquiti Firmware updates, checks the signature and rejects images that don't have it, making TFTP updates not work. fwupdate.real used to do upgrades via the command line, also checks and rejects images without the signature giving the "Invalid FW Part 3 MAGIC 'END.'" message.
I'm interested to hear other peoples thoughts on this please.

Hello. Did you get OpenWRT or LEDE working on the UAPv2? I need to use this third party OS to make the device act as router, firewall and multi-AP, and with these new versions I can't. This is the worst thing Ubiquiti could do to these devices...

No. It's not really a matter of getting OpenWRT or LEDE to work, it's about Ubiquiti blocking the installation of third party firmware in the first place by checking that any firmware has the correct RSA signature before its even loaded. Ubiquiti wont even discuss this. Try asking the question on their support forum and see what they say .

One thing is support the 3rd party firmware and another, completely different, is not allowing me to install it at the ubiquiti devices. Are you telling me that Ubiquiti is restricting the 3rd party firmwares installation?

i've recently came up with an idea how to flash locked/signed firmware on litebeam ac gen2. basically you start flashing same ubiquiti fw that is already on device and interrupt the process, that leaves mtd partitions unlocked and you can flash another image to these using dd. more info in this GH comment-> -493658317

In the Firmware Tips section of the How-To Guide you will find assistance if you experience an issue uploading firmware to your device. The How-To Guide also contains a Virtual Machine Installs section for help installing x86_64 firmware images on a VM for a virtualized node.

For all of the device models discussed below you will be asked to set a static IP address on your computer as part of the install process. Various computer operating systems have different ways of accomplishing this, and there is a wealth of information in computer manuals, publications, and online resources to walk you through the steps for your specific computer.

If you choose not to use an intermediary network switch, then you will be responsible for making sure your computer maintains an active interface with the static IP address. You may need to power on the node temporarily in order for your computer to bring up its interface, but then immediately power off the node in order to follow the installation instructions for your model. Having an intermediary network switch eliminates these steps.

Depending on your computer operating system you may not have various command line tools available on your computer. The required tools are native to both Linux and MacOS computers. For Windows computers you may need to enable specific features or install appropriate programs as noted below.

These devices are programmed to download a boot image from an external source. Your computer will provide the Preboot eXecution Environment (PXE) which will give the node an IP address via DHCP as well as providing the firmware image via TFTP.

If you have a Windows computer you must install and configure a PXE server. The examples below use Tiny PXE which can be downloaded from erwan.labalec.fr. There may be other alternative Windows programs that accomplish the same goal, such as ERPXE or Serva. For TP-LINK devices you may be able to run a simple TFTP server such as Tftpd64 as explained in the TP-LINK section below.

The recommended method for installing AREDN firmware is to download and follow the appropriate Install Checklist below which matches your device hardware. Additional descriptions are also provided in the sections that follow.

Download the Install Checklist for Ubiquiti 802.11n devices. These devices have a built-in TFTP server to which you can upload the AREDN factory image. Your computer must have TFTP client software available. For more information, see the Preparing Your Computer section above.

Different TFTP client programs may have different command line options or flags that must be used, so be sure to study the command syntax for your TFTP client software. The example shown below may not include the specific options required by your client program.

c80f0f1006