Do not use wl radio on/off, radio off does not take care of stopping the related services and interfaces, depending on config and usage this causes memory to be consumed without ever freed.
Thanks for the advice! I assume your duplicate of startservice was accidental in that one would be stopservice, assuming no need to run it twice. I will get this tested soon and report back. [edit] Or maybe I'm wrong and i need to replace off with on to do the opposite, will test here either way.
I'll look around for a feature request section to post in, but if radio scheduling supported a grid/matrix with no only hours of the day, but also days of the week, this would eliminate my need to use cron for this. Thanks for all your work on this! (BrainSlayer too!) Been running dd-wrt for like a decade on WRT54G's...just now upgrading since it can't keep up with my internet speed anymore.
No change here using the new commands. I used the radio_off_0 and radio_on_0, saw the nas process go away, but still locked up on me within a couple hours. We sure this is still related to nas? I'll disable wifi altogether now and see what we get.
[edit added]
WiFi is disabled in UI completely, rebooted router and wland still running. Not sure it matters, just pointing it out for now. For reference, part of the ps output:
576 root 752 S /sbin/hotplug2 --set-rules-file /etc/hotplug2.rules
581 root 804 S /sbin/mstpd
687 root 2376 S startservice_f init_start -f
850 root 912 S dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_h
975 root 1748 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.con
976 root 1740 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.con
1103 root 0 Z [process_monitor]
1106 root 1280 S inadyn -u <removed> -p <removed>
1119 root 0 Z [wland]
1121 root 728 S cron
1123 root 1440 S wland
1129 root 1624 S ttraff
1145 root 1192 S syslogd -L
1157 root 3968 S httpd -p 80
1159 root 1252 S resetbutton
1309 root 1504 S process_monitor
1324 root 980 R dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_h
1325 root 1192 S -sh
Do not use wl radio on/off, radio off does not take care of stopping the related services and interfaces, depending on config and usage this causes memory to be consumed without ever freed.
Thanks for the advice! I assume your duplicate of startservice was accidental in that one would be stopservice, assuming no need to run it twice. I will get this tested soon and report back. [edit] Or maybe I'm wrong and i need to replace off with on to do the opposite, will test here either way.
I'll look around for a feature request section to post in, but if radio scheduling supported a grid/matrix with no only hours of the day, but also days of the week, this would eliminate my need to use cron for this. Thanks for all your work on this! (BrainSlayer too!) Been running dd-wrt for like a decade on WRT54G's...just now upgrading since it can't keep up with my internet speed anymore.
No change here using the new commands. I used the radio_off_0 and radio_on_0, saw the nas process go away, but still locked up on me within a couple hours. We sure this is still related to nas? I'll disable wifi altogether now and see what we get.
[edit added]
WiFi is disabled in UI completely, rebooted router and wland still running. Not sure it matters, just pointing it out for now. For reference, part of the ps output:
576 root 752 S /sbin/hotplug2 --set-rules-file /etc/hotplug2.rules
581 root 804 S /sbin/mstpd
687 root 2376 S startservice_f init_start -f
850 root 912 S dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_h
975 root 1748 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.con
976 root 1740 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.con
1103 root 0 Z [process_monitor]
1106 root 1280 S inadyn -u <removed> -p <removed>
1119 root 0 Z [wland]
1121 root 728 S cron
1123 root 1440 S wland
1129 root 1624 S ttraff
1145 root 1192 S syslogd -L
1157 root 3968 S httpd -p 80
1159 root 1252 S resetbutton
1309 root 1504 S process_monitor
1324 root 980 R dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_h
1325 root 1192 S -sh
1.5 day uptime so far when all wifi is disabled in UI. Longest ever on any version of dd-wrt that has R6400 support. So it seems something isn't been released/free'd up even when stopping the service properly. As long as the service never starts, all is well. Obviously I do need wifi though.
Do not use wl radio on/off, radio off does not take care of stopping the related services and interfaces, depending on config and usage this causes memory to be consumed without ever freed.
Thanks for the advice! I assume your duplicate of startservice was accidental in that one would be stopservice, assuming no need to run it twice. I will get this tested soon and report back. [edit] Or maybe I'm wrong and i need to replace off with on to do the opposite, will test here either way.
I'll look around for a feature request section to post in, but if radio scheduling supported a grid/matrix with no only hours of the day, but also days of the week, this would eliminate my need to use cron for this. Thanks for all your work on this! (BrainSlayer too!) Been running dd-wrt for like a decade on WRT54G's...just now upgrading since it can't keep up with my internet speed anymore.
No change here using the new commands. I used the radio_off_0 and radio_on_0, saw the nas process go away, but still locked up on me within a couple hours. We sure this is still related to nas? I'll disable wifi altogether now and see what we get.
[edit added]
WiFi is disabled in UI completely, rebooted router and wland still running. Not sure it matters, just pointing it out for now. For reference, part of the ps output:
576 root 752 S /sbin/hotplug2 --set-rules-file /etc/hotplug2.rules
581 root 804 S /sbin/mstpd
687 root 2376 S startservice_f init_start -f
850 root 912 S dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_h
975 root 1748 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.con
976 root 1740 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.con
1103 root 0 Z [process_monitor]
1106 root 1280 S inadyn -u <removed> -p <removed>
1119 root 0 Z [wland]
1121 root 728 S cron
1123 root 1440 S wland
1129 root 1624 S ttraff
1145 root 1192 S syslogd -L
1157 root 3968 S httpd -p 80
1159 root 1252 S resetbutton
1309 root 1504 S process_monitor
1324 root 980 R dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_h
1325 root 1192 S -sh
1.5 day uptime so far when all wifi is disabled in UI. Longest ever on any version of dd-wrt that has R6400 support. So it seems something isn't been released/free'd up even when stopping the service properly. As long as the service never starts, all is well. Obviously I do need wifi though.
Any other suggestions here greatly appreciated.
In addition, there seems to be an issue with the system not renewing its WAN IP properly when the lease is up. If my WAN IP changes, my internet just goes down. I have to disable the WAN, then re-enable it to get the new IP.
Otherwise things are still good with no wifi. Anyone have anything else worth trying here?
Router: Netgear R6300V2CH
Firmware:Linux version 4.4.134 (bluebat@opensuse.site) (gcc version 6.3.0 (LEDE GCC 6.3.0 r4639-eb43a817f7) ) #568 SMP Thu May 31 11:02:32 CEST 2018
Kernel:4.4.134
Status:10 days
Reset: only before installation, had Netgear OFW and after installation. No need to reset.
Errors: I see authorization errors in the syslog when I leave the web gui open while logged in, but nothing to do with performance. I don't run anything special to test all that is available such features as adblocker, NAS, Samba etc. Wireless runs as well as expected using your builds, Nat/qos only stability as far as no issues.
Joined: 08 Oct 2007 Posts: 47 Location: Winnipeg, MB
Posted: Wed Jun 20, 2018 18:25 Post subject: EX6200 AP
Router: Netgear EX6200
Firmware: DD-WRT v3.0-r36070M ( 05/31/18 )
Kernel: Linux 4.4.134 #567 SMP Thu May 31 10:52:33 CEST 2018 armv7l
Reset: YES
Errors:
1) Default WIFI password on factory reset for AP dd-wrt is not the default password from the router. GUI shows this:
2) Adding guest WIFI on 2.4GHZ, finding that instead of running both SSID at the same time, it seems like the router will pick one or the other. Sometimes it will broadcast the main AP, other times it will just broadcast the guest AP.
The MACID of the main AP and the VAP are identical, the third one created gets a different MACID.
A work around is to add a THIRD VAP. Made the first two AP's identical, then treated the THIRD one as the guest AP. Third AP will always be running, and it won't matter which of the first two are active.
I'm sure that's probably not the best way to deal with that, but it was working.
3) I didn't test this much further, but I wasn't able to add a secondary DHCP server to control the guest AP. I could add it on the networking tab, but I couldn't get it working. Wondering if this is just a limitation of the "MINI" build. Also I'm running this unit as just an AP, not router, so I did have the main DHCP server disabled. I'm pretty sure I did try enabling it. Sorry, this one is vague.
4) Doesn't seem to be a *.bin update file, which I think is breaking ddup --flashlatest. I was however able to update by flashing the .chk file through the dd-wrt GUI.
I updated my ASUS AC68U to this version. But some clients can not connect to the router after the update even after power cycling the router. After reverting to the previous version, everything works fine again.
Posted: Mon Jun 25, 2018 7:31 Post subject: httpd -S take too much CPU
Router: Netgear 7000p
Firmware: DD-WRT v3.0-r36070M kongac (05/31/2018)
Kernel: Linux 4.4.134 #568 SMP Thu May 31 11:02:32 CEST 2018 armv7l
Status: Slow Web GUI. httpd -S took 50% CPU
Reset: No
Errors:
I seems that all releases after 35550 have this httpd -S taking too much CPU cycle issue. Rolled back immediately since webGUI is sluggish and unresponsive.
Posted: Mon Jun 25, 2018 12:44 Post subject: DD-WRT v3.0-r36070M kongac Report
Router: Netgear R7000
Firmware: DD-WRT v3.0-r36070M kongac (05/31/2018)
Kernel: Linux 4.4.134 #568 SMP Thu May 31 11:02:32 CEST 2018 armv7l
Status: Working
Reset: Yes, Hard
Previous: 35550M
Errors: Yes
Ran into a problem with the Gateway R7000.
The GUI loads up correctly and fast but getting
Code:
daemon.err httpd[1323]: Request Error Code 401: Authorization required. please note that the default username is "root"
and Wifi connection slow downs from tx 866 to tx 17-117 till I reboot router or turn off wifi off on macbook.
On wired connection I'm getting
Code:
daemon.err httpd[1323]: Request Error Code 401: Authorization required. please note that the default username is "root"
and
Code:
daemon.err httpd[6031]: Request Error Code 408: No request appeared within a reasonable time period.
Even with the errors issue all other services where working fine and fast: DNSCrypt, OpenVPN, etc...
Second
when using Encrypt DNS with any
DNS Crypt Resolver for example with Ipredator.se it works only 24 hours then I can't access to internet until I manually enable and disable Encrypt DNS. Resolving time with Ipredator.se is more fast then on Google DNS servers
Working very well :
Router mode : DHCP
SFE Enable
STP Enable
DNSMasq
Encrypt DNS
Cache DNSSEC data
Validate DNS Replies (DNSSEC)
Local DNS
No DNS Rebind
Query DNS in Strict Order
SPI Firewall
Usb
Nas, Samba, ftp, JFFS2,
wl0, wl1
Vpn (OpenVPN Server)
wl1 is terrible unstable!!!! same config as always but getting pure connection. Don't know where to dig to fix?!
Posted: Sat Jul 14, 2018 20:22 Post subject: Re: New Kong's Test Build v3.0-r36070M kongac (31/05/2018)
Router: Asus RT-AC5300
Firmware: DD-WRT v3.0-r36070M kongac (05/31/1
Kernel: Linux 4.4.134 #568 SMP Thu May 31 11:02:32 CEST 2018 armv7l
Status: Working
Reset: Yes. nvram erase and gui
Errors: Yes. dhcp6c not working.
Everything has worked perfectly for several weeks until I tried to configure ipv6.
After troubleshooting I found dchp6c does not work on this router. It seems to be running but does nothing. (Router never gets ipv6 nor any ipv6 packet). Tried default conf /tmp/dhcp6c.conf and variations but the result was always the same: dhcp6c seems to do nothing. Then I tried debugging it by running it in foreground with -f... there is no output at all. dhcp6c (or dhcp6_multicall) has zero output with -d or -D. Thinking it might be something from my setup, so I tried resetting to defaults and configure nothing but ipv6, same results: dhcp6c provides no output at all. My modem (Arris SB6183) is supposed to support ipv6. Not sure at this point if a hard reset would make any difference from nvram erase.
There where some issues where the interface have to be set in promiscuous mode for the dhcp6c packets to pass.
Thanks for the suggestion!
I tried that too, setting my vlan2 to promisc mode. No luck.
I think it might be something related to the binaries. I would expect at least some sort of output when running dhcp6c in debug mode, even if it ended in error, but it does nothing, not a single line of output.
Update:
On a hunch I copied older versions of dhcp6_multicall (or dhcp6c) to my opt folder and tested for output. It turns out I get output (although not functionality of ipv6) on files from kong versions 4800 or before. The binaries from v4900 and later do not work on my router. Thinking on applying a stable version prior to v4800 and test.
Update2:
I've resolved most of it: the problem with dhcp6c and dhpc6_multicall in this version (and since v4800) is the lack of output either to syslog or console when running on the foreground. Using a previous version allowed me to troubleshoot my specific issue (which was an invalid dhcp6c_duid, it doesn't build it properly leaving 00s instead of the MAC address at the end).
Router Model: Netgear R6400
Firmware Version: DD-WRT v3.0-r36070M kongac (05/31/2018)
Kernel Version: Linux 4.4.134 #568 SMP Thu May 31 11:02:32 CEST 2018 armv7l
Upgraded: from DD-WRT v3.0-r35030M kongac (02/19/2018)
Reset: No
Error: Incomplete iptables rebuilding
Greetings, all:
This is the first time I'm posting in the forum so pardon me for missing any important information to help troubleshooting. However I want to bring this issue to the attention of the devs. I have observed a weird behavior of the kong build since upgraded to r35030M a while ago and it is persistent in the current test build of r36070M. Within the Access Restrictions tab if the "Apply Settings" button was pressed the router will rebuild the iptables rules but sometimes the iptables rebuilding will give an incomplete result, causing the router not behaving as expected (for example not having the desired Access Restrictions applied).
root@ROUTER_MAIN:~# iptables -vnL FORWARD
Chain FORWARD (policy ACCEPT 76 packets, 14710 bytes)
pkts bytes target prot opt in out source destination
71 16053 lan2wan 0 -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP 0 -- br0 br1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP 0 -- br0 br1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP 0 -- br1 br0 0.0.0.0/0 0.0.0.0/0 state NEW
6 2117 ACCEPT 0 -- br1 * 0.0.0.0/0 0.0.0.0/0 state NEW
When the above happens I checked the /tmp/.ipt file and all the rules are there but if I run the "iptables-restore -vt < /tmp/.ipt" command I'll get a line error.
What's interesting is that this behavior randomly occurs. If I check the /var/log/messages right after pressing the "Apply Settings" button the following lines are logged but their order is not always the same:
I'm not sure about the inner workings of dd-wrt but could there be a race condition when multiple services trying to modify the iptables during the rebuilding process and caused some rules not applied?
My previous workaround is simply press the "Apply Settings" button again and more often than not the second iptables rebuilding will succeed and put the router to the expected behavior.
However, today I decided to regress to r34015M build (2017/12/09) just for the kicks and lo and behold this issue is no more. Every time the iptables are rebuilt successfully. As I've stated previously I observed this issue on both r35030M (2018/02/19) and r36070M (2018/05/31) builds so most likely some code changes in the beginning of this year caused this?