Closed Bug 157733 Opened 22 years ago Closed 22 years ago

DNS: lookup regression

Categories

(Core :: Networking, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: adamlock, Assigned: smeredith)

Details

(Whiteboard: has r/sr needs a=)

Attachments

(1 file, 4 obsolete files)

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 /
i will take a look.  it may be a regression caused by recent changes to the dns.
Assignee: new-network-bugs → dougt
Severity: normal → blocker
I had the same problem in trunk 20020714, seems to be gone in 20020715, although
I admit I just reinstalled the OS also (WinXP).
I can not reproduce this in a build from this morning. Windows.
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?
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.
Dialup networking was enabled by bug 93002
Attached patch Patch (obsolete) — Splinter Review
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.
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.)
Status: NEW → ASSIGNED
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.
>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.
Attachment #91657 - Attachment is obsolete: true
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.
Keywords: mozilla1.1
over to steve who is working on this.
Assignee: dougt → smeredith
Status: ASSIGNED → NEW
Keywords: mozilla1.1
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.
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. 
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.
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.
Status: NEW → ASSIGNED
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.
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.
Attachment #91836 - Attachment is obsolete: true
Attachment #91889 - Attachment is obsolete: true
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
Summary: DNS lookup regression → DNS: lookup regression
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.
Attachment #91910 - Attachment is obsolete: true
Comment on attachment 92274 [details] [diff] [review]
Minor change to pick up the right dialing location.

r=adamlock
Attachment #92274 - Flags: review+
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
Attachment #92274 - Flags: superreview+
asa, dbaron could you a= this regression fix?
Whiteboard: has r/sr needs a=
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
Attachment #92274 - Flags: approval+
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
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: