Closed Bug 336285 Opened 14 years ago Closed 12 years ago
INetwork Link Service for Mac OSX
Implement nsINetworkLinkService for Mac OSX
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.
Note that on trunk we are 10.3+ only, so that patch doesn't need dynamic symbol loading.
NOTE: this is targeted for FF2 :-)
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.
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.
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?
> 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.
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 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)?
OK, I understand. I'll need to investigate that.
At least you understand. This sentence didn't make any sense! > This is because you won't have any gateways will be set up
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.
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.
This is a dupe of 426932, which is expecting a patch landing as soon as m-c reopens. yay!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 426932
(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
You need to log in before you can comment on or make changes to this bug.