Uncategorized – WirelessMoves

RustDesk – Part 3 – Project Setup and Network Traffic

And on we go with yet another look at Rustdesk, a cool software for remote support, particularly for smartphones in my case: How does the project set-up look like and how does it transfer data over the network?

Project Setup, Licenses, Code Availability

Before coming to the network traffic, I decided to say a few words about the project setup, because I find it a bit strange. When looking at their website, an address for a company office in Singapore is given. On a different page, it is stated the the laws of the Cayman Islands apply. And that’s pretty much it. In other words, it looks a bit strange.

On the positive side, the server and client software is hosted on Github under the AGPL-3.0 and MIT licenses, so the code can be inspected and forked. Another plus is that the client is available on F-Droid, where it is compiled by the project rather than by the author. Also on the positive side, the project’s documentation and FAQ is very extensive, so it looks to me like it is currently well maintained. Also, apart from the free community edition, they do have paid plans with extra features, so they probably have a sustainable setup.

Rustdesk – Part 2 – From Mobile to Mobile

In the previous post I had a look at how to give remotely support an Android device from a notebook. While it’s a bit of a setup orgy, once it’s on Android and all permissions are granted, it works really well. An interesting twist: The RustDesk Android app contains both, client and supporter roles. So is it possible to support an Android user from another Android smartphone?

And indeed, it’s possible and works very well. Connecting to the remote mobile device works just as it does from the notebook, and touch interaction on the other device is possible as well. There is of course a bit of a lag when tapping a button remotely, and keys on the remote on-screen keyboard have to be pressed slowly to prevent missing or wrong characters. This is no big issue, however, and I am very impressed. I’ve been waiting for this for many years!

The screenshot on the left shows RustDesk’s main window on Android. The ‘Connection’ button on the lower left opens the tab in which a RustDesk remote ID can be entered to establish the connection to a remote device to support. And the ‘share screen’ button opens the tab where the remote party can start the screen sharing session and allow the incoming connection.

Remote Android Support with Rustdesk – Part 1

‘Mobile First’ has definitely arrived which made me wonder a bit how I could remotely support people on their mobile devices in the future as some will probably drop their notebook entirely. One option that looks particularly appealing to me is the open source RustDesk app. It can either be used via the project’s server on the net to connect a device to be supported with the notebook of a supporter, or it can be used with a self hosted server if one fancies to control the full transmission chain. Let’s have a look how this works in practice.

Lithium-Ion Batteries and Temperature

Earlier this year, I wrote a post about being surprised that my Anker A1336 72 Wh power bank, which I very much like by the way, has an interesting charge and discharge behavior when it gets warm. While it can be charged and discharged at 100W and can even be charged and discharged at the same time, as soon as it reaches around 42 deg Celsius on the inside, it stops charging other devices and continues to charge at only 22W. At the time I was wondering a bit why thermal protection was kicking-in at such low temperatures. However, when I recently researched the topic a bit more, I found out that this is actually the proper and expected behavior.

For NFC Payment, I Turn Off NFC on my Mobile

Yes, this is a bit of a strange headline, but I’m not kidding. For NFC payment ‘with’ my mobile device, I actually turn-off NFC to make it work.

CoMaps for Android – Part 2 – Privacy and Location Sharing Done Right

Continuing from the previous post about the pros and cons of CoMaps, a fork of OrganicMaps for Android, let’s have a look at how private and offline CoMaps actually is. From a privacy respecting maps app, I expect that the app doesn’t spill my location to anyone on the network, including potential project servers. So that’s my baseline here.

CoMaps for Android – Part 1 – Bringing the Speed Back for Maps

I’ve been a frequent user of OpenstreetMaps for Android (Osmand) for many many years. It is packed with features and does everything for me from finding nearby businesses, adding and editing features on the map for the community to navigation advice, i.e. routing, over large distances. However, over the years I’ve noticed a gradual slow down when I zoom in and out of maps or swipe in any direction to see a different part of the map. It got to a point with my Pixel 8 and GrapheneOS where I really started to get annoyed and actively started to look for something different. And it seems there is a very good and privacy respecting alternative: CoMaps, a recent fork of OrganicMaps.

Being Mobile Device Overlord For a Day

If you are working for a company that employs more than a handful of people and use a company smartphone or tablet, chances are that the device is owned and ‘managed’ by the company. ‘Managed’ basically means that the company uses a remote Mobile Device Management (MDM) solution that hooks into a management API of the smartphone. The same applies to notebooks as well, but I want to focus on mobile devices in this post. While the concept was clear to me in theory, the practical aspects of this have always been a bit vague, as I’m not working in an IT department that ‘manages’ remote devices. Recently, however, I came across an MDM solution that offers a free trial account. So I jumped at the chance and became a ‘Device Overlord’ for a day to see just how much can be controlled remotely and how the device enrollment process works.

UnifiedPush – Part 4 – Power Efficiency

Finally in this series, I’d like to say a few words about UnifiedPush (UP) and power efficiency. UP is a decentralized system and can use different transport options. Have a look at previous posts on this topic for details. And surprisingly, some transport options are much better than other when it comes to sending keep alive packets to ensure that Network Address Translations (NAT) gateways do not forget the connection and inadvertently block incoming notifications.

UnifiedPush – Part 3 – Molly-FOSS and the Gateway to Signal

In the previous post, I’ve had a look at how to set up UnifiedPush (UP) on Android. The easiest option: Download the SunUp app, switch-off battery optimization so it can run in the background and you are done. Easy! At the moment, I’m using UP on GrapheneOS for two applications: Tusky, a Mastodon reader and Molly-FOSS, a Signal messenger fork which replaces the Google cloud notification service with UnifiedPush. Molly-FOSS can run on its own without UP, but then uses Signal’s fallback proprietary web socket push system that sends keep-alive packets several times a minute. This is very power inefficient and I wouldn’t want to use this method in practice. Setting up UP in Molly-FOSS is not difficult, but it was a bit confusing for me at first, because it requires an additional setup step which is not part of the normal UP configuration procedure. Let me explain: