Using GL.INET GL-AR750 and GL-AR300 My entire network failed.
Using Nightly Build ...2074... I have Tunnels back up on the GL-AR750s, but RF Local Mesh on these devices are still not working.
Is it me or the firmware?
To clarify - I had 3 different hubs (GL-AR750) with tunnels and then 3 different RF Local Mesh networks with GL300s.
It appears the GL-AR750 have lost RF Mesh and the GL300s are essentially useless at this point.
Is this a known issue being worked on or ??
N1ATP Knut
You are here
Since 3.22.12.0 and Nightly Builds
Sun, 01/01/2023 - 12:27
#1
Since 3.22.12.0 and Nightly Builds
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Are you on channels -1 or -2? LOTS of failures on those channels with nightly 2017 and later.
Yes, It's being worked on and the next nightly is supposed to improve it.
We do have reports that these units work ok on Channels 1-11 with N-2017 - N2074, but have issues Channels -1 and below. We have seen success with networks using mixed earllier versions of firmware able to talk to the lower channels. Development team is aware and working on these issues,
Nightly 2074 did not help
Hi, Knut:
I loaded Nightly Build 2074 on my AR300M16 and it is linking at 144.4 TxMbps
with my MikroTik RouterBOARD 952Ui-5ac2nD.
I am using channel 1.
I also put NB 2074 on my AR750 and my AR150 and they also linked on channel 1.
This was posted from my Wi-Fi Client USB150 running NB 2074 over a tunnel.
73 and HNY, Chuck
Current Nightly Build firmware (since ver 2017) has synced with OpenWRT 22.03.2 (our upstream parent code), so the target architectures have changed. Once you upgrade to NB on a device like the AR750 or AR300M16 you can revert to previous firmware by using the GL.iNet debrick procedure and then applying 3.22.12.0 (for example). I've got an AR750 with NB 2081 linking on channel -2 @ 10MHz with an AR150 running 3.22.12.0. There are going to be some quirks with the new NB firmware because so much has changed with the migration to OpenWRT 22.03.2.
Would the concept be the same by using the TFTP load for UBNT and Mikrotik devices?
Concept should be the same for UBNT and Mikrotik. Do a fresh "factory" install and go from there.
Used the de-brick procedure on my GL-iNet AR750 (because it was the easiest to work on) to bring it back to 3.22.12.0. After it was working and meshing on channel 3, I moved it to channel -2. Then enabled RF on my hAP-Portable (Nightly 2074) and moved it to channel -2. Gave that a few minutes and it became stable with those two nodes communicating on -2. Then moved my RB-LHG-2nD-XL (Nightly 2074) from channel 3 to channel -2. Again, took a while to become stable, but it then communicated with the hAP-Portable and AR-750. Next was the GL-iNet USB150. As with the others, it took a while to get stable, but eventually it did. Next was to move the other hAP - hAP-at-Home (Nightly 2065) from channel 3 to channel -2. Just like the others, it took a while, but it worked. Last step was to turn off RF on the hAP-Portable (it's normal state). That has left the hAP-at-Home (nightly 2065), AR750 (3.22.12.0), USB150 (nightly 2074), and RB-LHG-2nD-XL (nightly 2074) all communicating on channel -2.
When I said that it took a while, let me explain that a bit. Before I began all this, I started a continuous ping from my PC to all five nodes involved. With each node, after moving to channel -2, I would see the pings come and go and in some cases very long ping times (up to almost a full second). It took almost 10 minutes for the pings to become fairly stable with most of the ping times under 10 mSec and only the occasional time under 40 mSec.
Last night's nightly build appears to have fixed the -1 and -2 channel problems on my test devices.
Concur. NB2089 fixed the -2 issue.
I went brute force. My 2 GHz network at home consists of five nodes (one normally has RF off) - two hAP lites (one normally RF off), a RB-LHG-2nD-XL, a GL-iNet USB150, and a GL-iNet AR750. I had reverted the AR750 to 3.22.12.0 which then allowed all four other nodes to operate correctly on -2. This included after turning off the AR750. So this morning the hAP-at-Home, USB150, and LHG-2nD were working on channel -2. The only connectivity to the network is via the hAP. I updated the LHG and USB150 to nightly 2089 and well before either of those had completed the update, I updated the hAP. Once the hAP completed, I was able to reach all three 2 GHz nodes.
Got everything back running again - thanks everybody for all the good advise. New problem when attempting nightly builds 2145:
Same message upgrading my GL-AR750.
Is it me, or?
N1ATP Knut
It's not you. SSH into the node and type this command: echo "#!/bin/true" > /usr/local/bin/firmwarecheck.sh
Gets around a typo that was in one version.
To expand on K6CCC's comment above. Once you issue that command and get a # prompt beck, you can then upgrade to the latest nightly. Issuing the command fixes the issue that was blocking the upgrade.
Well Gentlemen, the SSH connection is refused and generating a key is just beyond the limit of my networking knowledge. Hence, I have non-updatable system. I don't know if there is another option here?
N1ATP Knut
Remember that AREDN nodes use port 2222 for SSH - not trhe standard 22.
Hi, Knut:
Please show us your SSH connection command and the failure response.
gelmce@nc8q-mesh:~$ ssh -p2222 root@NC8Q-SXT5HP-175 root@nc8q-sxt5hp-175's password: BusyBox v1.35.0 (2023-01-03 00:24:21 UTC) built-in shell (ash) _____ ______ _____ _ _ /\ | __ \| ____| __ \| \ | |TM / \ | |__) | |__ | | | | \| | / /\ \ | _ /| __| | | | | . ` | / ____ \| | \ \| |____| |__| | |\ | /_/ \_\_| \_\______|_____/|_| \_| AMATEUR RADIO EMERGENCY DATA NETWORK ----------------------------------------------- 1) Research AREDN and choose a supported device 2) Download and install AREDN firmware 3) Deploy and enjoy the mesh ----------------------------------------------- 2173-45ac6c5, r20028-43d71ad93e ---------------------------------------------- root@NC8Q-SXT5HP-175:~#73, Chuck
Gent's - Your guidance is always helping me - port 2222 was the solution for me so I could SSH in and execute the command from K6CCC and realize the K1KY provided response prompt.
I thank you all for being so supportive when I am expanding my hobby knowledge to new levels.
N1ATP Knut