What's new
By:

  • 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!

traffic manager crazy numbers again 374.41 (Merlin build)

fantom said:
I tried following the build instructions from https://github.com/RMerl/asuswrt-merlin/wiki/Compile-Firmware-from-source-using-Ubuntu on Ubuntu 12.04 32-bit (running natively), but got the following error:

sysdeps/broadcom/broadcom.c:2393: error: 'wl_bss_info_t' has no member named 'vht_cap'

Anyone knows how work around it? I am building for RT-N66U
Click to expand...

Make sure you compile it from within the src-rt-6.x/ folder, since the RT-N66U is now based on the SDK 6.x environment.

Despite having once more configured a PPPoE server within my network, connected a test router to that server and done transfer through it, I'm still unable to reproduce the issue. That's why the best I could do after a whole night dedicated to trying for the third (and last time) was to initialize a few variables that might potentially be used uninitialized.

The issue does seem indeed to start right in rstats itself (and possibly in libshared, as some functions from it are used by rstats). I highly doubt it's inside the webui code.
 
RMerlin said:
Make sure you compile it from within the src-rt-6.x/ folder, since the RT-N66U is now based on the SDK 6.x environment.

Despite having once more configured a PPPoE server within my network, connected a test router to that server and done transfer through it, I'm still unable to reproduce the issue. That's why the best I could do after a whole night dedicated to trying for the third (and last time) was to initialize a few variables that might potentially be used uninitialized.

The issue does seem indeed to start right in rstats itself (and possibly in libshared, as some functions from it are used by rstats). I highly doubt it's inside the webui code.
Click to expand...


Really appreciate the time you put into this.
 
fantom said:
Just to make sure that I am changing ony one variable at a time I merged the rstats fixes (https://github.com/RMerl/asuswrt-merlin/commit/f7803859e9f3dd379e030b64dbb60b5f22545cdf) into the .41 load and it changed the behaviour only slightly: the data points in rstats-speed.js do not seem to be random any more and they just move to the left as they are supposed to do. But the values are still off.
I will poke around a bit more when I have time.
Click to expand...

Did you merge just the rstats changes, or also the shared/misc.c changes?
 
RMerlin, where will "_dprintf" be logging? In syslog?
 
Last edited by a moderator:
fantom said:
RMerlin, where will "_dprintf" be logging? In syslog?
Click to expand...

Serial console. Just replace them with printf if you are not using a serial cable.
 
Anyone knows the exact release when this functionality stopped working? I went from 35_4 (working) to 38_2 (not working), but it would help if someone could help to narrow the releases range...
 
Well, I seem to have "hacked" something working based on .41. I did so by downgrading the release/src/router/shared/misc.c:netdev_calc function to the version from .35_4. I monitored the 24h page for 15 minutes so far and the chart makes sense now. Tested on RT-N66U.
Should work for .42 as well, but have not tried that yet.

Disclaimer: I have no idea what I could have broken by making this change.

RMerlin, I could use your help/suggestions here. Below are the first two log messages from release/src/router/rstats/rstats.c:calc. The first set is for a working use case (.41 with a downgraded netdev_calc) and the second one is for the original .41. Notice that the ppp0 interface is handled differently: it is "ignored" in the first case (working) and is processed in the second case (not working).

I set up my router after a factory reset by going through the wizard, which detects PPPoE and I am wondering if not everything (wan interface, or something like that) is set properly in nvram and that confuses netdev_calc later on? Might also explain why it works for non-PPPoE users as well as why you cannot reproduce the issue if you do not start from a factory reset and the wizard.

Any thoughts that could help with pin-pointing the real issue?

>>>>> .41 with release/src/router/shared/misc.c:netdev_calc downgraded to .35_4

=== lo: 4570 27 0 0 0 0 0 0 4570 27 0 0 0 0 0 0
=== eth0: 1731429 3412 0 0 0 0 0 0 562210 3325 0 0 0 0 0 0
=== eth1: 13141 31 0 0 0 211 0 0 43195 426 2 0 0 0 0 0
>>> eth1, WIRELESS0, 13141, 43195, , 0, 0 <<<
=== eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>> eth2, WIRELESS1, 0, 0, , 0, 0 <<<
=== vlan1: 175115 1637 0 0 0 0 0 7 272334 1297 0 0 0 0 0 0
>>> vlan1, WIRED, 175115, 272334, INTERNET, 1556314, 289876 <<<
=== br0: 350415 3013 0 0 0 0 0 165 1654949 2644 0 0 0 0 0 0
>>> br0, BRIDGE, 350415, 1654949, , 1556314, 289876 <<<
=== wl0.1: 185817 1332 0 0 0 211 0 0 1452813 1797 0 0 0 0 0 0
>>> wl0.1, WIRELESS0.0, 185817, 1452813, , 1556314, 289876 <<<
=== ppp0: 1479613 1749 0 0 0 0 0 0 244732 1995 0 0 0 0 0 0

>>>>> .41 as is

=== lo: 7338 43 0 0 0 0 0 0 7338 43 0 0 0 0 0 0
=== eth0: 716662 4750 0 0 0 0 0 0 771159 4470 0 0 0 0 0 0
=== eth1: 14930 34 0 0 0 579 0 0 59063 578 2 0 0 0 0 0
>>> eth1, WIRELESS0, 14930, 59063, , 0, 0 <<<
=== eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>> eth2, WIRELESS1, 0, 0, , 0, 0 <<<
=== vlan1: 416036 3803 0 0 0 0 0 12 476991 2262 0 0 0 0 0 0
>>> vlan1, WIRED, 416036, 476991, INTERNET, 300626, 294168 <<<
=== br0: 441664 4093 0 0 0 0 0 309 515478 2375 0 0 0 0 0 0
>>> br0, BRIDGE, 441664, 515478, , 300626, 294168 <<<
=== wl0.1: 26460 236 0 0 0 579 0 0 121275 734 0 0 0 0 0 0
>>> wl0.1, WIRELESS0.0, 26460, 121275, , 300626, 294168 <<<
=== ppp0: 205559 897 0 0 0 0 0 0 244878 2151 0 0 0 0 0 0
>>> ppp0, INTERNET, 205559, 244878, , 300626, 294168 <<<
 
BTW, the change in question was introduced in .37 and the code remained the same in all releases including .42 ...
 
fantom said:
Well, I seem to have "hacked" something working based on .41. I did so by downgrading the release/src/router/shared/misc.c:netdev_calc function to the version from .35_4. I monitored the 24h page for 15 minutes so far and the chart makes sense now. Tested on RT-N66U.
Should work for .42 as well, but have not tried that yet.

Disclaimer: I have no idea what I could have broken by making this change.

RMerlin, I could use your help/suggestions here. Below are the first two log messages from release/src/router/rstats/rstats.c:calc. The first set is for a working use case (.41 with a downgraded netdev_calc) and the second one is for the original .41. Notice that the ppp0 interface is handled differently: it is "ignored" in the first case (working) and is processed in the second case (not working).
Click to expand...

netdev_calc() was the latest place where I dug a bit a few days ago in my last attempt. It has some complicated logic implemented so it can substract IPTV traffic based on its VLAN. That's what the rx2/tx2 vars seem to be related to.

Do you have either IPTV or use VLANs? That was one of my theories that could explain why it worked fine for me - I obviously have no IPTV involved in my test setup where I ran a PPPoE server on a VM within my LAN.

Another theory is that the two backup vars that I am now initializing might need to be re-initialized after netdev_calc() has processed all available interfaces.

I'm too tired tonight to take another look at the code, but I suspect that one thing that might have changed between 35 and 37 could be either that IPTV-related support, or Dual WAN support. See if you can trigger/resolve the issue by playing with the Dual WAN settings - that could be one thing that got changed after you did a factory default reset.
 
RMerlin, your last changes in netdev_calc provided me with a lot of information as to where to start looking. That really helped to narrow down the affected area.

Yes, the change I backed out has to do with dual wan and IPTV. I tried enabling dual wan the moment I realized that, but with no success, I did not think about IPTV though. I might try that later to see if enabling IPTV will make any difference (or both).

I am not using IPTV, VLAN, or anything else; I make it a point to disable absolutely all the functionality that I do not use (including nat helpers, etc). So my RT-N66U is configured as a router only without any bells and whistles. Although I do install some custom iptables rules via start scripts

I am hoping you could take a look at the changed code at some point and help with some advice.

The screen shot below shows the 24h chart since midnight when I restarted the router the last time. Finally looks like it is supposed to do.
 

Attachments

  • 24h.jpg
    24h.jpg
    36.4 KB · Views: 243
I want to ask for help from those who are using their router as PPPoE client (and the modem as a bridge), running the newer (not necessarily the newest: v >.40 would work) firmware and have NO issues with their 24h traffic manager page: can you pls provide a text export of your nvram so that I can compare the values and see what could be causing the failure for me and others? Right now there is a suspicious that there is config param that confuses this page and if I can locate it, we could work around the issue without any code changes.

This is the procedure that can be followed to make sure no private information is shared.

1. Export you current config so that you can quickly restore at the end
2. Perform a factory reset
3. Configure PPPoE using the wizard and enter some dummy wireless info
4. Run some traffic and monitor the 24h page for about 10 minutes; that is enough to see the issue or the lack of it
5. If no issues noticed, export nvram "nvram show > /tmp/nvram.dmp"
6. Copy the /tmp/nvram.dmp file to USB or your computer
7. Delete your PPPoE name and password from the file
8. Restore the router to the original state be reloading the config from the backup made in step #1

I would prefer the export from a RT-N66* so that I could compare apples to apples. There was a person on this thread (sinshiva) who seem to be running RT-N66R with no issues. There could be others with RT-N66U. RMerlin, maybe you could share your config?

P.S. I think this forum allows sending private messages, although I never tried.
 
Last edited by a moderator:
I am sure if I make my modem a PPPoE client, thenthe issue wll go away...

BTW for those interested, .42 has the same problem and can be "fixed" the same way.
 
Try this modification in netdev_calc(), resetting the two backup vars after they get used:

Code: 
                // special handle for non-tag wan of broadcom solution
                // pretend vlanX is must called after ethX
                if(nvram_match("switch_wantag", "none")) { //Don't calc if select IPTV
                        if(strlen(modelvlan) && strcmp(ifname, modelvlan)==0) {
                                backup_rx -= *rx;
                                backup_tx -= *tx;

                                *rx2 = backup_rx;
                                *tx2 = backup_tx;                               

                                backup_rx = 0;
                                backup_tx = 0;

                                strcpy(ifname_desc2, "INTERNET");
                        }
                }//End of switch_wantag
                return 1;
 
Here is what is happening:

1. "rstats.c:calc" is expected to ignore all traffic from ppp0, because as far at it is concerned ppp0 is not a WAN interface.

2. "shared/misc.c:netdev_calc" used to return 0 for "ifname==ppp0" because the statement below (from 35_2) would never evaluate to true ("wan_ifnames=eth0" for PPPoE) and "netdev_calc" would execute "return 0" at the end of the method.

// find in WAN interface
else if(nvram_match("wan0_primary", "1") && nvram_contains_word("wan_ifnames", ifname))

3. The new behaviour of netdev_calc is different: it treats ppp0 as a WAN interface: get_wan_unit in the statement below would return WAN_UNIT_FIRST for _both_ eth0 and ppp0, which is a significant change for rstats. Once this evaluates to true, netdev_calc returns 1 at line 1158 (in .42). That confuses rstats.c to no limit.

// find in WAN interface
else if (ifname && (unit = get_wan_unit(ifname)) >= 0)

4. Below is a fix that I made locally in rstats.c:calc to check for the ppp0 interface before netdev_calc is invoked. I considered making the fix outside of rstats.c, but the logic is quite complicated and confusing.

if(!strncmp(ifname, "ppp", 3))
continue;

if(!netdev_calc(ifname, ifname_desc, &counter[0], &counter[1], ifname_desc2, &rx2, &tx2))
continue;


RMerlin, your thoughts?
 
You must log in or register to reply here.

Similar threads

B
Traffic Analyzer: Different results between Global and Per Device
Replies
4
Views
2K
RMerlin
RMerlin
K
Yet another ugly clone of Asuswrt-Merlin firmware (extremely outdated now)
Replies
3
Views
3K
Kobold
K
Similar threads
Thread starter Title Forum Replies Date
i0ntempest IPv6 traffic forwarding problem: connection hangs Asuswrt-Merlin 9
N Forward only specific port's traffic to Wireguard VPN Asuswrt-Merlin 1
M How to NAT traffic inbound to a specific host or network ? Asuswrt-Merlin 6
Celico Routing only traffic to specific IP through VPN? Asuswrt-Merlin 7
G Using VPN Director to route only torrent traffic through VPN Asuswrt-Merlin 9
H Asus RT-AX58U v2 Merlin: Route all traffic to Pi-hole (running directly on router itself) Asuswrt-Merlin 12
L How can I monitor all Ip traffic from my wyze camera in Merlin? Asuswrt-Merlin 2
M RT-AX88U_PRO Traffic Monitor does not work Asuswrt-Merlin 6
W AX56U traffic log questions. Asuswrt-Merlin 6
M Merlin GT-AX11000 Internet Up But No Traffic Passing Asuswrt-Merlin 12

Similar threads

Latest threads

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!

Members online

Total: 530 (members: 28, guests: 502)
Back
Top