I have tracked down the jffs problem with the funny characters in the status page. Apparently by default when the space is first created, there is so little used that it doesn't display a correct value I found by copying a file, or file(s) that take a couple of megs to /jffs using scp corrects the problem and the space is correctly displayed. For example I used the netgear-r7000-webflash.bin in my test, but any file should work. it just seems that the only thing here is that the space used need to be at least a MB, or 2.
I'm not sure if this is a fault of DD-WRT, or JFFS, however, I just wanted to post this note for information.
Hope this helps.
P.S. I was able to discover this by initially enabling jffs and having a valid value displayed then I sshd into the router, and found that the jffs space had the stuff from the stock firmware still there such as circle, etc. After clearing the jffs space, that's when the strange characters came back, and then i did the above test to show what was going on. Router used in this test was Netgear R7000.
Joined: 26 Mar 2013 Posts: 1855 Location: Hung Hom, Hong Kong
Posted: Tue Jun 23, 2020 8:28 Post subject:
iFrog wrote:
Hey all, just a quick note here:
I have tracked down the jffs problem with the funny characters in the status page. Apparently by default when the space is first created, there is so little used that it doesn't display a correct value I found by copying a file, or file(s) that take a couple of megs to /jffs using scp corrects the problem and the space is correctly displayed. For example I used the netgear-r7000-webflash.bin in my test, but any file should work. it just seems that the only thing here is that the space used need to be at least a MB, or 2.
I'm not sure if this is a fault of DD-WRT, or JFFS, however, I just wanted to post this note for information.
I still would bet that it's just a Javascript bug, a function named scaleSize(x)! In my Status -> Router:
scaleSize(x) is defined in common.js! And it called another function comma(e), also in common.js!
Code:
function scaleSize(e){
if(isNaN(e*=1))return"-";if(e<=9999)return""+e;for(var t=-1;++t,9999<(e/=1e3)&&t<2;);return comma(e.toFixed(2))+"<small> "+["kB","MB","GB"][t]+"</small>"
}
Did you notice the "$1 $2" inside comma(e) below?
Code:
function comma(e){
for(var t=e=""+e;(e=e.replace(/(\d+)(\d{3})/g,"$1 $2"))!=t;)t=e;return e
}
" " is not needed at all? Wanted a comma? To avoid HTML character display problem? Could it have just used HTML entity "\&\#44;"? '\' is for display purpose!
Should I open a SVN? Someone? kernel-panic69?
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
I have tracked down the jffs problem with the funny characters in the status page. Apparently by default when the space is first created, there is so little used that it doesn't display a correct value I found by copying a file, or file(s) that take a couple of megs to /jffs using scp corrects the problem and the space is correctly displayed. For example I used the netgear-r7000-webflash.bin in my test, but any file should work. it just seems that the only thing here is that the space used need to be at least a MB, or 2.
I'm not sure if this is a fault of DD-WRT, or JFFS, however, I just wanted to post this note for information.
I still would bet that it's just a Javascript bug, a function named scaleSize(x)! In my Status -> Router:
scaleSize(x) is defined in common.js! And it called another function comma(e), also in common.js!
Code:
function scaleSize(e){
if(isNaN(e*=1))return"-";if(e<=9999)return""+e;for(var t=-1;++t,9999<(e/=1e3)&&t<2;);return comma(e.toFixed(2))+"<small> "+["kB","MB","GB"][t]+"</small>"
}
Did you notice the "$1 $2" inside comma(e) below?
Code:
function comma(e){
for(var t=e=""+e;(e=e.replace(/(\d+)(\d{3})/g,"$1 $2"))!=t;)t=e;return e
}
" " is not needed at all? Wanted a comma? To avoid HTML character display problem? Could it have just used HTML entity "\&\#44;"? '\' is for display purpose!
Should I open a SVN? Someone? kernel-panic69?
Yep, I noticed the syntax. It's been a while since i've done any sort of web development. Anyway, the router seems to be working normally, and this is just cosmetic, I just wanted to let people know that based on the tests I did i was able to find out at least in part what was going on. I also wanted to mention that the 0 count problem with the wifi interface status I reported a couple builds back, was probably not a problem for me after all. I was looking at the wrong channel with no wireless clients connected. Once I that, I changed the interface being viewed, and all was normal, and as expected.
Joined: 26 Mar 2013 Posts: 1855 Location: Hung Hom, Hong Kong
Posted: Tue Jun 23, 2020 10:50 Post subject:
iFrog wrote:
Yep, I noticed the syntax. It's been a while since i've done any sort of web development. Anyway, the router seems to be working normally, and this is just cosmetic, I just wanted to let people know that based on the tests I did i was able to find out at least in part what was going on. I also wanted to mention that the 0 count problem with the wifi interface status I reported a couple builds back, was probably not a problem for me after all. I was looking at the wrong channel with no wireless clients connected. Once I that, I changed the interface being viewed, and all was normal, and as expected.
Are you familiar with Javascript? If you had time, kindly join DD-WRT's developers! YOu might be table to improve its WEBUI at least.
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Yep, I noticed the syntax. It's been a while since i've done any sort of web development. Anyway, the router seems to be working normally, and this is just cosmetic, I just wanted to let people know that based on the tests I did i was able to find out at least in part what was going on. I also wanted to mention that the 0 count problem with the wifi interface status I reported a couple builds back, was probably not a problem for me after all. I was looking at the wrong channel with no wireless clients connected. Once I that, I changed the interface being viewed, and all was normal, and as expected.
Are you familiar with Javascript? If you had time, kindly join DD-WRT's developers! YOu might be table to improve its WEBUI at least.
I mainly did HTML, and basic JS, but that was back in 1998 or a little before. The main language I played with was BASIC. I will continue to report problems though, and any solutions to them, I come up with.
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Tue Jun 23, 2020 11:13 Post subject:
mwchang wrote:
iFrog wrote:
Hey all, just a quick note here:
I have tracked down the jffs problem with the funny characters in the status page. Apparently by default when the space is first created, there is so little used that it doesn't display a correct value I found by copying a file, or file(s) that take a couple of megs to /jffs using scp corrects the problem and the space is correctly displayed. For example I used the netgear-r7000-webflash.bin in my test, but any file should work. it just seems that the only thing here is that the space used need to be at least a MB, or 2.
I'm not sure if this is a fault of DD-WRT, or JFFS, however, I just wanted to post this note for information.
I still would bet that it's just a Javascript bug, a function named scaleSize(x)! In my Status -> Router:
scaleSize(x) is defined in common.js! And it called another function comma(e), also in common.js!
Code:
function scaleSize(e){
if(isNaN(e*=1))return"-";if(e<=9999)return""+e;for(var t=-1;++t,9999<(e/=1e3)&&t<2;);return comma(e.toFixed(2))+"<small> "+["kB","MB","GB"][t]+"</small>"
}
Did you notice the "$1 $2" inside comma(e) below?
Code:
function comma(e){
for(var t=e=""+e;(e=e.replace(/(\d+)(\d{3})/g,"$1 $2"))!=t;)t=e;return e
}
" " is not needed at all? Wanted a comma? To avoid HTML character display problem? Could it have just used HTML entity "\&\#44;"? '\' is for display purpose!
Should I open a SVN? Someone? kernel-panic69?
the problem is. there is no such funny character in the sourcecode
Quote:
function comma(n)
{
n = '' + n;
var p = n;
while ((n = n.replace(/(\d+)(\d{3})/g, '$1\u202f$2')) != p) p = n;
return n;
}
Router/Version: Netgear r7000
Firmware: DD-WRT v3.0-r43471 std (06/19/20)
Kernel: Linux 4.4.227 #372 SMP Fri Jun 19 09:01:04 +04 2020 armv7l
Previous: DD-WRT v3.0-r40559 std (08/06/19)
Mode/Status: Wireless bridge / working
Reset: yes, before flashing but only cos I couldn't recall it's address
Issues/Errors: 1 GUI hiccup, but otherwise working well so far. 60-65MB/s throughput on SMB file copies when linked to one of the 5ghz channels on my r8000.
Uptime: variable, but reliable (has had multiple testing reboots through today)
Temperatures: Oops, didn't note them.
iFrog wrote:
I have tracked down the jffs problem with the funny characters in the status page.
I setup a USB for this r7000 - 2Gb Optware, 2GB jffs, 1GB swap, 9.something GB fat32 for NAS duties.
GUI was reporting /jffs as 2EB (presumably exabytes) of the 2GB partition. Fix was similar to iFrog - copy 300mb of files to it and reporting self-corrected.
Router/Version: Netgear r7000
Firmware: DD-WRT v3.0-r43471 std (06/19/20)
Kernel: Linux 4.4.227 #372 SMP Fri Jun 19 09:01:04 +04 2020 armv7l
Previous: DD-WRT v3.0-r40559 std (08/06/19)
Mode/Status: Wireless bridge / working
Reset: yes, before flashing but only cos I couldn't recall it's address
Issues/Errors: 1 GUI hiccup, but otherwise working well so far. 60-65MB/s throughput on SMB file copies when linked to one of the 5ghz channels on my r8000.
Uptime: variable, but reliable (has had multiple testing reboots through today)
Temperatures: Oops, didn't note them.
iFrog wrote:
I have tracked down the jffs problem with the funny characters in the status page.
I setup a USB for this r7000 - 2Gb Optware, 2GB jffs, 1GB swap, 9.something GB fat32 for NAS duties.
GUI was reporting /jffs as 2EB (presumably exabytes) of the 2GB partition. Fix was similar to iFrog - copy 300mb of files to it and reporting self-corrected.
It reverts if you remove the data, so, seems like it's a space reporting issue when there isn't much used on JFFS2. Glad to see though, the issue can be reproduced, and corrected in the same way by others though.
Firmware: v3.0-r43471 std (06/19/20)
Router/Version: Netgear R7000 Kernel: Linux 4.4.227 #372 SMP Fri Jun 19 09:01:04 +04 2020 armv7l
Previous: v3.0-r43381 std (06/10/20)
Mode/Status: AP wired and wireless, Up and running for 1 days
Reset: Soft boot before and after upgrade
Temperatures: CPU 61.9 °C / WL0 46.9 °C / WL1 52.3 °C
Issues/Errors: Nothing significant
Updated via webif. No 'nvram erase' this time, last one was in July 2018 (r36325).
The minor issue with the zero packet count on wl0 has returned, and "Connected Clients" is stuck at zero. The wl1 counts seem correct.
Upload and Download speeds are good.
Seems like a good build.
Current basic R7000 setup (subject to change of course):
- Static WAN IP
- SFE - On
- STP - On
- IPv4 only, both WAN and LAN
- LAN DHCP Enabled
- Wireless: AP, Regulatory Domain = CANADA, wl0 Mixed (ch. 6), wl1 AC/N-Mixed (ch. 149, VHT80), AES
- 1 wireless VLAN on wl0
- SNMP disabled, SSH enabled, Telnet disabled
- Firewall enabled, Log Level high
- Syslog: to local server. klogd: disabled.
- USB support - Off
- No custom scripts
- NO: ttraf, Tor, VNC, Zabbix, VPN, Radius
- NO: UPnP, DMZ, QoS
- NO: Samba, CIFS, JFFS2, miniDLNA, Entware, Optware _________________ Netgear R7000: v3.0-r54248 std (11/29/23)
EdgeRouter-X: EdgeOS v2.0.9-hotfix 7
Joined: 26 Mar 2013 Posts: 1855 Location: Hung Hom, Hong Kong
Posted: Tue Jun 23, 2020 14:49 Post subject:
BrainSlayer wrote:
mwchang wrote:
Did you notice the "$1 $2" inside comma(e) below?
Code:
function comma(e){
for(var t=e=""+e;(e=e.replace(/(\d+)(\d{3})/g,"$1 $2"))!=t;)t=e;return e
}
" " is not needed at all? Wanted a comma? To avoid HTML character display problem? Could it have just used HTML entity "\&\#44;"? '\' is for display purpose!
Should I open a SVN? Someone? kernel-panic69?
the problem is. there is no such funny character in the sourcecode
Quote:
function comma(n)
{
n = '' + n;
var p = n;
while ((n = n.replace(/(\d+)(\d{3})/g, '$1\u202f$2')) != p) p = n;
return n;
}
So the Unicode character "\u2020f" (NARROW NO-BREAK SPACE) was translated into something else, possibly by the HTML character escape fix related to Admin->Command many builds ago?
Should we just put a " " there and see how it goes?
Comments from any web developers here? Meow...
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Joined: 21 Nov 2013 Posts: 65 Location: Cathedral City, CA, USA
Posted: Wed Jun 24, 2020 0:51 Post subject:
BrainSlayer wrote:
the problem is. there is no such funny character in the sourcecode
Quote:
function comma(n)
{
n = '' + n;
var p = n;
while ((n = n.replace(/(\d+)(\d{3})/g, '$1\u202f$2')) != p) p = n;
return n;
}
What I see is the garbage characters in the field are not following the function scaleSize(e), as my first field JFFS used will show MB (used) and then in second field it still shows garbage with MB at the end, my JFFS is 8 GB, so maybe the length of digits add the extra garbage into the displayed number and overflowing the field. If I add enough files to go over the MB threshold in first field (jffs used) it will switch to garbage with MB still at the end. I can reproduce this easily. Since that function is using KB, MB, GB to be added to the end of the jffs space used field and jffs total field there is something causing an issue. I also notice KiB is used in the RAM fields on same screen. IDK just my two cents.
Thanks for the great work on these builds! _________________ Router/Version: Netgear R7800
File/Kernel: DD-WRT v3.0-r50671 std (10/26/22), Linux 4.9.330 #1313 SMP Wed Oct 26 05:13:03 +07 2022 armv7l
Joined: 26 Mar 2013 Posts: 1855 Location: Hung Hom, Hong Kong
Posted: Fri Jun 26, 2020 16:13 Post subject:
pandemonium420 wrote:
What I see is the garbage characters in the field are not following the function scaleSize(e), as my first field JFFS used will show MB (used) and then in second field it still shows garbage with MB at the end, my JFFS is 8 GB, so maybe the length of digits add the extra garbage into the displayed number and overflowing the field. If I add enough files to go over the MB threshold in first field (jffs used) it will switch to garbage with MB still at the end. I can reproduce this easily. Since that function is using KB, MB, GB to be added to the end of the jffs space used field and jffs total field there is something causing an issue. I also notice KiB is used in the RAM fields on same screen. IDK just my two cents.
The simplest solution is to just display the numbers, not using any units (KB, MB, GB)! That saves some debugging and testing time. I wondered who requested that feature in the very beginning.
The use of units also could cause confusion: should it use binary or decimal system? Do you notice that hard disk size is specified in decimal numbers(1K is 1000 not 1024)?
Anyway, I read that that strange string was actually just a comma. It's been fixed in build 43516. Well... onto the next minor bug! Meow...
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!