cancel
Showing results for 
Search instead for 
Did you mean: 

198.18.1.x address problems

Community Veteran
Posts: 19,107
Thanks: 452
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

Regarding the link, yes, I've made a complete arse of myself Embarrassed getting it wrong for the second time by rushing to correct it. I'll amend it again. Roll_eyes
I would think you really knew which link of the 4 in that thread I really meant.
We all make mistakes from time to time, you choose to use that minor mistake to try and belittle everything else I've said with your second comment.
It has nothing to do with my opinion not agreeing with you. As the comment says, there are posts of yours in the past (and I'm not going to search for links, other's can readily do that, I would prefer to do something more constructive) where you have just dismissed the 582n as - I'll paraphrase - a pile of junk. It's rather odd that a number of major ISPs have chosen to use the TG582n including the well respected A&AISP so it can't exactly be a pile of junk. So you mention forum rules as another red herring to justify your position. I have always said that the 582n is quite good for a budget modem/router, that doesn't mean it's perfect. Now do you think we can stop this petty bickering and actually discuss some facts especially using terminology and language that the majority of people instead of a select few might understand.
I'll reply further with some technical responses in a follow up post.
Community Veteran
Posts: 5,438
Thanks: 628
Fixes: 25
Registered: ‎10-06-2010

Re: 198.18.1.x address problems

It's totally bizarre when someone says: It's not <something> ... it's <that same thing which they just said it wasn't>!
So, just to check I've got this right, it's not that my opinion doesn't agree with yours, it's that my opinion of the 582n in a very small number of posts a long time ago, does not agree with your opinion of the 582n.
Community Gaffer
Community Gaffer
Posts: 5,463
Thanks: 817
Fixes: 9
Registered: ‎04-04-2007

Re: 198.18.1.x address problems

Just ran into this on my mum's connection! Sad
Kelly Dorset
Broadband Service Manager
Superuser
Superuser
Posts: 16,459
Thanks: 6,715
Fixes: 61
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

Hi Kelly,
Happy Christmas.  Hope the thread helped you circumvent the issue.  May be when you get back to the office, you'll give the product boys a prod?  I've tried but no one has responded on this issue.
...for a moment I thought you where working the forums today Grin
Kevin
Community Gaffer
Community Gaffer
Posts: 5,463
Thanks: 817
Fixes: 9
Registered: ‎04-04-2007

Re: 198.18.1.x address problems

I didn't have time to read the thread, so I just used Googles DNS which got around the issue.
I'm flagging it up with Matt again today though.
Kelly Dorset
Broadband Service Manager
Superuser
Superuser
Posts: 16,459
Thanks: 6,715
Fixes: 61
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

Kelly,
Thanks for that - much appreciated. I have made direct approaches to people in products asking for this to be examined, but I have not received a reply on the matter.
In passing, I was 'elsewhere' yesterday with my laptop and could not connect to anywhere until after I had 'unfixed' my fix for being at home with the TG582n router.  Now that I'm back home I had issues on start-up (which seem to have righted themselves) but I suspect I'll need to reapply the fix later today - not ideal!  Angry
Kevin
Community Gaffer
Community Gaffer
Posts: 5,463
Thanks: 817
Fixes: 9
Registered: ‎04-04-2007

Re: 198.18.1.x address problems

What's your fix?
Kelly Dorset
Broadband Service Manager
Superuser
Superuser
Posts: 16,459
Thanks: 6,715
Fixes: 61
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

Hi Kelly,
Rather than the PC being configured to get the DNS server address via DHCP (that is to use the TG582n as the DNS proxy) I 'burn' the PN DNS servers into the NIC's IPv4 configuration.
I do not believe this to be a general issue with PN's DNS server, rather it is something to do with the behaviour of the TG582n DNS service with the PN DNS servers AND some specific DNS caching issue with Win8 / 8.1 / 10.
From what I have seen, the OS 'acquires' a name resolution to 198.18.1.x for a URL.
Browser access, ping, tracert etc will then all fail.
NSLOOKUP delivers the correct resolution via / from 192.168.1.254 but the above still fail
Sometimes launching a new browser session will function OK, but the old one does not
ipconfig /flushdns clears out the issue until next time.

My theory is that (a) for some unknown reason the TG582n dishes out URL resolutions as 198.18.1.x (b) unlike prior OSs the later Win products 'hold on to' that resolution longer than in the past (c) using another DNS server avoids the purveyor of the 198.18.1.x resolutions.
In my case yesterday, I rather suspect that the network I was connected to might have had some form of block against using third party DNS servers.
Kevin
Community Veteran
Posts: 5,438
Thanks: 628
Fixes: 25
Registered: ‎10-06-2010

Re: 198.18.1.x address problems

I thought it was supposedly something that Win 8/8.1/10 is doing differently (yet people don't seem to want to run wireshark or similar to find out what exactly that is) that's causing the 582n to dish out the 198.18.1.x IP addresses when it shouldn't.
I did once set up my old PC with a PPPoE server, and connected a 582n to that, so I could also capture on the WAN side of the 582n. Of course since I don't have a Win 8/8.1/10 computer, or anything else that experiences this problem, I didn't discover anything particularly useful towards this issue.
I also can't believe that this issue affects all Windows 8/8.1/10 users trying to use the 582n in its default configuration, if it did, surely there would have been more people complaining, and Plusnet would have had to push out a configuration update to everyone.
Community Gaffer
Community Gaffer
Posts: 5,463
Thanks: 817
Fixes: 9
Registered: ‎04-04-2007

Re: 198.18.1.x address problems

Yeah, that's what's puzzling.
This affected my mother who has a bog standard ADSL + Technicolor 582 + Windows 8 laptop combo.  She did nothing bar using it normally to run into it.  Something must happen on the line to trigger it.
Kelly Dorset
Broadband Service Manager
Superuser
Superuser
Posts: 16,459
Thanks: 6,715
Fixes: 61
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

Quote from: ejs
I thought it was supposedly something that Win 8/8.1/10 is doing differently (yet people don't seem to want to run wireshark or similar to find out what exactly that is) that's causing the 582n to dish out the 198.18.1.x IP addresses when it shouldn't.

Hi ejs,
If that refers to me, its not a matter of not wanting to, its having the time to do it when the problem bites, rather than working around it to get on with what I'm doing.  Not overly familiar with wire shark  Also TBH I suspect that by the time, you see the problem WS is not going to show anything between the PC other than the router, other than if re-resolved probably getting the spoofed address.  What one really needs is router to DNS tracing to see why the URL gets spoofed in the first place.
I take the view that this problem has been well profiled - there ought to be enough info to go and ask the router suppliers for a view on what their code is doing.  As you have noted on several occasions, it is likely that asking BOTH DNS servers for name resolution at the same time is unhelpful.
Kevin
Community Veteran
Posts: 5,438
Thanks: 628
Fixes: 25
Registered: ‎10-06-2010

Re: 198.18.1.x address problems

I thought it was obvious that if you want to find out what caused the problem, you'd need to start monitoring / recording / logging / tracing before the problem starts. These must be fairly modern computers to have such a recent version of Windows, I'd like to think they'd be capable of running wireshark in the background.
Some DNS tracing was how I noticed the duplicate DNS queries, and although the duplicates are wasteful, it'll be the same behaviour regardless of Windows version or other operating system you might be using.
Community Veteran
Posts: 19,107
Thanks: 452
Fixes: 21
Registered: ‎31-08-2007

Re: 198.18.1.x address problems

We haven't got a trees smiley, there is a wood for the trees problem here  Huh
Quote from: Kelly
What's your fix?

The "fix" should be -
Turn off the DNS spoofing as suggested by Matt
Quote from: Matt
You can turn off this functionality by running the command given by npr earlier ":dns server config WANDownSpoofing=disabled"

Matt explained in that post that the TG582n did this when the WAN was down, however that was not the complete picture. It will also do it when a DNS lookup fails.
He went on to say it was
Quote
so that any browsing requests are directed towards 'helpful' features on the router to get people back online.

Well to be quite honest I found that this "feature" and the 'Web browsing Interception' "feature" to be two of the most unhelpful "features" of the TG582n's default settings. Even with the various firmware upgrades they never seem to have directed towards anything helpful. I have both turned off. As far as I'm concerned they have no practical purpose whatsoever.
The Spoofing issue is the primary context of the thread. However there are 3 different things going on here which have become confused at various times and resulted in some red herrings on occasion. So for clarity they are -
1) With default settings the TG582n produces a spoofed IP address if a DNS lookup fails
2) Certain Windows OSes compound the problem because they cache the spoofed addresses which are not cleared in a timely manner - this results in browsing failures
3) Plusnet DNS lookups seem to fail more frequently than other DNS resolvers
To get rid of the problem - Turn OFF the Spoofing by telnetting into the TG582n and run the following commands.
dns server config WANDownSpoofing = disabled
dns server debug spoof clear
dns server debug spoof list
saveall
exit
The spoof 'clear' and 'list' commands are to make sure the list is empty (so your OS cache won't pick up any old spoofed addresses).
When you've done the above, then clear your OS (usually Windows) caches.
That will get rid of the problem.
To try and keep this simple, DNS Lookups fail from time to time for a variety of reasons. It doesn't matter which DNS resolvers you use, whether they are Plusnet, Google, Level3, OpenDNS etc. it happens. I've used different DNS, different routers, different OSes & different machines at various times and it still happens now and again.
If you want to know why a particular one failed, you will probably be chasing your tail for a long time. But you will need to do a variety of things such as wiresharking and the likes as has been suggested by Matt, ejs and others. I've tried some of these at various times in the past and found it to be totally fruitless because the failures are generally random (except when there's been an obvious resolver issue which has affected multiple users) and for example, the results of a eg. wireshark simply show the lookup has failed.
Matt asked for an example, one was given here. If he looked at it, he didn't come back to comment.
Now if you want to know why Plusnet DNS ones fail more frequently, that's a very good question which many have asked about from time to time over the years but we've never had a real explanation. But as Plusnet's network is changing, that question may no longer be relevant - or may become more relevant if there's a gremlin somewhere Undecided
If you find Plusnet DNS resolvers to be a problem then pick some other ones and either set them in your Router or in your OS IP Config.
@Townman
Have you actually tried turning off Spoofing?
Quote from: Kelly
I didn't have time to read the thread, so I just used Googles DNS which got around the issue.
I'm flagging it up with Matt again today though.
Quote from: Townman
Kelly,
Thanks for that - much appreciated. I have made direct approaches to people in products asking for this to be examined, but I have not received a reply on the matter.

Kelly, getting any feedback from Products regarding any Modem/Router firmware issues seems to be a problem these days (apart from one very helpful individual) which makes it  virtually impossible  to help a variety of people with their problems from time to time, so I have virtually given up.
Superuser
Superuser
Posts: 16,459
Thanks: 6,715
Fixes: 61
Registered: ‎22-08-2007

Re: 198.18.1.x address problems

AO,
Thanks for the recap!  I've now modified my router to turn off spoofing and will wait to see what happens.
I remain unconvinced though that the mater is quite as crystal clear as implied.  There is something still less than clear about the spoofing process which ought to be explored by PlusNet products...
- what causes an address t become spoofed?
- under what conditions will it be "given out" even though a resolution is available from the DNS server?
- under what conditions will a spoofed address be correctly resolved?
On the last point (before updating / clearing the list) spoofed URLs were not having the spoofed address returned to applications (post ipconfig /flushdns) which implies that a full DNS lookup was performed and was successful.
As ejs suggests may be I need to find some free time and run up Wireshark - though I rather think PlusNet ought to be in a better position to do this.  Wink
Community Veteran
Posts: 5,438
Thanks: 628
Fixes: 25
Registered: ‎10-06-2010

Re: 198.18.1.x address problems

There's also the fact that the 582n has asked both DNS servers (albeit in a very short time), and it only needs to receive an answer from one of them. If it's serving up the 198.18.1.x addresses because it didn't receive an answer from Plusnet's DNS servers, that implies it didn't receive an answer from either of them.
There's also this:
Quote from: ejs
This or this (reporting the same thing) suggest Technicolor should already be aware of it. Presumably it doesn't affect all Win 8.1 computers or we'd have seen more about it here.

Quote from: Shelly_Telstra
Investigations have identified an incompatibility between Windows 8.1 (releasing 18/10/2013) and the 10.x series of Technicolor Firmware (TG587n V3 & TG797n V3). 

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.