Implement nsINetworkLinkService for Mac OSX

RESOLVED DUPLICATE of bug 426932

Status

()

Core
Networking
P1
normal
RESOLVED DUPLICATE of bug 426932
11 years ago
8 years ago

People

(Reporter: Darin Fisher, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
Implement nsINetworkLinkService for Mac OSX
(Reporter)

Updated

11 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
http://tuvix.apple.com/documentation/Networking/Conceptual/SystemConfigFrameworks/SystemConfigFrameworks.pdf

APIs are 10.3+, so we'd need to use a dynamic component or dynamic symbol loading.

Comment 2

11 years ago
Note that on trunk we are 10.3+ only, so that patch doesn't need dynamic symbol loading.
(Reporter)

Comment 3

11 years ago
NOTE: this is targeted for FF2 :-)

Comment 4

11 years ago
I meant that the patch for trunk should be different than the one for FF2.
When was the trunk 10.3+ decision made? I didn't see that discussion.

Comment 6

11 years ago
I don't remember when it was made, it was a while ago. We had a lot of different conversations about it. Contact me on email/irc if you have questions, this bug isn't a good place to discuss this.

Comment 7

11 years ago
You can use the notification-based SCNetworkReachability* on 10.3+.  If you need something for 10.2, you can still use SCNetworkCheckReachabilityByAddress/Name, but they're one-shot functions and don't automatically notify you when anything changes.  (Note: "scutil -r" from the command line is a quick harness to these functions.)

It should be possible to watch for SC changes with something like:

  SCDynamicStoreCreate
  SCDynamicStoreSetNotificationKeys
  SCDynamicStoreCreateRunLoopSource
  CFRunLoopAddSource

where you set the notification keys to ones that might change when reachability changes.  Look in SCSchemaDefinitions.h for keys, you'd minimally want ones like kSCPropNetIPv4Addresses and kSCPropNetIPv4Router.  I'm not sure, but you can probably also just ask for kSCEntNetIPv4 and kSCEntNetIPv6 to be notified for the hierarchies rooted at those points.

Then, in your callback, you'd call SCNetworkCheckReachability* and update the state accordingly.  That should give you something notification-based that works on 10.2.

Darin, how are you going to treat the case where the local interfaces are all auto-configured with RFC 3927-esque 169.254/16 addresses?
(Reporter)

Comment 8

11 years ago
> Darin, how are you going to treat the case where the local interfaces are all
> auto-configured with RFC 3927-esque 169.254/16 addresses?

Mark, I'm not sure I understand the issue you are referring to.  I wouldn't expect to have to worry about DHCP configuration.  I just want to be able to ask the system if it is capable of making a network connection or not.
(Reporter)

Comment 9

11 years ago
So, it seems that I need to pick a hostname (or IP) to use to test for reachability.  I guess that makes sense, and I suppose I could just use www.mozilla.org as the hostname to test.  Another choice might be the user's homepage, although that won't make much sense for Tbird.

Comment 10

11 years ago
Comment 8 is related to comment 9.  :)

Recent Macs, like recent Windowses, when configured to get their IP address by DHCP, will self-assign a 169.254/16 address in the absence of a DHCP server.  This lets them talk to others on the local network without any additional intervention.

On the Mac at least, if you're using the reachability APIs on a computer with a self-assigned address like this, you'll generally get a (correct) result of "not reachable."  This is because you won't have any gateways will be set up, and the reachability check is targeted at a specific address for which there will be no route.  In my opinion, that's the correct behavior.

My question was more about other platforms.  Since apparently the other platforms don't check the reachability of a specific address, I wonder if they're just looking at the interface up/down states?  When you do the check on a win32 box with a self-assigned address, does it report that the network is up (probably wrong) or down (probably right)?
(Reporter)

Comment 11

11 years ago
OK, I understand.  I'll need to investigate that.

Comment 12

11 years ago
At least you understand.  This sentence didn't make any sense!

> This is because you won't have any gateways will be set up
(Reporter)

Comment 13

11 years ago
I'm not going to have time to do this, and I'm also not convinced that it can be done in a satisfactory way.  I'm tempted to WONTFIX, but instead I'll just reassign to defaults.
Assignee: darin → nobody
Status: ASSIGNED → NEW
Priority: P1 → --
Target Milestone: mozilla1.8.1alpha2 → ---
I think the correct way to do this from our point of view is to check whether a non-loopback network interface is configured.

Reachability is "better" in some sense but it's too open-ended, and besides, applications can check reachibility to their particular servers manually (e.g. the way GMail+Chat does). So I think it makes sense for nsINetworkLinkService to be just checking link status and providing quick, reliable feedback when there is no link.
Now that offline support is in Firefox, the absence of this on OSX is a little glaring.
Flags: wanted1.9.1+
Flags: wanted-next+

Updated

9 years ago
Blocks: 440552

Updated

9 years ago
Priority: -- → P1

Comment 16

9 years ago
roc,

(In reply to comment #14)
> I think the correct way to do this from our point of view is to check whether a
> non-loopback network interface is configured.

Define "configured" here. Is any non-loopback interface with any sort of IP (even self-assigned) sufficient for us to say the link is up?

> 
> Reachability is "better" in some sense but it's too open-ended, and besides,
> applications can check reachibility to their particular servers manually (e.g.
> the way GMail+Chat does). So I think it makes sense for nsINetworkLinkService
> to be just checking link status and providing quick, reliable feedback when
> there is no link.

If we wanted to, we could easily use the reachability APIs here. I understand if we want the platforms to work the same here though, and for that reason simplify the check.
I guess the key thing is whether there's a default route.
Anyone interested in whipping this up for 1.9.1?  It would be sooo nice for Thunderbird 3.
Adding status whiteboard so the Thunderbird 3 folks can track core bugs we need.
Whiteboard: [tb3needs]
This is a dupe of 426932, which is expecting a patch landing as soon as m-c reopens.  yay!
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 426932

Comment 21

9 years ago
(In reply to comment #20)
> This is a dupe of 426932, which is expecting a patch landing as soon as m-c
> reopens.  yay!

426932 landed before the tree closure, http://hg.mozilla.org/mozilla-central/rev/3ea2c46a9814

Updated

8 years ago
Whiteboard: [tb3needs]
You need to log in before you can comment on or make changes to this bug.