Since 3.22.12.0 and Nightly Builds

18 posts / 0 new

Sun, 01/01/2023 - 12:27

N1ATP

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

Sun, 01/01/2023 - 15:55

K6CCC

Are you on channels -1 or -2?

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.

Sun, 01/01/2023 - 17:27

k1ky

Channels 1+ seem to work?

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,

Sun, 01/01/2023 - 19:17

K6CCC

Nightly 2074 did not help

Mon, 01/02/2023 - 07:30

nc8q

I loaded NB 2074 on my AR300M16 and AR750

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

Mon, 01/02/2023 - 11:06

AB7PA

Current Nightly Build

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.

Mon, 01/02/2023 - 14:15

(Reply to #6) #7

K6CCC

Would the concept be the same

Would the concept be the same by using the TFTP load for UBNT and Mikrotik devices?

Mon, 01/02/2023 - 16:55

(Reply to #7) #8

AB7PA

Concept should be the same

Concept should be the same for UBNT and Mikrotik. Do a fresh "factory" install and go from there.

Mon, 01/02/2023 - 23:16

K6CCC

Having one node on 3.22.12.0 made -2 work!

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.

Wed, 01/04/2023 - 08:48

#10

KK4ZUZ

Last night's nightly build

Last night's nightly build appears to have fixed the -1 and -2 channel problems on my test devices.

Wed, 01/04/2023 - 10:58

#11

K6CCC

Concur. NB2089 fixed the -2 issue.

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.

Thu, 01/12/2023 - 21:24

#12

N1ATP

Daily updates

Got everything back running again - thanks everybody for all the good advise. New problem when attempting nightly builds 2145:

Firmware CANNOT be updated
firmware file is not valid: platform check image failed

Current Version: 2103-5214d35 Hardware Type: (ath79/generic) (gl-ar300m16)

Same message upgrading my GL-AR750.
Is it me, or?

N1ATP Knut

Thu, 01/12/2023 - 22:12

#13

K6CCC

Not you.

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.

Thu, 01/12/2023 - 23:19

(Reply to #13) #14

k1ky

.... Then upgrade

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.

Tue, 01/17/2023 - 21:59

(Reply to #14) #15

N1ATP

Well Gentlemen, the SSH

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

Tue, 01/17/2023 - 22:14

(Reply to #15) #16

K6CCC

Remember that AREDN nodes use

Remember that AREDN nodes use port 2222 for SSH - not trhe standard 22.

Wed, 01/18/2023 - 06:11

(Reply to #16) #17

nc8q

SSH connection is refused

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

Wed, 01/18/2023 - 06:24

#18

N1ATP

Gent's - Your guidance is

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

Amateur Radio Emergency Data Network

Menu SF

You are here

Since 3.22.12.0 and Nightly Builds

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

Since 3.22.12.0 and Nightly Builds