I use a laptop and take the laptop between home and work, at both places I use DHCP in order to get an IP address. If I leave the browser running, put the computer into suspend and go from one site to the other and reconnect the network at the new site, mozilla refuses to find any sites until it is restarted. It appears as though the ip number for eth0 is being used in inet_addr of sockaddr_in, instead of leaving it set to INADDR_ANY. This would prevent a connect from occurring if the underlying IP number was changed. You may want to not set the local IP adder, if you do not set this member of the sockaddr, it will default to whatever eth0 has when the connect function is called. Good Luck!

*** This bug has been marked as a duplicate of 64857 ***

REOPEN: That bug only addresses changes in the DNS server configuration, not in the IP address. Other bugs I am trying to digest suggest this may be a separate problem. You could isloate DNS by going to a URL via IP address after making the DHCP change.

Hmm. I am inclined to think this will still end up a dup of bug 64857 (a dhcp renegotiation will update both dns servers and ip addr through at the same time, and the update to the ip addr needs to be picked up through nsDnsService anyways...), but for now getting this out of unconfirmed.

I'll take this one since it's somewhat DNS related.

isn't both this and bug 64857 basically dups of bug 26718?

I see this bug on Mac OS X, too. For reference, I use a DHCP server that gives me IPs which have no corresponding DNS entries, so it's not a problem with cached DNS entries. Perhaps related, perhaps not: for me, the following steps repeatably cause mozilla to hang hard: 1) sleep 2) wake 3) quit mozilla

Chris: can you confirm (via ifconfig), that your address changes b/c of sleep/wake? If not, (sleep only problem, no IP number change), lets get a new bug, b/c sleep/wake is tested for, and we've fixed bugs like this in the past.

Ben, If you suggest I need to file a new bug, I'd be happy to do so. Please advise me (offline, if you like) I cannot reproduce here at work since I keep getting the same IP from DHCP lately. Just now I tried sleep, wake, quit and didn't get a hang, but since I got the same IP it's not much of a test... But I just thought up and tried another test: * Launched moz (including my IMAP connection) * unplugged ethernet cable * quit moz which resulted in a lockup just like I saw before. Maybe it's just waiting for a timeout and I was too impatient before force-quitting, but it is really locked hard in that interval - app doesn't respond in any way. I see similar behavior at home when connected by modem and the connection drops unexpectedly -- Mozilla hangs on quit in both of these scenarios: * I quit while disconnected * I reconnect, note that I can browse in a newly-launched IE, but cannot browse/read mail/etc in moz despite the up connection. I try to quit moz and get a hang. I have not checked that the IP changes on re-dialup, but I assume it does. If you'd like me to, I can check next time I'm home and dialed up. Sorry this is such a messy report...

This sounds like an dup of 64857. We should get 64857 as soon as we can. *** This bug has been marked as a duplicate of 64857 ***

Chris: I'm not sure why mozilla would hang on quit if you had a physical network disconnect. Do you see this only on Mac OS?

Benjamin: I just did some testing. I cannot reproduce the hang with a clean profile, or with a clean profile plus my IMAP connection. But with my usual profile, I can reproduce the hand with these steps: * Launch moz (2002032008 build) (my IMAP connection auto-launches with the main/news window) - connects to Google as my default page * Disconnect the ethernet cable for my LAN - note that I get a "lookupd sighup" on the console * Quit Mozilla - hangs with typical OSX "spinning CD" - reconnecting the cable does not un-hang The exact same steps do not result in a hang for a clean profile (except the mail/news win auto-open, which I launched manually, and the default page is mozilla.org, not google). Lookupd is not at fault, because I see the same error message with the clean profile with no hang. I hate irreproduceable problems like this.... Any ideas what prefs might be involved? I assume it must be an open connection that's causing the hang. But if it's not IMAP, I don't know what it is. Maybe an HTTP 1.1 keepalive?

Chris: a clean profile might have different network activity. This looks distinct from this bug, so lets create a new bug, copy the steps you have, and continue there.

VERIFIED/dupe This was never fully isolated, but if it were still a problem, we would be getting more reports.