The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.
Hello Davidc502 and hello all, after quite a while i flashed with david's new ver of lede for my caiman. I read every day this thread and now i stumbled upon the problem about ssl certificate that i know you guys talked about.
now i read something to change in /etc/config/uhttpd file
option redirect_https '1' to '0' but it didnt change nothing.
Is this been solved or am I missing something. Thanks for any help...
(Last edited by moccolo on 8 Mar 2017, 12:07)
Did you restart the router after making the change to uhttpd?
Do you connect to the router on http://192.168.1.1 afterwards?
Did you restart the router after making the change to uhttpd?
Do you connect to the router on http://192.168.1.1 afterwards?
yes after restart i tried and got the same result. then i cleand all browser history and still the same. then i manually put http and now it works but it says not secure... dunno really what should be the by default
(Last edited by moccolo on 8 Mar 2017, 13:32)
adri wrote:Did you restart the router after making the change to uhttpd?
Do you connect to the router on http://192.168.1.1 afterwards?yes after restart i tried and got the same result. then i cleand all browser history and still the same. then i manually put http and now it works but it says not secure... dunno really what should be the by default
Hey there,
I was under the impression that Chrome will always say connecting to your router is "risky" because it's a self-signed certificate and not verified by a third party (unless you wanted to buy a third party cert from Verisign or something). I think this is the normal behavior. You can mark the certificate as trusted by importing it into your certificate store (Windows) or Keychain (Mac). Not sure how certs are managed in Linux. Once you do that, Chrome will at least let you connect without having to do the advanced > proceed anyway thing, but it will still show as insecure in the address bar.
This has been my experience; someone feel free to correct me.
yes after restart i tried and got the same result. then i cleand all browser history and still the same. then i manually put http and now it works but it says not secure... dunno really what should be the by default
if you look at your screen, you will see you are connected to the router via http, since the read https is missing from the address bar now.
You should no longer receive the 'self signed' or 'invalid' certificate error, since you are not using https.
But Chrome always displays 'not secure' for a http site, when there is a 'password' field present.
This applies to Lede/OpenWRT, since you land on the login page.
Once you do that, Chrome will at least let you connect without having to do the advanced > proceed anyway thing, but it will still show as insecure in the address bar.
Not if you generate the certificate correctly. For example, it will still show as insecure if the certificate is imported in your certificate store (so trusted) but not generated for the specific IP address from which it is being accessed (in the case of the screenshot there it's the ubiquitous 192.168.1.1).
EDIT (to avoid confusion from the above wording): This requires setting up a CA (import cert) and then generating a signing request to generate a cert for the router (this is the one that needs the correct IP reference). This isn't the place to run through the logistics, there are ample resources on the web that discuss this.
(Last edited by InkblotAdmirer on 8 Mar 2017, 19:36)
Hello guys!
So, it feel like it´s time for an upgrade now, for my wrt1900acs, since the last one was Davidc502:s sept 2016 openwrt code and there are no more of those - only LEDE. I tried an upgrade to LEDE with my current configs for Openwrt - it went straight to hell! -So I face the facts; to either stay with the version I have (that in fact works very well) or to somehow try to document every setting in all my current config and transfer them to the LEDE configs (looks like I probably will spend weeks getting them all to work)...
I realy don´t know if I have the time and patiance for starting all over again, and my family want´s Internet 24/7 (almost) - So I wonder if there is an easy way to convert my configs to LEDE before I jump on the "new train"?
-To say the least, I am a bit dissapointed - when everything finally works as it should have from the start (bought my router when it came out and it worked crappy). In summer 2016 (mr F release in june) it worked pretty good and with Davidc:s release in sept, I was happy. Now... back to squere one again OR stay with a release that´s getting old :-(
It´s not that I don´t appriciate all your excellent work - it´s just the way things have turned out (with Openwrt and LEDE) that´s frustrating.
Hello guys!
So, it feel like it´s time for an upgrade now, for my wrt1900acs, since the last one was Davidc502:s sept 2016 openwrt code and there are no more of those - only LEDE. I tried an upgrade to LEDE with my current configs for Openwrt - it went straight to hell! -So I face the facts; to either stay with the version I have (that in fact works very well) or to somehow try to document every setting in all my current config and transfer them to the LEDE configs (looks like I probably will spend weeks getting them all to work)...
It's a bit like using CyanogenMod for years and then having to make a full wipe for LineageOS if there's no transitional build for your device. 
I don't know the level of customization of your router...normally, most of the configuration you changed will be in /etc/config, and the names of the files are self-explanatory. There is a file called wireless, a file called network, a file called firewall etc. For me, coming from OpenWRT and switching to LEDE on my ACS I could just copy over most of them or at least most of their content. Worth a try.
(Last edited by floydburgermcdahm on 10 Mar 2017, 22:57)
I've been consistently told that OpenWrt tree is being merged into LEDE, but will take the developers time to go through everything.
You might go ahead and make the switch. Keep in mind, just keep OpenWrt on the other partition so it's there when you need to go back, and you can always flip to LEDE to finish up the configurations.
Sorry, to hear the configurations from OpenWrt were kept when trying LEDE. At this point I should just put a .gif of a bomb going off if attempted. lol
Need a few 1900ac V1 testers for Kernel 4.9.13. Would like to know if there's still a hourly reboot going on with V1 and the new kernel.
Link -- https://davidc502sis.dynamic-dns.net/sn … u/generic/
None of the other builds will be available for download -- Just V1 for right now.
Need a few 1900ac V1 testers for Kernel 4.9.13. Would like to know if there's still a hourly reboot going on with V1 and the new kernel.
Link -- https://davidc502sis.dynamic-dns.net/sn … u/generic/
None of the other builds will be available for download -- Just V1 for right now.
Ran for around 40 minutes before a reboot. The reboots seem to be getting worse for me too. I had it crash half way through boot (after the first reboot) and then it wouldn't even stay up long enough for me to SSH in.
Doesn't seem like any crash log is created in /sys/kernel/debug but I'm not really sure what I'm looking for.
Hi David et all !
Wanted to check with you guys if this exception that I'm getting ( pretty frequently indeed ) , is something normal or I shouldn't care . See extract from Kernel Log below:
Router: 1900ACS V2. CPU Temperature: Normal ( I Think... 80, 81 Celsius ). Software: LuCI Master (git-17.056.73941-fd2c692) / Lede leviathan V SNAPSHOT r3582-8873474
[70185.019365] ------------[ cut here ]------------
[70185.024051] WARNING: CPU: 0 PID: 0 at net/sched/sch_hfsc.c:1426 hfsc_dequeue+0x180/0x50c [sch_hfsc]()
[70185.033319] Modules linked in: pppoe ppp_async pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt sch_cake em_nbyte act_ipt cls_basic sch_prio sch_pie sch_gred em_meta sch_dsmark sch_teql em_cmp act_police em_text sch_codel sch_sfq sch_fq sch_red act_connmark nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress mwlwifi mac80211 cfg80211 compat cryptodev ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables msdos bonding ifb tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 sha512_generic sha256_generic md5 hmac authenc ohci_pci uhci_hcd ohci_platform ohci_hcd sd_mod gpio_button_hotplug
[70185.179741] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.50 #0
[70185.185684] Hardware name: Marvell Armada 380/385 (Device Tree)
[70185.191638] [<c0027d90>] (unwind_backtrace) from [<c00244b4>] (show_stack+0x10/0x14)
[70185.199419] [<c00244b4>] (show_stack) from [<c021d804>] (dump_stack+0x8c/0xa0)
[70185.206674] [<c021d804>] (dump_stack) from [<c0034e70>] (warn_slowpath_common+0x94/0xb0)
[70185.214799] [<c0034e70>] (warn_slowpath_common) from [<c0034f28>] (warn_slowpath_null+0x1c/0x24)
[70185.223626] [<c0034f28>] (warn_slowpath_null) from [<bf1a6218>] (hfsc_dequeue+0x180/0x50c [sch_hfsc])
[70185.232903] [<bf1a6218>] (hfsc_dequeue [sch_hfsc]) from [<c03c9fac>] (__qdisc_run+0xc0/0x198)
[70185.241468] [<c03c9fac>] (__qdisc_run) from [<c03a8dc0>] (net_tx_action+0xe8/0x164)
[70185.249159] [<c03a8dc0>] (net_tx_action) from [<c0038444>] (__do_softirq+0xd0/0x20c)
[70185.256934] [<c0038444>] (__do_softirq) from [<c0038838>] (irq_exit+0xac/0xd4)
[70185.264189] [<c0038838>] (irq_exit) from [<c006ff04>] (__handle_domain_irq+0x9c/0xac)
[70185.272052] [<c006ff04>] (__handle_domain_irq) from [<c00094dc>] (gic_handle_irq+0x54/0x94)
[70185.280439] [<c00094dc>] (gic_handle_irq) from [<c000a614>] (__irq_svc+0x54/0x70)
[70185.287950] Exception stack(0xc0695f48 to 0xc0695f90)
[70185.293023] 5f40: 00000001 00000000 00000000 c000b4a0 c0694000 c0696498
[70185.301235] 5f60: c058dbe0 00000000 c068f220 c0695fa0 00000000 c0692118 60000013 c0695f98
[70185.309445] 5f80: c0021544 c0021548 60000013 ffffffff
[70185.314518] [<c000a614>] (__irq_svc) from [<c0021548>] (arch_cpu_idle+0x34/0x50)
[70185.321948] [<c0021548>] (arch_cpu_idle) from [<c0068a90>] (cpu_startup_entry+0x148/0x210)
[70185.330251] [<c0068a90>] (cpu_startup_entry) from [<c0652d50>] (start_kernel+0x458/0x464)
[70185.338468] ---[ end trace 35c49a9c4ae6dfb0 ]---
[70185.343798] ------------[ cut here ]------------
[70185.348445] WARNING: CPU: 0 PID: 3 at net/sched/sch_hfsc.c:1426 hfsc_dequeue+0x180/0x50c [sch_hfsc]()
[70185.357712] Modules linked in: pppoe ppp_async pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt sch_cake em_nbyte act_ipt cls_basic sch_prio sch_pie sch_gred em_meta sch_dsmark sch_teql em_cmp act_police em_text sch_codel sch_sfq sch_fq sch_red act_connmark nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress mwlwifi mac80211 cfg80211 compat cryptodev ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables msdos bonding ifb tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 sha512_generic sha256_generic md5 hmac authenc ohci_pci uhci_hcd ohci_platform ohci_hcd sd_mod gpio_button_hotplug
[70185.504143] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 4.4.50 #0
[70185.511480] Hardware name: Marvell Armada 380/385 (Device Tree)
[70185.517429] [<c0027d90>] (unwind_backtrace) from [<c00244b4>] (show_stack+0x10/0x14)
[70185.525208] [<c00244b4>] (show_stack) from [<c021d804>] (dump_stack+0x8c/0xa0)
[70185.532462] [<c021d804>] (dump_stack) from [<c0034e70>] (warn_slowpath_common+0x94/0xb0)
[70185.540587] [<c0034e70>] (warn_slowpath_common) from [<c0034f28>] (warn_slowpath_null+0x1c/0x24)
[70185.549416] [<c0034f28>] (warn_slowpath_null) from [<bf1a6218>] (hfsc_dequeue+0x180/0x50c [sch_hfsc])
[70185.558682] [<bf1a6218>] (hfsc_dequeue [sch_hfsc]) from [<c03c9fac>] (__qdisc_run+0xc0/0x198)
[70185.567245] [<c03c9fac>] (__qdisc_run) from [<c03a8dc0>] (net_tx_action+0xe8/0x164)
[70185.574935] [<c03a8dc0>] (net_tx_action) from [<c0038444>] (__do_softirq+0xd0/0x20c)
[70185.582711] [<c0038444>] (__do_softirq) from [<c00385b0>] (run_ksoftirqd+0x30/0x50)
[70185.590400] [<c00385b0>] (run_ksoftirqd) from [<c0051038>] (smpboot_thread_fn+0x180/0x194)
[70185.598702] [<c0051038>] (smpboot_thread_fn) from [<c004e690>] (kthread+0xf0/0xf8)
[70185.606304] [<c004e690>] (kthread) from [<c0009d38>] (ret_from_fork+0x14/0x3c)
[70185.613563] ---[ end trace 35c49a9c4ae6dfb1 ]---
[70185.618826] ------------[ cut here ]------------
[70185.623495] WARNING: CPU: 0 PID: 3 at net/sched/sch_hfsc.c:1426 hfsc_dequeue+0x180/0x50c [sch_hfsc]()
[70185.632758] Modules linked in: pppoe ppp_async pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt sch_cake em_nbyte act_ipt cls_basic sch_prio sch_pie sch_gred em_meta sch_dsmark sch_teql em_cmp act_police em_text sch_codel sch_sfq sch_fq sch_red act_connmark nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress mwlwifi mac80211 cfg80211 compat cryptodev ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables msdos bonding ifb tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 sha512_generic sha256_generic md5 hmac authenc ohci_pci uhci_hcd ohci_platform ohci_hcd sd_mod gpio_button_hotplug
[70185.779200] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 4.4.50 #0
[70185.786538] Hardware name: Marvell Armada 380/385 (Device Tree)
[70185.792488] [<c0027d90>] (unwind_backtrace) from [<c00244b4>] (show_stack+0x10/0x14)
[70185.800267] [<c00244b4>] (show_stack) from [<c021d804>] (dump_stack+0x8c/0xa0)
[70185.807522] [<c021d804>] (dump_stack) from [<c0034e70>] (warn_slowpath_common+0x94/0xb0)
[70185.815645] [<c0034e70>] (warn_slowpath_common) from [<c0034f28>] (warn_slowpath_null+0x1c/0x24)
[70185.824475] [<c0034f28>] (warn_slowpath_null) from [<bf1a6218>] (hfsc_dequeue+0x180/0x50c [sch_hfsc])
[70185.833741] [<bf1a6218>] (hfsc_dequeue [sch_hfsc]) from [<c03c9fac>] (__qdisc_run+0xc0/0x198)
[70185.842305] [<c03c9fac>] (__qdisc_run) from [<c03a8dc0>] (net_tx_action+0xe8/0x164)
[70185.849995] [<c03a8dc0>] (net_tx_action) from [<c0038444>] (__do_softirq+0xd0/0x20c)
[70185.857771] [<c0038444>] (__do_softirq) from [<c00385b0>] (run_ksoftirqd+0x30/0x50)
[70185.865460] [<c00385b0>] (run_ksoftirqd) from [<c0051038>] (smpboot_thread_fn+0x180/0x194)
[70185.873760] [<c0051038>] (smpboot_thread_fn) from [<c004e690>] (kthread+0xf0/0xf8)
[70185.881362] [<c004e690>] (kthread) from [<c0009d38>] (ret_from_fork+0x14/0x3c)
[70185.888621] ---[ end trace 35c49a9c4ae6dfb2 ]---@listerwrt and @mariano.silva
Appreciate the both of you testing. Really, I was hoping there was more progress on this issue, but appears it hasn't been handled yet.
Will keep my ear to the rail and hopefully there will be a solution to the problem soon.
@davidc502 ... sorry for the confussion... my message had nothing to do with the test you asked for ... it's something I noted with the latest build I've downloaded from your site.
@davidc502 ... sorry for the confussion... my message had nothing to do with the test you asked for ... it's something I noted with the latest build I've downloaded from your site.
I didn't look at the build number you provided, my fault.
Are you running QOS currently? I did a quick search for this issue, and one user said they were running QOS, and then switched to SQM and fixed the issue.
Seems to be a pretty rare issue as there's not a lot on it. I do know there have been kernel bumps/changes on every build over the past 4 months, so it probably has something to do with that versions kernel build.
I didn't have any users report this issue on r3293, so you might give it a try. https://davidc502sis.dynamic-dns.net/mv … _r3293.zip
Or, if you want to wait I should have a new build tonight to try.
Thanks for looking at this David! I'll wait for the new release tonight... Btw: where can I find the latest release ( like r3293... Por the one you release tonight)? The latest one on your site for Shelbyville is the one I currently have installed... It's there a "beta" por "unstable release" folder?
Thanks for looking at this David! I'll wait for the new release tonight... Btw: where can I find the latest release ( like r3293... Por the one you release tonight)? The latest one on your site for Shelbyville is the one I currently have installed... It's there a "beta" por "unstable release" folder?
When I upload the new builds to the sever, all of the current builds will be archived, and the new builds will take their place.
Would it be possible for you to include the version or release ID in the file name? Useful to know how far ahead these builds are before downloading.
EDIT: Specifically on the "stable" ones not inside archive/
(Last edited by h4waii on 12 Mar 2017, 23:44)
Would it be possible for you to include the version or release ID in the file name? Useful to know how far ahead these builds are before downloading.
EDIT: Specifically on the "stable" ones not inside archive/
I second that
Also versions on the download page would help.
Regards,
Mariano
I have to be careful of the changes I make because it affects other things, like links for example. But it's given me an idea I might be able to work with.
Hi are the builds stil on kernel 4.4.50?
Latest build is 4.4.50. The build currently compiling will be 4.4.53.
Build r3716 has been uploaded to the server and is ready for download.
Kernel 4.4.53
(Last edited by davidc502 on 13 Mar 2017, 03:01)
Hey David,
Been listening to all that's been going on recently, and the 4.9.x kernel 1900acv1 bug has caught my eye. I'm still on r2695 (3 months old!), and wanted to ask you and any acv1 owner on the recent non 4.9.x builds if the builds are rebooting at all. R2695 has been great to me with ~45 days continuous uptime. (Last reboot was testing the build after r2695)
Thanks for everything,
ThePatrikos
Hey thepatrikos!
Yes, v1 owners are reporting back reboot issues with the 4.9.x kernel builds. Until it gets fixed I have kept all the releases in the 4.4.x range.
If everything is going well with r2695, and it sounds like it is, there really isn't a reason to upgrade at this time.