Dear Santa, could you compile CC for GLiNet AR150

frietpan · 2015-12-03T13:47:15.000Z

Thing is that I’m trying to get the basic Chaos Calmer version installed (if that is possible)

I want to have the most stable OS release running. So that i can rule out bugs due to beta packages from trunk.

Im reading up on how the Release cycle of OpenWrt works, but it’s not yet clear to me what is the most stable release. I assume that BB and CC are supposed to be stable

and that trunk is beta, and can contain nasty bugs. My goal is to have a solid OS that i can rely on, that runs for at least a year without the need of a reboot, without bugs that eat up memory or loops that cause the SoC to run hot. The GLi firmware seems to run very reliable, but it’s not clear to me if i can rely on it.

When i use Debian then there is a clear Stable release and a Testing release

Ubuntu also has a Stable LTS vesion, and a less stable version in between LTS releases.

With OpenWrt it’s still not clear to me what is stable and what is beta. I assune that all of trunk is Beta software that can change by the minute and depending on what time you have grabbed it it can contain a bug in the snapshot. So that’s why i want CC and not trunk that is going to be a stable DD somewhere in the future. And since it’s not yet clear to me if my assumptions are correct i’m testing the water and pull my feet back when it feels cold.

I like to swim in warm water without bugs.

When use a router for myself in a non critical setup then I don’t mind that much, but when I set up a router that has to run for someone else, friend, family or customer, then I want a known to be stable OS to be taking care of business.

I also asked about this on the OpenWrt forum and there also seems to be missing some clarity.

There someone said CC is stable that there is no risk to brick a device. But that is to my no assurance to be stable as a router that you can give to someone 100 miles away. When there is a bug that eats up memory and the thing starts to crash after a month then it becomes a problem when that person starts to call for support.

Now I’m happy that the router seems very stable, and i did not have any issues, so thumbs up for that. But I’m looking for the Stable release that I can rely on. People use internet 24/7 and when it only fails for a few minutes then panic already kicks in. So for those people you want a rock solid OS release that has no serious bugs inside.

So thats the long reason why I asked Santa for a OpenWrt CC version. Thats to me seems to be a ‘frozen’ and known to be stable release without risky trunk development bugs. Once trunk is a year further and all the serious bugs are fixed and Stable, then it gets the name DD, but until then it is trunk and with unknown bugs.

Or… I assume that that’s the case…

Mainly because CC was released a few weeks ago. Released to me means. OK now it is stable. And that’s when I moved from BB to CC.

Still I will try the option that was suggested. But since it is trunk I don’t want to put this on devices for people that don’t have any knowledge of hardware and software, so I keep looking for a true CC.

I hope I’m not causing any confusion because I’m trying to understand it myself.

EDIT

https://forum.openwrt.org/viewtopic.php?pid=301958#p301958

That topic was recently updated, so it looks like I was making the wrong assumptions… Still this doesn’t really help to figure out what is a real Stable release. For AR9331 devices CC without trunk feels like a good choice.

alzhao · 2015-12-03T13:57:32.000Z

understand. Trunk may have problems because it updates frequently. Some bugs there causing problems. We have used AA, BB and CC and is satisfied with the stability.

The only thing is that I need to compile every package. Because for a firmware, you cannot install kernel modules if it is not compiled with the kernel at the same time. So, with the firmware from us you cannnot install kernel modules from openwrt. This is the problem.

frietpan · 2015-12-03T14:22:15.000Z

Ok is see, this clears up a few things thank you!

So for the encoder that should now work right? You did recompile those two kmod packages into the kernel. They no longer give dependency errors so that looks ok.

Although i don’t yet see how to make it work.

rangerz · 2015-12-06T08:15:53.000Z

So are you saying that a version of CC from GLI would be based upon all the fixes that are discussed in (the links in) this thread on OpenWRT OpenWrt Forum Archive and that this is a moving target? The packages would be the ones you save (create\compile) at the point in time you make the image file, and thus not the ones in the standard CC repository?

This post is related. 404 Page not found - GL.iNet Is it appropriate to submit the targets to OpenWRT for CC as well. That way if the devs decide to make a 15.05.1 that the AR150 (and other models) may get added to the CC branch?

I would think that it would make life easier for GLI if there was an official OpenWRT version that you could call stable as a basis across all products?

rene · 2015-12-06T08:31:44.000Z

Well, there is a stable version of openwrt cc1505 it is revision 46767 see git.archive.openwrt.org Git - 15.05/openwrt.git/commit

but this version does not contain the patches for the ar-150 but in a few months the “actual” state from the trunk source will be the stable version and so on

if u wanna go for a stable stable version u should go for bb1407

rangerz · 2015-12-07T00:32:13.000Z

I would think that it is GLI’s best interest to have their newest products running on the latest “stable” release 15.05.? As a customer, that’s pretty much what I expect. Not sure that 46767 is better or worse than what would be complied based on the links above. 46767 offers the ability to use the OpenWRT packages, the updated version I believe will not.

I do not know that there is a process to submit patches back that would basically allow a version of 46767 to be made available on OpenWRT. It seems the “next best” is what I am asking about above. My question is a clarification on Alzaho’s comment on 12/3.

I do not want BB, mostly because I want the OpenVPN GUI and it is not available in BB. But also in general do not want year old software (on a new box), and do not want Alpha or Beta either. I’m not even saying I do not want the GLI delivered product (GUI). I just think there should be an option.

I am thinking that going forward it might be a good option to offer firmware with and with out the GLI GUI at a given revision.

rene · 2015-12-07T02:11:40.000Z

Well it is not possible to use the most stable version of cc1505 simple because the router have been added in the source a few weeks ago and stable was released 3 months ago

u have to use the patch under GitHub - domino-team/OpenWrt-patches: Patches for OpenWrt for the stable version of cc1505 or have to wait…

gl.inet makes it own image with nice webgui and is supporting external packages i didnt see the problem there take a look at and see how much packages are compiled for the gl.inet firmware 404 Page not found - GL.iNet

if u wanna play with it like “hacking” it u should go always go for the trunk build if u wanna have a stable device go for the gl.inet firmware

i like the way how open the system is u could deploy any firmware and for the 6416 u could even go for images for tp-link703

rangerz · 2015-12-07T12:01:27.000Z

Rene, please use punctuation.

Are you a GLI Employee?

I have looked at the GUI, indeed wrote a post on it. You are missing the point of some of the posters. We want a clean, stock, substantially current version of OpenWRT with no GLI GUI for the device as an option and do not want, or can not build it. I would think that the same software that is used to build the 2.13 version should be available to compile a version with no GUI. My links are to the most current set of OpenWRT info and my question has still NOT been answered.

While many users want to hack, I do not. I want a feature rich product that I can use while traveling for business. The only real problems I have with the GLI GUI is that it is not documented and has a DDNS service with no integrated controls. For security conscious people these are problems, real or perceived, it does not matter.

You can not put 6416 firmware on an AR150. Read Alzhao post 404 Page not found - GL.iNet

rene · 2015-12-07T13:21:18.000Z

Hello RangerZ,

first i am sorry for not using punctuation, since english is not my native language it is very difficult for me to use correct grammar. i´m sorry!

But we can talk in german if you wish =)

Second, no i´m not a gl employee, but it would be cool to get on vacation in china.

But anyway, i understand the wish some people need a stable version but its not possible that way.

You could use nightly builds or compile the latest stable trunk by your own with the patch ,but keep in mind you could not install kernel modules since they need to be compiled with the same linux kernel as the latest stable version of cc1505.

it´s not gl.inet fault you have to talk to the developers of openwrt.

if u dont like the ddns service gl.inet offers you could easily deactivate it see here: 404 Page not found - GL.iNet

If you want to use another image based on a stable cc trunk with modifications, such as for tethering and modems you could use the ofmodemsandmen Firmware http://ofmodemsandmen.com/downloadsp.html

But i´ve got one question, do you think a naked firmware is “feature rich”? since you have to configure it all by hand in the console

i´m not sure but i think the securly firmware : GL.iNet download center is based on a stock image

alzhao · 2015-12-07T16:22:10.000Z

Our patches are in openwrt trunk (DD), sometimes they backport to CC1505, but that totally depends on openwrt developers. Even for CC1505, after release, openwrt developers update the code. Not very often but sometimes. That means they will recompile the whole repository of software packages and you need to reinstall the firmware. If you don’t, you will not able to install kernel package again.

What we can do is to compile a clean, with LuCI firmware from CC1505 and all the software/kernel packages. But that way, you still need to trust us that we didn’t add something in the software.

frietpan · 2015-12-07T23:36:56.000Z

I see my topic has triggered a thing or two.

Since A real CC doesn’t seem to be an option, a basic CC with Luci would be nice. Though the main reason for my initial question was stability. To have a router that can be given to someone and then just works for a long time without ‘beta bug issues’. It seems to be a lot to ask for since the answers that can be found on the OpenWrt forum on the topic are not all that clear either about how stable a stock OpenWrt release actually is. So it would be good if that could be cleared up before DD is released.

I’m not sure if it can be done, but to me the best option would be a CC release that does not have beta software from trunk. But with backported patches that can be considered stable.

I don’t have enough coding skills to estimate stability, I cannot see if there is beta software running, that’s why I started looking for a known-to-be-stable release.

I understand it is not possible in the way I initially had in mind, as Rene explained. The option that Alzhao just suggested seems a good one to me.

A clean CC1505 with Luci and all the kernel packages. If this rules out beta software and eventually includes backports. Then that sounds like a reliable solution for someone like me who still has to learn a lot about software.

For hacking I then would use the DD based firmware (in case some kernel package needs do be recompiled)
But for devices that I configure for others I then have a reliable release based on CC1505.

And then when the DD release arrives it all should come together.

DD then can be frozen as a reliable stable release for basic users. And trunk then is the developers repository. To end-users it’s important to have a clear difference between Stable and trunk/dev/beta.

And please don’t rush this, take time to figure out what is best for end-users. So the GLi front end will still be good to have as a package that we can install. It is a very user friendly interface.

klaberte · 2015-12-19T02:43:54.000Z

Yes, we understand that even if GLI compiles a clean CC w/ luci, we the users have to trust that GLI didn’t “sneak in” some additional code. Granted. For me (and apparently frietpan) this is fine.

My concern is not thinking that GLI cannot be trusted. It is that your closed-source code can have problems that are much less likely to be identified and fixed as compared to the OpenWRT final CC. We have already identified an earlier issue with passwords being stored as clear text in an earlier GLI GUI version.

Please compile the final OpenWRT CC with packages for use with the AR150. Many of us would use it and appreciate it!

alzhao · 2015-12-19T11:59:56.000Z

If we compile a clean firmware, we will not put any of our own codes there. So there will not be our UI.

But we will have a short Christmas holiday now. Hope it will not be too late to compile this after Christmas.

frietpan · 2015-12-19T13:25:22.000Z

A clean firmware will be very welcome, I already ordered a few new AR150’s (so in a week or two I will be able to test)

I’m not worried that code is ‘sneaked in’ since that sooner or later will be discovered and would not be in any-ones best interest. I’t very good to see that GLiNet does an effort to take this route and listens to our feedback. Everyone seems to want something else and all with good reasons. GLi has to find it’s way trough all our wishes, their own vision, and also what OpenWrt gives us all to work with. Form my point of view it’s most important to have a reliable release. (without the risk of having beta bugs)

In some cases reliabillity is more important then features. But for other cases modern features are important. 4G, VPN, etc. but they introduce a higher chance of bugs. So that’s a trade-off. If i need to configure a router for someone who does not need 4G or VPN then it’s good to have a clean CC available and also have the ability to use the HUGE OpenWrt repository in a reliable way. It’s this repo that makes OpenWrt so damn beautiful. And a repo relies 100% on a reliable core.

Please correct me if I’m wrong.

Have a good Christmas! Knowing that it there is a CC version coming soon that’s good enough for me.

@klaberte: “Please compile the final OpenWRT CC with packages for use with the AR150.”

What packages do you mean by this?

Switch, USB?

klaberte · 2015-12-21T10:34:35.000Z

@alzhao, I strongly agree with what frietpan wrote. We understand that if GLI compiles the pure OpenWRT final CC, there will be no GLI software/GUI provided. That is exactly what we are asking for. Since you’ve provided patches for DD, someday that will be final and stable, but who knows how long that will be? We want something clean and lean today (OK, after Christmas is OK. <grin>)

@frietpan, perhaps I’m mistaken, but I thought that it was advisable only to use additional packages that were compiled with the same settings and toolchains as the base firmware. So, the common practice is to compile not just the base firmware, but the few hundred packages at the same time. Perhaps I’m wrong. If the .ipk files at the repository (Index of /chaos_calmer/15.05/ar71xx/generic/packages/) should work with the base firmware compiled by GLI for the ar150, then that is all we need GLI to do.

frietpan · 2015-12-21T19:25:35.000Z

Once there is a CC for the AR150 then it instantly becomes the most interesting small OpenWrt supported router, and it could be interesting for the sales in the long run.

GLi seems to be the only one (?) who uses OpenWrt and do their best to adopt to the culture of GPL while still keeping things going on the industrial level. And yes OpenWrt uses a GPL licence that has to be satisfied, but there is also an industrial principle at play that also needs to be satisfied. So both sides have to give and take and re-model until everyone is happy. From PCB till end user there are many steps and they are very different then from software to end user. And it all has to dance to different cultural music and morph together into a new-age choreography. The art of modern tech indusrty.

- YouTube

alzhao · 2016-01-04T12:33:27.000Z

Here are the clean firmware with Luci, for AR150: GL.iNet download center

The clean firmware is available for AR150, 6416, AR300 and Domino. Check the folder of other device to find the firmware.

frietpan · 2016-01-06T05:20:34.000Z

T H A N K Y O U

tomj · 2016-02-06T23:56:01.000Z

>Here are the clean firmware with Luci, for AR150: GL.iNet download center

alzhao, is this any different from the below, aside from lack of GL UI?

http://www.gl-inet.com/firmware/ar150/v1/openwrt-ar150-2.13.bin

Speaking as a OpenWRT noob, I would add my agreement with some here that I very much dislike the added GL UI, even though it supposedly makes it easier for me (noob) to use the device. It’s a kludge, being a shell upon a shell, with parts of it irrelevant (webcam) or useless (Chinese 3G modems) to my use. As with others, I would much prefer a stock option w/o it.

Anyone who willingly buys an OpenWRT device already knows that it’s not geared toward total noobs, and any noob (raises hand) would have to climb the learning curve. A “starter” shell can’t help.

Anyway, I’ll have to wait for my next AR150 to show up, having bricked my present one. Have also ordered a FTDI USB-TTL cable to have serial access, to hopefully debrick the existing unit.

klaberte · 2016-02-07T01:04:53.000Z

Tomj,

The GL-inet UI does more than make it easier. Perhaps its best attribute is that it allows you to reset the modem to factory conditions (e.g. when you are arriving at a new hotel) and then configure it from your phone. Stock Openwrt does not have wireless on, so there is no way to configure it with a phone after a reset. Whether or not that is an important use case for you is up to you. For me, I’m using the AR150 as an AP in my home, so I prefer no added UI. RangerZ has another use case.

Also, likely you haven’t bricked the AR150. You need to put it in u-boot mode. I’ve asked alzhao to make a new video for the AR150. Perhaps you could ask him as well and it will move up his priority list.