You are here

GL-iNet B1300 Firmware rejected

34 posts / 0 new
Last post
M0GXB
GL-iNet B1300 Firmware rejected
My GL-iNet B1300 (Convexa-B) works fine with the factory OpenWrt system, and behaved as per the documentation, but I cannot install AREDN because the firmware image is immediately rejected due to some kind of verification that it is doing*. Conveniently it reports the SHA of what it read which is exactly correct - so data corruption is not the reason.

So what am I supposed to do to make the firmware install?

* The instructions say "Verify that you uncheck the Keep Settings" but do not say where this option is to be found. I did not see this option anywhere before I started the download. Maybe it appears after the verification is passed?
 
K6CCC
K6CCC's picture
Correct file???
What is the exact file name of the flash file you are using?
That error usually indicates that it is the wrong file.
 
M0GXB
I just had the same problem
I just had the same problem with the GL-iNet MT1300
On the B1300 I used file: aredn-3.24.10.0-ipq40xx-generic-glinet_gl-b1300-squashfs-sysupgrade.bin
On the MT1300 I used the file: aredn-3.24.10.0-ramips-mt7621-glinet_gl-mt1300-squashfs-sysupgrade.bin
I would be very surprised to hear that they are the wrong files.

I get the impression from other sources that OpenWrt made itself incompatible with itself over firmware loading, so presumably there is a nightmare of update sequences required to fix it. This really needs to be in the installation notes and is disappointing that this was allowed to happen.

Not a great first impression for a new user!
 
M0GXB
Fixed one of them
I have got the MT1300 working now. Quite a hassle. FYI it is not exactly new but not very old either, maybe 2 years old.
I upgraded using the manufacturers own latest system which worked OK.
I was then able to make it upgrade to AREDN which it complained about but worked.
Then I lost contact and had trouble getting it started. Not sure what this is about, and am not sure just what it takes to get it restarted - some messing about with power and reset button etc. Eventually it burst into life but the DHCP did not work.
I had to reboot the PC to get DHCP working so eventually I got the new home page, which I did not like because it does not fit on the screen as well as the old one, and in live use the screen will be much smaller.
QUESTION: The TIME setup gave me all the options I might want EXCEPT setting the actual time. How am I supposed to do that? It seems to have great expectations of exotic time servers or GPS that might do it - but in my real use I will want to tell it the time and have it serve that itself.
We would expect to be able to use networks in isolation from the public Internet.
BTW My PC did not want to use the AREDN WiFi connection due to poor security it claimed. I hope that is just a configuration issue or else might be a problem.
Now I will have a go at the other one before risking the more complicated-looking Ubiquiti beams I have.
=====
So I am looking at options for high-speed data for use by RAYNET-UK. Due to various groups either investigating options or using different systems I was wanting to see how interoperable different systems might be and maybe even get a consensus on what would be good. Our group controller has an older AREDN demo setup and I have another GL-iNet device with OpenWrt on it but which seems to have dropped out of favour with AREDN in spite of having lots of RAM.

I chose the GL-iNet devices because they happened to be available cheaply and had the most RAM and I had used one before, and according to your notes they should have been the easiest to get working.

 
M0GXB
B1300 still a problem
The procedure that worked for the MT1300 does not work for the B1300.
Even with the manufacturer's upgrade the AREDN firmware is still rejected.
It says its version is 4.0.0 which is less than the MT1300 version.
 
K7EOK
              in my real use

              in my real use I will want to tell it the time and have it serve that itself.

If you search on the forum you can find quite a lot about the time shown by the node.  In reality, as AREDN is designed to serve HTTP services the time really does not matter, but it is nice to have correct.  Time is not stored in non volitile memory so the device has to find system time with every power cycle.  We have several time servers on our network to chose from or there is internet sometimes availabe.  In the long run doesn't actually matter as your services will run on the clock and time of the pc on the LAN provided by the node.

               We would expect to be able to use networks in isolation from the public Internet.

Yep.  That's the point of AREDN.

           BTW My PC did not want to use the AREDN WiFi connection due to poor security it claimed. I hope that is just a configuration issue or else might be a problem.

I see you're in the UK.  I don't know anything about the rules for amatuer radio in the UK.  In the US we are not allowed to encrypt communications sent over the air by us amatuers, so AREDN has been constructed to only allow HTTP and not HTTPS.  All you do is instruct your browser to accept HTTP and away you go.  Yes, it is less secure.  However not every Tom Dick and Harry are supposed to be on a closed amatuer radio operated data network.  You choose to join or not to join knowing these limitations.  If this is not acceptable to you, and if you are allowed to encrypt, perhaps you should look at another system than AREDN.

               I was wanting to see how interoperable different systems might be

AREDN is NOT an interoperable system.  It is a stand alone backup system for use when internet and other coms fail.  It is not substitue or backup internet access.  There are some exceptions but pretty much it does it's own thing and ignores all other data networks.  Tunnels are just a VPN to get connected over internet where there are no rf links available.  But the traffic is not internet compatible ...

AREDN is quirky and strange at times.  However, it does work pretty well when you stop fighting it's strange quirks and go with it.  Chuck's comments about your starting with Gl-iNET devices are spot on.  You could not have picked more inappropriate things for a first node to test with.  I suggest get something easy to use like a pair of Nanostation or a CPE-510 (stick with 5ghz) and put them a block or two away pointing at each other and learn with normal kit.  AREDN firmware is written to run just fine with 64 or 128 Mb memory, all the device is doing is being a router at most ... so long as the device is not sunset it will be fine with less memory.

Cheers, Ed
 
M0GXB
Thanks for the clarification
I had misunderstood AREDN slightly.
> In the US we are not allowed to encrypt communications sent over the air by us amatuers, so AREDN has been constructed to only allow HTTP and not HTTPS
The UK rules are much the same but there are some exceptions. In an emergency situation UK amateurs can carry messages for certain specified organisations and use encryption, and this may be required . There is also a general requirement to have secure access to remote unattended equipment, which might preclude using the old and weak WiFi (which I seem to remember is hackable by modern fast equipment so quickly that it is barely worth asking for the password).

QUESTION: If you had a gateway to an alien network on an AREDN mesh, does the AREDN routing system effectively make it impossible to use it, even if a client node knew the AREDN IP address of the gateway? If it can reach it, can the AREDN DHCP be configured so the client doesn't have to know where the gateway is? I can now see why this might be hard.

On the original topic: I have logged the B1300 problem on Github. There is no software bug to fix I think, I am guessing that it just needs someone to rebuild the B1300 firmware. I will test it for you when done. As it stands it appears that the B1300 is effectively not supported hardware.
Can I also suggest that you add a "star rating" to the hardware support table because there is nothing I saw that says that my choice of using these devices was a bad idea (they are not for long range use, just expanding local Wifi coverage).
 
K7EOK
M0GXB (name?) ...
M0GXB (name?) ...

So back to the beginning.  You had problems installing the firmware on a device.  This happens now and then.  The firmware is written and maintained by volunteers and there are alway new issues that crop up every time the device mfgs decide to change chips or firmware on their end.  This forum is full of examples of things being reported, debated, and eventually solved.

What are you actually trying to do with AREDN anyway?  If you want wifi coverage inside a building just use what we call part15 wifi devices and move the LAN traffic ... its not necessary to have AREDN to do this.  You can go easily short distance building to building keeping factory firmware as well.  AREDN exists because a section of the rules here allow licensed amatuer radio operators to operate in these frequency bands with higher power than consumers are allowed.  So ... we can create a long(er) distance rf network for our em coms if we use the AREDN firmware.  If you want to evaluate AREDN I urge you to look at an acutal outdoor rated device with some actual power and see what it can do.

At a location/station .... once the AREDN network has delivered traffic to a router, it can be passed locally as LAN via cable or part15 wifi so that part is fairly easy. 

The other part of this is you started looking at the firmware right during a major update and ... stuff happens.  So reporting the issues with your devices will help the developers.  The devices I suggested for testing are not very expensive and are outdoor rated, then only take 10W power so you can rig up a few portable stations easily and try things out.  Chuck, Orv, or one of the people who are better informed might tell you some folks near you who have AREDN working and might be a good local resource including some fixed locations you might be able to connect to with the right equipment.  73, Ed
 
M0GXB
I am just trying to setup and
I am just trying to setup and run an AREDN network across the room, just to get actual experience of it,. I have some Ubiquiti long range devices which I bought a while ago but at that time OpenWrt was unhelpful with them as the signal indicator was not supported making setting up a narrow beam so hard that the RAYNET group using them told me that they flashed them with the manufacturer firmware to set the link up and then flashed the OpenWrt system for the mesh - which worried me as it was not clear how many reflashes they would take (some types of flash memory have extremely small number of rewrites possible).

The B1300 problem is clearly due to some past snafu with OpenWrt. I guess it just needs the .bin file to be recreated to fix it. I am happy to help test the result.

I have designed both hardware and software handling Ethernet traffic so I may know something of the packet level but am less familiar with the higher level protocols around these days (long ago and written in machine code on a DSP).
George.
 
K7EOK
Hi George, I guess the
Hi George, I guess the question now is if you are trying to figure out if AREDN is worth doing.  That depends on if the services (http web browser based) appeal to you.  In your case I'd suggest you re purpose one of your existing Gl-iNET devices to access a tunnel into the mesh to see what the user experience is like.  You do not have internet access, and the choices of services is somewhat limited as there cannot be internet dependencies (for emergency use when the internet is out ...).  You have to ask locally for a tunnel from a mesh that is active, or from the US or another country in Europe where you can access and play with the services.  The tunnel is a temporary connection to learn about this so you find out if you want to go further, but won't survive a coms failure.

You won't learn much by making a network from one corner of the room to the other as there will be nothing to use on your network of two devices, and you can do that with a cable.  The Worldwide Mesh Map is not necessarily correct but it doesn't look like you have many people to connect to via rf in the UK but someone else can suggest ideas.  My 2 cents.

Cheers, Ed
 
K6CCC
K6CCC's picture
Time might matter...

In reality, as AREDN is designed to serve HTTP services the time really does not matter, but it is nice to have correct.

That's not entirely correct.  With Wireguard tunnels, the time must match between the two ends - as I recall within a few minutes.
 
K7EOK
Oh yeah ... Wireguard
I forgot about that one.  But in that case ... set both tunnels to internet time servers as ... you won't have a tunnel without internet access on both nodes.  So not really a problem so long as you coordinate both ends which of course you have to do anyway.  I think from the posts M0GXB hasn't yet constructed a network where there could even be a tunnel ... yet.

Ed
 
K6CCC
K6CCC's picture
WireGuard and time server
Correct, that it you are using a WireGuard tunnel, you must have Internet so using a Internet time server works fine.  I ran into that when I first moved to WireGuard.  At my house I have no RF connectivity to anything, but I do have a stratum 1 time server accessible via AREDN.  At my office I have two Rocket M5 nodes that connect to two different mountaintop nodes, and also via tunnel to my house.  I originally had them set to use my time server at home.  When I changed the tunnels to WireGuard, all was fine - until the first reboot.  Since I beta test almost every nightly build, reboots happen regularly.  After the first NB update, the tunnels would not connect.  With some local help, found out about the time issue.  Changed the NTP source for the work nodes to an Internet based time server and all was well after that.

 
M0GXB
Time sync sounds like a nasty problem.
This seems very disappointing as not having an accurate time server is exactly what happens in a disaster situation. There is far too much that relies on GPS these days - just for getting the time. I would have hoped that a network like AREDN would be able to connect up without accurate time as this is also a reason for failure of public mobile networks.

Just how accurate does the time have to be for Wireguard - and why does it even care?
 
w6bi
w6bi's picture
Tunnels in AREDN
George, AREDN is primarily intended for local RF links - tunnels are a relatively late adoption, and while they're fun to use, should not be relied on in disasters since they use the Internet for linking.

The nodes themselves don't use timestamps for anything except log files.  Wireguard allows for a time difference of up to 180 seconds before the periodic handshakes between ends fail.

Hope this helps clarify things.

73
Orv W6BI
 
M0GXB
Can you not use tunnels over RF links?
I thought they might be useful to link two separate networks that perhaps do not want to join up too closely (although obviously not if they need accurate time).
K6CCC
K6CCC's picture
The nodes are connected -
The nodes are connected - regardless if it's a tunnel or an RF link.  Putting a tunnel of an AREDN RF link would only add more overhead to the link traffic.
 
K7EOK
Still makes no sense to me
George,

An AREDN network is a network.  It is meant to be RF based.  Tunnels (VPNs) only exist to allow people to join an AREDN network when no viable rf path exists.  Tunnels are a VPN over INTERNET.  If you have rf connections, you don't duplicate with a tunnel as this makes HUGE problems with traffic routing.

You say "they might be useful to link two separate networks ....".  What separate networks are you talking about?  Two AREDN networks?  Other networks?  AREDN is not designed to move traffic from other networks or the internet ... in other words you do NOT use AREDN to move non AREDN traffic.  AREDN is not the tunnel for other networks ... tunnels can be used over INTERNET to patch AREDN users together.  NOT the other way round.

Again ... I still don't understand why you want AREDN at all.  It sounds like you want to fit a round peg into a square hole.

Ed
 
kf7yrs
GL-Inet Aredn FW
I've had a few GL-iNet AR300M16 that would not load Aredn FW via the usual method.   It has been a while, so I don't remember the exact language but the Aredn FW would not pass a verification test and would not load.   I got around this by using the optional/alternate user interface (Luci ?) available in the advanced settings of the GL node.  This interface had the option to "Force" the FW upgrade.   I forced it and it worked fine,  I've done this about 3 times with no hitches.
M0GXB
Thanks, I will give that a go.
I was assuming that the firmware installer did its check before installing so it would be impossible to bypass it.
I will try that and then I might get an actual mesh network to try out.
I don't know if it is just me but I find there is a lot of "easy when known" stuff in the documentation. If anyone is bothered I could make a list as the trouble with this (affects all I.T.) as that once you do know stuff it is hard to know how a newbie will see it all. I am endlessly looking up acronyms and other bits that was obviously known to the person who wrote the documents. A lot of small details are skipped. This is why I feel the need to experiment with a toy network!
 
M0GXB
Not so easy!
My brain was offline.
I am not using the AREDN installer because I haven't got that far.
The "out of box" device has OpenWrt on it but with GL-iNet custom interface (rather like AREDN do).
I cannot find how to access LUCI even though I think it is on the system.
GL-INet custom interface downloads the .bin and then checks it - and it fails.
I am not sure exactly what is going on as the file that arrives on the system is 532 bytes smaller than the .bin file, but maybe it has stripped off a digitial signature as there is a .sig file that seems to be commenting on that aspect.
I know it thought the download was OK because it lists the SHA of it - which is correct.

Also I found a B1300 firmware dated today - sadly it fails too.

 
kf7yrs
This worked for the first flash of Aredn
This works to force a FW update on a factory-fresh GL-iNet AR300M16.  I'm looking at a brand new AR300M16 in order to record these steps.

Get into the GL-iNet with your password.
On the left there is a column of selections, click on "System".
In the "systems" category, click on "advanced Settings.
You'll get a warning, click on the IP address at the bottom.
Re-enter your password.
That will open the LuCi "Status" page
Across the top of the Status page, there are selections.
Click on "system".
There's a list of things you can do, at the bottom of the list is "Flash New Firmware Image"
Click on the blue "Flash Image" box to select your image.

I can't give you step by step instructions from here on, since I don't want to flash this particular router.  I remember the choices are obvious.  As I recall, the router will examine your file and reject it.  Then there is an option to force the update.  Someplace along here you can choose not to save your settings,  Make sure you DON'T keep your settings.  Force the update.  Good luck (and Merry Christmas!)
Lee


 
Image Attachments: 
M0GXB
Thanks Lee - YOU FIXED IT!!
I would never have found that procedure without your excellent detailed description - because at the angle I was viewing my screen the IP address thing to click on was so light in colour that it was invisible! So thanks again - it is working now. My next problem is that I only have one Ethernet reversing cable so I must sort out some hubs to get things joining up properly.
BTW I am finding that SSH always results in an instant connection rejected message without any prompts at all - unlike what the documentation implies. My SSH worked fine on the original GL-iNet firmware. Just curious, as Telnet works as per normal so I can now go exploring the guts!
Merry Christmas.
George.
 
kf7yrs
Try different computer, turn of anti-malware
Sometimes these things are resolved "magically" by using a different computer.  Also, if i don't turn off my Avast anti-malware software, everything seems to work fine but nothing really happens, no changes to the node.
K7EOK
Hmmm.
Hmmm.

On rare occasion ... our local group finds one device that simply will not accept firmware.  We try using different computers, different methods, different firmware packages (older), and go round and round until we decide that we simply have a device we can't use.  If your existing device still has the original firmware and works ... is it still within a return window?  Did you get another device to accept AREDN firmware?

Just saying ... and good luck.  Ed
 
M0GXB
Mesh not working
So having got 2 machines both working now, I tried getting them to form a mesh and they don't connect
Obviously I have made a stupid mistake, but what is it?
I have set each ones 5GHz radio to mesh mode and they are using the same channel.
Is that not enough?
One of them has its 2.4GHz accessing my LAN - and that is all just fine, the other has 2.4GHz turned off.
I am on the Ethernet LAN port of either of them but the mesh page is just blank and indeed I cannot ping one from the other.
So what does everyone fail to get right? I can't find any clues in the documentation.

 
K6CCC
K6CCC's picture
Are they set to the same
Are they set to the same bandwidth?
 
M0GXB
Thanks - didn't notice that!
I thought the channels had a defined bandwidth and it was channel aggregation that made it bigger.
This was a near disaster as there was only one choice on one of my devices and luckily the other could do that particular one.
This must make meshing nodes together really hard? What do I do if the next one is different again?

Now I just need to understand why I can't route to the WAN on the other device even though it works just fine if I connect directly to it. I thought the mesh links were like VPNs?

 
K7EOK
I assume we are talking now
Again ... we do not do a tunnel of the internet over AREDN.  You do not need to test moving internet traffic from your WAN over AREDN from one end of your room to the other end of the room.  AREDN is not the VPN for you to move internet traffic.  If you need to extend internet via rf use another method such as the stock firmware that came with the device.

Ed
M0GXB
Never mind the Internet...
...what about any locally attached services? I couldn't reach anything going across the mesh except the nodes themselves.
But worse!  I left the system powered while I had dinner, and on coming back to it the mesh link is gone.
So back to the start but with the nodes correctly configured - actually not the same, because the MESH page is showing itself. That is different to earlier when the mesh page was blank - before the two nodes managed to join up.

Update: it burst back into life when I pinged the other end, or it seemed to do that, unless it just took a long time to recover after restarting.
Update2: it has died again after a period of being idle. I think it was a reboot that fixed it as I can't get it going again.
 
K7EOK
What locally attached
What locally attached services?

If you can log into the LAN provided by the AREDN node you are attached to via cable or it's wifi, and you can see the other node ... YOU DID IT!  You now have a new AREDN network of two devices in one room.

What services?  You will NOT be able to provide services from your regular home or office network from one node to the other via AREDN. 

AREDN will not extend your home or office network, or extend the internet.

You have two brand new routers making their own LANs in the room with their totally different IP addresses that are NOT compatible with your home or office network.  AREDN services are an entirely different matter that we have not discussed with you.

Let's call your nodes A and B.  Cable in to A and get the home page at localnode.local.mesh.  Now do ipconfig or ifconfig and note your network address.  Then cable in to B and repeat.  These addresses will be different because each node is it's own router.  Neither will have 192.168.X.X addresses. 
M0GXB
Just to clarify...
By "services" I was referring to things like the admin tools although I could see how to write a service in LUA that would run on a node.
But the manual has a section that says this:
"Mesh to WAN
Enabling this switch will allow your node to route traffic from its Mesh interface to/from its WAN interface. This allows any device on the mesh network to use the WAN on your node, typically for accessing the Internet."

But the more immediate problem is that the mesh network seems to die after being idle for about an hour. Still investigating that problem.
 
K7EOK
Mesh to WAN
Mesh to WAN

Allow any mesh device to use local WAN.

Allow any node or device on the mesh to use our local Internet connection. This is disabled by default.

Please note ... Mesh to WAN is not recommended except for very unusual circumstances.  Leaving this on can seriously disrupt the network.  It's not usual.  It is default OFF for a reason!


George, I wish you well in the new year.  I'm going to back out of this conversation and perhaps others can step in and help you better.   Ed

M0GXB
Thanks for your help, Ed
I think you all misunderstand what I am trying to do. I am just trying to experience using this system to see what it can and can't do.
Unless EME works for it I can't see an RF link from UK to your network working and in a dire emergency I can't see tunnels working either, so I am looking at it as a stand-alone network which I would hope to be able to use locally and to join up other things too, including other groups using the same system.
What I really like is that you have a well defined package that will be the same everywhere. It is a real shame that the OpenWrt folks have blighted the firmware install process by creating a historic incompatibility which takes a bit of side-stepping if you run into it as is likely for the devices that already have OpenWrt as their basis (like GL-iNet do).

I now see that linking a node to an external network seems to mess up the mesh mechanism, - even without the WAN over mesh in use. I am getting all kinds of anomalies with the mesh in spite of the fact that for about 5 minutes I have had it fully working - I know this as it managed to load your map over my mesh network from my home Internet connection. But the mesh links strangely die for no obvious reason, including after a long period of being idle, so I guess some kind of routing issue must occur. It takes a reboot to fix this situation.

I have a load of very detailed technical questions as I haven't found a detailed technical description of how AREDN works. I resorted to looking at the filestore and worked some stuff out, but that has its limits.
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer