On 2014-07-15 04:28, Linda Walsh wrote:
Carlos E. R. wrote:
I found out how to do "bandwidth control" on my router, it does not have QoS. It is not clearly explained on the manual, which just about prints nice photos of the screen, with empty boxes so that I can not guess what is the acceptable syntax (it is a TP-Link TD-W8970)
Description Priority Upstream Bandwidth Downstream Bandwidth Status Min Max Min Max 192.168.1.2-192.168.1.254 /53 /ALL 5 1 100 1 100 Enable
===== ??? Description??? That doesn't sound like a place one puts addresses.
But it is. Trust me, I know it is. (because unless I do, the router complains of bad syntax and that it is waiting for a valid, non-zero, address. Remember that these things are not designed by British, North Americans, or Australians. You can not expect to understand how to use them by reading form names, menu entries, help files, or a hundred pages of documentation, even if it is English (and I did read it, start to end) ;-) Example of documentation: +++········ Address. Here you write the address. See photo ········++- And you get a photo of the screen, with no address written, so you can not even guess what to write there - unless you happen to know what an address is. And of course, the manual is full of photos, so it is huge. And then, when you try, it says that 1.1.1.1 is not a valid address... Believe me, I do know, now, what to write in the damn form. I spent hours to find out. Why are not these things designed and built in Germany, or Canada? Gosh, then I could hope to understand them! At least, they could hire good technical writers!
Does it want destination IP's or source IP's?
It wants the local IP addresses of my machines, on the LAN side of the router.
Description doesn't really tell you. It certainly doesn't specify if the policy is for TCP, UDP or ICMP (for example).
That's the "All" in the description. I said so somewhere.
which reads, I understand, like all internal machines (it does not allow external IPs defined in there) on port 53 UDP and TCP have a minimum of 1Kb/s reserved. For that port, I assume. It appears to work better, housewide.
I had to google many forum pages from people asking how to do it. Some answers just said to flash the device, which is not an answer.
If you say so... I've zero knowledge about how to config your router (not even knowing the brand/make/model...etc.).
I did say brand and model, it is in this post some lines up :-) I'm just saying that in my router it is done that way, no matter how absurd it looks, so that anybody looking in the archive one day can find that info.
But you see, I'm using my PC DNS daemon, aka bind. And it times out.
Doesn't matter. Your PC DNS daemon likely uses TCP to talk to the router, and the router likely uses UDP to talk upstream.
Nope. The router can not intercept my DNS queries and change them anyway, they are just packets to be routed. Only when I ask the router for solving DNS, it can do what it wishes. That is, I'm no longer doing: forwarders { 192.168.1.1; }; but forwarders { 80.58.61.250; 80.58.61.254; 208.67.222.222; 8.8.8.8; }; I said so several posts back.
If you config your PC DNS daemon to another DNS server, it may easily be TCP all the way.
I did... days ago, and posts ago. I said so here. And I said it apparently solved most of the issue.
You see, it first has to get a connection on port 53 to somewhere established... if this can not be made, it does not matter that once done it times out or not. "It" = PC or router? Connect -- UDP = connectionless.
PC. Bind.
5) if you are querying your ISP (or google) they likely have the answer to your query in their cache meaning they have no lookups to do and you just need to get a reply.
Which I don't get.
And some of the queries are to my isp asking for my isp smtp server, and they time out.
But are you doing those queries through your router? If it uses UDP, it would do so to your
Se previous answer.
One thing we don't know .. the types of the queries..
It would be good to use wireshark and look at the queries from your box to both, the router and to another DNS server. AND 2) hook a 2nd ethernet port up on the outside of your router and look how it is sending out the queries -- using TCP or UDP.
Can't be done. The outside of the router is a phone line. Gosh! Don't you know what an ADSL router is? It is not a business class CISCO router and ISP big client pipe!
But my PC, which queried my router, does have the cache. It is not powered off, but hibernated, so it should keep. And it doesn't.
That says the telefonica.net servers have a 40+ hour lifetime.
Ok.
The root name servers would NOT have your address in their DB -- it appears from YOUR lookup output, that you are using the root name servers to do recursive lookups. If you think doing root lookups of the TLD's is rude, how do you see those who ask the root nameservers to do the lookup for them? *ahem*..
Don't complain to me. That's how bind does things, as openSUSE ships it. But I don't think it is doing that, anyway.
Despite me having on /etc/named.conf
forwarders { 80.58.61.250; 80.58.61.254; 208.67.222.222; 8.8.8.8; }; forward first;
it is asking the root servers.
What is in /etc/resolve.conf? I'm fairly sure it is consulted first, as it contains the values of the nameservers.
search valinor nameserver 192.168.1.14 That is, it has to query my own DNS server, in this same machine. And the address solves: Telcontar:~ # host 192.168.1.14 14.1.168.192.in-addr.arpa domain name pointer Telcontar.valinor. Telcontar:~ # host Telcontar.valinor Telcontar.valinor has address 192.168.1.14 Telcontar.valinor mail is handled by 10 Telcontar.valinor. Telcontar:~ #
I know they are different; but the current problem, which is simply getting queries done, is basically the same: the router performance when the ADSL pipe is full.
Your router has to control the traffic.... it sounds like it doesn't. Some client (like your PC) is taking all the BW. There is no BW control. Um... that looks problematic.
And I said that I found out how to tell my router to do "some" of that. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)