search

dustinrue / ControlPlane

ControlPlane - context-sensitive computing for OS X
http://www.controlplaneapp.com
BSD 3-Clause "New" or "Revised" License
1.76k stars 180 forks source link

Active Network Adapter (en0) rule issues under El Capitan #431

Closed dr-diem closed 8 years ago

dr-diem commented 8 years ago

Hi,

I use en0 active/inactive rules to assist in deciding whether to use wired or wireless network connectivity, combined with sensing the presence of a given WiFi network.

Under Snow Leopard/CP 1.2.3 this scheme worked fine, but since upgrading to El Capitan and CP 1.6.1 I see the following issues:

1 - The 'network adapter active' rule now depends upon the relevant adapter to be configured with an IP address. In my previous setup I actually disabled IP V4 when on my WiFi context, yet the en0 active rule would still fire when the cable was plugged in.

2 - Even when configured with an IP address, the 'network adapter active/inactive' rules intermittently change state, causing a context switch with no change in configuration.

Issue #1 means that the adapters need to be enabled and configured with an IP address even if I do not desire to use them, the upshot of which is that I cannot find a combination of confidence percentages that allow the rules to fire but at the same time not cause a rule loop, causing the contexts to switch back and forth ad infinitum.

Are these issues caused by changes in the underlying OS X APIs and outside your control or do they represent bugs in the latest CP release? I will try reverting to CP 1.2.3 to see if I can assist in fault-finding.

Cheers,

Ian

dr-diem commented 8 years ago

Hi again,

I've tested using CP 1.2.3 and the short version is it works as expected under El Capitan, so it seems the issues described above related to CP 1.6.1 code.

I noticed when upgrading to 1.6.1 (and when downgrading to 1.2.3) that I needed to remove and recreate the Network Link rules - neither version would 'read' those created by the other version. I wonder if that has some bearing on why the 1.6.1 rules don't work properly?

Cheers,

Ian

dustinrue commented 8 years ago

I’ll look into this but 1.2.3 is going to be pretty broken in other ways on El Capitan.

dr-diem commented 8 years ago

Great! Thanks Dustin. Time to go click that Donate button methinks...

dustinrue commented 8 years ago

I can't replicate this issue. I use this evidence source everyday and it's one of the most solid evidence sources available in ControlPlane. In OS X, the adapter can only be considered active if it is running with an IP and the cable is connected.

You might need to rework your rules to make your setup work properly.

dr-diem commented 8 years ago

Hi Dustin,

The nub of the issue is that v1.2.3 can detect a cable being connected even if in Network Preferences Ethernet's 'Configure IPv4' is set to Off, whilst as you say in v1.6.1 it has to be configured with a valid IP address.

In my LAN I have a variety of firewall ports forwarded to one specific IP, so I want that IP to be assigned either to en0 or en1 depending upon whether I'm sat at my desk or somewhere else around the house. Consequently my contexts are configured to disable the adapter that's not currently in use and assign the IP to the one I'm using.

With v1.6.1 I had to leave both interfaces enabled in both contexts, and assign some other IP to the interface I'm not interested in in each context, which is sub-optimal.

Could you look again and compare the evidence source code between v1.2.3 and v1.6.1? In my view it is superior in the older release.

Cheers,

Ian

On 2015-11-05 17:52, Dustin Rue wrote:

I can't replicate this issue. I use this evidence source everyday and it's one of the most solid evidence sources available in ControlPlane. In OS X, the adapter can only be considered active if it is running with an IP and the cable is connected.

You might need to rework your rules to make your setup work properly.

— Reply to this email directly or view it on GitHub https://github.com/dustinrue/ControlPlane/issues/431#issuecomment-154221458.

My PGP public key http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc.

dr-diem commented 8 years ago

Hi again,

It occurs to me that it might be a useful feature to add both forms of network interface evidence source - one for the presence of an actual network and the other for the presence of the physical layer alone?

Just a thought,

Ian

On 2015-11-05 22:55, Ian Silvester wrote:

Hi Dustin,

The nub of the issue is that v1.2.3 can detect a cable being connected even if in Network Preferences Ethernet's 'Configure IPv4' is set to Off, whilst as you say in v1.6.1 it has to be configured with a valid IP address.

In my LAN I have a variety of firewall ports forwarded to one specific IP, so I want that IP to be assigned either to en0 or en1 depending upon whether I'm sat at my desk or somewhere else around the house. Consequently my contexts are configured to disable the adapter that's not currently in use and assign the IP to the one I'm using.

With v1.6.1 I had to leave both interfaces enabled in both contexts, and assign some other IP to the interface I'm not interested in in each context, which is sub-optimal.

Could you look again and compare the evidence source code between v1.2.3 and v1.6.1? In my view it is superior in the older release.

Cheers,

Ian

On 2015-11-05 17:52, Dustin Rue wrote:

I can't replicate this issue. I use this evidence source everyday and it's one of the most solid evidence sources available in ControlPlane. In OS X, the adapter can only be considered active if it is running with an IP and the cable is connected.

You might need to rework your rules to make your setup work properly.

— Reply to this email directly or view it on GitHub https://github.com/dustinrue/ControlPlane/issues/431#issuecomment-154221458.

My PGP public key http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc.

My PGP public key http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc.

dustinrue commented 8 years ago

Looked over the history of the file and it's been in its current state for a couple of years now. The changes were made to support thunderbolt adapters.

You might have better luck with this if you configure your home router to reserve the same IP address in question for both your wired and wireless connections. Use ControlPlane to disable WiFi if your wired connection becomes active and enable it again when the wired connection is no longer active.

dr-diem commented 8 years ago

Okay, so if the code is unchanged then it must be my environment that's causing the disparity in behaviour. To perform a complete uninstall (so as to install 1.6.1 completely fresh) do I just need to delete the app and its preferences file, or are there other files stored elsewhere?

On 2015-11-06 10:03, Dustin Rue wrote:

Looked over the history of the file and it's been in its current state for a couple of years now. The changes were made to support thunderbolt adapters.

You might have better luck with this if you configure your home router to reserve the same IP address in question for both your wired and wireless connections. Use ControlPlane to disable WiFi if your wired connection becomes active and enable it again when the wired connection is no longer active.

— Reply to this email directly or view it on GitHub https://github.com/dustinrue/ControlPlane/issues/431#issuecomment-154431814.

My PGP public key http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc.

dustinrue commented 8 years ago

defaults delete com.dustinrue.ControlPlane will remove the old prefs. If you used any actions that require the helper tool it'll remain on your system but is upgraded the next time it is run/used.