Ohh also I somehow managed to get my packages working again. I don't know exactly which one did the trick but I manually reinstalled opkg and wget along with a dependency that wget required and sure enough I can install any package that is part of the repository now.

Edit: Actually disregard this post. they are just the packages I installed manually, I was unaware that once a package is installed it will show up in luci as an available package when you use the search function

(Last edited by jvquintero1021 on 28 Dec 2016, 00:24)

@davidc502

Once again, thanks for the good work!
I think you need to take a look at the latest r2685. I believe opkg is broken. Just like @anymouse617, I have difficulties installing packages like shadow-useradd, luci-ssl etc. At first, I thought the packages are not included in the repos but they are. opkg would not install them instead complain that they are not available. Downloading the packages and installing is also very difficult as their dependencies are not easy to resolve.

I had to revert to the earlier version which doesn't have these problems. Please consider including luci-ssl in the next and future builds.

Thanks!

r2685 works fine except can not install vnstat.  No big deal, will wait for next release.

Appreciate the understanding.

r2695 has been uploaded and opkg has been tested and is working. 

Cake is built into this build. I have saved the .config, so it should remain moving forward.

sysupgrade with the -F option seems to still be required. I'm not sure who pushed out the change that caused this issue, but apparently needed more testing before committing.

crypto.mk  no longer contains any reference to cesa << Unknown reason why. I was going to put it back, but need to do some reading about what might have changed.

Those seems to be some of the outstanding issues.

**EDIT** I did not archive r2685 images.  Will keep the packages out there for a while, but will eventually remove them.

(Last edited by davidc502 on 28 Dec 2016, 15:57)

Need a little help. TIA.

Linksys WRT1900ACS v2

A while back, maybe 6 weeks or so ago, I installed one of davidc502's builds. It seemed to be working okay but I messed it up. There is some learning going on here. Needing things back in operation, I did the 3 REBOOTS method to take the router back to stock firmware.

I now have more time to investigate giving it another shot. It isn't clear to me how to proceed.

I am operating with stock (Linksys) firmware. Since the time that I installed davidc502's build, a new Linksys firmware was released. I installed it from the Linksys partition I was booted from.

I've noticed in my reading that setting settings to default is a good thing but in my case, how would I do that and is it necessary? I don't even know if the davidc502 build is on the other partition now since I installed a new stock firmware.

Any help for this newb is appreciated.

@nick59

I don't believe so. If you were on stock and flashed a new stock image, then stock images would be on both partitions.

I agree,:)

@nick59

If you flashed/upgraded a Linksys firmware while on Linksys firmware, you'll have the newer version of Linksys FW on one partition and the older one on the other. If you flash the new Linksys firmware again, then you'd have the latest version on both.

There's an option in the Linksys firmware to reset to defaults, but that would only affect the Linksys FW on the partition you are currently using. Its not needed before flashing LEDE/Open-WRT anyway.

If you want to start using @david's LEDE builds, simply flash the appropriate factory.img file (not the sysupgrade.bin file) from @david's website using the Linksys web interface at 192.168.1.1 (if you've recently ran LEDE, you may need to clear your browser cache to get the Linksys interface to load correctly).

Once you do that, you will have @david's build on the primary partition and the Linksys FW on the secondary/backup partition. When @david releases a new build, the best way to upgrade so that you keep the Linksys partition as a backup, is to use the method that you'll find at https://forum.openwrt.org/viewtopic.php … 59#p347359.

If you use the sysupgrade.bin file and flash from Luci or SSH, it'll overwrite the stock Linksys FW and you'll have @david's older build on the secondary partition, and the new build you just flashed on the primary.

@david
Latest build is working perfectly. No issues installing packages. Also, I was being lazy and simply flashed the sysupgrade.bin from Luci. Worked fine. Didn't have to SSH and use the -F switch.

(Last edited by starcms on 29 Dec 2016, 06:38)

@davidc502  Thanks for the latest build and your hard work.  Working fine with my 1900AC v1 and installed vnstat without problems.  Thanks again.

I just flashed the new build r2695 and I'm happy to confirm that it's working perfectly. opkg is back in action. Thanks to @davidc502 for the quick response. I also want to say thank you to all contributors for your excellent work.

I love this forum

(Last edited by omostan on 29 Dec 2016, 08:49)

r2695 is running smoothly on my 1900ACS v2 as well. Thank you David!

So far the new wifi driver is working well on r2695.

Any wifi driver issues out there?

Thanks for all the kudos!

David

@starcms
@david

Thanks for the help. I'll report back.

@daivd, wifi driver seems excellent.  Probably the best it's been since work began on it (even for those on 3200acm who are still seeing issues, the issues are getting smaller and smaller with each update).

Btw, I love the new stats on your website.  Averaging yesterday and today's download stats, Shelby still takes 1st by a large margin; Rango comes in second (big, big surprise there); Caimen and Mamba tied for 3rd (big surprise for Caimen for me; I thought I was one of the few with a Caimen); and Cobra (surprisingly to me) in last.

Also, I can't believe the number of packages downloaded!  Last night it was 1704 downloaded yesterday.  Today is only half over and it's at a skyrocketing 9880!

(Last edited by starcms on 29 Dec 2016, 20:30)

What I'd like to do is to add a top 5 packages downloaded statistic. It would be interesting to see what some of the most popular packages are.

I'm on vacation, and should be unplugging, but find it hard to do so... lol

**EDIT**

This morning I fixed https not working correctly. It would re-direct users back to http, which isn't helpful. It now stays on the https track no matter where you go on the page. Would like to get a certificate that has a valid CA, but it will cost $ to do so.  Might take a poll to see how many want SSL/TLS, and see if people are willing to donate OR if they are just willing to use the self signed certificate it currently has.

(Last edited by davidc502 on 29 Dec 2016, 20:56)

I'd venture a guess to Luci-SSL or Luci-ssl-openssl, and it's 3 depemcies. That's 5 right there.  Also possibly joe for an editor in SSL.

(Last edited by starcms on 29 Dec 2016, 20:55)

Hi David, looks like uhhtpd-mod-tls did not make it into this build - could you add it please?  Thanks

Downloading http://davidc502sis.dynamic-dns.net/sna … vfpv3.ipk.
Unknown package 'uhttpd-mod-tls'.
Configuring px5g-polarssl.
Collected errors:
* opkg_install_cmd: Cannot install package uhttpd-mod-tls.

You want to use Let's Encrypt. It's free and the way to go...

Accorting to https://wiki.openwrt.org/doc/howto/secure.access uhttpd-mod-tls hasn't been needed for Luci-SSL since Dec 2013.  I installed Luci-ssl-openwrt and px5g allowed uhttpd to generate the certificate and key just as it should.  Everything working perfectly.

Edit: "Note that uhttpd-mod-tls is not needed after r35295 in Jan2013. But you need a ustream-ssl wrapper library on top of the actual SSL library (polarssl, mbedtls, cyassl, openssl). Luci-ssl includes by default libustream-mbedtls (since Dec2016)."

But since OpenSSL and the openssl libustream ssl wrapper is is already included in @david's builds, I find it simpler to simply install Luci-SSL-openSSL and automatically all requried depencies (such as px5g) will be installed with it.  That simple.  If you use Luci-SSL as opposed to Luci-SSL-OpenSSL, you'll have an extra dependency installed automatically (libustream-mbedtls).

(Last edited by starcms on 29 Dec 2016, 22:42)

Thanks for explaining because I searched in menuconfig and couldn't find it, so I went out to the lede trunk packages and couldn't find it there either. 

I'm guessing someone ended up taking it out completely.

That's how it's set up... using let's encrypt and though it says it has a open CA, in my case its not using one.  Will look again and see if there's anything else I can do to get it to work.

Hi @davidc502,

thanks for your builds.

Do you have a bug tracker?

I noticed a couple of small issues since I installed your build for wrt1200ac and would like to let you know about them.

One is that there is no diffutils package available, which I often use to compare config changes.

Also, /sbin/fan_ctrl.sh doesn't seem to be useful on wrt1200ac, as this device doesn't have a fan. That script wouldn't work anyway, as it tries to determine the CPU temp by looking at /sys/class/hwmon/hwmon2, which doesn't exist on wrt1200ac. There's only hwmon0 and 1.

Plus a couple of further issues which I have forgotten. :-(

Let me know if you want me to report here, or if you have a bug tracker.

Kind regards,

Ralf

I made a few more edits to the post to clarify things further.  If you do decide to start including Luci-SSL-openSSL in your builds, it has at least one dependency (px5g, and possibly 1, maybe 2 others), but I'm sure your build-env should automatically determine that and include them, just like when you do opkg install.

Regardless if you decide to include Luci-ssl-openssl, I would highly recommend setting 2 default settings for future builds for those that are new to LEDE to ensure maximum security and avoid potential access from the WAN to SSL and Luci.

First, configure dropbear from the default unspecified interface to the LAN interface. 

Secondly, in the uhttpd configuration (/etc/config/uhttpd):

-Change the default settings of listen_http and listen_https from the default of (I think it was) 0.0.0.0 (which allows WAN access to Luci) to 192.168.1.1.  Also comment out or remove the second listen_http and listen_https of '[::]:80' and '[::]:443, respectively (which also allow WAN access to Luci over IPv6).

This is how mine looks:

config uhttpd 'main'
        list listen_http  '192.168.1.1:80'
#      list listen_http  '[::]:80'
        list listen_https '192.168.1.1:443'
#      list listen_https '[::]:443'

Because of the default configuration line " option redirect_https '1' ", the user isn't forced to type in https://192.168.1.1 if you decide to install Luci-SSL-OpenSSL.  It'll automatically redirect to https://192.168.1.1.  And if Luci-SSL isn't installed, that line doesn't auto-redirect to https:// (because like I said, option redirect_https '1' is the default setting in your builds now and obviously they don't redirect to https:// (which wouldn't work and return a 404 if Luci-SSL isn't installed).

Edit:  Also in the uhttpd config file, in the config cert 'defaults', if you start using Luci-SSL, you'll want to change the " option commonname to 192.168.1.1

option commonname '192.168.1.1'

The country, state, and location options are of no importance, but I have them changed to country US, state LA, and location WRT-Router (just because I'm OCD).

Obviously, the browser is going to bitch about the certificate not being source in the trusted root certification authorities store (the same error your website is now giving when accessing via https://), but if the codename is not set to the IP/address used to access the router, it will bitch about that, and even if you pay for a certificate from a trusted source, it still will bitch.)

Lastly, there is a way to manually install the certificate generated by px5g by uhttpd when using Luci-SSL into the trusted root store, so it doesn't give any errors, but it's a long, complicated process that would have to be done on each PC/phone/tablet/etc, so I've never bothered trying.  But again, if the codename isn't set to 192.168.1.1, you couldn't even do that.

One very last thing.  You can see in the uhttpd config file that the certificate is stored at /etc/uhttpd.crt.  For some reason, I've noticed that on some people's builds of LEDE, a very old certificate is created there when building (even if they don't have Luci-SSL or Luci-SSL-OpenSSL included in the build).  So if you decide to start including Luci-SSL-OpenSSL in your builds, make sure that no certificate is being build/included at /etc/uhttpd.crt.  A new certificate will automatically be generated on first boot using the config present in the uhttpd config.  But if an old certificate is present, a new one won't be generated.

(Last edited by starcms on 29 Dec 2016, 23:26)

Maybe you forgot to configure your web server to deliver the certificate chain?

I've started using it only some weeks ago, and I'm using it on multiple domains with no issues.

I see that you also use Apache. If you send me your certificate-related config snippet via email, I could have a look...

Kind regards,

Ralf

I bet there is a configuration error in how the certificate is being generated.  The common name of the certificate is li1293-151.members.linode.com.  I'm pretty sure it should be davidc502sis.dynamic-dns.net.  But even if there is a configuration error, Windows is still saying "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store."  So that makes me think that Let's Encrypt isn't a trusted certificate provider.  Or possibly it's throwing that error because the certificate configuration is incorrect.  Because when I visit https://letsencrypt.org/ , the certificate is fine, no errors from the browser, and if you look at the certificate, the CN (common name) is set to letsencrypt.org.  But also, the certificate on letsencrypt.org is generated by TrustID.  Your cerficiate is being generated by members.linode.com (which isn't a trusted certificate source).

So it looks like two issues.  One with the configuration.  And two, does letsencrypt.org actually generate certificates which are from a trusted certificate source.

Edit: Also for a trusted certificate, the country, state, and origination name must also match what was provided (not simply the common name if you are generating a simple non-trusted certificate for Luci-SSL)

Yours are currently O = SomeOrganization, S = SomeState, C = -- (C is for country).

The concerning thing is that according to the cert, even the issuer has identical values listed.  Also, the cert was issued to li1293-151.members.linode.com instead of to davidc502sis.dynamic-dns.net, and it was also issued by li1293-151.members.linode.com as well (which isn't a trusted source).

(Last edited by starcms on 30 Dec 2016, 01:37)