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

Enable internet access via connected cellphone #453

Open
c-w opened this issue May 11, 2020 · 8 comments
Open

Enable internet access via connected cellphone #453

c-w opened this issue May 11, 2020 · 8 comments

Comments

@c-w
Copy link
Member

c-w commented May 11, 2020

Currently we require a USB modem for the Lokole email client to access the internet.

Could we also use a cellphone connected via USB for internet access?

@tim-moody
Copy link

With release 7.1 IIAB allows an upstream/internet connection using its builtin wifi at the same time that the builtin wifi is used for IIAB's own hotspot. So if a smartphone provides a hotspot it should be possible for IIAB to connect to it. I also believe I and others have used a USB tethered smartphone for internet access.

@nzola
Copy link

nzola commented Jun 29, 2020

From Clemens;
Thanks for the reply. Here are some thoughts:

  1. Good for off-line emails as with IIAB, for a school or a small "closed" community.
  2. To be effective, it needs to have the "sync" capability with wider email community.

The original design goal for Lokole on IIAB was to be a closed local chat community since we assumed that IIAB deployments don't have internet access. On our main Lokole product outside of the IIAB integration, we do have internet sync capabilities. First we run WvDial to connect to internet via a USB modem (see StartInternetConnection) and then we connect to our email service on Azure to upload emails sent from the client and download emails sent to the client (see SyncEmails). We put a special eye to minimizing bandwidth usage to reduce costs as much as possible. The Lokole product that we deploy to users in the Congo DRC uses this connectivity functionality to periodically or on-demand sync emails.

  1. So you really don't need a dongle to do the "sync".
  2. Let me think about this. I am NOT a developer, but may be we can ask the wider IIAB Community to look at the feasibility as you have suggested.
  3. Can you let me what skills are required and the amount effort needed.

It's an interesting idea to replace the USB modem with a tethered phone. We already have a modality that assumes that the Raspberry Pi has access to a normal internet connection so that we skip the WvDial step (e.g. see code for hard-wired Ethernet scenarios). This means that as long as the phone can provide a normal Linux connectivity device similar to eth0, Lokole should be able to reuse this internet connection without any code changes. Is this how you envision the tethered phone to work? If not: how do you expect the phone to provide the internet connection to apps running on IIAB? I created an issue in the Lokole backlog to track this investigation (see #453).

Note that for performance and reliability reasons, the synchronization runs in a background worker (implemented in Celery, see run-celery.sh and run-crontab.sh) which currently isn't being run on the Lokole IIAB setup. Thus, a piece required for enabling email sync on Lokole on IIAB would be to extend the IIAB Lokole Ansible template to not only run the Lokole webapp but also the background workers. The amount of effort required for this change should be fairly minimal: adding a few more scripts to the Ansible template and testing the integration. The skills required for this work are Ansible, Bash and Python. I created an issue in the Lokole backlog to track this work and provide more background (see #454). If there's someone in your community who would be interested in picking up this work, I can also provide more technical support.

Last but not least, to control the amount of traffic to our email synchronization service in Azure, we require an explicit registration step for each new Lokole client. In our existing setup, the registration step happens as part of the installation of the Lokole software on the Raspberry Pi (see ClientSetup). To enable this registration on an ad-hoc basis for Lokole running on IIAB, I suggest to add a form to the Lokole application that takes the user through the registration flow (see #454 for additional details). This work will require some more intimate knowledge of the Lokole codebase, so if we go forward with this project and others can help with the modification of the IIAB Lokole Ansible templates and cellphone tethering investigation as described earlier in this email, I can commit to implementing this.

Hope this helps clarify some of my thoughts. Let me know what additional detail I can provide.

@adamsclafani
Copy link
Contributor

After chatting with @holta about this, we think it's possible to interface with, and leverage whatever internet connection an IIAB user has. First step would be to look at StartInternetConnection (which I have a bit of familiarity with 🙂), and along with help of IIAB's network experts, add something there to make that happen.

@nzola
Copy link

nzola commented Jul 18, 2020

@adamsclafani cool!

@georgejhunt
Copy link

  • I'm interested in thinking about how eMule, might be incorporated into the Lokole ecosystem -- See http://www.mule.global/emuleappuserguide.html.
  • I have downloaded the eMule code from https://github.com/ucam-emule/eMule and verified that it can still be compiled with the current android development tools.
  • My main desire is to leverage the email path Lokole has developed, to provide IIAB usage information to upstream managers.
  • The Lokole client email format, using zipped json, seems to be a good interface. And the upstream interface should be only a small change from what is already running on eMule.
  • I'm also interested in the lower tech solution i.e.: A small python program on the client IIAB, which writes queued email bundles to a USB stick, which is then carried to a machine with internet access, and then harvested for email bundles by a cloud based javascript client application. Maybe if the USB stick is to be bi-directional, the harvesting needs to be a python program, (since I don't think javascript can write to local storage).
  • I can easily volunteer to modify the ansible playbook, and generate the email packages with usage data. I don't have experience modifying java code for android machines. It would be great to find someone with those skills.

@nzola
Copy link

nzola commented Dec 23, 2020

Hi @georgejhunt Thank you for your proposal to add eMule on to Lokole ecosystem and your interest to provide help to do so. Our software engineers would look into the technicality of the operation and will let you know whether they will have time to work on the process of this integration. But other than that, it is always our desire to improve Lokole email system as we can and ideas and contributions as yours are always welcome.
Just for your info, it might take long for our software engineers to have time to look into this because they are all young, very busy with full time jobs and building new families. It is so hard to get volunteers for contributions.

@c-w
Copy link
Member Author

c-w commented Mar 8, 2021

My main desire is to leverage the email path Lokole has developed, to provide IIAB usage information to upstream managers.
The Lokole client email format, using zipped json, seems to be a good interface. And the upstream interface should be only a small change from what is already running on eMule.

@georgejhunt Could you provide some additional detail on your use-case? E.g. what sorts of usage information are you looking to upload? I'd be curious to hear your thoughts on what makes email the ideal format for this telemetry (instead of say, having IIAB upload usage files to some cloud drive and having a dashboard view ontop of those files)?

@georgejhunt
Copy link

georgejhunt commented Mar 16, 2021 via email

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

No branches or pull requests

5 participants