ANSWERED wonky LAN access

[m4rC31 0]

After the Eddie 2.13.6 to 2.16.3 update on an iMac (Retina 4K, 21.5-inch, Late 2015) with macOS 10.13.6, there is no more:

• AFP to computer names, just ip-addresses (likewise as for incoming connections)
• Screen Sharing to computer names, just ip-addresses (likewise as for incoming connections)
• AirPlay to an AirPort Express, its AirPort Utility connection invariably fails as well (unlike iOS devices with OpenVPN Connect 3.0.1, an AppleTV4 or 'Eddie-less' macOS computers)

Also, its iTunes needs to relaunch for the AppleTV4 to reconnect after sleep every time.

 

To remedy this most annoying hiccup a forums poster once suggested, if memory serves, to enter some 'Bonjour multicast address' (?) or other into Addresses Allowed of Network Lock Preferences. And rightly so!

At the moment though, that field is blank, whereas it wasn't prior to the current version, but the post in question seems untraceable.

 

Can anyone confirm the workaround still holds and point to the info required? If not, what is the proper way to deal with said wonkiness (bar disabling the network lock)?

 

cheers,

[Staff 9971]

Hello!

 

By enabling "Allow LAN/Private" in "Preferences" > "Network Lock" Eddie window you already allow Bonjor protocol IP addresses. Since you experience a different behavior by Eddie 2.13.6 and 2.16.3 on this matter, would you please post two system reports generated by those Eddie versions, to let us investigate? We guess that you have kept the same configuration in both cases, is this correct?

 

Kind regards

[m4rC31 0]

Tried and tested and trusted, excellent!

 

cheers,

 

 

PS - workaround worthy of mention in some FAQ till Eddie itself overcomes this 'flaw'?

[m4rC31 0]

Staff changed its answer meanwhile. It originally referred to Network Lock Preferences, something like:

• Addresses Allowed 224.0.0.251 and FF02::FB
• Incoming allow, Outgoing allow
• save
• disable and reenable

 

EDIT BY STAFF: please disregard the aforementioned answer, it was born out of a misunderstanding between Eddie developers and the person who replied. If you set Network Lock parameters both to "Allow" you will not have any Network Lock at all! Do NOT do that please.

[m4rC31 0]

Hello!

 

By enabling "Allow LAN/Private" in "Preferences" > "Network Lock" Eddie window you already allow Bonjor protocol IP addresses. Since you experience a different behavior by Eddie 2.13.6 and 2.16.3 on this matter, would you please post two system reports generated by those Eddie versions, to let us investigate? We guess that you have kept the same configuration in both cases, is this correct?

 

Kind regards

 

Allow LAN/Private ticked indeed in both instances, leaving but one difference between the two versions over here, namely the empty Addresses Allowed box. Which your original answer kindly straightened out.

 

Yours gratefully,

 

PS - perhaps Little Snitch obfuscates these here LAN doings

[Staff 9971]

 

Hello!

 

By enabling "Allow LAN/Private" in "Preferences" > "Network Lock" Eddie window you already allow Bonjor protocol IP addresses. Since you experience a different behavior by Eddie 2.13.6 and 2.16.3 on this matter, would you please post two system reports generated by those Eddie versions, to let us investigate? We guess that you have kept the same configuration in both cases, is this correct?

 

Kind regards

 

Allow LAN/Private ticked indeed in both instances, leaving but one difference between the two versions over here, namely the empty Addresses Allowed box. Which your original answer kindly straightened out.

 

Yours gratefully,

 

PS - perhaps Little Snitch obfuscates these here LAN doings

 

Hello!

 

Yes, the problem must lie elsewhere. Again, we wish to underline that you must ignore the previous answer (it was deleted, but clearly the deletion arrived too late). The reason is that those options influence Network Lock behavior in its entirety, and NOT only in relation to the allowed addresses. A recommendation to the devs to cause Eddie to issue a warning when using those options has been already sent.

 

Kind regards

[m4rC31 0]

Yes, the problem must lie elsewhere.

[…]

Elsewhere, right. Well, did restore the network lock as per recommendation (except for the added Bonjour addresses) and, presto, the glitches reoccured at once.

Care to enlarge on a method that does fix this?

 

cheers,

[Staff 9971]

Hello!

 

Please try the following settings:

• set Preferences > Network Lock > Incoming to Allow (but keep Outgoing to Block)
• enter the following addresses in the box Allowed addresses:
  

  239.0.0.0/8

  224.0.0.0/22

• click Save

• disable and enable "Network Lock"

Kind regards

[m4rC31 0]

[…]

• set Preferences > Network Lock > Incoming to Allow (but keep Outgoing to Block)
• enter the following addresses in the box Allowed addresses:

  239.0.0.0/8

  224.0.0.0/22

• click Save

• disable and enable "Network Lock"

[…]

 

Like the previous if to-be-disregarded workaround, this one delivers as well. Excellent.

 

Still, it kind of defeats the Allow-Lan/Private tick box’s purpose (ever since vs 2.13.6 no less). Worse, going by your edit above, it effectively disables the network lock for all incoming connections.

Both its consequences suggest a bug the devs need to address. Any prospect?

 

ta for now,

[Staff 9971]

 

[…]

• set Preferences > Network Lock > Incoming to Allow (but keep Outgoing to Block)
• enter the following addresses in the box Allowed addresses:

  239.0.0.0/8

  224.0.0.0/22

• click Save

• disable and enable "Network Lock"

[…]

 

Like the previous if to-be-disregarded workaround, this one delivers as well. Excellent.

 

Still, it kind of defeats the Allow-Lan/Private tick box’s purpose (ever since vs 2.13.6 no less). Worse, going by your edit above, it effectively disables the network lock for all incoming connections.

 

 

 

Hello!

 

It's your choice. In this way you are anyway protected because any listening service can't answer to the Internet, so it makes no difference under this respect. The big difference is that your system will answer to your local devices. That's what you asked for!

 

Can you trust them? Use this option only if you are the owner and administrator of such devices and you are sure they can't be exploited to launch attacks to the other devices in your local network. Anyway it's the very same hazard you have without VPN, nothing more nothing less, so in this specific case we can't see the point...

 

Kind regards

[m4rC31 0]

[…] , so in this specific case we can't see the point… […]

 

Much as your obliging explanation puts one's mind at rest, it ignores the whole Allow LAN/Private issue. It's a patchy option at best (since one must 'resort to' this workaround) that the devs may want to look at.

Trust you to see the point in that.

 

appreciative of your assistance all the same,