cancel
Showing results for 
Search instead for 
Did you mean: 

198.18.1.x address problems

HPsauce
Pro
Posts: 6,998
Thanks: 146
Fixes: 2
Registered: ‎02-02-2008

Re: 198.18.1.x address problems

Quote from: npr
If it works by manually configuring the dns in the devices then this method should also work.
I'm doing that on devices that need it as it's easier (for me) - only one device requires it at present.  Wink
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: 198.18.1.x address problems

Is anyone who experiences this problem going to do any packet capture to determine exactly what Win 8.1 does differently?
Does anyone know what the TTL (time to live) value of the spoofed 198.18.X.X values are? That should determine how long they get cached for by Windows. An old packet capture of mine has some with TTL values of zero, although that's from firmware 8.4.4.J (and with its WAN connection actually down). Apparently a DNS response with a TTL of zero is supposed to mean it shouldn't be cached at all, although a TTL of zero might be interpreted differently (or has caused problems in the past, at least).
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

ejs,
If you can give me some clues please I will go looking...
I cannot find anything obvious in the router.

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: 198.18.1.x address problems

I was about to suggest the "dns server debug spoof getflags" telnet command but it appears to do nothing, there's a flags column in the "dns server debug spoof list" output anyway.
But really I was thinking of running wireshark or another packet capture program on the computer that experiences the problem to look at the DNS packets.
The 10.2.5.2 firmware also servers up the 198.18.1.X responses with a TTL of zero (so they shouldn't be cached by the Win 8.1 laptop that receives them). Also both dig and wireshark complain that the DNS response packet is malformed. But that's probably another red herring because it was due to dig sending a different query packet than a normal lookup (dig +noedns makes the packet the dig command sends more similar to a normal lookup),
npr
Pro
Posts: 1,898
Thanks: 119
Fixes: 9
Registered: ‎21-01-2013

Re: 198.18.1.x address problems

I've always thought the router didn't save these spoof IP addresses when "web browsing interception" is disabled. My TG672 is not saving them with that feature disabled so don't see why the TG582n is saving them.
Those affected could try disabled the feature with the following telnet command
dns server config WANDownSpoofing=disabled
saveall
One thing I've recently notice in my win8.1 firewall log is when my laptop wakes from sleep it will be on one of two alternative LAN IP addresses. Interestingly each time the laptop is using one particular LAN IP addresses (192.168.1.60) packets forwarded by my local DNS resolver are dropped. Packets to the dns addresses in the laptops network adaptor are allowed so the problem is not noticed when browsing.
Another strange thing is that 192.168.1.60 is not in the routers dhcp pool so should not have been issued via DHCP.  Undecided
I'm not saying this is the same issue as being discussed here, it's not even the same Technicolor router, but it may be worth considering.
The solution proved to be something I'm always banging on about here -- tick "always use the same IP address" in the routers network settings for the device.  Cheesy




Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

I've always had my network set up to always use the same IP address for all regular devices. I've also had "Web browsing interception" disabled from the outset and my TG582n has always put entries in the spoof list when it has apparently failed to connect to DNS.
Disabling WANDownSpoofing is next on my list for experimenting, which as yet I haven't had time to try.
rmaharaj
Newbie
Posts: 6
Registered: ‎08-04-2015

Re: 198.18.1.x address problems

Also having a similar issue - twitter.com (along with many other sites) refuse to load. Sometimes loading partially.
I've tried traceroute and it dies in the middle.
Sites work fine using middleman proxies.
Changed DNS servers, but that doesn't help.
PN have booked an engineer to look at the line tomorrow, but I don't think anything is wrong with the line.
Support have asked me to try a new router - the only one I have is Sky, which won't work. I'll try that command when I get home to look at spoofed addresses.
All in all I'm actually glad I'm not the only one. PN support seem baffled by the problem.
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

Hi rmaharaj,
Welcome to the forum.
A site failing to load on an occasional one off might be a DNS issue but could equally be a number of other things. If it's repeatedly failing to load, I doubt it would be this problem.
Further to my last post on this, Disabling WANDownSpoofing makes no difference, it only prevents entries from going into the spoof list which aren't of much use anyway.
The only sensible quick workaround is to set alternate DNS on the PC.
rmaharaj
Newbie
Posts: 6
Registered: ‎08-04-2015

Re: 198.18.1.x address problems

Thanks for both your replies Anotherone. I'll try setting the DNS on the PC and see if that changes anything.
The reason I suspected I might have had the spoofing issue was that occasionally, a site that fails to load will load.
I believe PN support is on the case - hopefully they can find the issue.
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

Just to double check, this is the TG582n modem/router you are using? The spoofing issue doesn't apply to the 2704n.
rmaharaj
Newbie
Posts: 6
Registered: ‎08-04-2015

Re: 198.18.1.x address problems


I see - it was the 2704N - so then it can't have been this issue.
I've tried another plusnet router and the problem seems to have gone away. It seems like it was a faulty router.
Quote from: Anotherone
Just to double check, this is the TG582n modem/router you are using? The spoofing issue doesn't apply to the 2704n.
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

Thanks for letting us know that, shame Plusnet's "new" modem/router seem to be having quality problems at this stage.
PS. Please don't "Full quote" the whole of an immediately preceding post, it's against our forum rules.
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

Quote from: Chris
Quote from: Townman


EDIT: @CRT see post 15 here - http://www.gpforums.co.nz/threads/478377-Windows-8-1-Upgrade-Ramifications - there is a suggestion there that there is a specific issue between Win8 and TGs

See also posts here - http://answers.microsoft.com/en-us/windows/forum/windows_8-networking/internet-connection-dropping-w... - from 12 Jan 2014 onwards.

Is this on your / the CSC / Product's radar?

Sorry, not sure how I missed this thread.
I've asked the question internally if it's something we're aware of and what can be done, I'll get back when I've got a response.

Hi Chris,
Did you ever get a response please?
I'm building (updating) a PC to Win8.1 (long story) and was finding that things go pear-shaped just after the upgrade completes.  Investigation shows pings to google.co.uk return a 'spoofed' IP address, whereas nslookup returns the correct IP address for Google.
Internet research pointed me to doing an ipconfig /flushdns which fixed things.  That same research brought me back to this thread, hence the question on progress.
Kevin

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

The issue of failed DNS returns would appear to be a more general problem with Windows 8/8.1, not just specific to TG modem/routers. My suspicion is that in the odd thread (such as the one you linked) people's assumption that it was related to TG's is the a) lack of understanding of the reasons for a spoofed address by the TG, and 2) Changing the modem/router solved the problem.
There are cases where people using other routers experience similar DNS issues (no spoofing on those particular routers) and changing the router solves the problem BUT changing things on Windows networking can also solve the problem.
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).
Townman
Superuser
Superuser
Posts: 22,921
Thanks: 9,538
Fixes: 158
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

Hi AO,
Everything I've read is all about circumventing the issue as I have had to do, rather than identifying a proper root cause for someone to go resolve.
In rebuilding a mini laptop to Win 8 and then after upgrading it to Win8.1 I've run into the same problem again.  I have also hit the same issue after upgrading my main machine from Win7 to Win10.
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.
Investigating the problem shows...
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
Quote
#Microsoft Windows [Version 10.0.10240]
#28/11/2015-12:17:02.10
C:\Users\Kevin>ping google.co.uk
Pinging google.co.uk [198.18.1.94] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 198.18.1.94:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
#Microsoft Windows [Version 10.0.10240]
#28/11/2015-12:17:37.86
C:\Users\Kevin>nslookup
Default Server:  dsldevice.lan
Address:  192.168.1.254
> google.co.uk
Server:  dsldevice.lan
Address:  192.168.1.254
Non-authoritative answer:
Name:    google.co.uk
Addresses:  2a00:1450:4009:80a::2003
          212.56.71.219
          212.56.71.251
          212.56.71.223
          212.56.71.234
          212.56.71.229
          212.56.71.208
          212.56.71.218
          212.56.71.216
          212.56.71.212
          212.56.71.227
          212.56.71.245
          212.56.71.238
          212.56.71.249
          212.56.71.230
          212.56.71.240
          212.56.71.241
>
#Microsoft Windows [Version 10.0.10240]
#28/11/2015-12:18:00.15
C:\Users\Kevin>ping google.co.uk
Pinging google.co.uk [198.18.1.94] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 198.18.1.94:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
#Microsoft Windows [Version 10.0.10240]
#28/11/2015-12:18:22.23
C:\Users\Kevin>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
#Microsoft Windows [Version 10.0.10240]
#28/11/2015-12:18:34.75
C:\Users\Kevin>ping google.co.uk
Pinging google.co.uk [212.56.71.230] with 32 bytes of data:
Reply from 212.56.71.230: bytes=32 time=32ms TTL=60
Reply from 212.56.71.230: bytes=32 time=33ms TTL=60
Reply from 212.56.71.230: bytes=32 time=32ms TTL=60
Reply from 212.56.71.230: bytes=32 time=32ms TTL=60
Ping statistics for 212.56.71.230:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 33ms, Average = 32ms

At first sight, this all looks like an internal windows problem - even though nslookup resolves the URL to the correct address it is not "available" for other applications / processes on the windows environment.  After a /flushdns all is fine.  HOWEVER if I force the PC to use an external DNS (for example PlusNet's) rather than the router's then the problem goes away and stays away - period.
This rather looks like a TG582n issue at some level - compounded by inexplicable windows behaviour.
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.
As I asked before CHRIS - did your enquiries go anywhere?
Thanks,
Kevin

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.