Conn: Mach-O does not auto-connect

VERIFIED FIXED in mozilla1.3final

Status

()

Core
Networking
P1
critical
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Giovanni Gatti, Assigned: Simon Fraser)

Tracking

Trunk
mozilla1.3final
PowerPC
Mac OS X
Points:
---
Bug Flags:
blocking1.3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed1.3)

Attachments

(4 attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Created attachment 114068 [details]
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?
(Reporter)

Comment 2

16 years ago
I have installed 1.3b and did not work, but I relauched it and now works.
(Reporter)

Comment 3

16 years ago
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

16 years ago
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
(Reporter)

Comment 5

16 years ago
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.
(Reporter)

Comment 6

16 years ago
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.
(Reporter)

Comment 7

16 years ago
Created attachment 114437 [details]
Pciture of Network with Ip data

Comment 8

16 years ago
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.)
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.3?

Comment 9

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

Comment 10

16 years ago
We need this for 1.3. Who can help?
Flags: blocking1.3? → blocking1.3+

Comment 11

16 years ago
over to simon.  bounce if you don't have time.
Assignee: dougt → sfraser
(Assignee)

Comment 12

16 years ago
The answer probably lies in http://developer.apple.com/technotes/tn/tn1145.html
This is going to be in NSPR, I think.
Status: NEW → ASSIGNED

Comment 13

16 years ago
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.
(Assignee)

Comment 14

16 years ago
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

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

Comment 16

16 years ago
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.
(Assignee)

Comment 17

16 years ago
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

16 years ago
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
(Assignee)

Comment 19

16 years ago
My current thinking is that NSPR needs to register with the System Configuration
framework to get notified when the available network interfaces change.
(Assignee)

Comment 20

16 years ago
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?
(Assignee)

Comment 21

16 years ago
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

16 years ago
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

16 years ago
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.
(Assignee)

Comment 24

16 years ago
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.
(Assignee)

Comment 25

16 years ago
Created attachment 114960 [details] [diff] [review]
Patch to back out IPv6 support for Darwin (last resort)

Comment 26

16 years ago
Created attachment 114979 [details] [diff] [review]
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.

Updated

16 years ago
Attachment #114979 - Flags: superreview?(sfraser)
Attachment #114979 - Flags: review?(darin)

Comment 27

16 years ago
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

16 years ago
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

16 years ago
Comment on attachment 114979 [details] [diff] [review]
Proposed patch

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

r=darin
Attachment #114979 - Flags: review?(darin) → review+

Comment 30

16 years ago
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
(Reporter)

Comment 31

16 years ago
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

16 years ago
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 33

16 years ago
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)

Comment 34

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

Comment 35

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

Comment 36

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

Comment 37

16 years ago
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+

Comment 38

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

Comment 39

16 years ago
Patch checked into the MOZILLA_1_3_BRANCH (mozilla 1.3 final).
Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.3final

Comment 40

16 years ago
Thanks Wan-Teh.
Whiteboard: fixed1.3

Comment 41

16 years ago
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.
(Reporter)

Comment 42

16 years ago
ok, I'm going to download the current build
(Reporter)

Comment 43

16 years ago
OK, with ethernet DHCP direct connection it works now.

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

Comment 44

16 years ago
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

15 years ago
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.
Status: RESOLVED → VERIFIED

Comment 46

15 years ago
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!
You need to log in before you can comment on or make changes to this bug.