New Kong's Test Build v3.0-r36070M kongac (31/05/2018)

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
unixpunk
DD-WRT Novice


Joined: 07 Jun 2018
Posts: 13

PostPosted: Wed Jun 13, 2018 16:16    Post subject: Reply with quote
unixpunk wrote:
<Kong> wrote:
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.

To disable radios you have to use.

First radio:

startservice radio_off_0 -f
startservice radio_off_0 -f

Second radio:

startservice radio_off_1 -f
startservice radio_off_1 -f


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


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
Sponsor
unixpunk
DD-WRT Novice


Joined: 07 Jun 2018
Posts: 13

PostPosted: Fri Jun 15, 2018 1:38    Post subject: Reply with quote
unixpunk wrote:
unixpunk wrote:
<Kong> wrote:
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.

To disable radios you have to use.

First radio:

startservice radio_off_0 -f
startservice radio_off_0 -f

Second radio:

startservice radio_off_1 -f
startservice radio_off_1 -f


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


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.
unixpunk
DD-WRT Novice


Joined: 07 Jun 2018
Posts: 13

PostPosted: Fri Jun 15, 2018 22:51    Post subject: Reply with quote
unixpunk wrote:
unixpunk wrote:
unixpunk wrote:
<Kong> wrote:
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.

To disable radios you have to use.

First radio:

startservice radio_off_0 -f
startservice radio_off_0 -f

Second radio:

startservice radio_off_1 -f
startservice radio_off_1 -f


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


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?
native_tx
DD-WRT User


Joined: 26 Feb 2014
Posts: 169
Location: Texas

PostPosted: Sat Jun 16, 2018 2:50    Post subject: Reply with quote
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.
Tarv
DD-WRT Novice


Joined: 08 Oct 2007
Posts: 47
Location: Winnipeg, MB

PostPosted: Wed Jun 20, 2018 18:25    Post subject: EX6200 AP Reply with quote
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.

Thanks.

_________________
Switched to UniFi
stoney li
DD-WRT User


Joined: 12 Apr 2013
Posts: 248

PostPosted: Thu Jun 21, 2018 18:57    Post subject: Reply with quote
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.
jasonring
DD-WRT Novice


Joined: 15 Dec 2014
Posts: 8

PostPosted: Mon Jun 25, 2018 7:31    Post subject: httpd -S take too much CPU Reply with quote
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.
Nonikoff
DD-WRT Novice


Joined: 18 Mar 2016
Posts: 30

PostPosted: Mon Jun 25, 2018 12:44    Post subject: DD-WRT v3.0-r36070M kongac Report Reply with quote
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?!
    limerick_fr
    DD-WRT User


    Joined: 07 Nov 2012
    Posts: 111

    PostPosted: Fri Jun 29, 2018 13:10    Post subject: Reply with quote
    After 28 days, I had to reboot my R8000 today in order to recover the connection to my EX2700.

    This is a huge improvement compared to the usual 7 or 8 days limit of the several previous builds.
    marcelolagos
    DD-WRT Novice


    Joined: 14 Jul 2018
    Posts: 2

    PostPosted: Sat Jul 14, 2018 20:22    Post subject: Re: New Kong's Test Build v3.0-r36070M kongac (31/05/2018) Reply with quote
    Router: Asus RT-AC5300
    Firmware: DD-WRT v3.0-r36070M kongac (05/31/1Cool
    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.
    Per Yngve Berg
    DD-WRT Guru


    Joined: 13 Aug 2013
    Posts: 6865
    Location: Romerike, Norway

    PostPosted: Sat Jul 14, 2018 20:48    Post subject: Reply with quote
    I have IPv6 on build 36175.

    There where some issues where the interface have to be set in promiscuous mode for the dhcp6c packets to pass.
    marcelolagos
    DD-WRT Novice


    Joined: 14 Jul 2018
    Posts: 2

    PostPosted: Sat Jul 14, 2018 22:16    Post subject: Reply with quote
    Per Yngve Berg wrote:
    I have IPv6 on build 36175.

    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).
    taichun
    DD-WRT Novice


    Joined: 16 Jul 2018
    Posts: 3

    PostPosted: Mon Jul 16, 2018 2:50    Post subject: Incomplete iptables rebuilding Reply with quote
    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).

    This is a normal iptables I'm expecting:

    Code:
    root@ROUTER_MAIN:~# iptables -vnL FORWARD
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
     4099  758K 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
      180 17280 DROP       0    --  br1    br0     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
      119 12350 ACCEPT     0    --  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
        0     0 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0           state NEW
        0     0 ACCEPT     47   --  *      vlan2   192.168.1.0/24       0.0.0.0/0           
        0     0 ACCEPT     47   --  *      vlan2   192.168.1.0/24       0.0.0.0/0           
        0     0 ACCEPT     tcp  --  *      vlan2   192.168.1.0/24       0.0.0.0/0           tcp dpt:1723
        0     0 ACCEPT     tcp  --  *      vlan2   192.168.1.0/24       0.0.0.0/0           tcp dpt:1723
       72  2904 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0           
     2785  321K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
        0     0 ACCEPT     0    --  br0    br0     0.0.0.0/0            0.0.0.0/0           
      943  405K ACCEPT     0    --  br0    vlan2   0.0.0.0/0            0.0.0.0/0           
        0     0 ACCEPT     0    --  br1    vlan2   0.0.0.0/0            0.0.0.0/0           
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.99        udp dpts:27000:27030
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.99        tcp dpts:27014:27050
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.99        udp dpt:4380
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.99        udp dpts:27000:27030
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.99        tcp dpts:27014:27050
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.99        udp dpt:4380
        0     0 TRIGGER    0    --  vlan2  br0     0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0
        0     0 TRIGGER    0    --  vlan2  br0     0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0
        0     0 trigger_out  0    --  br0    *       0.0.0.0/0            0.0.0.0/0           
        0     0 trigger_out  0    --  br0    *       0.0.0.0/0            0.0.0.0/0           
        0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
        0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
        0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           
        0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           

    But sometimes I got this instead:

    Code:
    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:

    Code:
    Jul 14 23:14:03 ROUTER_MAIN user.info : cron : cron daemon successfully stopped
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : vpn modules successfully unloaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_conntrack_proto_gre successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : vpn modules successfully unloaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_conntrack_proto_gre successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_nat_proto_gre successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_nat_proto_gre successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_conntrack_pptp successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_conntrack_pptp successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_nat_pptp successfully loaded
    Jul 14 23:14:04 ROUTER_MAIN user.info : vpn modules : nf_nat_pptp successfully loaded
    Jul 14 23:14:05 ROUTER_MAIN user.info : wland : WLAN daemon successfully stopped
    Jul 14 23:14:05 ROUTER_MAIN user.info : syslogd : syslog daemon successfully stopped
    Jul 14 23:14:05 ROUTER_MAIN user.info : wland : WLAN daemon successfully started
    Jul 14 23:14:05 ROUTER_MAIN syslog.info syslogd exiting
    Jul 14 23:14:05 ROUTER_MAIN syslog.info syslogd started: BusyBox v1.28.4
    Jul 14 23:14:05 ROUTER_MAIN user.info : cron : cron daemon successfully started
    Jul 14 23:14:05 ROUTER_MAIN cron.info cron[15359]: (CRON) STARTUP (fork ok)

    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?
    egc
    DD-WRT Guru


    Joined: 18 Mar 2014
    Posts: 12877
    Location: Netherlands

    PostPosted: Mon Jul 16, 2018 6:52    Post subject: Reply with quote
    That is an interesting observation, you should file a bug report at : https://svn.dd-wrt.com
    _________________
    Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
    Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
    Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
    Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
    kernel-panic69
    DD-WRT Guru


    Joined: 08 May 2018
    Posts: 14208
    Location: Texas, USA

    PostPosted: Mon Jul 16, 2018 14:50    Post subject: Reply with quote
    Any network-related settings change will do that, or so it's been my experience. It's basically re-starting networking on the LAN side of the router.
    Goto page Previous  1, 2, 3, 4, 5, 6  Next Display posts from previous:    Page 4 of 6
    Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

    Navigation

     
    Jump to:  
    You cannot post new topics in this forum
    You cannot reply to topics in this forum
    You cannot edit your posts in this forum
    You cannot delete your posts in this forum
    You cannot vote in polls in this forum
    You can attach files in this forum
    You can download files in this forum