Any Linux that runs on gl.inet?

Technical Support for Routers
1

I recently had to co-bid on a project which required hundreds of devices such as the gl.inet routers. Gl.inet was considered but in the end, they went with another device which runs Debian.

We currently use openwrt but the problems with keeping up with that distro are too many. Packages become unavailable or the manufacturers change hardware revisions causing devices to get bricked. It’s a never ending game of catch-up. Plus, it takes time to convert the devices to our own custom openwrt version.

The better solution for us would be a device that simply runs a version of standard Linux which we know and can maintain for years to come without having to constantly change the firmware.

Wondering if anyone knows if devices such as the MT300N could run Debian for example or something else.

With the mention of 1GB NICS coming soon on gl.inet devices, I am especially interested in keeping an eye on where things are going with this company as you could be my source for ongoing hardware. We cannot afford all of the messing around we are doing with the hardware and need to settle on a platform that will work and keep working for us.

2

Are these forums empty? Doesn’t someone at gl.inet respond or do we need to contact support?

3

Sorry, I am afraid the device cannot run Debian.

Actually you can just use a stable release of openwrt don’t upgrade always. For software you need to make sure they works and don’t follow upgrade as well.

I think you can also try raspberry PI.

4

The raspberry doesn’t work for our needs. Keeping the exact same firmware is fine but the hardware keeps changing. I’ve not used enough gl.inet products to know if that is the case with this hardware. However, as far as I can tell, this is not such a big issue which is why I’ve also posted asking how to recover a unit. I’d like to better understand how one could be recovered when problems do happen since they already have serial pins soldered in.

This makes the gl.inet product more appealing to us along with the fact that 1GB ports are coming soon.

5

Hardware change is unavoidable. Each device will have one or two years life time before no one buy them anymore. I believe those running Debian have the same problem.

6

My task is to find something that will last as long as possible. The problem with openwrt being that converting the devices too often leads to problems and too much time being spent on having to maintain it.

7

Actually I don’t think it is necessary to main the software if you want the device works stable.

Of course, for quantity of just several hundreds it is difficult to find some hardware lasting for long.

8

Yes, this is the problem we are facing :slight_smile:

9

This is an interesting predicament you’re in, however I think the answer is simpler than you think.

OpenWRT is no different than other distros like Debian or CentOS. They are all standard Linux. They all run the Linux kernel, some more updated than others. If you have issues with OpenWRT, you’ll experience the same issues on Debian.

You can run Debian on OpenWRT devices with enough hacking, but you will end up in a worse situation than you would be with OpenWRT, which is designed for embedded devices.

Your choice of distro could actually increase/decrease the lifespan of your device, too. If you chose Debian, which isnt designed for embedded systems, you may face an issue in the future where your NOR chip or NAND chip has begun to fail because Debian has no optimizations for NOR/NAND flash IO.

The main problem with distros that are not designed for the hardware you are running is packages. Packages must be compiled for your CPU architecture before they can run, which is why Debian’s standard repository will not work on GL-Inet devices. Most of GL-Inet devices and routers in general run MIPS, not X86/X86-64 which is what desktops run and what the Debian standard repository is compiled for.

If you wanted to run what is your definition of “standard linux”, you will spend way more time trying to maintain your own cross-compiled repository which could be hundreds of gigabytes, and your own fork of the distro designed to run on your hardware of choice with the required drivers.

 

You might want to look into LEDE, which GL-Inet devices can run without any problems.

OpenWRT and LEDE have the only standard repository’s that are cross compiled to almost every CPU architecture you can imagine, including MIPS.

LEDE is generally more updated and designed for general embedded systems and not just routers.

 

Regardless of what distro you choose, as long as you choose a stable version of it, you don’t need to update the devices very often.

If you must update the devices often, you might want to consider forking your own version of the stable version of the distro you choose and the repository too.

 

I don’t really know what you mean by “converting the devices too often”, but if you mean flashing them with OpenWRT, you only really need to flash them once.

Adding an auto-updater shouldn’t be hard either, which can be used to automatically update thousands of devices at once without trying too hard to maintain them.

As mentioned in an above post, if something fails it is not very hard to recover the devices with the serial pins or the Uboot web interface on GL-Inet devices.

Uboot web interface is my preferred way to reflash firmware when I don’t have access to the firmware for whatever reason.

 

In any case, I believe that the solution to your problem is simply OpenWRT or LEDE. The firmware you create with OpenWRT and LEDE can be cross compiled for almost any architecture you can imagine. The only differences would be the drivers that the devices require. OpenWRT and LEDE can even run on X86/X86-64.

GL-Inet has device profiles in both LEDE and OpenWRT, so it is also very easy to create your own firmware for them by compiling it with the provided device profile. This will auto-select all of the necessary drivers to run on the target device.

10

Thank you for all this information. It helps a lot.

The main reason we started looking at different hardware was basically to find something that we could support in some easier way.
Once we have a full time person working on the devices, this will not even be an issue. That person will work with the other programmers that write the custom things we install on the devices. I have the task of maintaining the devices at this time because we are still in a development phase so cannot justify someone working on the hardware only just yet. Soon.

My objective was to try and find something where we didn’t have to rely on openwrt and its community which is a much too slow process of getting help when needed by using the forums. Also, most times, we cannot use trunk versions and must use stable versions because stable means they have ironed out any bugs/problems and everything has become the standard stable version.

Your points are very interesting but I was looking for hardware which already runs Debian or some other stable embedded Linux version. I didn’t know that Debian didn’t have an embedded version since I’ve seen so often people running it on all kinds of embedded devices.

Anyhow, at this point, there are two very interesting reasons that we’ll start using gl.inet.

1: You are coming out with 1Gb NICs which is another reason I had to hunt down new hardware.
2: These forums are becoming invaluable in trying to gather information, support and since we are working with the manufacturer directly, will be able to know the options we have and not have to guess. We will either need certain runs extended or buy existing in lots now and then but the plan is also to have our very own custom version built once we start requiring very large numbers.

My main concern with using gl.inet is needing to have devices in stock. It costs too much up front to order lots of units to sit on the shelf so we can ship them one at a time as needed. However, if gl.inet could/would ship directly from the US, then we could have them in a day or two, mod them as needed then ship them off to the user.

Having to wait weeks for shipping of just a few units would prevent us from using gl.inet.

 

 

 

11

@projects, I have been working in technology since the 80s and consulting to it since the 90s. Your comment “we cannot use trunk versions and must use stable versions because stable means they have ironed out any bugs/problems and everything has become the standard stable version.” could not be more wrong. Business put out products, including software products, on some type of schedule. OpenWrt has been roughly once a year. It does not really mean they are bug free. All that a Stable or Release version means is that it will not change and that the mass market can rely on some level of continued availability of the same features\functionality\support, etc. if they buy a product over the foreseeable future. Unless there is a entire rewrite, or major new functionality (ath10k maybe) it does not mean trunk is better or worse, though most believe so. All software is buggy.

If you need newer software then make sure you download all the packages that match trunk and you can support it like any other Stable build. Every night it changes. Sure, some particular versions are more buggy as some one introduced a new major enhancement and you may need to try a few versions until you find one you like (time consuming and expensive). I consider DD-WRT software all trunk. It changes every week or so. Don’t get me wrong, I am not advocating trunk over say 15.05.1 (or your own compiled 15.05.2 from git). It’s got lots more miles than any trunk release with very few people on a specific R-version.

The basic question that you need to address is is there something major in 15.05.1 that is broken or missing. If not put a stake in the sand and just use it until either OpenWrt or LEDE releases a new stable version. Then work on your next release if there is something compelling. The value you bring is your config and service, not the core OpenWrt version level.

Maybe OpenWrt is not the right product for you, but you need to be clear on what an embedded device is. It’s basically a single function device and it’s not restricted to any CPU or memory class. Embedded system - Wikipedia There are many x86 embedded devices, which can run Debian or other OS’s. Some of these may offer you more support options (paid or professional versions), but is also more expensive hardware (and no longer life cycles).

My expertise is in manufacturing and distribution, and I will suggest that you defer custom hardware until you can not find a box that will run your code. There is way to much cost involved. Look at some of these router startup projects that have raised 6-7 figures and then crashed and burned (go fund me, etc). Building your own does NOT guarantee a long life cycle (see below).

The better approach is to partner with someone like GLI who can take your variation of OpenWrt and install it on devices at the factory and ultimately drop ship it direct to your site. We call this Turnkey. It’s not an overnight process to build this relationship. You need to do this in house first, then slowly move pieces back to the vendor (load firmware, test, package, stock, deliver) as is reasonable. Ask yourself what your expertise is?

Today’s market is very dynamic. You need to keep a close eye on the life cycle of the components, either directly or through your vendor. They will get replaced with faster and cheaper ones every year. The only way to guarantee stock is to buy in at some level. It may mean owning a stock of SOC parts as opposed to entire routers, maybe both. Cases, PCBs, etc are commodity items and easily had. There are probably only a few key parts that turn, and hedging these is a good approach, again discussions to be had with your vendor. Even so, you need to keep an eye on the next gen product.

One of the nice things about the OpenWrt platform is the modularity. While I can not write a patch for my life, moving from one platform to another, should in theory, have little impact of the basic build of your end product (packages and config). Of course staying on the same platform (MIPS vs Atheros) is probably the least problematic.

12

The devs tell me that we can mod the software to fit anything, especially better if it is not openwrt. However, that said, all our stuff already works with openwrt so it’s fine, so long as I can find devices I can keep buying.

The problem isn’t so much openwrt, it’s the constant manufacturing changes of the devices. Worse, is when you buy a bunch of devices and suddenly find that the hardware or something was changed and now you brick some while trying to figure out what the problem is.

This is why I enjoyed going through the recovery test with the MT300N this part week, because until we have a full time person dealing with the devices, I need some way of keeping the device flow going, one at a time or dozens and sometimes hundreds at a time. It all depends on what the customer needs but we need access to them quickly. Having to wait weeks is a big problem.

I read somewhere that someone has gl.inet devices in the USA now so I’ll contact them to see if they will resell at a reasonable cost. If they mark them up too high, then I’ll have to keep using other devices until a real source becomes available in the US so we can get them quickly. I don’t see us being able to contract manufacturing for a year or two.