Asuswrt-Merlin 384.8 is now available

[RMerlin]

I uploaded a few early test builds. Gathering further feedback before finalizing a point release, so 384.8_2 won't be out for at least a couple of days.

 

[Benoitone]

I uploaded a few early test builds. Gathering further feedback before finalizing a point release, so 384.8_2 won't be out for at least a couple of days.

Thanks for this build.
VPN Server apply button work fine...
And french language too...
For me...
Good job!!!

 

[el pescador]

AC88U
Checked twice now.
Last night and this morning.

WTfast is causing both CPU's to spike upto 100% when on.

Played a game of Battlefield on ps4 last night.
1st game superb.
Next the network vrtn stated jumping about.

 

[fbusa2012]

RT-AC5300
Tried the test build, dnsmasq still fail to start up with dhcp-boot statement.

 

[RMerlin]

RT-AC5300
Tried the test build, dnsmasq still fail to start up with dhcp-boot statement.

Double check your configuration. This is entirely handled by dnsmasq itself, and has nothing to do with the firmware code itself.

 

[Le_Sage]

Hello,
For me I've upgraded to 384.8 from 384.7_2 on my AC88U but there is a lot of problem in French language (some data doesn't appear and some apply button don't work), even after factory reset..
In English Language no problem.
I've tested test build 384.8_1 and it work back in French!
Thanks!

 

[eclp]

Someone else just left it for 8 hours and it disappeared on its own.

With me, even after 24 hours nothing has changed.
Does anyone else have the suggestion of removing the flashing, annoying yellow exclamation mark?

 

[D_Day]

With me, even after 24 hours nothing has changed.
Does anyone else have the suggestion of removing the flashing, annoying yellow exclamation mark?

Try updating to the 384.8_1, maybe that might help.

 

[DroidST]

Always worked fine.

With me, even after 24 hours nothing has changed.
Does anyone else have the suggestion of removing the flashing, annoying yellow exclamation mark?

Did you check and disable

Tools | Other Settings | New firmware version check ?

Also for beta checks

 

[RMerlin]

With me, even after 24 hours nothing has changed.
Does anyone else have the suggestion of removing the flashing, annoying yellow exclamation mark?

Click on the Check button on the Firmware Upgrade page.

Also make sure you really are running 384.8.

For me I've upgraded to 384.8 from 384.7_2 on my AC88U but there is a lot of problem in French language (some data doesn't appear and some apply button don't work), even after factory reset..

Please read previous posts in this thread, already discussed at length.

 

[eclp]

Click on the Check button on the Firmware Upgrade page.

Also make sure you really are running 384.8.

 

[fbusa2012]

Double check your configuration. This is entirely handled by dnsmasq itself, and has nothing to do with the firmware code itself.

The same configuration was working on 384.7. I think the newest dnsmasq come with 384.8 causing it. I comment out the statement for now as I am not using PXE very often. If there is a newest dnsmasq version, I will try again. I am good now.

Thank you

 

[FLA_NL]

With me, even after 24 hours nothing has changed.
Does anyone else have the suggestion of removing the flashing, annoying yellow exclamation mark?

After updating it was also flashing still flashing on my router, however it was gone after I turned the router off, unplug the power, turn the power button on for 10 sec. Then turn it off again, plug the power in again, and then turn it on. Forgot what the name of this method is, maybe that helps for you also...

 

[RMerlin]

Post the output of these commands:

nvram show | grep webs_
cat /tmp/webs_upgrade.log

 

[eclp]

ASUSWRT-Merlin RT-AC88U 384.8-0 Sun Dec  2 18:39:58 UTC 2018
12345@RT-AC88U-A5:/tmp/home/root# nvram show | grep webs_
webs_notif_flag=
webs_last_info=
webs_state_update=
webs_state_odm=0
webs_state_url=
webs_state_flag=1
webs_state_error=
webs_state_upgrade=
size: 68510 bytes (62562 left)

12345@RT-AC88U-A5:/tmp/home/root# cat /tmp/webs_upgrade.log
cat: can't open '/tmp/webs_upgrade.log': No such file or directory

 

[RMerlin]

ASUSWRT-Merlin RT-AC88U 384.8-0 Sun Dec  2 18:39:58 UTC 2018
12345@RT-AC88U-A5:/tmp/home/root# nvram show | grep webs_
webs_notif_flag=
webs_last_info=
webs_state_update=
webs_state_odm=0
webs_state_url=
webs_state_flag=1
webs_state_error=
webs_state_upgrade=
size: 68510 bytes (62562 left)

12345@RT-AC88U-A5:/tmp/home/root# cat /tmp/webs_upgrade.log
cat: can't open '/tmp/webs_upgrade.log': No such file or directory

Something seems to be preventing your router from reaching the update server, as there are no webs_upgrade log. You can manually set the flag:

nvram set webs_state_error=0
nvram set webs_state_flag=0
nvram set webs_state_info=384_8_0
nvram set webs_state_info_beta=384_8_beta2
nvram set webs_state_update=1
nvram commit

 

[RMerlin]

RT-AC5300
Tried the test build, dnsmasq still fail to start up with dhcp-boot statement.

The bug lies in dnsmasq, caused by a recent change they made. That change will be temporarily reverted while the dnsmasq author sorts it out.

 

[dugaduga]

Saw this for about 30 min after updating to the latest fw. Didn't notice it at all till the next day, everything seemed fine last night.

Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:31 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: net_ratelimit: 95 callbacks suppressed
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:42 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: net_ratelimit: 244 callbacks suppressed
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:47 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: net_ratelimit: 37 callbacks suppressed
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:30:56 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: net_ratelimit: 246 callbacks suppressed
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:01 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: net_ratelimit: 108 callbacks suppressed
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:10 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:16 kernel: net_ratelimit: 100 callbacks suppressed
Dec 4 19:31:16 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:16 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:16 kernel: TCP: time wait bucket table overflow
Dec 4 19:31:16 kernel: TCP: time wait bucket table overflow

 

[hs222]

The problem is, some strings requires escaping, and others must not be escaped or it will show the actual backslash in the text, so it's not as easy as just doing a global search & replace.

Asus doesn't do much testing on non-English translations (and neither do my beta-testers since that issue wasn't spotted during the 3+ weeks of beta test), so every once in a while a translated string will break something. French and Italian are two languages that broke a few times over the past couple of years.

Hello,
yes that's true, escaping depends how the string is used and when writing localization strings it's not always easy to check how it is (or will be) used in the code.
So I've written a shell script to find dictionnary entries with unescaped single quotes that are used somewhere in code between single quotes.
I'm not a shell nor a regexp expert, so it's not perfect but at least it seems to perform a pretty good detection even if some are false alarms.

here's the script

#checkdict
#!/bin/sh
dict=$1
scannedfiles="/www/*.asp /www/*.htm /www/*.js"

allplaceholderfile=/tmp/allplho.$$
checkcmdfile=/tmp/checkcmd.$$

egrep -s ${scannedfiles}  -e "((.*<#[0-9]+#>.*).*?)'" > ${allplaceholderfile}

echo "#!/bin/sh" > ${checkcmdfile}
grep -n  [^\\][\'] /www/$dict | awk -F : '{print "egrep -s ${allplaceholderfile}  -e \"\x27((.*<#"$1-1"#>.*).*?)\x27\"";}' >> ${checkcmdfile}
source ${checkcmdfile}

rm ${allplaceholderfile}
rm ${checkcmdfile}

I run this shell script from a router session but of course it should be adapted to be run from the dev environment.

usage is : source ./checkdict FR.dict

and here is aresult for FR.dict

/www/start_apply2.htm:setTimeout("parent.parent.document.getElementById('drword').innerHTML = '<#160#><br/><br/>'", 10000);
/www/Advanced_VPNClient_Content.asp:code +="<td width='10%'><img title='<#411#>' src='/images/button-close2.png' style='width:25px;'></td>";
/www/Advanced_VPNClient_Content.asp:code +="<td width='10%'><img title='<#411#>' src='/images/button-close2.png' style='width:25px;'></td>";
/www/general.js:var default_hostname_label = '<a class="hintstyle" href="javascript:void(0);" onClick="openHint(5,13);"><#1912#></a>';
/www/Nologin.asp:return '<#1966#> ' + loginUserIp + hostName;
/www/Restarting.asp:parent.document.getElementById('drword').innerHTML = "<#2372#><br/>".replace("192.168.1.1", '<% nvram_default_get("lan_ipaddr"); %>');

once the result displayed it's easy to double check and see that all but the last one are real issues and should be fixed in the dictionnary
(obviously I don't need to say, entry <%N%> is refering to line N+1 in FR.dict)

best regards,
jerome

 

[RMerlin]

and here is aresult for FR.dict

Thanks for checking.

Might be interesting to test within the dev environment instead and see what happens with the unprocessed webpages, so instead of line numbers we will get actual labels.

In the general.js case, the issue was introduced by me, when I added custom DDNS labeling during 384.8 development, so fixing this within general.js was the most logical solution. I'll try to investigate the other reported entries to see if they are false positive or genuine issues.