Closed Bug 49990 Opened 20 years ago Closed 19 years ago

Networking Fails after sleep/wakeup cycle (MacOS only)

Categories

(Core :: Networking, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cyrus, Assigned: gordon)

References

Details

(Keywords: testcase, Whiteboard: [nsbeta3-][rtm++])

Attachments

(2 files)

On my PB G3, launch lizard, networking works, put pb g3 to sleep, wakeup
computere, networking doesn't work.

This may also be related to a similar problem where swithcing network addresses
requires a mozilla quit/launch.

Both of these things work under NC 4.7
*** Bug 49991 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
This happens under MacOS 8.6 as well, PowerBook G3 Lombard (SCSI) TCP/IP over
ethernet
*** Bug 52395 has been marked as a duplicate of this bug. ***
Importing keywords from bug 52395 
Keywords: 4xp, nsbeta3, nsmac2, rtm
Shouldn't gordon own this?
I've also noticed that networking fails after you switch TCP settings, such as 
from Airport to AOL Link (aol dialup). Should this be a different bug?
yes he should :)
Assignee: gagan → gordon
Networking also dies when DHCP server expires address lease and a new address 
is bound, without any TCP config changes on the client.  (DHCP server is 
IPNetRouter w/maximum lease length 20 min, client is OS 8.6 Lombard SCSI.)
Regarding pinkerton's question about changing TCP settings possibly being a 

different bug - I don't believe it is.  I suspect the problem is either that 

we're caching the IP address we get when networking starts up and/or that we're 

ignoring the message from OT when the IP settings change (be it due to a manual 

change or a DHCP lease expiring which could also be the case ina  sleep/wake 

cycle)

*** Bug 44984 has been marked as a duplicate of this bug. ***
*** Bug 26718 has been marked as a duplicate of this bug. ***
I was the original reporter of bug 26718. Thought I'd let folks know where the
bug stands from the Linux standpoint as of the 20Sept build.

If you launch Mozilla with no networking at all (all I had was the loopback
adapter) mozilla will crash about 1/2 the time if the start-up page is anything
that forces it to access the network. If the startup page is about:blank,
mozilla launches normally and then gives reasonable errors if an attempt to
access the net is made.

When Mozilla crashes, it briefly flashes a dialog that is blank and has
mozilla-bin in the title. About 2 seconds later, it segfaults. On the times that
it does not crash, it gives a reasonable "xxxx could not be accessed" error.

FYI

David

minus since futured.
Whiteboard: [nsbeta3-]
approving for rtm.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm+]
I have a fix for this.  I have one more test case to verify, and need to get 
reviews.  Part of the fix is in NSPR so I'll need to coordinate with Wan-Teh as 
well.  This could be ready for PR3.
Status: NEW → ASSIGNED
As much as I'd have liked this to go in for PR3, the stricter criterion just
wouldn't let us approve that. This a clear go for RTM though.
Just to let gordon know I have verified the fix works on my PowerBook as well as 

my G4 desktop.  I did run into the PowerBook hang on wakeup problem pinkerton 

reported but only once in about 12 tries (i.e. now that I want to repro it I 

can't) but I'm convinced that's a different problem.  I say check these netwrok 

fixes in as soon as we get approval.

PDT marking [rtm need info] until patch and code reviews are available.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm need info]
r=sfraser on latest patch
Target Milestone: Future → M18
Okay, we have reviews and super reviews.  Setting back to rtm+ for consideration 
by PDT.

Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm+]
This is a large-ish patch. How much risk is there? If more than 0%, please land
on the trunk and validate before landing on the branch. We can not afford
regressions on the branch.
No answer to the risk question, so marking [rtm-]. Time to focus on crash/data
loss issues.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm-]
Man I hate this rtm- after inactivity policy.

This bug will make Netscape 6 unusable for around 50% of Mac users, I'd estimate. 
Mac OS default settings are to sleep after 30 mins, and many users machines will 
sleep several times during the day, and certainly at night. If I had to quit and 
restart Netscape 6 several time a day because of this, it would go into the trash 
pretty quickly.

I think the patch has low risk; it's really just changing eager init of Open 
Transport to lazy init/reinit after sleep.

Putting [rtm need info] back.
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-][rtm need info]
i agree that the patch is minimal risk despite the size. this should go on the
branch.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm+]
Since we're having difficulty getting the NSPR changes landed on the trunk the 
plan is for sdagley, sfraser and gordon to test the AIM and mail components to 
make sure there's no unexpected side effects on them from the change and get back 
to PDT once that info is in hand
So thank you for the risk assesment. That helps.  Did this get landed on the
trunk per Phil's earlier request?  It would be good to check the change out
there.  Marking need info
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm+ need info]
Yes. This did land on the trunk and has had no problems and should land on the 
branch. Back to rtm+ and I STRONGLY recommend a rtm++
Whiteboard: [nsbeta3-][rtm+ need info] → [nsbeta3-][rtm+]
Please fix this soon!  My mac is currently hung due to network failure 
(presumably) since I turned off my networking while I ate lunch (while running a 
branch build).  I wish I would have left my Mac running the trunk build instead.  
:-(
These fixes (to nspr and nsDnsService) enable DNS lookups after a sleep/wakeup 
cycle (or a change to the TCP configuration). This allows connectionless 
protocols (such as HTTP) to continue working.  It does NOT fix connection-based 
protocols (such as IMAP), and Mike Pinkerton has filed a separate bug related to 
that (bug 56170).  Scott MacGregor informs me that AIM does not use nspr or 
necko, and so is unaffected by this change.  Pinkerton validates that browsing is 
better with the fix, and mail/news is no worse than before.

The fix to nsDnsService has been in the trunk since Monday, and I landed the nspr 
fix to the NSPRPUB_CLIENT_BRANCH, NSPRPUB_RELEASE_4_0_BRANCH, and tip yesterday.
per sdagley, testing this on the trunk showed a problem with mail after machine
wakes up - filed as bug 56170.  How far away are we from the complete fix to
have both browser and mail working correctly?  Is mail broken after sleeping
because of 1) this is an incomplete fix or 2) mail uses some interesting code
paths that we're not handling in this patch?  Thanks.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm need info]
The mail and browser cases are different. We have a separate "fix" for mail so
that it no longer locks the app, but you have to close and re-open the window.
That's fine by me for RTM!
Mail issue is an independent one (being tracked under bug 56170) marking this to 
rtm+ yet again... If someone has a new desparate need to set this back to [rtm 
need info] then please give me or gordon a call!
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm+]
rtm++ since the mail problem is a separate bug, not a problem with the patch for 
the DNS service which fixes the browser window. Since PDT wanted to make sure 
this patch was really correct, and it seems to be, marking rtm++
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm++]
Okay, the fix has been checked into the branch. Marking fixed.  Tom, do you have 
a way of validating this, or do you need some help?
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified on branch:

Mac os8.6 2000101908
Keywords: vtrunk
*** Bug 26421 has been marked as a duplicate of this bug. ***
QA REVIEW:
Dupe review: bug 44984, 26718 are no longer dupes and on their own.

+ relnote:

MacOS systems should now go to sleep and wake without going deaf to the network.

+testcase:
Should include powerbooks.

Summary: Networking Fails after sleep/wakeup cycle → Networking Fails after sleep/wakeup cycle (MacOS only)
VERIFIED: Mozilla 0.9.5
+testcase, -other keywords
Mac OS X build in 10.0.2
Mac OS build in classic mode
MacOS 9.1.

Status: RESOLVED → VERIFIED
Keywords: relnote, verifyme, vtrunk
You need to log in before you can comment on or make changes to this bug.