What's new

[Beta] Asuswrt-Merlin 384.11 Beta is now available

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

it works but it seems like it is limited. - it seems like it shuts of prematurely.

Some routers will drop traceroute (or any ICMP packet) packets. What you are seeing is simply that - a destination server that does not respond to ICMP packets, hence the * * *. This is normal for traceroute.
 
Some routers will drop traceroute (or any ICMP packet) packets. What you are seeing is simply that - a destination server that does not respond to ICMP packets, hence the * * *. This is normal for traceroute.
well maybe we need to add more hops because some test appear to never make it to the end of the rainbow -so to speak.
 
I see Asus hacked the traceroute source code a bit for non-HND platforms - since they left Netool disabled on all non HND platforms, I suspect they never fully succeeded in making the traceroute command work properly on old 2.6.xx kernels. If that's the case, then I will disable Netool support for all non-HND models, reverting them to their original Busybox-backed network tools.
 
well maybe we need to add more hops because some test appear to never make it to the end of the rainbow -so to speak.

If by 30 hops you end up with a bunch of ***, then you are not running out of hops - you are simply reaching the end of the line, and that final hop doesn't return ICMP packets.

In all these years, I have never needed to use more than 30 hops whenever I used traceroute to troubleshoot anything.
 
I see Asus hacked the traceroute source code a bit for non-HND platforms - since they left Netool disabled on all non HND platforms, I suspect they never fully succeeded in making the traceroute command work properly on old 2.6.xx kernels. If that's the case, then I will disable Netool support for all non-HND models, reverting them to their original Busybox-backed network tools.

I also have weird issues with traceroute as failure to do IP resolution for eBay too (no bogus delay values tho).
Otherwise Netool works fine for me, and I like it, please don't disable it!
 
RT-AC5300
Beta 2 dirty upgrade without a hitch...
 
so i imagine it is not broken then, just listed with a bunch of broken or non icmp servers
 
so i imagine it is not broken then, just listed with a bunch of broken or non icmp servers

We are discussing multiple separate issues here.

Bogus negative delay values, failure to do IP resolution: most likely a bug on the 2.6.xx kernel or the old uclibc used by these routers
Not reaching the final target: normal behaviour for traceroute if that final hop never answers to ICMP packets, like quite a few servers/routers do for performance/security reasons

For the final release I will revert back to the former Network tools implementation for routers still running 2.6.36 kernels/uclibc, and will only keep it enabled for the RT-AC86U and RT-AX88U (which seemed to have been at least partly Asus's intent).
 
the only thing i do not like that this new netools does not list the hostname addresses it only shows the IP's
 
the only thing i do not like that this new netools does not list the hostname addresses it only shows the IP's

It's a bug/compatibility issue, as it resolves properly on newer routers.

I also have weird issues with traceroute as failure to do IP resolution for eBay too (no bogus delay values tho).
Otherwise Netool works fine for me, and I like it, please don't disable it!

I can't let a half-broken implementation there in the final release, sorry. It will have to be reverted for older models.
 
Starting to wonder if maybe that traceroute command wouldn't be having issues with the older kernels. While I don't get bogus values here, it however fails to do IP resolutions - no issue on the RT-AX88U, which has a newer kernel.

Anyone using an RT-AC86U or RT-AX88U also having weird issues with traceroute (either bogus delay values or failure to do IP resolution)?

RT-ac68u , 384.11b2 Firmware. Same thing

Code:
traceroute to www.ebay.com (23.40.73.213), 30 hops max, 60 byte packets
 1  122.58.252.1 (122.58.252.1)  -1556866049456.128 ms  -1556866049457.553 ms  -1556866049456.087 ms
 2  * * *
 3  122.56.116.5 (122.56.116.5)  -1556866049456.331 ms  -1556866049456.398 ms  -1556866049456.514 ms
 4  122.56.127.17 (122.56.127.17)  -1556866049456.471 ms  -1556866049456.568 ms 122.56.119.53 (122.56.119.53)  -1556866049456.645 ms
 5  202.50.232.234 (202.50.232.234)  -1556866049686.103 ms 202.50.232.182 (202.50.232.182)  -1556866049569.179 ms 202.50.232.242 (202.50.232.242)  -1556866049618.323 ms
 6  122.56.119.86 (122.56.119.86)  -1556866049568.163 ms  -1556866049524.284 ms  -1556866049521.497 ms
 7  45.127.172.102 (45.127.172.102)  -1556866049502.916 ms  31.672 ms  -1556866049496.379 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
 
I can't let a half-broken implementation there in the final release, sorry. It will have to be reverted for older models.

Then it is only "Not reaching the final target" problem for me for eBay, and not resolving the hostname addresses in Traceroute in the Network Analysis tab. It resolves fine in the Netstat tab.
So does it "almost" work for me then? Seems to be "more" broken on RT-AC5300, RT-AC68..?
Code:
traceroute to www.ebay.com (184.51.9.149), 30 hops max, 60 byte packets
 1  10.4.0.1 (10.4.0.1)  3.141 ms  7.002 ms  6.823 ms
 2  89.216.4.30 (89.216.4.30)  7.045 ms  6.856 ms  6.691 ms
 3  89.216.5.16 (89.216.5.16)  18.429 ms  18.302 ms 89.216.5.18 (89.216.5.18)  16.229 ms
 4  89.216.5.76 (89.216.5.76)  20.881 ms 89.216.5.78 (89.216.5.78)  23.746 ms 89.216.5.76 (89.216.5.76)  20.678 ms
 5  193.203.0.167 (193.203.0.167)  28.011 ms  27.875 ms  27.746 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
But I do understand your point; then lets hope Asus fixes it (not likely) in newer FW (even less likely for my router...).
 
Last edited:
Some will show the location of their datacenters on their websites (Cloudflare does). However, I suspect that most important would be to use one that supports EDNS - I know that Cloudflare doesn't.

Very few servers support DoT. OpenDNS does not, they are still (at this time) stuck with their proprietary DNSCrypt protocol. Hopefully they will eventually switch to something backed by IETF, be it DoT or DoH.

After doing some more research, I found out that Cloudflare recently announced servers in my country, so the issue may, in fact, be related solely to EDNS support.

Do you know which ones support both EDNS and DoT, so I can look up the locations of their datacenters, @RMerlin?
 
After doing some more research, I found out that Cloudflare recently announced servers in my country, so the issue may, in fact, be related solely to EDNS support.

Do you know which ones support both EDNS and DoT, so I can look up the locations of their datacenters, @RMerlin?
I use Cloudflare in DoT, and my country server is per the "https://www.cloudflarestatus.com/" re-routed to Vienna, Austria:
Annotation 2019-05-03 092202.png

And Steam site works just fine...
 
After doing some more research, I found out that Cloudflare recently announced servers in my country, so the issue may, in fact, be related solely to EDNS support.

Do you know which ones support both EDNS and DoT, so I can look up the locations of their datacenters, @RMerlin?
Google dns?
Quad9 and CF both don’t have edns.
By the way, by default, stubby disable edns. U need to change the setting in yml.
edns_client_subnet_private : 1 —> 0
 
Starting to wonder if maybe that traceroute command wouldn't be having issues with the older kernels. While I don't get bogus values here, it however fails to do IP resolutions - no issue on the RT-AX88U, which has a newer kernel.

Anyone using an RT-AC86U or RT-AX88U also having weird issues with traceroute (either bogus delay values or failure to do IP resolution)?

Just tried a trace route to Yahoo on an AX88U, all looked fine....
 
Same issue on a 86U (newer router?):

traceroute to www.ebay.com (104.77.221.103), 30 hops max, 60 byte packets
1 10.11.16.17 (10.11.16.17) 4.328 ms 12.800 ms *
2 10.178.206.164 (10.178.206.164) 3.056 ms 3.098 ms 3.045 ms
3 10.178.206.165 (10.178.206.165) 2.880 ms 2.837 ms 2.873 ms
4 tcore3x-quebec14_0-4-0-2.net.bell.ca (64.230.87.104) 12.337 ms tcore4x-quebec14_0-4-0-2.net.bell.ca (64.230.87.106) 12.285 ms 12.222 ms
5 tcore3-montreal02_hundredgige2-12-0-1.net.bell.ca (64.230.40.172) 12.142 ms 12.092 ms tcore4-montreal02_hundredgige2-12-0-1.net.bell.ca (64.230.40.170) 12.011 ms
6 bx1-montreal02_hundredgige0-1-0-0.net.bell.ca (64.230.91.123) 11.989 ms bx1-montreal02_hundredgige0-2-0-0.net.bell.ca (64.230.91.125) 9.349 ms bx1-montreal02_hundredgige0-1-0-0.net.bell.ca (64.230.91.123) 9.256 ms
7 ix-ae-10-0.tcore1.w6c-montreal.as6453.net (66.198.96.9) 9.189 ms 9.125 ms 9.075 ms
8 if-ae-12-2.tcore1.mtt-montreal.as6453.net (64.86.31.26) 13.933 ms 13.460 ms 14.927 ms
9 if-ae-0-2.tcore2.mtt-montreal.as6453.net (216.6.115.90) 14.782 ms 14.840 ms 14.619 ms
10 if-ae-5-2.tcore2.n0v-new-york.as6453.net (64.86.226.58) 14.405 ms 14.353 ms 14.280 ms
11 if-ae-2-2.tcore1.n0v-new-york.as6453.net (216.6.90.21) 14.741 ms 14.357 ms 14.420 ms
12 if-ae-7-5.tcore1.nto-new-york.as6453.net (63.243.128.141) 14.077 ms if-ae-7-2.tcore1.nto-new-york.as6453.net (63.243.128.25) 14.533 ms 15.210 ms
13 if-ae-9-2.tcore1.n75-new-york.as6453.net (63.243.128.122) 14.192 ms 14.354 ms 14.031 ms
14 66.110.96.89 (66.110.96.89) 17.708 ms 17.559 ms 17.488 ms
15 ae2.coresite-ewr3.netarch.akamai.com (23.203.156.177) 34.734 ms 34.675 ms 34.630 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
I stopped it there.

Edit : traceroot seems to kill GUI too. Happened twice in 5 min durant traceroot testing. Nothing revelent in the log.
 
Last edited:
Can anyone confirm if DoT is causing problems with Steam?

I'm still on 384.10_2 (RT-AC86U), but I recently installed Stubby DNS (via amtm) and had to uninstall it because it made Steam unusable, due to the low download speeds (even their main website/store wouldn't load properly and take forever to load the few parts without any issue).

No issues or problems with Steam from my side.
 

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