Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented configurable interface bindings #231

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

elluisian
Copy link
Contributor

When applied, this commit tries to implement the feature requests reported on the issues #43 and #227. Basically, with this, it is now possible to make the server listen only on certain addresses. This increases security and allows the typical "SSH usage", that is, SSH + publickey auth + local port forwarding + VNC listening on localhost only.

To achieve this:

  • on droidvnc-ng.c, vncServerStart was modified in order to provide a further "jstring listenIf" parameter. It uses rfbScreenInfo*'s listenInterface property.

  • A TableRow was added in order to allow users to input the desired address to use ("Listening Address").

  • On droidvnc-ng.c, the method vncServerGetListenInterface was introduced in order to track if the server is currenctly set to listen to 0.0.0.0 or not (this is used to properly show what addresses are available to use on the UI).

Please note that, if an invalid address/host is set, by default, it is assumed the address 0.0.0.0 is requested.

@bk138
Copy link
Owner

bk138 commented Aug 22, 2024

I think we should aim for "interface names", not "IP addresses" in the UI. Also, what happens if the interface the server is using the IP of goes down?

@elluisian
Copy link
Contributor Author

elluisian commented Aug 23, 2024

@bk138 Hi, sorry for the late response.
Actually, I think I've used "listening address" as label... not IP address, also, technically, one specifies a single address of an interface to listen to (except for 0.0.0.0 which is a special address which stands for "active addresses of the available interfaces").

As for what happens when the interface is down... I'm sorry, I didn't check for that when I made the fix, I've checked while commenting this though.

I've made the server listening to my wifi IP Address and, if I disable wifi while the server is running, it simply stops (that is, the server gracefully stops and you can restart it, I guess this is the default behaviour you programmed?), if I do the same thing but when listening on localhost, nothing happens, the server continues to listen, same thing if using 0.0.0.0.

@bk138
Copy link
Owner

bk138 commented Aug 27, 2024

What I mean is that we should not bother the user to enter IP addresses in the UI but present choices like "Wifi interface", LAN, WAN etc and handle the device->address resolution under the hood.

@elluisian
Copy link
Contributor Author

elluisian commented Aug 27, 2024

How about a spinner with the current up interfaces plus, the possibility to define a custom IP address?
Something like:

Any
Wifi
Cellular
Loopback
...
Custom IP

It seems XVnc has a -interface option in order to customize the ip address.

@bk138
Copy link
Owner

bk138 commented Aug 27, 2024

Yes, but why would the user want to set a custom IP?

@elluisian
Copy link
Contributor Author

Ehr... eh eh, that's actually a good question... because... why not? :P
I know, stupid answer... the only use-case I can think of is if one wants to use a loopback address which is DIFFERENT FROM 127.0.0.1 (for example, 127.0.0.124).
I understand this is a far-fetched use-case... but still, considering it is relatively easy to make, why not?
All that is needed is to simply make the spinner and an edittext, similar to the one in my commit, only, this time, it is enabled only if "custom ip" is chosen.

@bk138
Copy link
Owner

bk138 commented Aug 27, 2024

Let's keep it as simple as needed: https://en.wikipedia.org/wiki/KISS_principle :-)

@elluisian
Copy link
Contributor Author

Ok, done, now it should be better, let me know what you think.

Copy link
Owner

@bk138 bk138 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments. Before delving into details, the two grand topics are:

  • what's the strategy when a listen interface goes down while the server is running?
  • what's the strategy when the server is started wit a listen interface that's not up?

If solutions for these are too hard to be found, the details are kinda moot...

app/src/main/cpp/droidvnc-ng.c Outdated Show resolved Hide resolved
app/src/main/cpp/droidvnc-ng.c Show resolved Hide resolved
libvncserver Outdated Show resolved Hide resolved
@elluisian elluisian force-pushed the configurable-network-binding branch 10 times, most recently from f60d76c to c7845a4 Compare September 1, 2024 20:50
@elluisian elluisian changed the title Implemented configurable listening address Implemented configurable interface bindings Sep 1, 2024
When applied, this commit tries to implement the feature requests reported on the issues bk138#43 and bk138#227.
Basically, with this, it is now possible to make the server listen only on certain addresses.
This increases security and allows the typical "SSH usage", that is, SSH + publickey auth + local port forwarding + VNC listening on localhost only.

To achieve this:

- on droidvnc-ng.c, vncServerStart was modified in order to provide a further "jstring listenIf" parameter.
It uses rfbScreenInfo*'s listenInterface property.

- A TableRow was added in order to allow users to input the desired address to use ("Listening Address").

- On droidvnc-ng.c, the method vncServerGetListenInterface was introduced in order to track if the server is currenctly set to listen to 0.0.0.0 or not (this is used to properly show what addresses are available to use on the UI).

Please note that, if an invalid address/host is set, by default, it is assumed the address 0.0.0.0 is requested.
When applied, this commit should improve the previous one, in relation to the address binding.
As requested by @bk138, now, instead of an EditText, a Spinner with the available interfaces is used.
This is how it is achieved:

- Re-using some of the methods already made by @bk138, all the available up network interfaces which have AT LEAST ONE IPv4 address are collected.
These will be shown into the Spinner by using the class ListenIfAdapter;

- The first option of the Spinner is always "0.0.0.0", so that one can use the previous default behaviour (listen to any interface);

- Some earlier modifications are not needed anymore, so they were removed (e.g. vncGetListenInterface in cpp);
Contrary to before, now, if some error occurs during address translation, it is reported, instead of using the 0.0.0.0 address.
- Most of the utility methods in MainService.java were moved to Utils.kt;
- MainActivity and MainService were updated accordingly;
- Revised some of the data used for ListenIfAdapter;
- NetworkInterfaceTester is a class that report change on network state, it's still a WIP, it is now used to update the Spinner in relation to the available network interfaces;
I was capable of implementing an all-Java solution.
For some reason though, I was not capable of making it work with VPNs (needs more testing, I think).
… feature

- Created interface INetIfData that defines the operations that must be used to keep info about a given Network Interface.
Removed NetIfData internal class from NetworkInterfaceTester;

- Created class NetIfData that implements INetIfData;

- Created the Decorator pattern for INetIfData: made NetIfDataDecorator, so that, it is possible to properly customize the display name of a particular network interface (this gives the possibility to implement friendly names more easily);

- Created class NetIfData that implements INetIfData;

- Created the Decorator pattern for INetIfData: made NetIfDataDecorator, so that, it is possible to properly customize the display name of a parti
cular network interface (this gives the possibility to implement friendly names more easily);

- Created the class NetIfDataDefaultNameDecorator, which, given a NetIfData instance, it simply shows its actual name;

- Created the singleton class IfCollector, which, as the name suggests, only collects NetIfData instances.
It distinguishes between loopback, any and other interfaces;

- Now NetworkInterfaceTester relies on IfCollector to properly add or get NetInfoDatas, moreover, now it properly detects VPNs;

- ListenIfAdapter is now simplified, because of the new implementation of NetIfData and the decorator pattern;

- MainActivity and MainService were updated according to the previous modifications;
@elluisian
Copy link
Contributor Author

Waiting for review @bk138, of course, when you have time.

@elluisian elluisian requested a review from bk138 October 4, 2024 09:51
@bk138
Copy link
Owner

bk138 commented Oct 18, 2024

@elluisian I'll try to take a look ASAP - will take some time due to the PR's size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants