192589 - Conn: Mach-O does not auto-connect

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Giovanni Gatti]

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:
1.
2.
3.

Comment 1

[Joseph Delaney]

Attachment: Crash log, after failure to connect followed by quit

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?

Comment 2

[Giovanni Gatti]

I have installed 1.3b and did not work, but I relauched it and now works.

Comment 3

[Giovanni Gatti]

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!

Comment 4

[benc]

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.

Comment 5

[Giovanni Gatti]

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.

Comment 6

[Giovanni Gatti]

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
10.1.5)
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.

Comment 7

[Giovanni Gatti]

Attachment: Pciture of Network with Ip data

Comment 8

[Adam]

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 ("www.mozilla.org
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.)

Comment 9

[Darin Fisher]

gordon, simon: can either of you take this bug?  thx!

Comment 10

[Asa Dotzler [:asa]]

We need this for 1.3. Who can help?

Comment 11

[Doug Turner (:dougt)]

over to simon.  bounce if you don't have time.

Comment 12

[Simon Fraser [no longer active]]

The answer probably lies in http://developer.apple.com/technotes/tn/tn1145.html
This is going to be in NSPR, I think.

Comment 13

[Darin Fisher]

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
solution.

Comment 14

[Simon Fraser [no longer active]]

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.

Comment 15

[Darin Fisher]

simon: does toggling the online/offline switch make any difference?

Comment 16

[Wan-Teh Chang]

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
address.

I suspect that removing IPv6 support will fix this problem.
I will attach a patch for you to try.

Comment 17

[Simon Fraser [no longer active]]

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.

Comment 18

[Wan-Teh Chang]

Simon is right.  Please try reverting mozilla/nsprpub/pr/include/md/_darwin.h
to rev. 3.10.4.1 and recompile nsprpub.  (No need to recompile anything outside
nsprpub.)

# change directory to the top of your build tree
% cd nsprpub
% make clean
% make

Comment 19

[Simon Fraser [no longer active]]

My current thinking is that NSPR needs to register with the System Configuration
framework to get notified when the available network interfaces change.

Comment 20

[Simon Fraser [no longer active]]

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 http://developer.apple.com/technotes/tn/tn1145.html do we
need to address? Does NSPR deal with the local IP address changing?

Comment 21

[Simon Fraser [no longer active]]

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.

Comment 22

[benc]

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.

Comment 23

[Wan-Teh Chang]

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.

Comment 24

[Simon Fraser [no longer active]]

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.

Comment 25

[Simon Fraser [no longer active]]

Attachment: Patch to back out IPv6 support for Darwin (last resort)

Comment 26

[Wan-Teh Chang]

Attachment: Proposed patch

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.

Comment 27

[Darin Fisher]

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?

Comment 28

[Wan-Teh Chang]

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 ...

or

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

etc.

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 29

[Darin Fisher]

Comment on attachment 114979 [details] [diff] [review]
Proposed patch

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

r=darin

Comment 30

[benc]

did this problem affect people who are not using IPv6? I never got my system to
break, and I know I'm IPv4-only.

Comment 31

[Giovanni Gatti]

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.

Comment 32

[Wan-Teh Chang]

This bug was introduced by my change to add IPv6 support
but it has nothing to do with IPv6.

Comment 33

[Wan-Teh Chang]

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).

Comment 34

[R.K.Aa.]

*** Bug 194592 has been marked as a duplicate of this bug. ***

Comment 35

[R.K.Aa.]

*** Bug 194476 has been marked as a duplicate of this bug. ***

Comment 36

[R.K.Aa.]

*** Bug 194479 has been marked as a duplicate of this bug. ***

Comment 37

[Asa Dotzler [:asa]]

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.

Comment 38

[Asa Dotzler [:asa]]

wtc, can you land this for us for 1.3? we're getting close and need everything
in asap.

Comment 39

[Wan-Teh Chang]

Patch checked into the MOZILLA_1_3_BRANCH (mozilla 1.3 final).
Marked the bug fixed.

Comment 40

[Asa Dotzler [:asa]]

Thanks Wan-Teh.

Comment 41

[benc]

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.

Comment 42

[Giovanni Gatti]

ok, I'm going to download the current build

Comment 43

[Giovanni Gatti]

OK, with ethernet DHCP direct connection it works now.

I launched Mozilla and then connected manually to the net, it works!

Comment 44

[Paul Burney]

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"???

Comment 45

[benc]

VERIFIED:
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.

Comment 46

[Paul Burney]

VERIFIED FIXED:

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!