Last Comment Bug 157733 - DNS: lookup regression
: DNS: lookup regression
Status: RESOLVED FIXED
has r/sr needs a=
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: x86 Windows XP
: -- blocker (vote)
: ---
Assigned To: Steve Meredith (gone)
: benc
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-16 09:16 PDT by Adam Lock
Modified: 2011-08-05 22:37 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (1017 bytes, patch)
2002-07-17 10:08 PDT, Adam Lock
no flags Details | Diff | Splinter Review
Patch which will not assume the service will alway dial. (3.95 KB, patch)
2002-07-18 11:26 PDT, Steve Meredith (gone)
no flags Details | Diff | Splinter Review
patch that checks OS settings better (20.06 KB, patch)
2002-07-18 17:39 PDT, Steve Meredith (gone)
no flags Details | Diff | Splinter Review
Minor change to last patch to get it to work on Win 2k as well. (20.28 KB, patch)
2002-07-18 21:44 PDT, Steve Meredith (gone)
no flags Details | Diff | Splinter Review
Minor change to pick up the right dialing location. (18.96 KB, patch)
2002-07-22 14:00 PDT, Steve Meredith (gone)
adamlock: review+
darin.moz: superreview+
asa: approval+
Details | Diff | Splinter Review

Description Adam Lock 2002-07-16 09:16:33 PDT
Attempt to load an invalid page, e.g. www.lkjldskfjlsdkjflksdfjlksdfjlk.com and
Mozilla just sits there forever. There appears to be a problem with the DNS
lookup behaviour.

This might be XP specific since I cannot reproduce on W2K, Mac or Linux.

For simplicity you can reproduce using TestSocketIO, e.g.

TestSocketIO www.lkjldskfjlsdkjflksdfjlksdfjlk.com /
Comment 1 Doug Turner (:dougt) 2002-07-16 09:29:45 PDT
i will take a look.  it may be a regression caused by recent changes to the dns.
Comment 2 Ere Maijala (slow) 2002-07-16 11:27:53 PDT
I had the same problem in trunk 20020714, seems to be gone in 20020715, although
I admit I just reinstalled the OS also (WinXP).
Comment 3 Doug Turner (:dougt) 2002-07-16 15:13:24 PDT
I can not reproduce this in a build from this morning. Windows.
Comment 4 Adam Lock 2002-07-17 06:10:20 PDT
I was able to reproduce this again late last night on XP but not W2K. What were
the recent DNS changes that may be causing this?
Comment 5 Adam Lock 2002-07-17 09:22:36 PDT
I've been digging and I think the problem is the automatic RAS dialup feature in
Win32.

The pref "network.autodial-helper.enabled" is set to true in all.js. On Win32
this means the socket transport will attempt to use the native connection helper
object when a DNS lookup fails. On my XP system I appear to have the "RasAuto"
service (it's probably there by default) so the nsRASAutodial thinks I want to
use it and attempts to dial out. Unfortunately, this fails each time so it goes
around and around for ever trying to do the lookup.

I'll see if there is a simple patch to fix RAS.
Comment 6 Adam Lock 2002-07-17 09:54:08 PDT
Dialup networking was enabled by bug 93002
Comment 7 Adam Lock 2002-07-17 10:08:53 PDT
Created attachment 91657 [details] [diff] [review]
Patch

This patch changes how the nsRASAutoDial decides if it should be used or not.
The old behaviour tested if the RAS service was running and returned
AUTODIAL_USE_SERVICE. On XP (on mine at least), the service always seems to be
running, either by default or because installing a modem or AOL enabled it. BTW
My IE is set to "Never dial a connection" so it isn't that.

Steve, can you verify and review the new ordering? In this ordering, we first
test the IE settings before resorting to guesswork based on whether the RAS
service is running or not. I also notice the RAS API has a method called
RasGetAutodialEnable which we don't call. Perhaps that would be more reliable
than testing for services, but I'm not familiar with RAS so I don't know.
Comment 8 Steve Meredith (gone) 2002-07-17 11:27:35 PDT
No, we need to check to see if the service is running first, and let it do its
work if it is. We only want to try to dial ourselves if the service is not
running. If you do it the other way around you can end up with two sets of
autodial dialogs if the user cancels the first one:

We dial from withing the code, and the user cancels the dialup dialog.
The service then tries to dial.

It sounds like what is happening in your case is that the service is running, so
we expect it to dial, but there are no connections set up, so it doesn't
actually dial. But we retry because we assume it would dial. 

I think the best fix is to not retry if the service is running, since we can't
assume it will dial just because it is running (the assumption I made when
writing this.)
Comment 9 Ere Maijala (slow) 2002-07-17 11:45:44 PDT
Please keep in mind that (R)RAS does much more than dial-up. Maybe we could
reproduce this also on Win2K (at least server) if RAS is enabled for dial-in?
Anyway, I think Steve is right in that we can't assume anything just because
it's running.
Comment 10 Steve Meredith (gone) 2002-07-18 11:23:28 PDT
>Please keep in mind that (R)RAS does much more than dial-up.

Yes, but the service we are examining only does the autodial stuff.
Comment 11 Steve Meredith (gone) 2002-07-18 11:26:14 PDT
Created attachment 91836 [details] [diff] [review]
Patch which will not assume the service will alway dial.
Comment 12 Adam Lock 2002-07-18 11:54:33 PDT
Adding keyword. 

Note that on XP is that the service runs even when it's not actually doing
or required to do anything. I don't think you can infer anything from the fact
it is running.
Comment 13 Doug Turner (:dougt) 2002-07-18 11:55:11 PDT
over to steve who is working on this.
Comment 14 Adam Lock 2002-07-18 12:07:39 PDT
The latest patch does work, however it puts some junk about the unresolved
address into my registry under HKEY_CURRENT_USER\Software\Microsoft\RAS
Autodial\Addresses. I still believe it is doing that because it erroneously
thinks I have RAS and want to use when I don't.
Comment 15 Steve Meredith (gone) 2002-07-18 12:14:56 PDT
Yes, if the autodial service is running, you'll get that "junk" in the registry.
That where Windows stores the autodial database, and that's how I try to force
the service to dial when it can't reach an address. (I don't add them to the
registry directly--I use the RAS API, and the service puts them there itself.)
Addresses will be added to that area of the registry by the OS in certain other
cases as well. 
Comment 16 Adam Lock 2002-07-18 12:28:36 PDT
As I mentioned though, I am *not* running RAS in any way shape or form. I have
no idea why the service is enabled on my XP system (perhaps all of them), but my
options all say to use the local network, not dial out. I just believe there is
something wrong if it tries to use the RAS service even when the internet
settings say it shouldn't.
Comment 17 Steve Meredith (gone) 2002-07-18 13:23:59 PDT
I see what you mean. I am interpreting the fact that the RAS autodial service is
running to mean that you want to use RAS autodial. In your case this isn't true
because you didn't start the service on your own. However, I don't know of any
other Windows settings relating to the autodial service.

Here are the problems I am trying to solve with my autodial approach:

People who know Windows XP know that they should start the autodial service if
they want the OS to autodial on error. That works fine with Mozilla without any
extra code, UNLESS there is a network card installed (even when it's not plugged
in to anything.) It that case, the only way the service will trigger an autodial
is if the network address is in the autodial database, and that's what I'm doing.

People who don't know XP want the OS to autodial if they turn it on in the
control panel | Internet Options | Connections. In reality, those setting have
nothing whatsoever to do with controlling the service: they only control IE and
Outlook. But we try to accommodate those people: if they configure auto there,
then we bring up the autodial dialogs ourselves in the code, UNLESS the autodial
service is running. Because if it is running, the service might try to dial. We
have no way of knowing if it did or not. If it did, and the user cancels, and
then we try to dial, there will be two dialup dialogs. 

Now I was assuming the service would always dial on error if running, so there
is a new additional problem: if it is running and doesn't dial, we won't either,
and autodial is broken for that case.
Comment 18 Steve Meredith (gone) 2002-07-18 13:42:07 PDT
Oh wait: there is a setting that controls if the RAS autodial service will dial
or not. I didn't come across this setting in my prior research. It's in Network
Connection | Avanced | Dialup Preferences. So if I test for that setting as well
as if the service is running, and carry on as before, I should be in good shape.
Comment 19 Steve Meredith (gone) 2002-07-18 17:39:47 PDT
Created attachment 91889 [details] [diff] [review]
patch that checks OS settings better

This patch changes the behavior such that the code won't write to the autodial
database unless the autodial service is running AND autodial setting is enabled
in Network Connections | Advanced | Dialup Preferences. I also now examine the
setting that is supposed to disable the autodial service for the remainer of
the logon session, which I wasn't doing before. 

I had to make some changes to pick up the setting from the dialing location,
and in the process fixed a problem where the dialing location was hardwired to
1 in the call to RasSetAutodialAddress(). These changes should make the
autodial behavior work better when used when the service is running. It will
still work as before when the service is not running.

Also, since the number of dynamically loaded functions is getting large, I
moved the initialization of those into functions and added NULL checking there
instead of at every call.
Comment 20 Steve Meredith (gone) 2002-07-18 21:44:29 PDT
Created attachment 91910 [details] [diff] [review]
Minor change to last patch to get it to work on Win 2k as well.
Comment 21 Adam Lock 2002-07-19 09:15:20 PDT
Comment on attachment 91910 [details] [diff] [review]
Minor change to last patch to get it to work on Win 2k as well.

New patch works for me. r=adamlock
Comment 22 Steve Meredith (gone) 2002-07-22 14:00:29 PDT
Created attachment 92274 [details] [diff] [review]
Minor change to pick up the right dialing location.

This is a change to the last patch to pick up the correct "dialing location" to
use when querying the autodial setting for the autodial service. The service
uses the setting of the "current" dialing location--last patch I was checking
for the setting on any dialing location.
Comment 23 Adam Lock 2002-07-23 09:11:37 PDT
Comment on attachment 92274 [details] [diff] [review]
Minor change to pick up the right dialing location.

r=adamlock
Comment 24 Darin Fisher 2002-07-23 12:00:04 PDT
Comment on attachment 92274 [details] [diff] [review]
Minor change to pick up the right dialing location.


>Index: nsAutodialWin.cpp

> // force it to dail in that case by adding the network address to its db.)

s/dail/dial/

otherwise the changes look solid to me.  sr=darin
Comment 25 jbetak@netscape.com (away - not reading bugmail) 2002-07-23 18:44:14 PDT
asa, dbaron could you a= this regression fix?
Comment 26 Asa Dotzler [:asa] 2002-07-23 19:09:55 PDT
Comment on attachment 92274 [details] [diff] [review]
Minor change to pick up the right dialing location.

a=asa (on behalf of drivers) for checkin to 1.1
Comment 27 jbetak@netscape.com (away - not reading bugmail) 2002-07-23 19:53:16 PDT
thanks Asa! 

I checked in the patch on Steve's behalf. Here is the protocol:

cvs commit -m "DNS: lookup regression, r=adamlock, sr=darin, a=asa, local fix 
for autodial by s..." nsAutodialWin.cpp nsAutodialWin.h (in directory 
C:\build\trunk\mozilla\netwerk\base\src\)
Checking in nsAutodialWin.cpp;
/cvsroot/mozilla/netwerk/base/src/nsAutodialWin.cpp,v  <--  nsAutodialWin.cpp
new revision: 1.3; previous revision: 1.2
done
Checking in nsAutodialWin.h;
/cvsroot/mozilla/netwerk/base/src/nsAutodialWin.h,v  <--  nsAutodialWin.h
new revision: 1.2; previous revision: 1.1
done

Note You need to log in before you can comment on or make changes to this bug.