You are here

Request for Testers for Ubiquiti XW Issues

 

 

Request for Testers for Ubiquiti XW Issues

 

Our need for XW testers is over. Thanks to the dedicated hams who volunteered to help tackle these thorny issues, we have completed most of the solution testing deemed sufficient to give us confidence in the applied fixes. There is still a bit of additional work to do before we announce a new stable release.

​We still need supporting information from our testers to be entered in the Bloodhound bug reporting system so that we can complete the verification. If you have tested the XW fixes, and have not yet updated the Bloodhound tickets with your reports, logs and data files, please do so as soon as possible.

 

The Development Team is currently focused on troubleshooting the Ubiquiti XW issue.  We believe there are likely multiple defects across multiple products which has made this a challenging exercise.

We are looking for testers willing to step out on the edge for us to confirm the existence of these problems across our supported Ubiquiti devices. 

Test Setup

You will want to have two devices in the test setup: one being a known good device (XM device) and the other being the XW device under test.  The XW device should have something connected to its Ethernet LAN port that generates some amount of traffic, although the amount of traffic is not terribly important.

The problems are easy to spot… the device’s Ethernet interface simply stops working. 

If these devices are being loaded for the first time, be sure to downgrade to the XW 5.5.x AirOS image first!  It would also be helpful to capture a “board.info” file for us before proceeding.  These are necessary to add full support for devices that haven’t previously been seen by the team.  We will keep a running report of these as they come in to avoid everyone needing to send them in.  Follow these steps:

While still in the AirOS:

1)Telnet or Putty into the node (default user is ubnt; password ubnt; default ip 192.168.1.20)

2)Run "cat /etc/board.info"

3)Send Joe, AE6XE, the output at AE6XE@aredn.org

 

Note that in the unlikely event you brick a device during these tests, you may be required to TFTP a new firmware image, or perhaps install a TTL interface to recover the device.  We will provide whatever assistance we can with this, but remember that ultimately you are out on the bleeding edge at your own risk here.

Okay, once your node is ready to load, go to the nightly downloads page [http://downloads.aredn.org/snapshots/trunk/ar71xx/generic/] and install the firmware on your device corresponding to the following table.

 

XW Debug Matrix

AREDN

Device

 firmware

   

AirGrid (XW) AG-HP-5Gxx

loco-m-xw

NanoBeam (XW)

 

   NBE-M5-16

loco-m-xw

   NBE-M5-19

loco-m-xw

NanoStation Loco (XW)

loco-m-xw

PowerBeam M5 (older Nanobeams)

 

   NBE-M5-300 / PBE-M5-300

loco-m-xw

   NBE-M5-400 / PBE-M5-400

rocket-m-xw

   NBE-M5-620 / PBE-M5-620

​Update Mar 16, 2017:  Do not attempt, confirmed Flash Driver incompatibility

      rocket-m-xw

Rocket M5 (XW)

rocket-m-xw

Rocket M5 Titanium (XW)

rocket-m-xw

 

Documenting the Occurrence

When the problem occurs, you should still be able to connect to the node under test via the RF link.  We would like a copy of the support file, found on the Administrative screen, to be sent to Joe at AE6XE@aredn.org .  

During the course of testing, please send the following updates, based on what you’re doing:

When you start testing:

I'm testing on Device 'X' with firmware image 'A' (e.g.  Rocket XW with AREDN-develop-138-9ec5e213-ubnt-rocket-m-xw-squashfs-factory.bin)

Weekly update:

I have been running for 'X' days with no symptoms on Device 'X' 

If you encounter the problem:

I found the symptom (ethernet port lock-up) and here is the support dump attached.

 

Thanks from the AREDN Development Team!

 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer