Dear Santa, could you compile CC for GLiNet AR150

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”.

tomj · 2016-02-08T01:33:47.000Z

Hi RangerZ,

I appreciate your input. Different views/philosophies notwithstanding, I respectfully disagree that OpenWRT devices in the present state can ever be geared for “general consumers,” and it is a mistake to try, as with the GL UI. Travel routers are a dime a dozen, and there are many user-friendly devices, not to mention being cheaper, and with stronger brands from mainstream vendors, for such “everyday” use cases. Not to say that one can’t use a GL router for such, but I’ll again assert that the main audience for OpenWRT devices are mostly enthusiasts, not the everyday user in need of a pocket router.

GL is indeed a business, and it should identify and focus on its core competencies, and not try to be all things to all people. What sets GL apart from the competition? Pre-installed OpenWRT routers, of course! AFAIK, it’s the only vendor on the market to do so. Then, concentrate and improve on that aspect, and leave the “everyday” routers to others more capable.

That said, we do agree that lack of good docs is a major constraint–not just for OpenWRT, but for GL devices. The docs section here is virtually empty. If GL wants for its devices to find a wider audience, then that would be the place to start. I also wholeheartedly agree with your other points regarding packaging & maintenance of the firmware.

Anyway, glad to exchange views with you! Differences are what make the world go around! It would be awfully boring if we agree with each other all the time.

frietpan · 2016-02-08T21:42:38.000Z

My opinion is in both camps.

I find that a router should just work for any standard use with a minimal need for IT skillset. Something that EVERYONE can use and provides a secure connection to the web especially for the everage guy who has a 9 to 5 job and no time to even think about configuring an SSID

But i also find that nothing should stand in our way to build things that nobody even thought about.

When you see the OpenWRT repository then it’s a shame that we need to dabble around in basic config shit that could be better documented and force us less to stat stuck in the same config loop afted doing a simple firmware upgrade. OpenWRT should make this DEAD simple. But i’m well aware that this needs developers so It is what it is… and i hope this eventually happens. (SOON??)

I also think that GLi does a lot to keep us happy with all our visions and opinions next to their own business goals. I’m sure they see that both paths have a business oppertunity.

The documentation is indeed one of the areas that needs improvement, lack of good documentation could cripple a business. the more customers you get the more people will ask the same questions. And those questions should all be covered in the documentation so that we can point there. And concentrate on new questions.

I’ve done a tiny bit of work on the OpenWRT wiki, and i must admit it is harder then i expexted to provide good documentation.

1 English is not my native language
2 I still need to learn and understand most of OpenWRT, so that makes it even harder to write a doc.

It is very hard to explain something that you not fully understand, in technical terms, in good English. In a organised manner. to name the basics.
And learn wikimarkup. and o yeah i also need to sleep.

So whenever you see an option to improve the wiki THEN DO IT. Even if it is just fixing a typo!!! Just fix it.

For GLi i think for some subjects even Chinglish would be fine. Then we could translate and correct it in good English to add to OpenWRT wiki, that then again can be copied and pasted back by GLi. into their wiki. (Or is that a weird proposal?) In my opinion we all would benefit and it also would work nicely as marketing when the GLi related docs on OpenWRT are better then all the rest. (If all of us manage to figure out a way that works for us)

yea, I make large assumptions. But hey I benefit from this, and I’m happy to share my idea’s back into the system.

It’s 2016 baby!!! New innovative ways might work better then doing things the old way. look at all of this OpenWRT stuff. It has more potential then all the standard shit. But it can be even more if we can ~~figure out ways~~ route around the obstacles.

So thank you all for being a part of this! Even if you don’t agree with a single word I just wrote.

alzhao · 2016-02-12T13:08:25.000Z

Nice discussion during our long New Year holiday. Really appreciate it.

We will be more than happy if we can sell with default OpenWrt firmware so we can just make hardware. But this is not the case. If a user get the router, plug in the power and Ethernet cable and he cannot find a ssid (the default openwrt firmware) or use the internet immediately, he will kill us.

Originally we just to make a simple UI, just change ssid and key, but we added more and more later, required by our users. Our main business, OEM clients, they just use their own firmware. But 90% of our individual users still need a ready UI. Only the top 10% hobbyist use clean OpenWrt firmware or compile his own firmware.

A question: How many hours have you spent to make an OpenWrt firmware work and configure the network settings? Don’t you think the opportunity cost is too high if you are not a developer?

Actually hobbyist give us priceless feedback and drive us forward. The only problem is, we cannot satisfy all your needs.

Docs are one of the most difficult thing to make. Believe me, you will not able to understand Chinglish.