-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rocket 2M XW ethernet port not working after 3.23.4.0 upgrade #829
Comments
Thanks for this report. Unfortunately the Rocket 2M XW is the one version of the rocket we dont have on-hand to test (it's marked as "unknown" in the SUPPORTED DEVICES table). We had hoped it would simply behave as the Rocket 5M XW does, but clearly this is not the case. Is there anyway I can borrow this device as I've been unable to buy one? |
I have 2 of these devices. One is my test device where I load firmware to try before I send to the remote location. Ironically that test unit programmed and tested flawlessly which is why I am in this situation. The other is currently mounted locally (but can be removed) and still has 3.22.8.0 installed. I have no idea if it will fail or not if I try the new firmware. You can borrow either one or both. Unfortunately, the failing unit is on a tower which I am not allowed to climb. As a side note, I flashed a NanoStation M2 XW which also lost DTD connection after the upgrade. It was odd in that the nano showed up as a neighbor, but if you click on the name it would timeout and not show the GUI. Logging into the router and running arp and nslookup I found the dtd(Ethernet) connection was there but the URL had "dtdlink" prepended. Subsequent upgrade attempts eventually recovered the DTD connection to normal operation. I don't know if it is related, but wanted to pass it along. |
I have both a NanoStation M2 XW and and NanoStation M2 XM and both are fine on the release version; the DtD works correctly. And a URL with dtdlink prepended has always been there and is associated with the IP address of the DtD interface rather than the primary address (without a dtdlink prefix) which is associated with the Mesh (usually wifi). Sometime the addresses can take a while to resolve correctly, especially on small networks of only a few nodes as there's very little traffic which forces various internal tables to update themselves. Just for clarity .. are you saying you have two rocket m2 xw - and one worked fine but the other failed? Or you have three including a remote one ...? |
I have two rocket m2 xw in my possession- one worked fine and the other
is at version 3.22.8.0 and I have NOT tried to flash to 3.23.4.0. The
3rd rocket is the one that failed at the remote location and is not
currently accessible.
…On 5/9/2023 5:22 PM, Tim Wilkinson wrote:
I have both a NanoStation M2 XW and and NanoStation M2 XM and both are
fine on the release version; the DtD works correctly. And a URL with
dtdlink prepended has always been there and is associated with the IP
address of the DtD interface rather than the primary address (without
a dtdlink prefix) which is associated with the Mesh (usually wifi).
Sometime the addresses can take a while to resolve correctly,
especially on small networks of only a few nodes as there's very
little traffic which forces various internal tables to update themselves.
Just for clarity .. are you saying you have two rocket m2 xw - and one
worked fine but the other failed? Or you have three including a remote
one ...?
—
Reply to this email directly, view it on GitHub
<#829 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMEQETMGZCL2ZR6KYTL5M3XFKYSNANCNFSM6AAAAAAX3OOZMA>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
So:
Do I have this right? |
correct
…On 5/9/2023 5:39 PM, Tim Wilkinson wrote:
So:
1. Rocket M2 XW running 3.23.4.0 - working
2. Rocket M2 XW running 3.22.8.0 - working
3. Rocket M2 XW running 3.23.4.0 - not working (and on a remote tower)
Do I have this right?
—
Reply to this email directly, view it on GitHub
<#829 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMEQEVAGRAAT2LLS4LSWWDXFK2QXANCNFSM6AAAAAAX3OOZMA>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Fantasic. So .. let's essentially forget everything I've said so far. I though we were dealing with faulty firmware, but that's not the case as you have a device running 3.23.4.0 on a Rocket M2 XW. It's good to know that works. Now .. your failed device at the remote location .. how do you do the tftp install remotely? Are you using the remote injector reset? |
I travel to the site and use the reset button on the POE. I tried 2 different POE. |
Thanks. I think the next thing to try - if you're willing - is to do an tftp install on your test Rocket M2 to make sure that works as expected. |
I took my working test node (3.23.4.0) and did a TFTP install of 3.23.4.0 and it broke it just like the remote node. No pings and no GUI. I did a few more flashes with no success. I was able to get a TFTP install of 3.22.12.0 to work through a series of steps too numerous to verbalize here. I then tried another TFTP install of 3.23.4.0 and it broke it again. So I guess that fits the scenario of the failures on the forum where they were all new installs and not upgrades, if I remember correctly. Anything else I should try? |
Thanks for trying this. It's "good" to have this narrowed down. Now i need to get hold of a Rocket M2 XW so I can debug this. Nothing I can easily do remotely I'm afraid. |
It does mean you should be able to restore you tower node to 3.22.12.0 at least. |
I can send you one of the rockets if you want it. I don't need them
both right now. Another anomaly I noticed is that if I use the New
Software Selector web page and type in " rocket xw" and select
3.22.12.0, it gives me:
*aredn-3.22.12.0-ar71xx-generic-ubnt-rocket-m-squashfs-factory.bin*
But if I use the older stable firmware chart ( AREDN™ Stable Firmware
(arednmesh.org)
<http://downloads.arednmesh.org/firmware/html/stable_322120.html> ) it
gives me
*aredn-3.22.12.0-ar71xx-generic-ubnt-loco-m-xw-squashfs-factory.bin*
The latteris the one I usedand it works. Am I missing something?
**
…On 5/9/2023 9:59 PM, Tim Wilkinson wrote:
It does mean you should be able to restore you tower node to 3.22.12.0
at least.
—
Reply to this email directly, view it on GitHub
<#829 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMEQEQB2L4BFH5K2B5TFY3XFLY7PANCNFSM6AAAAAAX3OOZMA>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Well after much rummaging in the basement I seem to have found a Rocket M2 XW ... new in box too. Someone must have donated it. This should help things. No point in worry about the 3.22.12.0 versions and how the compare to the new; OpenWRT deprecated the ar71xx firmware a couple of years ago so we cant use that anymore. And they changed the naming convention for everything. |
So the Rocket M2 will currently boot using the Ubiquiti Nanostation Loco M XW factory build for 3.23.4.0. The Rocket build is based off the same code .. so now I just need to work out how it got broken. |
So this should correct make a Rocket M2 XW build (see the new nightly build) |
Great! Thank you. I assume there will be a change in the firmware
selector to allow select M2 or M5? The guys on the north side of Fancy
Hill will be glad to see this node back on.
73 Glenn WA3LAB
…On 5/10/2023 1:48 AM, Tim Wilkinson wrote:
So this should correct make a Rocket M2 XW build (see the new nightly
build)
#832 <#832>
—
Reply to this email directly, view it on GitHub
<#829 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMEQEUSYGKGNQLERM4RO5DXFMT4RANCNFSM6AAAAAAX3OOZMA>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Following up to see if this has fixed the problem? |
Sorry, I was away a few days. Here are the results:
Test unit was at version 3.22.12.0
I used the nightly build 20230510-ca49646(r20134-5f15225c1e) FACTORY
Flashed OK - RF and DTD connection OK
I then flashed the node back to to
aredn-3.22.12.0-ar71xx-generic-ubnt-loco-m-xw-squashfs-factory.bin
I used the nightly build 20230510-ca49646(r20134-5f15225c1e) SYSUPGRADE
Flashed OK - RF and DTD connection OK
On 5/12/2023 8:47 PM, Tim Wilkinson wrote:
I repeated the procedure on my other Rocket M2 XW with same results. So
I believe this build looks good.
Before I went away I was able to get the remote node flashed backed to
3.22.12.0. I will upgrade that node at a later date.
Thank you so much for your resolution to this issue.
Glenn WA3LAB
…
Following up to see if this has fixed the problem?
—
Reply to this email directly, view it on GitHub
<#829 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMEQET7FQBKUPH7CMCWUHDXF3K2HANCNFSM6AAAAAAX3OOZMA>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Appears to be fixed. |
I updated my Rocket2M XW from 3.22.12.0 to 3.23.4.0. After the upgrade, the node worked via RF, but the DTD connection was lost. I tried repeating the upgrade several times via the RF connection with no success. I then used the TFTP method to flash the factory firmware. Now I do not get any response via Ethernet at 192.168.1.1 or 192.168.1.20 and the node is supposedly in the No-CALL state so RF connect is not possible. After a long reset (>55sec.), I can ping the node at 192.168.1.20 fine. The TFTP progam completes OK. After more than 10 minutes I tried to ping at 192.168.1.1 or 192.168.1.20 with no response. I repeated the factory flash 3 more times with no luck. I have this issue posted in the AREDN Forum under the "Nodes" section, and it appears others are seeing this issue also. I also tried several times to flash earlier versions of factory firmware with no luck.
The text was updated successfully, but these errors were encountered: