What's new

Asuswrt-Merlin 374.43 is out

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

RT-N66U: all ok here...

Just flashed on top of 374.42 on my RT-N66U without issues. Seems ok... all is working good so far :)
 
Same, fine here on the RT-N66U.
 
Does anyone else get alot of these?

un 7 18:53:10 dnsmasq-dhcp[527]: DHCPACK(br0) 192.168.1.245 xx:xx:xx:xx:xx:xx R2D2
Jun 7 18:54:29 dnsmasq-dhcp[527]: DHCPREQUEST(br0) 192.168.1.245 xx:xx:xx:xx:xx:xx

I used to get alot from windows 7 hosts, but that got fixed awhile ago, since dhcp-option=252,"\n" was put into the dnsmasq.conf so I didnt have to add it myself.

For some reason I see most of these entries in the log files from an iphone. Anyone else seeing this alot?
 
Last edited:
I get "it's now broken with Comcast" reported with every single new release, even when there was zero change to IPv6 code (like is the case with 374.43). Comcast's IPv6 support is simply quirky, the issue isn't the new firmware, it's the fact your router was rebooted, and it has trouble getting a new IPv6 connection established with Comcast - you would have experienced the same issue after a router reboot. Try a power cycle of your modem to fix it, that usually works.

I can't speak for the code changes (or lack thereof) but I can tell you this...something with this new build is affecting Comcast IPv6. I have a RT-N66U.

I upgraded to 374.43 and did a full factory reset. IPv6 is not working with reboots, power cycles, waving of chicken bones. This has not been a problem for me with previous builds where IPv6 was always enabled and addresses always assigned after any reboot. My Moto SB6120 has not changed. The only variable in the equation is the new build of firmware.

So I can't say what has changed or where the incompatibility may be, but something new has been introduced that has borked IPv6 for me on Comcast.
 
I can't speak for the code changes (or lack thereof) but I can tell you this...something with this new build is affecting Comcast IPv6. I have a RT-N66U.

I upgraded to 374.43 and did a full factory reset. IPv6 is not working with reboots, power cycles, waving of chicken bones. This has not been a problem for me with previous builds where IPv6 was always enabled and addresses always assigned after any reboot. My Moto SB6120 has not changed. The only variable in the equation is the new build of firmware.

So I can't say what has changed or where the incompatibility may be, but something new has been introduced that has borked IPv6 for me on Comcast.

Agree there may have been no changes to v6 in this build but after 2 days I am still unable to get a v6 address on my 68u it simply no longer works period. Using my N66 and I can get a v6 allocation but it takes time and multiple reboots to obtain it. When I revert back to a older version of firmware v6 works flawlessly again obtaining a v6 address simply by power cycling the modem and router the way it should be.

So for now I will keep the N66 in line because v6 is working and also because I noticed it has a much stronger signal on 2.4 ghz then my 68U does. I know others have reported no v6 issues with this build but for me that's not the case as my 68U never had any troubles with previous release other then the neighbor overflows that Merlin has addressed. I am not saying v6 is totally broke but something is definitely not right with native IPv6 and 43_0
 
Last edited:
Does anyone else get alot of these?

un 7 18:53:10 dnsmasq-dhcp[527]: DHCPACK(br0) 192.168.1.245 xx:xx:xx:xx:xx:xx R2D2
Jun 7 18:54:29 dnsmasq-dhcp[527]: DHCPREQUEST(br0) 192.168.1.245 xx:xx:xx:xx:xx:xx

I used to get alot from windows 7 hosts, but that got fixed awhile ago, since dhcp-option=252,"\n" was put into the dnsmasq.conf so I didnt have to add it myself.

For some reason I see most of these entries in the log files from an iphone. Anyone else seeing this alot?

YUP
I have 2 iPhones a 4 (IOS 6.1) and a 5 (IOS 7.1.1) They both exhibit this behavior. Other devices do not including a wireless thermostat, Epson printer, Android (Nexus) tablet, Chromebook, and PC using ASUS wireless NIC. Have seen this for multiple releases of Merlin firmware. Do not think it is a firmware issue with the router. More likely how Apple is doing the dhcp support on the iPhone. Like ignoring the lease time. Suspect it has to do with the iPhone going to sleep then waking up?
A web search will show that there are issues with how Apple handles DHCP and leases.
--bill
 
yeah i can understand

but you fixed it once =)

can you tell me, where i can find info how to fix it myself,
because I'm perry sure developer of minidlna doesn't do it.

Most likely it was Asus who upgraded to a newer version that was fixed, not me. I don't know anything about the DLNA protocol.
 
I can't speak for the code changes (or lack thereof) but I can tell you this...something with this new build is affecting Comcast IPv6. I have a RT-N66U.

I upgraded to 374.43 and did a full factory reset. IPv6 is not working with reboots, power cycles, waving of chicken bones. This has not been a problem for me with previous builds where IPv6 was always enabled and addresses always assigned after any reboot. My Moto SB6120 has not changed. The only variable in the equation is the new build of firmware.

So I can't say what has changed or where the incompatibility may be, but something new has been introduced that has borked IPv6 for me on Comcast.

According to this user, 374.41 broke IPv6 with Comcast, and it was fine with 374.40.

According to this user, 374.42 broke IPv6 with Comcast, and it was fine with 374.41

According to you two, 374.43 broke IPv6 with Comcast, and it was fine with 374.42.

See a pattern?

The bottom line is: Comcast's IPv6 is simply quirky, regardless of the firmware version being used. It randomly works for some of their customers, it never works for others, and it always works for others. And the firmware version shows no constant there - I get as many "it's now broken" reports as I get "it works fine" reports with all three latest releases.

There is nothing changing in the firmware between releases to fix or break anything - it just randomly breaks regardless of the version.

Here's the whole list of code changes done to the main rc daemon between 374.42 and 374.43. Not a single line of code touching IPv6 unless you are using a 6in4 tunnel:

Code:
merlin@mint-dev ~/asuswrt/release/src-rt/router/rc $ git diff 374.42 374.43 -- .
diff --git a/release/src/router/rc/firewall.c b/release/src/router/rc/firewall.c
index 6b2cf62..509ef86 100644
--- a/release/src/router/rc/firewall.c
+++ b/release/src/router/rc/firewall.c
@@ -4133,6 +4133,21 @@ mangle_setting(char *wan_if, char *wan_ip, char *lan_if, char *lan_ip, char *log
                             "-m", "state", "--state", "NEW", "-j", "MARK", "--set-mark", "0x01");
                }
 #endif
+#ifdef RTCONFIG_BCMARM
+               /* mark STUN connection*/
+               if (nvram_match("fw_pt_stun", "1")) {
+                       eval("iptables", "-t", "mangle", "-A", "FORWARD",
+                               "-p", "udp",
+                               "-m", "state", "--state", "NEW", "-j", "MARK", "--set-mark", "0x01");
+               }
+
+#ifdef RTCONFIG_IPV6
+               if (get_ipv6_service() == IPV6_6IN4) {
+                       eval("ip6tables", "-t", "mangle", "-A", "FORWARD",
+                               "-m", "state", "--state", "NEW", "-j", "MARK", "--set-mark", "0x01");
+               }
+#endif
+#endif
        }
 #endif
 }
diff --git a/release/src/router/rc/lan.c b/release/src/router/rc/lan.c
index cc98d32..f7566ae 100644
--- a/release/src/router/rc/lan.c
+++ b/release/src/router/rc/lan.c
@@ -3221,7 +3221,7 @@ void lanaccess_mssid_ban(const char *limited_ifname)
        eval("ebtables", "-A", "FORWARD", "-o", (char*)limited_ifname, "-j", "DROP"); // so that traffic via host and nat is passed
 
        snprintf(lan_subnet, sizeof(lan_subnet), "%s/%s", nvram_safe_get("lan_ipaddr"), nvram_safe_get("lan_netmask"));
-       eval("ebtables", "-t", "broute", "-A", "BROUTING", "-i", (char*)limited_ifname, "--ip-dst", lan_subnet, "--ip-proto", "tcp", "-j", "DROP");
+       eval("ebtables", "-t", "broute", "-A", "BROUTING", "-i", (char*)limited_ifname, "-p", "ipv4", "--ip-dst", lan_subnet, "--ip-proto", "tcp", "-j", "DROP");
 }
 
 void lanaccess_wl(void)
diff --git a/release/src/router/rc/services.c b/release/src/router/rc/services.c
index f34e69b..220e49c 100644
--- a/release/src/router/rc/services.c
+++ b/release/src/router/rc/services.c
@@ -707,6 +707,9 @@ void start_dnsmasq(int force)
                if (nvram_get_int("dhcpd_auth") >= 0)
                        fprintf(fp, "dhcp-authoritative\n");
 
+               /* Workaround for broken Win7/IE behaviour */
+               fprintf(fp,"dhcp-option=252,\"\\n\"\n");
+
                /* LAN Domain */
                nv = nvram_safe_get("lan_domain");
                if (*nv)
diff --git a/release/src/router/rc/sysdeps/init-broadcom.c b/release/src/router/rc/sysdeps/init-broadcom.c
index 9686b88..54f44f5 100644
--- a/release/src/router/rc/sysdeps/init-broadcom.c
+++ b/release/src/router/rc/sysdeps/init-broadcom.c
@@ -3534,7 +3534,7 @@ void generate_wl_para(int unit, int subunit)
 
        char tmp[100], prefix[]="wlXXXXXXX_";
        char tmp2[100], prefix2[]="wlXXXXXXX_";
-       char list[1200];
+       char list[3500];
        char *nv, *nvp, *b, *c;
 #ifndef RTCONFIG_BCMWL6
        char word[256], *next;
diff --git a/release/src/router/rc/watchdog.c b/release/src/router/rc/watchdog.c
index d4ce3cb..6a36918 100644
--- a/release/src/router/rc/watchdog.c
+++ b/release/src/router/rc/watchdog.c
@@ -70,6 +70,7 @@
 #define NORMAL_PERIOD          1               /* second */
 #define URGENT_PERIOD          100 * 1000      /* microsecond */
 #define RUSHURGENT_PERIOD      50 * 1000       /* microsecond */
+#define DAY_PERIOD             2 * 60 * 24     /* 1 day (in 30 sec periods) */
 
 #define WPS_TIMEOUT_COUNT      121 * 20
 #define WPS_WAIT               1               /* seconds */
@@ -108,6 +109,7 @@ static int wsc_timeout = 0;
 static int btn_count_setup_second = 0;
 static int btn_pressed_toggle_radio = 0;
 #endif
+static long ddns_update_timer = 0;
 
 #ifdef RTCONFIG_WIRELESS_SWITCH
 // for WLAN sw init, only for slide switch
@@ -1302,6 +1304,7 @@ void ddns_check(void)
                unlink("/tmp/ddns.cache");
                logmessage("watchdog", "start ddns.");
                notify_rc("start_ddns");
+               ddns_update_timer = 0;
        }
        return;
 }
@@ -1778,6 +1781,7 @@ period_chk_cnt()
 
 void watchdog(int sig)
 {
+       int period;
 #ifdef RTCONFIG_PUSH_EMAIL
        push_mail();
 #endif
@@ -1844,6 +1848,14 @@ void watchdog(int sig)
 #if 0
        cpu_usage_monitor();
 #endif
+
+       /* Force a DDNS update every "x" days - default is 21 days */
+       period = nvram_get_int("ddns_refresh_x");
+       if ((period) && (++ddns_update_timer >= (DAY_PERIOD * period))) {
+               ddns_update_timer = 0;
+               nvram_set("ddns_updated", "0");
+       }
+
        ddns_check();
 
 //#if defined(RTCONFIG_JFFS2LOG) && defined(RTCONFIG_JFFS2)
 
In other words stop reporting it to merlin about comcast and ipv6. Hes told you over and over again and you just will not listen. Go to stock firmware or back to whatever version you "thought" it worked on before and thats it.

If you have a version that works for you for any number of features you use stick with it. If you are willing to try new versions and feature breaks just go back to what you were using.
 
Last edited:
In other words stop reporting it to merlin about comcast and ipv6. Hes told you over and over again and you just will not listen. Go to stock firmware or back to whatever version you "thought" it worked on before and thats it.

If you have a version that works for you for any number of features you use stick with it. If you are willing to try new versions and feature breaks just go back to what you were using.

I will report to Merlin what ever i want to back off and keep your comments to yourself this does not concern you. Merlin can speak for himself and dont need you to do it for him. I was simply reporting a issue that i have experienced nothing more nothing less.
 
Last edited:
[*]A couple of webui-related issues were resolved, such as the problems with the new Media Server page, SSIDs with single quotes in their names breaking the webui, and a few others.

Thank you very much, RMerlin! That's really nice.
 
The bottom line is: Comcast's IPv6 is simply quirky, regardless of the firmware version being used. It randomly works for some of their customers, it never works for others, and it always works for others. And the firmware version shows no constant there - I get as many "it's now broken" reports as I get "it works fine" reports with all three latest releases.

I am starting to think it may depend on what CMTS they are on.

Comcast uses Arris, Cisco and Motorola from what I have heard.
 
Does anyone else get alot of these?

un 7 18:53:10 dnsmasq-dhcp[527]: DHCPACK(br0) 192.168.1.245 xx:xx:xx:xx:xx:xx R2D2
Jun 7 18:54:29 dnsmasq-dhcp[527]: DHCPREQUEST(br0) 192.168.1.245 xx:xx:xx:xx:xx:xx

I used to get alot from windows 7 hosts, but that got fixed awhile ago, since dhcp-option=252,"\n" was put into the dnsmasq.conf so I didnt have to add it myself.

For some reason I see most of these entries in the log files from an iphone. Anyone else seeing this alot?

These are normal DHCP log entries with iPhones. When idle, iPhones/iPads wireless clients sleeps then when it's awoken it will asks for an ip. It's iPhones way of conserving the battery, they(Apple) designed it to be not always on.
 
I am starting to think it may depend on what CMTS they are on.

Comcast uses Arris, Cisco and Motorola from what I have heard.

I had Comcast switch my CMTS brand thinking this was the case, it wasn't. Their service is just quirky.
 
Has Comcast officially deployed ipV6 or it's still in beta?

Comcast has deployed native v6 in almost all of its markets now and its not beta. I have had comcast v6 for almost 2 years now in my market.
 
I am starting to think it may depend on what CMTS they are on.

Comcast uses Arris, Cisco and Motorola from what I have heard.

It's quite likely to make a difference indeed. AFAIK, the neighbour advertisement flood only happen on some nods, so I suspect there are definitively some differences between nodes.
 
In other words stop reporting it to merlin about comcast and ipv6. Hes told you over and over again and you just will not listen. Go to stock firmware or back to whatever version you "thought" it worked on before and thats it.

If you have a version that works for you for any number of features you use stick with it. If you are willing to try new versions and feature breaks just go back to what you were using.

I don't need you to interpret for him or to be his spokesman. I can read, and I can also deduce that if all other variables are the same, and only one variable changes, and an issue occurs that can be reproduced at will, then something caused by that variable is the issue.

I'm not "blaming" Merlin or anyone else, and I'm very appreciative for the work that he puts into his firmware, but it's pretty obvious that something in the new version, at least in my case (and others apparently), has caused Comcast IPv6 to be an issue.

I assumed, maybe incorrectly, that Merlin and others may want to be aware. Don't blame the messenger for the message. I'll keep my feedback to myself and may just follow your suggestion and go back to the stock firmware or follow through with my plan to buy a Netgear R7000 (and I'm sure no one really cares).
 
I will report to Merlin what ever i want to back off and keep your comments to yourself this does not concern you. Merlin can speak for himself and dont need you to do it for him. I was simply reporting a issue that i have experienced nothing more nothing less.

Howdy,
NOW LISTEN HERE. The problem is with Comcast and your cable modem. Shut off you cable modem for a hour, and your router.... turn it all back on. It will probably work.

Merlin has stated this before, stop wasting bandwidth with your constant problem with IP6. It is not a asus firmware issue.

flame jacket off, off the soap box. :eek:
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top