Exclude link-local IPv4s from editor host list.

[Faless]

IPv4 has link-local addresses like IPv6 (block 169.254.0.0/16).
Those addresses should not be considered a valid option when selecting the remote_host setting for the debugger.

[follower]

I might be missing something but why are link-local addresses not considered a valid option?

For example, if two Mac devices are connected directly via an Ethernet cable--when a DHCP server is not enabled--eventually they will self-assign link-local addresses which means its possible to create a connection without explicitly configuring anything.

While I've not used this approach with anything Godot-related yet, its still seems like it would a valid option.

[Faless]

they will self-assign link-local addresses which means its possible to create a connection without explicitly configuring anything.

@follower Have you ever tried that out? In my very limited experience with the matter, I was not able to connect to a link-local address (169.254.0.0/16).
A friend of mine was in fact unable to listen/connect to it's own link-local address (on Windows).
We could change that if you can confirm it works.

[slapin]

I think this is OS-dependent. Also there might be multicast 224/8 addresses and other addresses which might not be wanted depending on particular system settings. The naive solution might break things, too.
I think currently the best bet would be

1. Have list of all listen-able addresses.
2. Have a helper function which filters these and reports them according to RFC. This thing might be already available and also can be implemented in user's application.
3. It is up to user to decide which addresses can be used or can't be used for listenning (UI option).
   The user should be able to do final decision on what addresses to use. Godot can't handle all existing broken setups everywhere. But also there is no reason to prevent it from working on non-standard setups which work for other applications. However Godot can supply the information (list of addresses) and reasonable defaults.

[Faless]

Also there might be multicast 224/8 addresses and other addresses which might not be wanted depending on particular system settings.

@slapin it wouldn't make sense to list multicast addresses, as TCP can't work with multicast, so this is certainly not a problem (and multicast addresses, are already excluded).

2\. Have a helper function which filters these and reports them according to RFC. This thing might be already available and also can be implemented in user's application.

This is exactly what I'm trying to do here, this PR do not change the result from get_local_addreses, it just filter the value in editor settings.

3\. The user should be able to do final decision on what addresses to use. Godot can't handle all existing broken setups everywhere.

I don't think having a text edit there is a good idea. It would just be confusing to many people, and prone to errors. All for very exceptional cases (i.e. using editor-debugger connection on a broken network setup).

Command line options are not affected,
I think it's more important to have an 'listen for debugger' button instead, which you can use for any weird setup (and lunch your game app accordingly via CLI). And that yes, can have a line dit (pre-filled with last/default value, probably just a wildcard).
But this is up for debate of course :)

[mhilbrunner]

I agree with @Faless - having a simple button that works in 99% of cases is preferable as long as CLI options exist.

Note that we currently also exclude IPv6 link local adresses. IPv4 link local adresses in comparison are IMO both uncommon and nonstandard.

We can discuss adding UI options for more control over this, but as this is just for the Editor debugger, and only does for IPv4 (where again, link local addresses are esoteric anyhow) what is already done for IPv6, this is fine to merge by me.

Further discussion on more elaborate handling should IMO be done in a PR for that or an issue.

[mhilbrunner]

Fine to merge by me, as stated above :)

[slapin]

I think adding an option in network section of preferences will not hurt (one of LANs I use assigns windows auto-assign addresses (which became IPv4 "link local" addresses) and actually NATs them to outside world to avoid having DHCP server). Not nice setup, but I guess quite common with older windows networks. Patching again just for that is annoying.

…

On Wed, May 1, 2019 at 9:49 PM Max Hilbrunner ***@***.***> wrote: ***@***.**** approved this pull request. Fine to merge by me, as stated above :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27569 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABPU3NBELUPBQYS6JZDYTPTHQZ5ANCNFSM4HCSMWJA> .