Discussion

[BayLee4]

Continuation of the discussion from aaronjwood/PortAuthority#134

[BayLee4]

Note:
Embedding ip_neigh as an executable and execute it from the Java code seems a pain to do with NDK, plus stdout is redirected to /dev/null. Maybe using it as a shared library, and redirecting stdout to a pipe which will be read from the Java code? This should work and keep the changes needed minimal. Reference : https://stackoverflow.com/questions/47554141/android-jni-pipe-always-waiting-in-filereader?noredirect=1&lq=1

[5hahryar]

@BayLee4 This is beyond my knowledge at this point. What I understand is that you proposed two ways:

1. Compiling ip_neigh as an executable and then calling it exactly like ip neigh command on SDK < 30 and then reading the results from input stream.
2. I honestly have no idea :( , just that it's probably easier to use this method than the first one.

[BayLee4]

@5hahryar Exactly, I'm also trying to learn as I never did that before, but if I understood correctly one way to achieve that would be the following :

On the Java side [1]:
ParcelFileDescriptor.createPipe(), then getFileDescriptor() for the write side and give it to the C side.

On the C side [2]:
AFileDescriptor_getFd, and use this file descriptor instead of stdout to print the output.

[1] https://developer.android.com/reference/android/os/ParcelFileDescriptor#createPipe()
[2] https://developer.android.com/ndk/reference/group/file-descriptor

[BayLee4]

I'm currently working on this branch : https://github.com/BayLee4/PortAuthority/tree/api_30

(Which includes my PR aaronjwood/PortAuthority#135)

[BayLee4]

Ok, I finished the implementation, it's even working with API 31 now :)

TODO: Work on the getMacAddress() method, which is currently commented due crashing the application.

[5hahryar]

@BayLee4 Amazing work, I tested your code on a couple of devices and it works like a charm.
But for Mac address of the device it self, is it even possible? I noticed that fing and wifiman that both support Mac address on SDK > 29 don't show it.

[BayLee4]

@5hahryar Great news, I only tested on the emulator for now, so I'm glad to know it also works well on real devices!

Regarding the MAC address I don't know yet, if it works it will probably be the randomized-per-network MAC address. But I guess this is still useful, as it would be the MAC address broadcasted to the local network. If it don't work, this is effectively not dramatic, but I would like to know why it's not working.

[BayLee4]

Ok, seems like it doesn't even return a randomized-per-network MAC address, just null, so I'll return Not available in this case.

[BayLee4]

Note: needs to verify that changing api to 31 didn't broke the CI, and if so, fix it.

[BayLee4]

Ok, I updated travis.yml so the CI shouldn't broke. This should be PR ready, but I want to do more cleanup in libnetlink.c/h first, as there still is a lot of unused functions. This should save a few Kb per arch.

@5hahryar Could you ping me here if you find any bug in the meantime?

[BayLee4]

Done: should be PR ready.

[5hahryar]

@BayLee4 Sure thing, I'll report any bugs that I may find.

[BayLee4]

@5hahryar Thanks, I'll also do more testing on my real device. If we don't find any bug then I'll add it to my existing PR.

[BayLee4]

First bug: android:exported="false" should be true, I'll push the fix.

[BayLee4]

Note: I noticed on my network that sometime hostnames are not resolved when they should have been. It happens randomly on each scan : some hosts are detected and some are not. I would like to implement a mecanism to retry on a failure to resolve the hostname, something like 3 times. But this hostname resolution is not simultaneous, so this retry mecanism would slow down the entire operation if implemented as is.

Todo:

• See if we can do the hostname resolution simultaneously for multiple hosts
• Implement a retry mecanism which will not slow down the application
• Refactor the onProgressUpdate() method from ScanHostsAsyncTask.java (for which such plan apparently existed at some point)
• Remove .local suffix for resolved hostnames
• Drop JCIFS dependency : outdated (2012 !) and bloated, port and use Angry IP Scanner NetBIOSResolver.java instead

[BayLee4]

Update: hostnames can be resolved simultaneously, so it will be easier to implement and it will speed up by a lot the operation, which is currently done host by host in a blocking way.

[BayLee4]

The more I look at the code, the more I realize it's so much outdated that it will be incredibly difficult to implement features I would like to see (like aaronjwood/PortAuthority#136). And I'm not even talking about the UI, which honestly look like an application of the first iPhone. I think I'll finish working on some tasks in the todo list above, but after that, if I manage to find the time, I may work on a new application on which it will be easier to implement Fing like features.

@5hahryar Do you know where I can find a template/mockup for modern android application which would fit this use case? I'm no front end dev, so without such base this is sure that I couldn't do it because it would take me too much time.

[5hahryar]

@BayLee4 I agree, using modern android development tools will help a lot. Kotlin features like flow and coroutines would be good examples of that. There are some guides on app architecture from android dev team that are very useful: arch samples, guides.
Also I'm very interested in creating a whole new project to build an app from the ground up. I can help on the UI and android side of things, and you can work on the core if you're interested?!

[BayLee4]

@5hahryar Yes, that would be perfect!
Thanks for the links it will be an interesting read, I really need to learn more about modern android development.

I'll drop the refactoring plan of the onProgressUpdate() method and the implementation of a retry mecanism (this is something that I'll implement for this new project), so I should have submitted my PR upstream by tomorrow as the .local suffix removal and NetBIOSResolver.java porting are trivial.

Would you be available on the next monday or so to discuss about the looks of this new application? That gives some time to imagine/find ideas for the averall design (aaand to rest after this long week).

[5hahryar]

@BayLee4 Sure thing, please contact me on this email.