Closed Bug 192589 Opened 17 years ago Closed 17 years ago

Conn: Mach-O does not auto-connect


(Core :: Networking, defect, P1, critical)






(Reporter: jcr, Assigned: sfraser_bugs)



(Whiteboard: fixed1.3)


(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212
Build Identifier: MachO nightly of today

The MachO nightly installs and runs, very fast, but when you have to check the
mail or navigate, it waits indefinitely for a connection which does not arrive.
If I run other browsers, I can navigate.

Is there something special to set?

Reproducible: Always

Steps to Reproduce:
I experienced this for the first (and hopefully only) time today.

Mac OS X 10.2.3
Mozilla Mach-O 2003020603
DSL connection using PPPoE

Mozilla had been running fine previously. I quit Mozilla, later started it up
again (the computer had gone to sleep) and it would not connect to anything. I
started up IE and that worked fine.

Quitting Mozilla resulted in a crash (crashlog is attached), and starting it up
again everything went back to normal. Maybe it's just a coincidence and part of
a sleep bug in OS X?
I have installed 1.3b and did not work, but I relauched it and now works.
Now I have enquired more.

to reproduce the bug
0) disconnect from the Internet
1) launch MachO, working online
2) connect to the Internet via DHCP (I don't know if via modem this works)
3) check mail

you see Mozilla checks but cannot connect.

If you swap point 2 with point 1, you will see everything works out fine!
This works for me w/ Mozilla 1.3b.
I'm using DSL w/ PPPoE set with "Connect automatically when needed."

Giovanni: are you using just ethernet, or PPPoE? I need a better description of
how you "connect" via ethernet and DHCP.

Joseph: please put your problem into a new bug w/ a link to the crashlog you
added here. I saw some sluggishness, but no crash.
Summary: MachO does not feel connection to the Internet → Conn: Mach-O does not auto-connect
Now I am using a PPP dial-up connection and the problem is the same.

It seems that Mozilla cannot use the feature offline/online.

That is:

1) connect to the internet via dialup PPP
2) launch mozilla

then if you launch Mozilla AFTER the established connection, it works
if you launch it BUT the connection is still not established, it does not work,
you have to relaunch Mozilla


About the other type of connection, I have a breadband but no PPP nor ADSL, it
is a service we in Italy have, Fastweb, it connects directly via a DHCP and
ethernet to a device called HAG.

Will be more precise tomorrow.
By chance I discovered new facts:

1) connct via dialup PPP
2) launch mozilla and work with it
3) drop the connection and put the powerbook to sleep (I have G3 lombard with
4) wake up, connect via dialup PPP 
5) turn to Mozilla and use it: IT WORKS REALLY GREAT!
6) send long email attachment 4500 [details]kb)
7) unfortunately while sending, drop the connection
8) re-connect same way without stopping the upload: IT WORKS GREAT!

So it seems the bug is at the very first time you launch Mozilla.
Confirming. This is bad. Setting critical and blocking1.3? (this needs to get
fixed before 1.3)

If you launch Mozilla without an active network connection, and then connect,
Mozilla will behave as though it can't connect to the network ("
couldn't be found..." etc.), forcing you to relaunch (apparently it never
re-checks to see if there is an active connection). This is not a problem with
online/offline mode (you can switch back and forth all you want, it makes no
difference), and only occurs if Mozilla starts up before a connection is
established. Mac OS X 10.2.4, Mozilla 1.3b, dialup connection.

(There was a similar problem with the classic Mozilla a couple of years ago.)
Severity: normal → critical
Ever confirmed: true
Flags: blocking1.3?
gordon, simon: can either of you take this bug?  thx!
We need this for 1.3. Who can help?
Flags: blocking1.3? → blocking1.3+
over to simon.  bounce if you don't have time.
Assignee: dougt → sfraser
The answer probably lies in
This is going to be in NSPR, I think.
simon: i didn't read much of that link, but i just wanted to point out that we
have autodial code for windows that lives outside NSPR.  please see
nsSocketTransport::RecoverFromError ... maybe this could be done using a similar
Mozilla succesfully causes the modem to autodial for me. However, I can
reproduce this problem by:
1. Pull out network cable
2. Launch mozilla, note that it can't find the host for the homepage
3. Put network cable back in.
4. Hit reload. Mozilla continues to fail to connect until restarted.
simon: does toggling the online/offline switch make any difference?
I believe this is my fault.  When I added IPv6 support for
Mac OS X, I added a lookup for the IPv4 and IPv6 network
addresses of the local machine during NSPR initialization.
The result of the lookup is used by PR_GetIPNodeByName to
determine if it needs to return IPv4 or IPv6 addresses.

If NSPR is initialized while the local machine is off line,
PR_GetIPNodeByName will remember that the local machine has
no IPv4 and IPv6 network addresses and will not return any

I suspect that removing IPv6 support will fix this problem.
I will attach a patch for you to try.
The issue here seems to be that _pr_have_inet_if in prnetdb.c never gets set
back to 1 when the network becomes available.
Simon is right.  Please try reverting mozilla/nsprpub/pr/include/md/_darwin.h
to rev. and recompile nsprpub.  (No need to recompile anything outside

# change directory to the top of your build tree
% cd nsprpub
% make clean
% make
My current thinking is that NSPR needs to register with the System Configuration
framework to get notified when the available network interfaces change.
Yeah, reverting _darwwin.h fixes this. Should we proceed with the "correct fix"
(listen for system configuration changes), or should we back out IPv6 for Darwin?
FWIW, I've had requests that Chimera support IPv6, so it is wanted.

What other issues in do we
need to address? Does NSPR deal with the local IP address changing?
Note that it's easy to reproduce this bug by just toggling the network ports in
the Network system prefs panel. You don't have to pull any wires out of the wall.
IPv6 is not tested by QA, so if you need to make this work for 1.3f and we are
running out of time, get rid of it for the purposes of the release.
I think fixing this bug is more important than IPv6 support.
We should back out the IPv6 support change in
mozilla/nsprpub/pr/include/md/_darwin.h, and work on the
long term solution.

Listening for system configuration changes is not portable.
Ideally I want a portable solution because the same code is
also used for AIX and FreeBSD, although I don't think there
are enough laptops running AIX or FreeBSD to make this a
serious problem for their users.
I have a chunk of sample code that listens for network configuration changes on
OS X. Of course, we'd have to wrap this in the usual nest of NSPR defines, so
that other platforms can implement it in different ways.

I guess, for now, we can just #if 0 the IPv6 stuff in _darwin.h.
Attached patch Proposed patchSplinter Review
Keep looking up the local IP addresses as long as there
are none.  This will allow us to detect the transition
from offline to online.  NSPR does not care about the
actual addresses but rather whether the local host has
any IPv4 or IPv6 network interfaces.

Please try this patch.
Attachment #114979 - Flags: superreview?(sfraser)
Attachment #114979 - Flags: review?(darin)
Comment on attachment 114979 [details] [diff] [review]
Proposed patch

this patch makes sense, but what if someone has an IPv6 interface up and
running, but then shuts it down (possibly replacing it with an IPv4 interface)?
 how is the online to offline transistion handled?
The online to offline transition won't be detected, but
PR_GetIPNodeByName fails anyway when the machine is offline.
When the machine goes online again, PR_GetIPNodeByName
will use the IPv4 and IPv6 interface presence information
it obtained previously, which will be correct except for
the following cases, which I don't think are likely to
happen in practice:

... IPv4 interface up -> offline -> IPv6 interface up ...


... IPv6 interface up -> offline -> IPv4 interface up ...


Another way to look at this patch is that although it can't
handle some rare cases, it is strictly better than what we
have now.
Comment on attachment 114979 [details] [diff] [review]
Proposed patch

ok, that's what i thought.  thanks for the detailed explanation :)

Attachment #114979 - Flags: review?(darin) → review+
did this problem affect people who are not using IPv6? I never got my system to
break, and I know I'm IPv4-only.
Summary: Conn: Mach-O does not auto-connect → Conn: IPv6: Mach-O does not auto-connect
I don't know what IPv6 is, but even if I use dialup connection Mozilla does not
work if the connection is established after Mozilla is launched.
This bug was introduced by my change to add IPv6 support
but it has nothing to do with IPv6.
Summary: Conn: IPv6: Mach-O does not auto-connect → Conn: Mach-O does not auto-connect
Comment on attachment 114979 [details] [diff] [review]
Proposed patch

Patch checked into the NSPR TIP (NSPR 4.3) and the
NSPRPUB_PRE_4_2_CLIENT_BRANCH (mozilla 1.4alpha).
Attachment #114979 - Flags: superreview?(sfraser)
*** Bug 194592 has been marked as a duplicate of this bug. ***
*** Bug 194476 has been marked as a duplicate of this bug. ***
*** Bug 194479 has been marked as a duplicate of this bug. ***
Comment on attachment 114979 [details] [diff] [review]
Proposed patch

We'd like to get this for 1.3. Can someone make sure it's landed for the 1.3
branch? Thanks.
Attachment #114979 - Flags: approval1.3+
wtc, can you land this for us for 1.3? we're getting close and need everything
in asap.
Patch checked into the MOZILLA_1_3_BRANCH (mozilla 1.3 final).
Marked the bug fixed.
Closed: 17 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.3final
Thanks Wan-Teh.
Whiteboard: fixed1.3
Giovanni: Can you try a new build? I was not able to reproduce this bug (hence
all my questions to wtc...) so I don't think I could safely verify this fix.
ok, I'm going to download the current build
OK, with ethernet DHCP direct connection it works now.

I launched Mozilla and then connected manually to the net, it works!
I've tried:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030325

as well as the 1.3 final release and the bug still seems to be there.

1) Quit Moz

2) Disconnect from network (Airport in my case)

3) Start Moz

4) No connections (domain not found)

5) Connect to network

6) Still no connections (domain not found)

Reproducible: Always

Maybe it is caching the result of "I can't connect now so I won't bother trying"???
Giovanni - based on your comments, as reporter, I'm verifying this.
Paul, please try a newer version and see if you have the same problem. If so,
file a new bug.

I just tried in a recent 1.6 build and everything seems to work fine.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113

Great Job!  Thanks!
You need to log in before you can comment on or make changes to this bug.