198.18.1.x address problems

[#1]

It'll be interesting to see if Chris Parr comes back with anything.
But

Quote from: Townman

This rather looks like a TG582n issue at some level - compounded by inexplicable windows behaviour.

As it happens with other modem/routers it's obviously not a straight forward issue solely related to the TG582n. Whether it's some incompatibility due to Windows OR due to the the various modem/routers suffering the problem I don't know. What I do know is by turning off spoofing, you get rid of part of the problem. Specifying additional alternate DNS on Windows devices can help get rid of the rest.

[#2]

The behaviour of nslookup and ping is explicable: if nslookup performs a DNS lookup each time, but the ping command and other programs use the Windows DNS system including the cache, then nslookup will get correct IP addresses while other programs get the 198.18.1. spoofed addresses from the cache. Of course using wireshark or some other network packet capture program would clarify when dns lookups are done and when they aren't so answers must come from a cache. If ipconfig /displaydns works on Windows 8/8.1/10, then that might help show if the 198.18.1. addresses are being cached, and how long they get remain in the cache for.

Quote from: Townman

This rather looks like a TG582n issue at some level

Some of us reached that conclusion quite some time ago. It might not help that the Technicolor firmware sends each query to both DNS servers at the same time, unlike pretty much everything else which does the expected behaviour of sending each query to the primary DNS server, and then sending it to the secondary DNS server if it didn't get a response from the primary.

[#3]

See this from a couple of years ago...

[#4]

So do non-technicolor routers that display a failed DNS lookup send the DNS requests to both servers at the same time ejs?

[#5]

Could you name some of these non-technicolor routers of which you are referring?

[#6]

Quote from: Anotherone

Suggest googling "DNS issues Windows 8" and you'll find a number of threads on Microsof't's site which may be helpful, as well as other sites. There was one case I read briefly where a VPN was causing the issue (well it wasn't the VPN per se, of course).

Doing that will yield threads where Non-Technicolor routers fail to do DNS lookups periodically and changing the Router solves the problem.

[#7]

Quote from: ejs

If ipconfig /displaydns works on Windows 8/8.1/10, then that might help show if the 198.18.1. addresses are being cached, and how long they get remain in the cache for. It might not help that the Technicolor firmware sends each query to both DNS servers at the same time, unlike pretty much everything else which does the expected behaviour of sending each query to the primary DNS server, and then sending it to the secondary DNS server if it didn't get a response from the primary.

Hi ejs,
Thanks for the insight and theory on what might be happening.
For the seen behaviour, the suggestion that nslookup always does exactly that (requires DNS) must also be true for the TG because if it did not, it would surely service the request with its cached spoofed address.
It would also have to be the case that the new result obtained by nslookup is not placed in the PC's cache.
The prevalence of this issue on Win8 upwards would imply a significant change to how windows is managing its resolved address cache, for if this behaviour of the TG is constant, why is it less of an issue to Win7 and below? (Rhetorical question.)
There is still the sceptre around this problem of why with a link up condition is the TG 'raising' spoofed DNS resolutions?  Is it indeed down to the double query mentioned by ejs or does this point to residual DNS request servicing issues within the PN network?
If PlusNet can suggest some level of diagnostics which would assist investigation, please ask.  Pointing direct to specific DNS servers from the PC is somewhat untidy and ideally I'd like to avoid it, by using the kit as it was intended to work.
Kevin

[#8]

Edit: In reply to whatever point Anotherone is trying to make about other routers also having their own problems
Oh dear, I should probably apologise, I forgot that I'm not allowed to point out any problems with any Plusnet supplied routers without doing a comprehensive assessment of every other router that's ever existed and reporting back on which ones also have a problem in that area.
I don't think it really matters which other routers also have their own problems with their internal DNS server. Windows 8.1 might be doing something different, but it's not doing anything wrong, just different. So I'm not really expecting Microsoft to fix Windows, because that's not what's broken. At least some of the people you can find by searching the Internet have reached the same conclusion as to where the problem is.
It's not the first time people have had problems with the 582n dns server, nor is it the only problem. This thread was fairly recent, and no, the 582n with 8.4 version firmware isn't the only router to have a problem with dns replies over a certain size.

[#9]

ejs,
Is something missing from the thread?  Your last post does not seem to follow on from my thanks for your insight.
The first link seems a bit confused though - it talks about DNS as though it performs the DNCP DHCP function (allocates addresses to lan devices).  In my research, I've not yet found anything referencing the 'spoofed' IP addresses.
Kevin

[#10]

So it does. Obviously the workarounds they were given were (1) to set all devices to have static IP addresses, and (2), enter some external DNS server addresses on their computers. As it turns out, the first workaround they were given is irrelevant. Well that's what you get from searching the Internet, much of what you find is rubbish.
I suppose you could experiment to see if the double query (which is a problem in itself) behaviour is anything to do with the problem. "Simply" increase the metric for the DNS servers automatically obtaining from the PPP, and add a couple of other DNS servers with lower but different metrics.

:ppp ifdetach intf=Internet
:ppp ifconfig intf=Internet dnsmetric=100
:ppp ifattach intf=Internet
:dns server forward dnsset add set=0 dns=212.159.13.49 metric=10 intf=Internet
:dns server forward dnsset add set=0 dns=212.159.13.50 metric=20 intf=Internet
:saveall

Obviously I haven't tried any of those commands so don't even know if the syntax is correct, nevermind if they do what I was intending. I'm not sure if there's a way to completely stop the automatically obtained DNS servers from being used, you could manually delete the automatically added ones, rather than ending up with 4 dns servers and finding that the problem disappears with 4 dns servers.

[#11]

Ah, I see you've come up with another unproven theory, interesting! Maybe I'll try it out sometime in the future.
Can we get one fact clear, because I don't think it has been made clear at anytime (without re-reading the whole thread - which I'm not going to do) -
The Spoofed addresses that appear in the TG582n cache are just the TG582n's way of dealing with a failed DNS lookup. The consequences of that is those spoof addresses can end up elsewhere eg. Windows caches. Turning off Spoofing gets rid of that problem. Behaviour is then no different from any other Router that has a failed DNS lookup.

Quote from: Townman

ejs....... The first link seems a bit confused though.....

Well yes and no. It says what we've seen before that the DNS lookup has failed, but subsequent nslookups not using the router dns are fine. The trouble is nothing can replicate exactly what happened at the instant the lookup failed. But it the 2nd link the 4th link also mentions some theory about the size of the message return. I have no idea if that's a common factor with other Routers (non Technicolor) that have occasional DNS lookup failures.

Quote from: ejs

I don't think it really matters which other routers also have their own problems with their internal DNS server.

Doesn't it? Oh dear, we might never discover what common factors there might be (apart from Windows). Your comment seems to suggest that it could be a hardware problem - might it be, I don't know, I'd like to find out.

Quote from: Townman

....The characteristics are that all of a sudden, browsing to web pages cease with a message that the destination cannot be reached.  Indeed this afternoon I had a page from the community displayed and right clicked a link to open in another tab and it failed....... ........... The problem is complicated by the fact that sometimes in the middle of this situation, launching a new browser session will pick up the correct IP address (as returned by nslookup) whilst the first window still fails to connect.

Apart from the fact that I've experienced the same, to me this suggests that Windows is handling things in a rather odd way.

Quote from: ejs

Edit: In reply to whatever point Anotherone is trying to make about other routers also having their own problems

The point was there there might/must be some common factor which you seem to want to dismiss, without doing any research.

Quote from: ejs

Oh dear, I should probably apologise, I forgot that I'm not allowed to point out any problems with any Plusnet supplied routers without doing a comprehensive assessment of every other router that's ever existed and reporting back on which ones also have a problem in that area.

Yes you should apologise, because from your posts over a period of time, it seems you too readily dismiss all Plusnet supplied routers as ......whatever.

Quote from: ejs

Windows 8.1 might be doing something different, but it's not doing anything wrong, just different. So I'm not really expecting Microsoft to fix Windows, because that's not what's broken.

How do you know, you have not looked for the common factors and why some different routers also have the problem.

Quote from: ejs

At least some of the people you can find by searching the Internet have reached the same conclusion as to where the problem is.

Well I can see how they readily jump to that conclusion, they have the problem, swap to another router and no problem. BUT if they had just happened to swap to another router with a similar issue, what conclusion would they have drawn then?

Quote from: ejs

It's not the first time people have had problems with the 582n dns server, nor is it the only problem. This thread was fairly recent, and no, the 582n with 8.4 version firmware isn't the only router to have a problem with dns replies over a certain size.

I don't believe anyone has said it was the first or only time and btw 10.2 firmware is no different.  I see we are now back to the reply size theory!
Then there is this one -

Quote from: ejs

It might not help that the Technicolor firmware sends each query to both DNS servers at the same time, unlike pretty much everything else which does the expected behaviour of sending each query to the primary DNS server, and then sending it to the secondary DNS server if it didn't get a response from the primary.

In response to that, it was a genuine question that I asked you in reply #78 because of your extremely good knowledge  of routers which is far superior to mine. It's a shame the best you could do was the sarcasm of reply #82.
Could you please explain the mechanism for that last quote as well? I might be being a bit thick today,  but I'm not sure how to simultaneously send two lots of digital data over a digital connection at the same instant.
It would be really good if you could do just a bit of serious investigation using your undoubted expertise.
Edit: 2nd edit:  correction (shown in red) to overlooked to error mentioned in a later posts - have used the link this time.

[#12]

Quote from: Anotherone

In response to that, it was a genuine question that I asked you in reply #78 because of your extremely good knowledge  of routers which is far superior to mine. It's a shame the best you could do was the sarcasm of reply #82. Could you please explain the mechanism for that last quote as well? I might be being a bit thick today,  but I'm not sure how to simultaneously send two lots of digital data over a digital connection at the same instant.

To which I asked you a very simple question in reply #79, which routers are you talking about? How difficult could it possibly be to copy and paste the URLs of some of the webpages you found? What exactly do you expect me to be able to tell you about some arbitrary unknown routers?
But if you want a load of generalised stuff, I can tell you, then, that Technicolor firmware is almost entirely made up of custom Technicolor software, all mashed together into two huge lumps. There's the 4.1MB nmon.ko kernel module, and the 8.9MB executable program linux_appl.exe. Most other routers have separate programs to run the DNS server, DHCP server, web server, wireless, and numerous other things rather than combine everything into a single large program. Most other routers use the standard firewall that's part of Linux, but not Technicolor. There's not much common software between Technicolor firmware and other router firmware.

Quote from: Anotherone

Quote from: Townman ejs....... The first link seems a bit confused though..... Well yes and no. It says what we've seen before that the DNS lookup has failed, but subsequent nslookups not using the router dns are fine. The trouble is nothing can replicate exactly what happened at the instant the lookup failed. But it also mentions some theory about the size of the message return. I have no idea if that's a common factor with other Routers (non Technicolor) that have occasional DNS lookup failures.

I didn't see anything about packet sizes in either page of this: http://answers.microsoft.com/en-us/windows/forum/windows8_1-networking/windows-81-and-router-technic...

Quote from: pwatson

See this from a couple of years ago...

Perhaps you missed this, Anotherone? It links you to http://crowdsupport.telstra.com.au/t5/Modems-Hardware/Windows-8-1-RTM-Technicolor-TG587n-v3-DNS-Issu...
Where a representative of the ISP actually confirms a bug in the Technicolor firmware:

Quote from: Shelly_Telstra

The issue relates to the way that Windows 8.1 performs DNS lookups, which differs from all previous versions of Windows OS. This change has exposed a timing/race condition bug within the Technicolor gateway firmware, and results in some webpages failing to load. To rectify this issue, Technicolor have identified a temporary workaround that can be applied via our remote management system. The delivery of this fix is currently being trialled for deployment next week. Technicolor have engineered a firmware fix that will be incorporated in the next maintenance release.

Oh, and there is very little serious investigation I can actually do when I'm not experiencing the problem myself!

[#13]

Quote from: Townman

1. Pinging the URL attempts to ping a 198.18.1.x address 2. nslookup of the URL (using the router proxy) returns the correct address 3. Pinging the URL still fails 4. doing a ipconfig /flushdns clears the problem ... for a short while

Did you ever get a Wireshark of that, ping and nslookup resolving different addresses for the same host? 

[#14]

Quote from: ejs

Quote from: Anotherone Quote from: Townman ejs....... The first link seems a bit confused though..... Well yes and no. It says what we've seen before that the DNS lookup has failed, but subsequent nslookups not using the router dns are fine. The trouble is nothing can replicate exactly what happened at the instant the lookup failed. But it also mentions some theory about the size of the message return. I have no idea if that's a common factor with other Routers (non Technicolor) that have occasional DNS lookup failures. I didn't see anything about packet sizes in either page of this: http://answers.microsoft.com/en-us/windows/forum/windows8_1-networking/windows-81-and-router-technicolor-tg582n/610a6846-ab7a-40d2-a0cd-168fc6c979d7?page=2

My apologies for a 2nd time, the it now highlighted in red, was an uncorrected error that I forgot to correct before posting. It should refer to the 2nd 4th link   I have edited the post again and used a link this time.

[#15]

Quote from: Anotherone

It should refer to the 2nd link.

I couldn't see anything about packet size in the second link either - this thread https://community.plus.net/forum/index.php/topic,124871.0.html

Quote from: Anotherone

Quote from: ejs Oh dear, I should probably apologise, I forgot that I'm not allowed to point out any problems with any Plusnet supplied routers without doing a comprehensive assessment of every other router that's ever existed and reporting back on which ones also have a problem in that area. Yes you should apologise, because from your posts over a period of time, it seems you too readily dismiss all Plusnet supplied routers as ......whatever.

I'm not going to apologise for having an opinion that does not concur with Anotherone's opinion. The vast majority of my posts are factual and express no opinion whatsoever. If a few of my posts in the distant past expressed an opinion that Anotherone does not approve of, well, too bad, as far as I was aware, the forums rules allow people to have and express different opinions.