198.18.1.x address problems

[#1]

@Townman I'm afraid you have missed a significant point here. Most users do NOT need to understand the problem, indeed a great number would not have the knowledge or wish to have it as to why and where etc.

All you need to do is know you have a DNS issue. You make sure this issue is fixed first, and see if it cures the problem. If not, you go looking for other causes of DNS problems.

WANDownSpoofing is a "feature" that has never served any practical purpose, nor is there anything useful in the firmware that might make it so, and at least one other service provider has NEVER had the bug feature enabled from at least as far back as 8.4.4.J firmware.

[#2]

---

@bobpullen wrote:
Yes there is, although these devices run a pretty dated firmware by today's standards so it wouldn't make sense to invest too much time in the root cause. I suspect it will end up being a decision around whether or not to globally disable the 'feature' if anything.

---

Bob, is there a reason this still hasn't been globally disabled?

I just help another friend diagnose why their parent's plus.net connection keeps dropping out. Turned out this was the route cause again. If I'd not stepped in, they were to change ISP and tell all their friends how useless and unreliable the plus.net connection was.

This really reflects badly on plus.net - I don't think plus.net appreciate quite how many people there are out there who are living with an internet connection that doesn't work some percentage of the time because they don't have the skills/energy to diagnose a difficult issue - yet plus.net could easily fix it for everyone with pretty much the wave of a hand.

[#3]

And, btw, I have no idea how to fix it for them. I think my best suggestion may actually be to change ISP, as the router they get from the new ISP will "fix" it.

[#4]

That is a bit of a presumption: if they get a router with the same behaviour / settings, it will fail the same way.

Remember this is an interaction between the router (when doing DNS resolution) and the OS - change either and the issue appears to be abated.  Who is to say that the OS is not at fault?

As the person who first raised this issue, whilst a circumvention has been identified, it is not clear to me why Win 8 / 8.1 / 10 keeps requesting resolution of a URL it had already resolved ... only to then get a duff one whilst the router is throwing a fit?  The configuration change to the router, or setting the PC to directly use PlusNet's (or another's) DNS simply addresses the symptoms, not the route cause of persistently re-resolving an already resolved URL.

Whatever, as suggested a blanket change to the configuration of these routers would indeed mask the symptoms being experienced.

[#5]

---

@Townman wrote:

That is a bit of a presumption: if they get a router with the same behaviour / settings, it will fail the same way.

---

Very true. I guess part of the process of recommending a new ISP would be to check that technicolour routers aren't in use. I think most of the big providers (Sky / BT / talk talk) don't use them so should be relatively safe. (If anyone knows for sure any input would be welcome!)

---

@Townman wrote:

Remember this is an interaction between the router (when doing DNS resolution) and the OS - change either and the issue appears to be abated.  Who is to say that the OS is not at fault?

---

It also affects (some?) linux distributions. The first time I ran into this the problem was with a linux client. The common thing to all the problems is the router; most routers don't randomly hand out incorrect DNS results and, in my opinion, any router that does so is horribly broken. There are far better ways to achieve the desired result - ie. if you must interfere with traffic, do it at the IP routing level not the DNS level, as IP routing done inside a router cannot be cached by clients.

---

@Townman wrote:

Whatever, as suggested a blanket change to the configuration of these routers would indeed mask the symptoms being experienced.

---

I very strongly agree with this. I hope someone from plus.net can comment on why they've not yet done this.

[#6]

jheenan wrote:

It also affects (some?) linux distributions. The first time I ran into this the problem was with a linux client. The common thing to all the problems is the router; most routers don't randomly hand out incorrect DNS results and, in my opinion, any router that does so is horribly broken. There are far better ways to achieve the desired result - ie. if you must interfere with traffic, do it at the IP routing level not the DNS level, as IP routing done inside a router cannot be cached by clients.

I've not come across reports of this happening with Linux - which is quite interesting and again points to inexplicable repeat requests for URL resolution.

Back at the beginning of my investigation into this issue, one was perplexed by the characteristics that on the same network using the same router at the same time, Win 8 / 8.1 / 10 platforms were failing intermittently whilst Win XP / 7 continued to function without issue.  It took a lot of analysis and research to realise that there needs to be an interaction of events / states for the symptoms to be seen, leaving two unanswered questions / issues.

1. Why does the router fail to resolve the DNS query from PlusNet's DNS service?

Note (a) Changing the router's DNS setting to another DNS service or (b) Changing the PC's DNS to not use the router's DNS (say use PlusNet's direct) avoids the symptoms

2. Given that the earlier OS environments appear to keep on trucking when the router is in this state, why does (amongst others) Win10 fail?  It implies a failure to use already resolved address mappings.

Note: I have encountered a situation with Win10 where one browser window will not connect to a service, but another will.  In investigating the issues, I have seen DNS resolution (via the router's DNS) resolve correctly, but browser sessions still failing to connect - starting a new browser session or doing a DNS flush 'fixes' the issue.  Like wise forcing the router to refresh / clear its spoofed IP table helps too - until next time.

This is not solely a router / ISP issue.

There has though for a long time been concern about how PlusNet's DNS configuration behaves; but there is no conclusive proof that those issues have a bearing here.  It is all very dark black magic - certainly if @bobpullen cannot bottom this out, it must be voodoo!

[#7]

I think the situation can be stated much more simply:

The router should never return incorrect DNS results. These routers do, so the routers are broken.

Yes, different OSes behave differently after having received invalid DNS, but that really doesn't matter (apart from, as you observe, making it an absolute pain to diagnose the problem!). There is no evidence that those OSes are behaving incorrectly, just differently from each other. (There are no hard and fast rules about how little/much OSes should cache DNS). Hence some OSes will work fine with these routers, but the OSes that don't aren't broken.

The fix is undeniably to make the routers never return incorrect DNS results.

[#8]

---

@Townman wrote:

That is a bit of a presumption: if they get a router with the same behaviour / settings, it will fail the same way.

Remember this is an interaction between the router (when doing DNS resolution) and the OS - change either and the issue appears to be abated.  Who is to say that the OS is not at fault?

Please refer to messages #52 or #87 in this thread - Technicolor acknowledged the fault with their firmware. The issue in this thread should be a solved problem, not some big complicated mystery!

[#9]

After the recent huge Windows 10 update / re-installation / whatever, the old DNS trouble returned and I had to disable WANDownSpoofing again. Coincidence? (Also, several hundred files that I had deleted some time ago had reappeared, but I guess that has nothing to do with this topic.) Surely a W10 installation should not mess with a router .ini file?

[#10]

---

ejs wrote:

Please refer to messages #52 or #87 in this thread - Technicolor acknowledged the fault with their firmware. The issue in this thread should be a solved problem, not some big complicated mystery!

Hi @ejs,

Shall we agree that we differ here?  This is a "perfect storm" scenario, which requires a number of contributing factors to come together at the same time for the problem to be seen.  Whilst the link in #87 states that Technicolor identified an opportunity to deliver improvement, it also states that Win 8 does its DNS stuff differently and that Microsoft was investigating.

The practice of spoofing IP addresses is but one factor in the problem.

1. Win8 / 8.1 / 10 appears to (for the want of a better phrase) compartmentalise DNS resolution / caching.  I have reported elsewhere that, I have seen pinging a URL use (resolve to) the spoofed address, whilst at the same time dnslookup (using the router DNS) delivers the correct IP.  I have also seen concurrently two different browser windows not working / working using the spoofed / correct address respectively.  Surely no one would claim that is correct?  It rather looks like having got a bad resolution followed by a revised resolution, Win 8 (etc) persists to use the older bad resolution.  Accepting that a spoofed address resolution ought not to have been delivered, being bipolar about resolution is simply wrong and Microsoft ought to be fixing that.

2. The reason for generating a spoofed address appears to be obscure - switching the router away from using the PlusNET DNS seems to avoid the problem.

@jheenan Wanted to point a finger here - to do that one needs to be clear about where the real problem is.  I suggest that remains a mystery, as we know of at least 3 contributing factors here: change the DNS; switch off spoofing; change the OS; each appears to eliminate the problem.

Personally I just do not see the merit of spoofing; if for whatever reason the router fails to get a good resolution with its upstream DNS, returning a duff resolution (as though it's a good one) is simply unhelpful.   'I could not properly fulfil your resolution request, so here is an address from the test addres pool' ( https://en.m.wikipedia.org/wiki/Reserved_IP_addresses ) is just plain daft.

For Win 8 (etc) to be capable of being bipolar in the instance about the resolution of an IP address is stupid beyond comprehension.

---

Whilst it is not possible to point a finger of blame here, it does remain within PlusNet's ability to remove one of the contributory factors here - to force turn off IP address spoofing.  That does not however identify why when configured with PlusNet's DNS the router churns out spoofed addresses and does not if configured to use (say) Google's public DNS.

i guess we will never know the answer here, rather just be left with "if we remove 'this' factor then the 'perfect storm' does not happen".  Imperfect days!

[#11]

---

@Townman wrote:

---

@ejs wrote:

Please refer to messages #52 or #87 in this thread - Technicolor acknowledged the fault with their firmware. The issue in this thread should be a solved problem, not some big complicated mystery!

Hi @ejs,

Shall we agree that we differ here?  This is a "perfect storm" scenario, which requires a number of contributing factors to come together at the same time for the problem to be seen.  Whilst the link in #87 states that Technicolor identified an opportunity to deliver improvement, it also states that Win 8 does its DNS stuff differently and that Microsoft was investigating.

The practice of spoofing IP addresses is but one factor in the problem.

1. Win8 / 8.1 / 10 appears to (for the want of a better phrase) compartmentalise DNS resolution / caching.  I have reported elsewhere that, I have seen pinging a URL use (resolve to) the spoofed address, whilst at the same time dnslookup (using the router DNS) delivers the correct IP.  I have also seen concurrently two different browser windows not working / working using the spoofed / correct address respectively.  Surely no one would claim that is correct?  It rather looks like having got a bad resolution followed by a revised resolution, Win 8 (etc) persists to use the older bad resolution.  Accepting that a spoofed address resolution ought not to have been delivered, being bipolar about resolution is simply wrong and Microsoft ought to be fixing that.

---

You've drawn an incorrect conclusion here. Please, stop guessing about how this stuff should work and actually dig into some of the details so you understand.

The behaviour you are detailing, whilst it appears wrong to the user, is easily explained by:

a) tabs in the latest browsers being isolated into separate processes

b) a per-process DNS cache

As has been stated several times, the problem is the bad DNS responses. No one has found any evidence that Windows is caching a DNS response beyond the time it was told it was valid for. You perhaps don't like the way Windows caches DNS responses, but that's not a bug.

Can we please try to keep to discussing the root problem with the router that causes the 198.18.1.x addresses in the first place? I'm still hoping we can get an official response from plus.net on why they're not fixing this.

[#12]

---

@jheenan wrote:

Can we please try to keep to discussing the root problem with the router that causes the 198.18.1.x addresses in the first place? I'm still hoping we can get an official response from plus.net on why they're not fixing this.

---

IIRC, after the last FTTC firmware upgrade we pushed out, we did globally disable the WAN spoofing across the units we'd upgraded. Not all of these will have been successful though due to routers being offline at the time etc.

There will still be some units affected and for anyone impacted, I would suggest they carry out the previously discussed 'fix' of telnetting to the router and doing:

: dns server config WANDownSpoofing=disabled
: saveall

Whilst I can't be 100% sure, I remain somewhat doubtful that we'll see any firmware upgrades for this unit from here on in.

[#13]

---

jheenan wrote:

Looking through one wireshark dump it was obvious that the router returning a 198.18.1.32 IP address for a DNS lookup was the issue. Googling then finally brought us here.

Complete shot in the dark, but @jheenan: I don't suppose you still have access to a wireshark capture taken whilst this problem was evident? A recent Windows update seems to have triggered a load more instances but I'm damned if I can replicate the issue myself

[#14]

Hi Bob

I wish I could say I'm surprised, but honestly I'm not! I hope this is the thing that finally gets a firmware update for these routers that fixes this once and for all!

As it happens, I found the pcap lurking in my email - I've sent you a PM with a link to it.

Joseph

[#15]

Note (a) Changing the router's DNS setting to another DNS service or (b) Changing the PC's DNS to not use the router's DNS (say use PlusNet's direct) avoids the symptoms

Correct! BT own the DNS and it's broken. What you are discussing here are the various different results of the failed DNS lookups from BT's broken DNS system.