What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

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

Can u edit your client list names ?, have 2 ps3 console that only display numbers, like to name them ps3, is that impossible, or do i have to ask ethan hunt :)

You can do that by "reserving" an IP for them. Generally, I just "reserve" the IP that they currently have using this facility at the bottom of the "LAN" -> "DHCP Server" page. First you enable reserving IP addresses, then you add the specific ones (identified by MAC address) that you want to name using the "+" sign for each one, and then clicking on "Apply" when you're done adding IP address reservations. The name that you give each entry that you add will appear in your client list, and in the DHCP lease log. Nicely implemented, and very useful for naming clients that don't supply identifiable names.

One of the cool things about how this was implemented is that there's a dropdown list for picking out the MAC addresses when adding a client, so you don't generally have to type them in when you add existing devices to this list.
 
Have you updated your laptop to Win10 recently? I don't know anything specific here, but we're still learning about Win10 quirks.
W10 have a habit of assigning "public network" to connections without asking that breaks networking discovery and file and printer sharing.
 
W10 have a habit of assigning "public network" to connections without asking that breaks networking discovery and file and printer sharing.

Yes, running the "HomeGroup Troubleshooter" is an easy way to get that switched back from "Public" to "Private". You can skip the network troubleshooting, and just let it find that your network is "Public", and allow it to switch it back to "Private".
 
I'm curious if anyone with an RT-AC68P has carefully looked at their traffic monitor graphs, especially while doing a speed test or streaming media and finds the "realtime" and the "last 24 hours" graphs to be correct...including looking at the "internet"/"wired"/2.4GHz./5GHz. wireless breakdowns? My traffic monitor graphs are just wrong, so wrong *smile*.

Thanks!
 
Last edited:
I'm curious if anyone with an RT-AC68P has carefully looked at their traffic monitor graphs, especially while doing a speed test or streaming media and finds the "realtime" and the "last 24 hours" graphs to be correct...including looking at the "internet"/"wired"/2.4GHz./5GHz. wireless breakdowns? My traffic monitor graphs are just wrong, so wrong *smile*.

Thanks!

I just ran a few speedtests off my phone while looking at the real-time graphs, and they seem to match up.

When I then clicked over to the Last 24 hours, I assumed the Speedtests would show up (under the max transmission) but they did not, other than that, everything seemed to be accurate.

What are you seeing?
 
I just ran a few speedtests off my phone while looking at the real-time graphs, and they seem to match up.

When I then clicked over to the Last 24 hours, I assumed the Speedtests would show up (under the max transmission) but they did not, other than that, everything seemed to be accurate.

What are you seeing?

I'm seeing that the last 24 hours is not at all accurate, in that I see the speed tests go up to 180Mbps, and am lucky to see 70Mbps on the "last 24 hours". And the wired + wireless do not add up to what's on the "internet" graph for the "last 24 hours". Also, if I watch things with the realtime monitoring while I'm running a speed test, the speed test will show up on the "internet" graph (inaccurately), but not the "wired" graph at all (I'm using a wired desktop). And the "last 24 hours" wireless graphs are much sparser than my activity with my mobile devices, while a lot of activity shows up on the "internet" graph (even though it is inaccurate).

So the traffic data graphs are really messed up, useless for me. Tried a lot of things, factory reset and re-entering settings, changing where I store the traffic data, switching my desktop from hard-wired to wireless and looking at that, nothing changes the gross inaccuracy I see. I'm thinking of switching over to tomato on the R7000 again, since traffic monitoring works well there, and the wireless is comparable. And I do look at these graphs to see what's going on, most likely too much. Since this Asus router is otherwise very functional, I haven't switched yet, but will probably do so soon. I haven't looked at this issue on the latest RMerlin yet, but the wireless is better on this fork so am not strongly motivated to do that.
 
Last edited:
Remember that the last 24 hour graph has the data averaged over the display interval (I'd have to check what it is...I forget off the top of my head)... so it will generally be much less than the peaks you see on the realtime graph unless you are doing long sustained transfers.

I also took a look at the latest Merlin code to double check if they had sneaked any 68P specific code in (they haven't).

Are you doing anything special with QoS? Any special VLAN setup? And I think you said you were DHCP connect, as opposed to PPPoE? There were some problems in the past with PPPoE and traffic monitor, but as far as I know the fork has all the fixes.

EDIT: It would be interesting to see if the latest Merlin behaves the same....at least it would confirm some change that I could try and track down or say it's something unique to your configuration.
 
Last edited:
Remember that the last 24 hour graph has the data averaged over the display interval (I'd have to check what it is...I forget off the top of my head)... so it will generally be much less than the peaks you see on the realtime graph unless you are doing long sustained transfers.

I also took a look at the latest Merlin code to double check if they had sneaked any 68P specific code in (they haven't).

Are you doing anything special with QoS? Any special VLAN setup? And I think you said you were DHCP connect, as opposed to PPPoE? There were some problems in the past with PPPoE and traffic monitor, but as far as I know the fork has all the fixes.

EDIT: It would be interesting to see if the latest Merlin behaves the same....at least it would confirm some change that I could try and track down or say it's something unique to your configuration.

My configuration here is vanilla...auto DHCP connection, no QoS, no VLAN setup, no VPN, no dlna. Just routing and wireless, that's all I need *smile*. I do use dual-stack IPv4/6, that's about it.

Okay, I'll try the latest RMerlin here, and see what I see
 
My configuration here is vanilla...auto DHCP connection, no QoS, no VLAN setup, no VPN, no dlna. Just routing and wireless, that's all I need *smile*. I do use dual-stack IPv4/6, that's about it.

Okay, I'll try the latest RMerlin here, and see what I see

Just flashed and set up latest RMerlin. Same thing, running a speed test and did not show up in the realtime "wired" graph at all, but did show up on realtime "Ethernet WAN" graph. Then read the note about CTF, so turned that off and rebooted, same results.

One odd thing I noticed on the realtime "Ethernet WAN" graph, showed my download rate going up to 2GBps...odd that, not exactly what I expected, either. Right now the realtime graph is showing pretty intense transfer spikes, up to 2GBps, that my system task manager performance monitoring is not showing. So unless I have the NSA busily sending someone that I don't know lots and lots of data, this ones actually worse than the fork.
 
Last edited:
One odd thing I noticed on the realtime "Ethernet WAN" graph, showed my download rate going up to 2GBps...odd that, not exactly what I expected, either.
Interesting....as far as the above comment, the fork has code that filters out obviously bad data that isn't in Merlin. I spent days trying to track that one down (I had seen that myself...I think it's a counter wrapping somewhere), but finally gave up and just added the filter.

Now, sorry for this question...but have to ask after thinking about this for a while. Are you sure you have the modem plugged into the WAN port and the Ethernet into the Ethernet port?
 
Interesting....as far as the above comment, the fork has code that filters out obviously bad data that isn't in Merlin. I spent days trying to track that one down (I had seen that myself...I think it's a counter wrapping somewhere), but finally gave up and just added the filter.

Now, sorry for this question...but have to ask after thinking about this for a while. Are you sure you have the modem plugged into the WAN port and the Ethernet into the Ethernet port?

I think I'm done here *smile*. This isn't helping anyone, and I feel like I'm wasting multiple people's time with it. Sorry to waste yours, you have things to work on that you can make forward progress with. I was just trying to find out if others with the same router were having similar problems. The response that I got indicated that person was seeing stuff on the realtime graphs that I'm not (if they looked at the "wired" and "wireless" graphs as well as the "internet" graph).

So I guess that there's stuff going on here that's screwing up my traffic monitoring. I've decided to move on with this one, otherwise the router works really well. So it goes. I need to decide what the value of the traffic data is to me, and do the appropriate thing.

Again, thanks, sorry for taking up your time.
 
@RogerSC - No need to apologize....I hate unsolved mysteries and don't mind spending the time. I'll keep thinking about it.
 
@RogerSC - No need to apologize....I hate unsolved mysteries and don't mind spending the time. I'll keep thinking about it.

Okay...Just switched back to the R7000 with tomato. Traffic monitoring graphs and data are working well there, not as pretty, but having them do what I expect has a lot of value to me. I'll come back to the RT-AC68P at some point, or maybe try tomato on the 68P and see how the traffic data works there.
 
Hi all, I'm a newbie on the (great!) fork software.
Loaded it in my RT-N66 and encountered 2 strange things I cannot seem to resolve.

I'm not able to select 2.4 MHz channels manually. In the GUI it changes and seems to be adjusted. Checking with wireless monitor tool tells me it allways stays on channel 6, whatever channel I choose. I tried reloading to latest Asus software, then it does work fine. Going back to latest Fork again only channel 6.

The other problem: I adjusted trx power via telnet and GUI to 200 mw according to some of the posts here.
There is really no diference in db's, again checked with the wireless monitor tool.
After reloading fork testing the channel problem as described above, in the GUI I checked the value, it is still on the initial value of 80mW.
But the measured value in the wireless monitor tool is up from -66 to -59 dBm.
Checking in telnet via "wl txpwr" gives a me value of 31.75 db /1496 mW. Rather high as "wl txpwr_limit" gives me 200mW max. What am I seeing?
 
Last edited:
Reloaded the latetst fork and did a factory reset and configured the router from scratch. After that I adjusted the country regulation settings accordingly the post on page 3 of this topic via telnet.
Now channelswitching works. Except channel 14, then it falls back to 6 again.... Anyone?
Powersettings in GUI indeed changes the values measured via my wireless monitoring tool, so it looks ok.
Stil seeing 31.75 db /1496 mW when using "wl txpwr". Can't find an explanation for those values
 
Quick question: Is it normal for the router (latest fork) to publish the MAC address of the LAN to the cable modem (WAN) side? My cable modem lists two (2) known CPE MAC addresses, one from the WAN and one from the LAN of the router.

Just curious as to why the LAN MAC is on the WAN side to the cable modem.
 
not sure either.

maybe it is the max power capable by the hardware.

anyway, these commands will reflect the correct power settings for 2.4/5ghz

nvram get wl0_TxPower
nvram get wl1_TxPower


Reloaded the latetst fork and did a factory reset and configured the router from scratch. After that I adjusted the country regulation settings accordingly the post on page 3 of this topic via telnet.
Now channelswitching works. Except channel 14, then it falls back to 6 again.... Anyone?
Powersettings in GUI indeed changes the values measured via my wireless monitoring tool, so it looks ok.
Stil seeing 31.75 db /1496 mW when using "wl txpwr". Can't find an explanation for those values
 
Reloaded the latetst fork and did a factory reset and configured the router from scratch. After that I adjusted the country regulation settings accordingly the post on page 3 of this topic via telnet.
Now channelswitching works. Except channel 14, then it falls back to 6 again.... Anyone?
Using that mod is a use at your own risk and isn't officially supported as it disables a lot of the regulation checking in the code. For channel 14, it's only 'legal' in Japan for 11b connections. It may still be reacting to the latter part of that restriction.
Powersettings in GUI indeed changes the values measured via my wireless monitoring tool, so it looks ok.
Stil seeing 31.75 db /1496 mW when using "wl txpwr". Can't find an explanation for those values
Asus has not implemented a lot of the wl commands, especially with respect to power and especially on the MIPS based routers. I'm not sure if this command is reflecting a hardware limit or maybe a safety shutdown threshold, but it does not reflect anything with respect to the current power settings. AFAIK, there is no way to query the current actual power output via wl commands on any of the ASUS routers.
 
Quick question: Is it normal for the router (latest fork) to publish the MAC address of the LAN to the cable modem (WAN) side? My cable modem lists two (2) known CPE MAC addresses, one from the WAN and one from the LAN of the router.

Just curious as to why the LAN MAC is on the WAN side to the cable modem.
Not sure I fully understand what you are seeing....on my modem, under Known CPE MAC addresses, it says 'Max 1' and contains the MAC of the attached router which is normal (and why it's sometimes necessary to shutdown your modem for a while to reset things at the ISP when changing routers).
 

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