Dear Santa, could you compile CC for GLiNet AR150

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.

tomj · 2016-02-07T21:51:45.000Z

Hi Klaberte,

I agree that everyone’s needs and wants are different. But one thing we as OpenWRT users have in common is that we want to be able to easily customize the device to our needs, as that’s OpenWRT’s forte.

A shell makes it harder, and a shell-on-a-shell makes it harder still. Even while I appreciate LuCI’s value in flattening the learning curve, once I veer off the paved path and try something that isn’t on the menu, LuCI makes things more complicated.

To give an example, I’m presently trying to configure another router (WDR3600) as a bridged-repeater, a fairly common need that is not available in LuCI. I’ve found a how-to for it. But it, as well as all of the how-to’s on OpenWRT.org, is geared toward UCI, not LuCI. Since I’m still using LuCI as a learning crutch, I don’t know how any change I make in LuCI will affect the changes I made in UCI. It makes my learning harder, not easier. OpenWRT is complicated enough as it is.

That’s the problem with all shells. They’re fine as long as you stick to the menu. But the whole point of OpenWRT is the freedom to customize, and no shell can accommodate. The GL UI is VERY limited, which means we have to use LuCI anyway for probably 90% of even normal uses. It also is packed with what would normally be called bloatware, ie specific menus for webcams and Chinese 3G modems. It compounds my above difficulty, as now I have to be on guard for GL UI’s interactions with LuCI, as well as LuCI’s interaction with the underlying tools. It doesn’t reduce complexity, but adds to it.

As well, I take issue with some of the “value-add,” such as loading AdBlock filter by default in the startup script. AdBlock is undoubtedly useful for certain use cases, but as with the webcams/3G modems, it’s bloatware that reduce the device’s performance and take up precious resources. It’s fine if these were available as packages, but they shouldn’t be loaded by default.

Again, the main audience for OpenWRT devices are enthusiasts who like to customize things their way. I do see LuCI as a necessary crutch for us noobs. But anything else, I would steer away from.

Please excuse the rant. Anyway, as with others, I’m fine with whatever Alzhao wants to do with GL UI, as long as a comparable clean firmware version is available. It’s all good.

HAPPY NEW YEAR EVERYBODY!