Dear Santa, could you compile CC for GLiNet AR150

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!

frietpan · 2016-02-07T22:07:16.000Z

@klaberte

with the script that rangerz posted the router can find and connect to known SSID’s automatically

rangerz · 2016-02-08T00:21:23.000Z

@tomj, GLI is a business. They, rightly wish to make their device as easy to use for as many as they can. You are not adequately considering the average, or below average, consumer who wants a router to be just a router. A good documented GUI is the only thing that will save OpenWrt. There is NO Luci docu, which is real poor. Lack of docu is a basic developer trait. If you look at my long and boring post here, http://www.gl-inet.com/forums/topic/wifimgr-tool-to-automaticaly-select-an-apstation-from-a-list-of-saved-aps/ you will find relatively substantial docu. I am exasperated with the lack of a basic package descriptions and install instructions for OpenWrt packages.

Your premise about OpenWrt, is FALSE

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.

Some people just want to USE a router. I came to OpenWRt because I wanted a VPN (config, not customize) and because DD-WRT made it so hard to upgrade and did not have any docu on their regular releases.

I do not know, nor do I really ever want to know CLI, but I agree it’s necessary for some things. I use WinSCP to configure anything that I can not do in the GUI, and to backup my config folder. If there was no shell for OpenWrt, I would be long gone. BTW, there is Gargoyle, Of Modem and Men and others. If you want to build your own you can have JuCi. https://forum.openwrt.org/viewtopic.php?id=59439 And yes, no shell can be expected to do everything the CLI can, but it should be able to do the major one, indeed all the ones the average user knows about. I agree that the OpenWrt docu is poorly written and inconsistent. You want to learn, have at it. I want to USE it. I have spent stupid time getting this thing to do what most stock devices do well, and probably would have suffered through their security issues, other than I need a VPN device for the road, and there isn’t one.

Alfie has not commented, but I suspect that the GLI GUI is not a GUI on a GUI, but just a separated GUI.

I have mixed feelings about the GUI. I mostly use the feature to connect to an AP, and it’s light years ahead of the OpenWrt process, and much faster (Though I think my post makes it even easier for know APs). I think that the feature set is appropriate for the general consumer, though I think that the DDNS in particular, needs to have an On\Off tool, and should not be displayed on the web page for all to see. It also needs real documentation. In general, addons should have a switch. Not to concerned about the extra 3mb of firmware or so on a 16mb device. Do you really think you will load that many more packages??

I would like to see GLI take a slightly different approach to firmware.
1 - Lock down an OpenWrt version of 15.05 for all devices, and unless there is a SP1 use it for all future dev until the next general release. At the same time, push patches to get to a point where the next release (15.05 SP1 or more likely DD) becomes the next offical GLI upgrade path…
2 - Offer the GLI GUI as an install option on top of the firmware (though it should be installed on delivered hardware). I expect that the install will add the needed OpenWrt packages from the above repository to support thier GUI functions.

This would allow GLI to streamline their GUI dev an a single base firmware for a year or so. Patches would be in trunk, do what you want, but no GLI GUI. If you get a new device, you can flash the non-GLI version of OpenWrt, and if you want then reload this, or upgrade it to the latest GLI GUi.

I would like to see a list of the packages in “clean”.