What's new

[384.12_Alpha - builds] Testing all variants.

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

Status
Not open for further replies.
Since it’s again somebody else than @RMerlin posting the link:

How can we verify that the link is indeed to the “official” OneDrive account and not somebody else’s (with possibly bad intentions) who just named folders and files the same?

(Definitely not blaming @octopus of this behavior, but what if this kind of post for a next build is from someone new on the forum with hardly any posts?)

There’s always the hash you could verify...isn’t there an mdasha1 hash on alphas??


Sent from my iPhone using Tapatalk
 
Code:
rc: change default behaviour of resolv.conf to use ISP instead of loc…
Rmerlin how does this change effect people who are using a different DNS server listed in Wan1 and Wan2 instead of their isp being listed there.-- It would be nice if this was made into an option and placed on the gui in the WAN section, instead of a forced setup because some people are not experiencing this issue.
 
Code:
rc: change default behaviour of resolv.conf to use ISP instead of loc…
Rmerlin how does this change effect people who are using a different DNS server listed in Wan1 and Wan2 instead of their isp being listed there.-- It would be nice if this was made into an option and placed on the gui in the WAN section, instead of a forced setup because some people are not experiencing this issue.
It’s still controlled by the setting in Tools Other Settings, but in the next release it will default to no. Just change back to yes if you prefer.
 
Code:
rc: change default behaviour of resolv.conf to use ISP instead of loc…
Rmerlin how does this change effect people who are using a different DNS server listed in Wan1 and Wan2 instead of their isp being listed there.-- It would be nice if this was made into an option and placed on the gui in the WAN section, instead of a forced setup because some people are not experiencing this issue.
It not really going to be your ISP DNS, but whatever is configured for DNS in the WAN page (ISP via DHCP or else manual WAN DNS1 and 2).
 
It’s still controlled by the setting in Tools Other Settings, but in the next release it will default to no. Just change back to yes if you prefer.
I kind of figured that. I honestly believe that people will still continue to have issues with the Network monitoring though, because even on stock people have the problem with it and on stock default is to use ISP like merlin is changing it to. I haven't seen it cause any issues with NTP server though.
 
The root issues that lie with Network Monitoring is simply how it has been implemented- meaning i have never had problems with it if i manually do settings myself, but if i rely on the settings that asus place in there by default it causes issues.
 
The root issues that lie with Network Monitoring is simply how it has been implemented- meaning i have never had problems with it if i manually do settings myself, but if i rely on the settings that asus place in there by default it causes issues.
If I resolve dns.msftncsi.com on my router, I only get back the 131 ipv4 address and the ipv6 address. I never see the middle address returned. Maybe Microsoft broke it. ;)
Code:
131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1
 
If I resolve dns.msftncsi.com on my router, I only get back the 131 ipv4 address and the ipv6 address. I never see the middle address returned. Maybe Microsoft broke it. ;)
Code:
131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1
no it is limitations of the builtin nslookup. do a NSlookup using a google searched one and you will see every address .
 
Code:
131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1
Try and ping one of these IP's using the built in ping option.
tell me how much packet loss
 
I’ve been trying to understand wanduck and not getting too far, but one interesting bit of code is a difference in behavior if DoT is enabled, one of the checks is to run:
Code:
/sbin/tcpcheck 3 127.0.1.1:53
Normally it would run it for each of your WAN DNS servers, but with DoT it’s checking Stubby instead. And port 53 is hard-coded, so if anyone has changed the listening port, that check would fail. I can only think of a small few curmudgeons who may have been motivated to change the listening port for Stubby, but it’s a small lesson in how configurability can lead to unintended consequences.

Still don’t really see how it all works together, but the tcpcheck is certainly part of the mix.

Code:
131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1
Try and ping one of these IP's using the built in ping option.
tell me how much packet loss
Since the router is only resolving the name, does the ping matter?
 
I’ve been trying to understand wanduck and not getting too far, but one interesting bit of code is a difference in behavior if DoT is enabled, one of the checks is to run:
Code:
/sbin/tcpcheck 3 127.0.1.1:53
Normally it would run it for each of your WAN DNS servers, but with DoT it’s checking Stubby instead. And port 53 is hard-coded, so if anyone has changed the listening port, that check would fail. I can only think of a small few curmudgeons who may have been motivated to change the listening port for Stubby, but it’s a small lesson in how configurability can lead to unintended consequences.

Still don’t really see how it all works together, but the tcpcheck is certainly part of the mix.


Since the router is only resolving the name, does the ping matter?
Ping should matter. if you cant reach the resolve host how can it be used to determine if the connection is up. The other bit of information is the response you get back for verification.
 
Ping should matter. if you cant reach the resolve host how can it be used to determine if the connection is up. The other bit of information is the response you get back for verification.
The DNS probe is only checking your router’s ability to resolve a well-known hostname to the expected IP. It doesn’t make a connection to it, only to your DNS server. The ping target is different. At least this is my current understanding. But the person to solve Internet Disconnected will be crowned Merlin-for-a-Day! :p
 
The DNS probe is only checking your router’s ability to resolve a well-known hostname to the expected IP. It doesn’t make a connection to it, only to your DNS server. The ping target is different. At least this is my current understanding. But the person to solve Internet Disconnected will be crowned Merlin-for-a-Day! :p
Hah, Not denying ping target is different, just speculating that if the router cannot receive a request from the domain, then the DNS probe will fail.
 
Last edited:
Hah, Not denying ping target is different, just speculating that if the router cannot receive a request from the domain, then the DNS probe will fail.
The DNS probe does have to be able to get back a IP response that is equivalent to what NSlookup shows or what a ping would show as the IP and it has to be congruent when it does so.
 
The DNS probe does have to be able to get back a IP response that is equivalent to what NSlookup shows or what a ping would show as the IP and it has to be congruent when it does so.
I watched tcpdump output on the loopback (without DoT) just to see what it gets back, and it’s only getting back the 131 address, so I’m assuming it only has to match one of the probe content values to pass. Not sure what this proves or has to do with the alpha anymore, so I’ll go quietly and start a new thread about Network Monitoring if i have any other breakthroughs. :rolleyes:
Code:
# tcpdump -i lo -p port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
01:15:13.060651 IP localhost.localdomain.44338 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:13.141411 IP localhost.localdomain.domain > localhost.localdomain.44338: 2 1/0/0 A 131.107.255.255 (50)
01:15:28.157922 IP localhost.localdomain.56508 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:28.228296 IP localhost.localdomain.domain > localhost.localdomain.56508: 2 1/0/0 A 131.107.255.255 (50)
01:15:43.242531 IP localhost.localdomain.48165 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:43.343747 IP localhost.localdomain.domain > localhost.localdomain.48165: 2 1/0/0 A 131.107.255.255 (50)
01:15:58.367674 IP localhost.localdomain.51265 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:58.368487 IP localhost.localdomain.domain > localhost.localdomain.51265: 2 1/0/0 A 131.107.255.255 (50)
01:16:13.393254 IP localhost.localdomain.41968 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:13.485268 IP localhost.localdomain.domain > localhost.localdomain.41968: 2 1/0/0 A 131.107.255.255 (50)
01:16:28.496294 IP localhost.localdomain.47622 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:28.497158 IP localhost.localdomain.domain > localhost.localdomain.47622: 2 1/0/0 A 131.107.255.255 (50)
01:16:43.512480 IP localhost.localdomain.55037 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:43.609127 IP localhost.localdomain.domain > localhost.localdomain.55037: 2 1/0/0 A 131.107.255.255 (50)
01:16:58.624738 IP localhost.localdomain.56419 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:58.729870 IP localhost.localdomain.domain > localhost.localdomain.56419: 2 1/0/0 A 131.107.255.255 (50)
01:17:12.741807 IP localhost.localdomain.49052 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:17:12.742663 IP localhost.localdomain.domain > localhost.localdomain.49052: 2 1/0/0 A 131.107.255.255 (50)
 
I watched tcpdump output on the loopback (without DoT) just to see what it gets back, and it’s only getting back the 131 address, so I’m assuming it only has to match one of the probe content values to pass. Not sure what this proves or has to do with the alpha anymore, so I’ll go quietly and start a new thread about Network Monitoring if i have any other breakthroughs. :rolleyes:
Code:
# tcpdump -i lo -p port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
01:15:13.060651 IP localhost.localdomain.44338 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:13.141411 IP localhost.localdomain.domain > localhost.localdomain.44338: 2 1/0/0 A 131.107.255.255 (50)
01:15:28.157922 IP localhost.localdomain.56508 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:28.228296 IP localhost.localdomain.domain > localhost.localdomain.56508: 2 1/0/0 A 131.107.255.255 (50)
01:15:43.242531 IP localhost.localdomain.48165 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:43.343747 IP localhost.localdomain.domain > localhost.localdomain.48165: 2 1/0/0 A 131.107.255.255 (50)
01:15:58.367674 IP localhost.localdomain.51265 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:58.368487 IP localhost.localdomain.domain > localhost.localdomain.51265: 2 1/0/0 A 131.107.255.255 (50)
01:16:13.393254 IP localhost.localdomain.41968 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:13.485268 IP localhost.localdomain.domain > localhost.localdomain.41968: 2 1/0/0 A 131.107.255.255 (50)
01:16:28.496294 IP localhost.localdomain.47622 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:28.497158 IP localhost.localdomain.domain > localhost.localdomain.47622: 2 1/0/0 A 131.107.255.255 (50)
01:16:43.512480 IP localhost.localdomain.55037 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:43.609127 IP localhost.localdomain.domain > localhost.localdomain.55037: 2 1/0/0 A 131.107.255.255 (50)
01:16:58.624738 IP localhost.localdomain.56419 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:58.729870 IP localhost.localdomain.domain > localhost.localdomain.56419: 2 1/0/0 A 131.107.255.255 (50)
01:17:12.741807 IP localhost.localdomain.49052 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:17:12.742663 IP localhost.localdomain.domain > localhost.localdomain.49052: 2 1/0/0 A 131.107.255.255 (50)
atleast this is a test showing it is working so IMHO it appears to pass.
 
I watched tcpdump output on the loopback (without DoT) just to see what it gets back, and it’s only getting back the 131 address, so I’m assuming it only has to match one of the probe content values to pass. Not sure what this proves or has to do with the alpha anymore, so I’ll go quietly and start a new thread about Network Monitoring if i have any other breakthroughs. :rolleyes:
Code:
# tcpdump -i lo -p port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
01:15:13.060651 IP localhost.localdomain.44338 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:13.141411 IP localhost.localdomain.domain > localhost.localdomain.44338: 2 1/0/0 A 131.107.255.255 (50)
01:15:28.157922 IP localhost.localdomain.56508 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:28.228296 IP localhost.localdomain.domain > localhost.localdomain.56508: 2 1/0/0 A 131.107.255.255 (50)
01:15:43.242531 IP localhost.localdomain.48165 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:43.343747 IP localhost.localdomain.domain > localhost.localdomain.48165: 2 1/0/0 A 131.107.255.255 (50)
01:15:58.367674 IP localhost.localdomain.51265 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:15:58.368487 IP localhost.localdomain.domain > localhost.localdomain.51265: 2 1/0/0 A 131.107.255.255 (50)
01:16:13.393254 IP localhost.localdomain.41968 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:13.485268 IP localhost.localdomain.domain > localhost.localdomain.41968: 2 1/0/0 A 131.107.255.255 (50)
01:16:28.496294 IP localhost.localdomain.47622 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:28.497158 IP localhost.localdomain.domain > localhost.localdomain.47622: 2 1/0/0 A 131.107.255.255 (50)
01:16:43.512480 IP localhost.localdomain.55037 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:43.609127 IP localhost.localdomain.domain > localhost.localdomain.55037: 2 1/0/0 A 131.107.255.255 (50)
01:16:58.624738 IP localhost.localdomain.56419 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:16:58.729870 IP localhost.localdomain.domain > localhost.localdomain.56419: 2 1/0/0 A 131.107.255.255 (50)
01:17:12.741807 IP localhost.localdomain.49052 > localhost.localdomain.domain: 2+ A? dns.msftncsi.com. (34)
01:17:12.742663 IP localhost.localdomain.domain > localhost.localdomain.49052: 2 1/0/0 A 131.107.255.255 (50)
Heres with my test
Code:
01:42:59.923050 IP localhost.localdomain.37751 > localhost.localdomain.domain: 2+ AAAA? cloudflare-dns.com. (36)
01:42:59.923738 IP localhost.localdomain.domain > localhost.localdomain.37751: 2 2/0/0 AAAA 2606:4700::6810:f8f9, AAAA 2606:4700::6810:f9f9 (92)
01:42:59.924385 IP localhost.localdomain.46239 > localhost.localdomain.domain: 3+ A? cloudflare-dns.com. (36)
01:42:59.925002 IP localhost.localdomain.domain > localhost.localdomain.46239: 3 2/0/0 A 104.16.249.249, A 104.16.248.249 (68)
01:43:14.989898 IP localhost.localdomain.57944 > localhost.localdomain.domain: 2+ AAAA? cloudflare-dns.com. (36)
01:43:14.990560 IP localhost.localdomain.domain > localhost.localdomain.57944: 2 2/0/0 AAAA 2606:4700::6810:f9f9, AAAA 2606:4700::6810:f8f9 (92)
01:43:14.991172 IP localhost.localdomain.53051 > localhost.localdomain.domain: 3+ A? cloudflare-dns.com. (36)
01:43:14.991823 IP localhost.localdomain.domain > localhost.localdomain.53051: 3 2/0/0 A 104.16.248.249, A 104.16.249.249 (68)
 
What this shows is that if Network Monitor was causing issues you wouldn't expect to see this type of tcpdumps.
 
just curious...

Anyone know where this rules come from?
This rules are generated when router reboot or manually execute service restart_wan.
And with service restart_firewall, this rules disappear.
I don't enable any iptv related option.
Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    32 ACCEPT     igmp --  eth0   any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth0   any     anywhere             base-address.mcast.net/4

Chain PREROUTING (policy ACCEPT 229 packets, 15898 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth0   any     anywhere             base-address.mcast.net/4
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top