Jami - Linux & Android - Requires Toggling Offline/Online (Disable/Enable)
Hardware Settings: No power saving, LAN always connected
Jami Settings: DHT Proxy enabled, TURN enabled, UPnP enabled
Issue found on at least two devices, one running Ubuntu 20.04 lts, the other Kubuntu 20.04 lts.
Issue: Text messages seem to flow, but file transfers and calls will not always connect unless the accounts at both ends are toggled Disable/Enable. It feels like Jami "goes to sleep".
The only work around I've come up with is to have a timed job which runs a script killing and re-starting Jami every 20 minutes. 20 minutes appears to be the optimum timing; much longer and Jami is more often offline, much less and Jami becomes awkward to use. This comes close (but not 100%) to keeping Jami online permanently. However, it isn't a very convenient method.
Activity
Hi Sébastien
Thank you so much for your quick response.
I to attach two text files, with the logs of two events in each. I've inserted a break and description of the action for each.
- The first log in both cases is a log of a failed call from one account to another on the two devices.
- The second logs for both are slightly different:
- The account on the laptop (Ubuntu) was toggled disable/enable, and a call succeeded to the desktop (Kubuntu)
- The account on the desktop (Kubuntu) was not toggled, a call was placed which succeeded
Lastly, in answer to your query regarding "DHT Proxy enabled", I enabled this in my quest to see what could be going wrong with the connectivity. I haven't disabled it.
(log files removed 1/8/22)
Edited by James Beale
Hi.
Thank you for the log files, but sadly, it seems that there is only the side of the caller at the same time? (timestamp from 1657654703 to 1657654742 are in kubuntu logs, but not ubuntu and vice-versa for other calls).
As far as I can see, for now, the other side is not answering, but this can be due to a ton of factor that I can't really describe more precisely. Also I guess "no response from DHT to E2E request." was removed?
Hi Sébastien
Thank you for looking at these logs. As I said, there are two sets of logs in each file, which I've indicated and separated within the logs.
I agree with you that "the other side is not answering". But this is cured by toggling the "enable/disable" switch within the account settings in Jami on the other side. It really is as simple as that. And I can confirm that this clears the issue every single time, without fail.
For your convenience, I have attached a further log of today's date from the Ubuntu laptop, when I attempted a call to the Kubuntu desktop.
The sequence of events is as follows:
- Attempt call to desktop (green dot visible in profile on desktop PC screen).
- Jami goes off line without any intervention by user (red dot visible in profile on laptop screen).
- First attempt to re-enable account failed, second succeeded.
- Attempt further call to desktop.
I think this goes to the heart of the matter. Jami is quietly and without user intervention, going offline. In this case it was noticeable as the red dot appeared, but in most cases it isn't, because the dot remains green. The only was to establish communications is to toggle the account "enable/disable".
Edited by James Beale
@JamesBeale I think this issue is the same / similar? #1395 (closed)
Similar in Android, yes. But Linux is a different matter. And yes, I've studied #1395 (closed) also, but it provided me with no answers.
It seems that both the Android and Linux apps "go to sleep". The only workaround I can come up with (in Linux, not Android) is, as I said, to create a cron job to run a bash script to restart Jami every 20 mins. It isn't perfect, but it's the nearest I've come to rectifying the issue.
It seems to me that there is something needing tweaked within Jami.
Edited by James BealeAnother small update.
I've noticed that occasionally the system monitor shows two separate instances of jami-qt whilst running my 20 minute restart script.
My script issues this command every 20 minutes:
(QT_QPA_PLATFORM='' /snap/bin/jami -t &> /dev/null &)But sometimes a zombie jami-qt instance seems to persist, and has to be removed thus:
killall jami-qtMaybe this little piece of extra information will help the developers, or anyone who is trying to work out what is happening, and why Jami seems to "go to sleep".
Edited by James BealeHi Sébastien
Could I make a request, please? This "going to sleep" problem (i.e., Jami seems to go offline) is a problem for all the users I personally know. They are using a mix of Linux, Windows, Android and Apple.
It seems reasonable to me to ask if you could make a temporary fix by creating a user configurable "toggle offline/(short pause)/online" function in the "account settings" - e.g., every n minutes. This would not be a full restart of Jami, in the way I'm currently doing it, but simply a disable/enable toggle. It need only be a simple thing, but would at least mean that Jami was less frequently "asleep" for users. The downside is, of course, that during a call, the user would have to disable this function to avoid interruption. But this seems to me to be preferable to not being able to contact the user at all due to "going to sleep", and the user would be at liberty to leave the option disabled anyway. I can report that, so far, this method seems to have worked for me and a couple of other Linux users known to me.
When this issue is resolved (perhaps by Jami performing some kind of self-check, and performing an "offline/online" toggle only when necessary), then the temporary user configurable function can be removed.
It would be great if this issue could be resolved. Jami is such an excellent application.
Many thanks.
Edited by James Beale
Merci @sblin et @JamesBeale "this seems to me to be preferable to not being able to contact the user at all due to "going to sleep" Oui de nombreux utilisateurs de nos amis ont abandonnés jami pour cette raison. C'est un point essentiel à résoudre, je suis bien conscient par ailleurs que c'est sûrement complexe, mais sans cela je ne ne vois pas comment convaincre de nouvelles personnes à utiliser jami ? ...
@VEROJEAN Merci beaucoup pour votre soutien. J'espère que le traducteur en ligne fonctionne correctement, mais j'ai inclus ma réponse en anglais ci-dessous.
C'est une grande honte car Jami est par ailleurs une excellente application.
J'ai réussi à faire en sorte que ceux que je connais en utilisant Linux adoptent ma solution de contournement, mais sur Android, il n'y a pas de méthode sans enraciner le smartphone. Quant à Apple, eh bien, n'y allez pas!
Heureusement, ceux que j'ai persuadés d'utiliser Jami sont un groupe robuste, à l'exception peut-être de deux, et semblent résoudre le problème.
@sblin Ce serait merveilleux, Sébastien, si vous pouviez déployer d'urgence la solution de contournement que j'ai suggérée et que je teste depuis des semaines maintenant.
@verojean Thank you very much indeed for your support. I hope the online translator works properly, but I've included my English reply below.
It is a great shame because Jami is otherwise an excellent application.
I have managed to get those I know using Linux to adopt my work-around, but on Android there is no method without rooting the smartphone. As for Apple, well, no-go there!
Fortunately those who I have persuaded to use Jami are a hardy bunch, with the exception of maybe two, and seem to be working through the problem.
@sblin It would be marvellous, Sébastien, if you could roll out as a matter of urgency the work-around I suggested and have been testing for weeks now.
Edited by James Beale-
It seems reasonable to me to ask if you could make a temporary fix by creating a user configurable "toggle offline/(short pause)/online" function in the "account settings" - e.g., every n minutes.
Adding hacky stuff it's not a way to go. And there is no reason to do this.
Also this may introduces more problems (killing ongoing connections, possible actions and is a logic to maintain that is a No go)
As far as we tested, for now, nobody I know reproduced this issue, so to debug it can take time without understanding the scenario.
Thank you Sébastien for this reply.
- I agree that "hacky stuff" isn't a long term solution.
- I don't agree that there is no reason to do this in the short term, in this case.
Please allow me to explain.
The primary raison d'être for Jami is to satisfy it's users. When a communications system which a decent number of users find unreliable does not meet this fundamental criterion, it might be that the communications system earns a bad name in the wider world. It could, ultimately, become largely ignored. This would be sad, as Jami is an excellent package, and deserves widespread use and success.
When some clearly knowledgeable users report an issue, and at least one of them has tied down some kind of workaround - and tested it for an extended period - it feels to me that it might be a good idea to engage with these users to try to eradicate the problem.
In the meantime, providing a workaround to the wider audience (who may or may not be experiencing the issue), with a user configurable choice of whether to enable or disable the workaround, with a clear message regarding disabling it for calls, might not be such a bad idea to avoid Jami getting a bad name in the wider world.
My interest is to continue to use and suggest the widespread adoption of Jami through my own channels. But while this issue persists, I cannot do this.
I remain available to assist in resolving this issue with you.
@JamesBeale Not sure - maybe I was able to reproduce ... a similar bug jami-client-qt#776
You might be right. A similar, or even the same bug.
I don't have direct access to a Windows machine, although one of my non-techy friends uses one, and seems to experience this "going to sleep" issue.
I wonder, could you set up your Windows machine to do a
jami -tevery 20 minutes, and use either another Windows machine or a Linux box (I use Linux only) to periodically call the first machine?I'm currently testing a laptop running Linux, with a 20 minute
jami -trestart (but see also my earlier post regarding the zombie incidences appearing), and periodically calling the laptop from a Linux desktop.Normally I find that if I have toggled the account "Enable/Disable" switch on the desktop, I get through to the laptop first time. If I don't toggle, I don't.
From the laptop to the desktop, if I haven't toggled the desktop, the laptop call doesn't get through.
I only have one 64-bit Windows device (Jami does not support 32-bit, which is my other device).
May I ask If you mmediately start a video call after you see the green dot of the other peer (#1388 (comment 34674)) does your issue change or persist?
@El4 When I toggle "enable/disable" on my desktop, and immediately call the laptop, the connection works flawlessly. Ditto the other direction.
Edited by James Beale@JamesBeale Do you also (manually) toggle "enable/disable" if you launch Jami (both devices) the first time?
Because I never toggle my account on/off it happens automatically.I wait a few seconds then I see a green dot (my own account and my contacts)?
I never had the chance to test Desktop <-> Desktop (I might try Android smartphone <-> Android tablet) so maybe it's an issue because of the Android client (but I thought all Jami apps use the (same) daemon)?
@El4 No. Upon initial launch I do not toggle "enable/disable". At that point Jami hasn't yet "gone to sleep".
The experience of others seems to tally with mine; Jami "goes to sleep" after a time. At that point toggling the "enable/disable" is necessary. Once this is done, communications are fully restored across all devices and operating systems.
On Linux I have automated the process by forcing Jami to restart.
I suspect this doesn't answer your own query, but it sounds like there are similarities between your experience and mine.
Edited by James BealeSébastien - a further thought occurs to me. I'd probably be able to recruit people to trial my suggestion before you release it, even on the nightly builds, if that helps you. I suspect @VEROJEAN might also.
Edited by James Beale======= SUMMARY =======
For anyone reading this thread, the only way I can (mostly) reliably connect to another Jami (sometimes it takes a few attempts) is by disabling "OpenDHT proxy" in the "Accounts Settings".
Note that this means Jami is not operating strictly peer-to-peer in this mode, but relaying via a TURN server somewhere on the internet.
=======================
I have continued to test. Using 4 devices (Ubuntu laptop, Kubuntu desktop, and 2 Android) and 5 accounts - one device has 2 accounts. I disabled the script I described above for re-starting Jami for these further tests.
I have found:
- I have the best chance of making a call (ie., Jami seems most probably not "gone to sleep") when OpenDHT proxy is disabled.
- The settings across all accounts are therefore OpenDHT proxy = disabled, TURN = enabled, UPnP = enabled.
- With the above settings, I can more often than not call each account from each other one. Sometimes it takes more than one go to connect. I'm assuming this is latency driven by the relay to your TURN server, rather than Jami "going to sleep", but I can't be sure.
- When testing with OpenDHT enabled, on the machine with 2 accounts, occasionally one of the accounts is offline (red dot), whilst the other is online, and receives calls. This seems very odd.
- If TURN and OpenDHT proxy are both enabled, the "going to sleep" issue occurs.
It looks like OpenDHT isn't functioning well. I know I can reach this server:
PING dhtproxy.jami.net (51.91.75.152) 56(84) bytes of data.
64 bytes from ns31187728.ip-51-91-75.eu (51.91.75.152): icmp_seq=1 ttl=50 time=36.4 ms
TURN says this:
PING turn.jami.net (92.222.89.217) 56(84) bytes of data.
64 bytes from 217.ip-92-222-89.eu (92.222.89.217): icmp_seq=1 ttl=47 time=36.5 ms
Connections to both the OpenDHT and TURN servers therefore perform similarly.
Having to use TURN permanently and solely does not seem like a great idea, since, as I understand it, Jami ceases to be peer-to-peer, but uses the TURN server to relay everything. (https://jami.net/why-is-jami-truly-distributed/)
I know that I can make connections in a properly peer-to-peer mode using the OpenDHT server as the "telephone (IP) directory", if I try hard enough. But it seems that Jami is most likely to "go to sleep" if I use that method.
I would be very grateful for any input from other users, but most especially from the authors.
Many thanks.
Edited by James Beale@JamesBeale What happens if you (always) enable TURN AND OpenDHT? Do you get the same issue? Or are there alternatives to OpenDHT?
-
The default parameters for Jami are TURN enabled and OpenDHT proxy off, and it's because it's designed to be like this. And on Desktop, there is no need for a DHT proxy anyway.
Having to use TURN permanently and solely does not seem like a great idea, since, as I understand it, Jami ceases to be peer-to-peer, but uses the TURN server to relay everything.
No. Also it's two completely different concepts. TURN is there for NAT traversal and has nothing to do with the DHT (which is there for sending connection requests) (like in jitsi or any webrtc app, or a lot of other app). A TURN is a relay, like any router between you and the peer will relayed packets. Also, if you or your peer doesn't have IPv6/UPnP/NatPMP, TURN will be mandatory anyway. If other methods works before, it will not be used.
I'll still try to reproduce.
This is strange, as I understood that Jami would fall back to TURN if OpenDHT didn't work.
It's two different concepts, TURN is only used between you and your contacts, the DHT is used before any connection request as the discovery network
Hi Sébastien
Thank you very much for your prompt reply.
Point 1:
In the October 09, 2019 Blog, "Why is Jami truly distributed?" (https://jami.net/why-is-jami-truly-distributed/), it says this:
...the data that users choose to share is always transmitted through entirely peer-to-peer connections, except when a TURN server is necessary.
And in the June 07, 2019 Blog, "Establishing peer-to-peer connections with Jami" (https://jami.net/establishing-peer-to-peer-connections-with-jami/), is written:
...TURN is the perfect compromise for situations where a fully peer-to-peer connection is not possible...
From these I have understood that Jami ceases to be a strictly peer-to-peer connection when using TURN, because it is using the TURN server as a relay for all data. Am I wrong?
Point 2:
Referring again to the June 07, 2019 Blog, "Establishing peer-to-peer connections with Jami" (https://jami.net/establishing-peer-to-peer-connections-with-jami/), and your very kind and patient reply above, I now understand (or am I wrong?) that TURN plays no part in the discovery process of a peer's address, and so without OpenDHT Jami is relying solely on Interactive Connectivity Establishment (ICE). But the final connection must route through TURN. So it's either ICE or TURN which, in the absence of OpenDHT, may be causing an initial delay, meaning I sometimes have to re-try the call attempt a few times.
However, nothing so far seems to shine any light on why Jami seems to "go to sleep" when OpenDHT is enabled.
Thank you again for your kind input. Please be assured it is highly appreciated.
´@sblin Can you reproduce the connecting issue: any Linux-Distro -> Android (jami-client-qt#776) Or is it just an issue because of the Windows 10 client?
Is it related to this issue?
-
without OpenDHT there is just nothing. you can't discover anyone, it's the main network.
But basically there is 3 modes:
- work as a DHT node (default, and preferred way, however it needs to sync with the network and on mobile the node is generally killed due to battery optimization)
- delegate the DHT work to a proxy (the DHT proxy option) to avoid syncing (especially for mobile), however needs a constant connexion (so still battery optimization off, which is generally not the case)
- DHT proxy + push notifications (preferred for mobile) as it doesn't need to be connected with the proxy. However until we implement the unified push system, the only way is FCM/APN
In Jami, when you try to contact someone, you will send your connection informations over the DHT to your peer. See the DHT as a collection of mailboxes. You put a letter in the mail the person check. And the peer answer with its informations. At this point there is no end-to-end socket, just enough informations to start a TLS session over the 2 peers. This contains basically all ips that can be reached (local, public, relayed all for ipv4 + ipv6)
Once everybody has enough informations, it starts to negotiate a socket, and basically the ICE protocol will make a checklist and test all possibilities to check the best depending the priority
(so will start local->local in ipv6, ipv4, then public, then with relayed). If you (or you peer) have IPv4 only and no UPnP/NATPMP or other nat punching protocol on your router, basically, every incoming connection will just be declined, so a relay is mandatory.
@El4 avoid to ping me. I see messages. if I reproduce or advance or have more informations I update the tickets
Thank you Sébastien.
So that means, in my scenario with OpenDHT = disabled, TURN = enabled, UPnP = enabled, I'm operating in your first mode listed:
work as a DHT node
Therefore I'm still findable on the network, and can find others. But I'm still not strictly operating peer-to-peer.
I apologise if this is documented somewhere. I must have missed it. Thank you for the clarification.
Edited by James Beale
added to-check label
-
Bonjour @JamesBeale @El4 et @sblin, Merci pour ces échanges éclairants, synthèse traduite en Français avec [(https://libretranslate.com)]
[https://forum.jami.net/t/jami-proxy-dht-et-turn/1482?u=verojean] Jamicalement
Bonjour @VEROJEAN. Merci beaucoup pour l ' excellente description de DHT sur https://forum.jami.net/t/jami-proxy-dht-et-turn/1482
J'ai continué à exécuter et enregistrer mes tests, et les modèles et autres choses ont été apparus. J ' espère que, dans quelques jours, j ' aura abouti à d ' autres conclusions que je publierai ici.
Merci encore.
Post Scriptum: Merci aussi pour la page LibreTranslate. Excellent.
Hello @VEROJEAN. Thank you so much for the excellent description of DHT on https://forum.jami.net/t/jami-proxy-dht-et-turn/1482.
I have continued to run and record my tests, and patterns and other things have appeared. I hope in a few days to have reached some further conclusions which I shall post on here.
Thank you again.
Post Scriptum: Thank you also for the LibreTranslate page. Excellent.
-
Some news:
I did some tests on different network (some with bad connectivity) on different devices and didn't observed any problem. However, if multiple interfaces behind the same router, I got some incorrect updates.
I did a patch https://github.com/savoirfairelinux/opendht/pull/628 at least to solve this point, that may be related (to confirm I'd need logs with candidates when failing and after the retrigger).
I also re-checked the log in this message: #1456 (comment 36560)
And I missed one bad thing:
[1659177521.457|39545|manager.cpp :937 ] Using OpenDHT version 2.4.0OpenDHT 2.4.0 means that the version is old (seems a version from March) so there is a lot of modifications since then (https://git.jami.net/savoirfairelinux/jami-client-qt/-/wikis/Changelog)
Jami sleeps on Wi-Fi. Ubuntu 20.04 LTS kernel bug? Android & Apple notes.
I have spent some time working through various scenarios, and documenting them in the hope that this will be helpful.
HP EliteBook 840 G4 14" Laptop, Ubuntu 20.04 LTS
Canonical has upgraded the kernel of 20.04 LTS, but with that may have come a bug.
$ uname -r 5.15.0-46-genericAccording to this link, https://askubuntu.com/questions/1403954/wifi-issues-in-ubuntu-22-04lts , kernel 5.15 may have “bad wifi”. NOTE: this bug can also exist in an installation of 22.04 LTS also. (See also: https://answers.launchpad.net/ubuntu/+question/702754)
At the time of writing, Canonical does not yet offer aother kernel for 20.04 LTS.
-
Switching off the hardware power-save function for Wi-Fi does not solve the issue:
◦ sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf ◦ change the value 3 in the line “wifi.powersave = 3” to 2 -
Using a script to restart Jami, it is possible to keep it mostly online:
/snap/bin/jami -t ping -c 6 8.8.8.8 /snap/bin/jami %u –minimized -
NOTE: if the script is disabled, allowing Jami and Wi-Fi to go offline, and the laptop is then opened and used, and the network connection then becomes active (e.g. doing a web search or saving files across the LAN), Jami does not always automatically come back on line. Both user wts and tt remain offline (red dot in their own profiles). To return to online, the accounts must be toggled disable/enable.
-
Using a script to toggle the Wi-Fi off/on, it is also possible to keep Jami mostly online:
/usr/bin/nmcli r wifi off > ~/tmp sleep 6 /usr/bin/nmcli r wifi on > ~/tmp -
Although equally effective as the first script, this isn’t really a viable option, since it causes other software to go offline during the Wi-Fi toggle process.
When on a wired connection Jami does not seem “go to sleep”. The reason is likely to be because the Wi-Fi is not in use.
Android & Apple
The “going to sleep” issue seems unresolved in Android (and probably Apple according to feedback from my other users).
The Android devices are set to “battery not optimised” and “background usage unrestricted” for Jami on two Android devices (Amazon Fire Tablet, and Galaxy Tab A). And yet Jami continues to “go to sleep”. It’s somewhat less so on the Galaxy.
There are further settings on the Amazon Fire tablet, “Automatic Smart Suspend” and “Scheduled Smart Suspend”, which are both also disabled for Wi-Fi, meaning that Wi-Fi connectivity never goes down. Also “Wi-Fi scanning” is enabled, allowing apps and services to scan the Wi-Fi.
The users I have on Apple also find that they have to do a kill and re-start of Jami from time to time.
Conclusion
It feels like Jami is “going to sleep” when an internet connection is lost (e.g., aeroplane mode, or in an area of no Wi-Fi or mobile signal), and not always wakening when connectivity is restored. Remember, these devices have power saving disabled.
This may be seen in the following test (Amazon Fire tablet, Android):
- Jami is opened and backgrounded on the Amazon Fire tablet, but the device’s cover is closed, and the screen blank
- test call to Jami from another device and account fails
- log in to tablet and open browser, leaving Jami backgrounded, and open a web page
- allow web page to fully load, then close tablet again, blanking the screen
- a further test call to Jami from the other device fails
- log in to tablet again, and this time bring Jami to the foreground
- wait for 15 seconds
- a final test call to Jami from the other device succeeds
This behaviour on Android is replicated across two different devices, with the Galaxy Tab A less likely to fail.
On the Ubuntu laptop, this similar behaviour of “going to sleep” and not “wakening” when the Wi-Fi connection is restored has also been observed. This seems similar, but not exactly the same as Android, the difference being that the Wi-Fi connection on Android does not go offline (it’s set that way).
I feel that Jami needs to be more resilient to “going to sleep”. It also needs to know when to awaken, in other words, to sense when networking is available. On Android, WhatsApp and all the others are resilient and do not go to sleep. On Ubuntu, the going offline bug on Wi-Fi does not upset other applications.
Jami knows when it has gone offline; the user’s red dot on their own profile says so. But that’s probably not enough.
I’ve attached a spreadsheet of test actions and results. I hope this is helpful.
In the meantime, I will have to continue to use the jami -t scripted option to keep Jami on my Ubuntu laptop (mostly) online. The Kubuntu desktop is a wired connection, and does not suffer this issue. As for Android and Apple, there is, unfortunately, nothing more I can do to prevent Jami from “going to sleep”.
Edited by James Beale-
-
Will check in details when I'll have more time in my todo list. Just to say that we did a nightly yesterday with various fix when DHT proxy without push is enabled (https://git.jami.net/savoirfairelinux/jami-client-qt/-/wikis/Changelog)
-
"It feels like Jami is “going to sleep” when an internet connection is lost (e.g., aeroplane mode, or in an area of no Wi-Fi or mobile signal), and not always wakening when connectivity is restored." Oui je constate régulièrement cela avec mes contacts, très régulièrement avec ceux sur iOS, régulièrement avec ceux sur android, jamais avec ceux sur desktop (debian, ubuntu, windows).
Merci pour vos commentaires. Je suis content que ce ne soit pas seulement moi ! Jami est une telle application, et je veux tellement qu'elle réussisse. Mais j'ai une tâche difficile qui justifie de le recommander à d'autres personnes jusqu'à ce que ce problème soit corrigé.
(Merci encore pour l'info LibreTranslate.)
Thank you for your feedback. I'm glad that it isn't just me! Jami is such a great app, and I so want it to succeed. But I'm having a difficult task justifying recommending it to any more people until this problem is fixed.
(Thank you again for the LibreTranslate info.)
-
Ok so lot of things:
- For GNU/Linux, on the current master, with or without DHTProxy, disabling wifi/ethernet or switching network seems to always rebring the account online since jami-client-qt@17041f78
I'm doing a release today, so this is hopefully fixed this side.
- For Android, the fixes for the DHT proxy should help, but there is several modes:
- Proxy & push from Google, which is generally the most supported by the devices.
- No push, but a proxy or without. In this case, battery optimization must be disabled (and running in background on). But it's generally not enough for a lot of mobile. https://dontkillmyapp.com/ is a good resource to describe per vendor.
There can be two ways to evolve the second point:
- Implement support for OpenPush (no Google) which is currently ~at the top in my todo list
- https://code.briarproject.org/briar/dont-kill-me-lib/-/tree/main/lib/src/main but this is incomplete
However, in any case, it will not work if on https://dontkillmyapp.com/ there is "no known solution for the devs"
Anyway, I'm also doing a beta today for this (version 340) which will hopefully bring the improvements needed
- For iOS
They changes their all notifications mechanisms in iOS 15, we recently (during the previous weeks), migrate to this new method. And to be honest, it's the worst mechanism of push notifications ever made.
Finally, the no green dot but calls works is a bug already present in another tickets.
So, for the original issues, the behavior should be improved with the next version (linux >= 20220824 & android >= 20220825 (or 340)).
added wait-for-answer label
removed to-check label
-
@JamesBeale just to check if your issue is fixed now on current version (>=20221101), else if you have logs or scenarios
Hi Sébastien
Thank you so much for your continued support. It is much appreciated.
As it stands, my laptop Ubuntu installation is still running my script toggle script. This has resulted in faultless performance from Jami. With the arrival of the new version, I shall disable the script, and see what happens with Jami. I'll report back to you in due course.
The Jami instance installed on my Kubuntu desktop seems to perform faultlessly without any toggle script.
My Android version is still at 20221007-01, which will be a feature of Fdroid. I seem to recall that you said you don't have control of the Fdroid repository for Jami. Have you ever considered permitting users to download the most up-to-date .apk from your own website? Just a thought.
Thanks again, and I'll be in touch regarding the Ubuntu installation.
-
Bonjour @sblin @JamesBeale , nous pensons que ce serait vraiment une bonne chose : "we're also working on adding Unified Push"
Edited by orevlucanje @sblin Hi Sébastien
Hope you're well.
I have now done some further testing, and am finding inconsistent results. I attach my spreadsheet. The new data begins on row 98.
In summary, on my laptop device (Ubuntu 20.04 LTS),
- without my re-start script, Jami appears to go offline overnight (haven't worked out the exact timing)
- calls don't always work properly
- texts and files don't always send properly
Numbers 2 & 3 above seems to happen on the user wts but mostly not user tt.
I'm at a complete loss to guess what the issue might be, but it feels a little like some problem of synchronisation.
On the user sp (desktop device, Kubuntu 20.04 LTS) I am receiving and sending as normal to other people, including user tt on the laptop (usually), but not wts on the laptop.
wts was the first user created on the laptop. tt was added later. That's the only difference between the two users.
Thank you again for your help. It's very much appreciated.
James.
removed wait-for-answer label
added to-check label
I am still trying to tie this issue down. Recent updates to Jami seem to have broken my hack using a re-start script.
I upgraded from Ubuntu 20.04 LTS to 22.04 LTS earlier this month (Jan 2023). The kernel is 5.15.0-58-generic. According to this link, this kernel should be OK on the Wi-Fi: https://askubuntu.com/questions/1403954/wifi-issues-in-ubuntu-22-04lts
I am using the up to date Snap installed Jami version, 202301181639.
I am still finding that I have to toggle the "enable account" setting in account settings after the laptop has been idle overnight. The Wi-Fi is constantly active, and I have the following set, which disables power saving on Wi-Fi, so I know it is always on:
/etc/NetworkManager/conf.d/default-wifi-powersave-on.confwifi.powersave = 2'2' sets disable powersave to 'on', i.e., disable powersave.
(See https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55 and https://www.linux.org/threads/theres-some-bug-in-ubuntu-wifi-that-keeps-shutting-it-off.42221/)
I can reach the laptop from a desktop after a night's inactivity, but for whatever reason Jami "goes to sleep" during that period. This does not happen when the laptop is connected via a wired LAN connection.
I cannot yet be sure if it's Jami or Ubuntu, but I'll keep looking.
I attach a spreadsheet log on my findings with Jami on WiFi, Ubuntu, HP laptop. Any thoughts would be welcome.
I see there is a new version in snap, which I will now upgrade to. Perhaps I'll have a different outcome.
-
They are tracking down the issue on macOS which is similar. It's an ongoing work, I will keep posted.
For the restart script it should work I guess, we didn't change much (https://git.jami.net/savoirfairelinux/jami-client-qt/-/wikis/Changelog for all changes)
That's great Sébastien. Thank you. I'm so glad it isn't just me! I was beginning to doubt my own sanity! As this thread shows, I've been on this case for quite some time, around 6 months.
Today I plugged the test device into a wired LAN, and shall continue my tests. However, as already discovered, I expect Jami to be connected 100% of the time under this environment. It seems Wi-Fi is the issue.
As for my re-start script, I don't know what has changed for this to stop working. It may not be anything to do with Jami. The device has been upgraded from Ubuntu 20.04LTS to 22.04LTS. Some interplay between the upgraded OS and Jami may be the reason, who knows? Anyway, it isn't worth the trouble of trying to find out.
I also attempted to keep things alive with a different script, one which caused internet traffic using fping every 2 minutes, to ensure Wi-Fi connectivity. But this made no difference to Jami "going to sleep".
I very much look forward to finding out what the issue is! I'd be very interested to know.
Thank you, again.
Hi Sébastien
I thought I'd try another approach to this issue. Previously my laptop was Ubuntu 22.04lts upgraded from 20.04lts.
I cleared the whole installation, and did a vanilla install of 22.04lts. I allowed everything to update. Then I installed Jami via Snap.
Jami simply would not load. I attach two files, "jami_terminal_output.txt" and "output.log". The first is the output from the terminal, the second the result of the command on the first line of the terminal file.
After that failed, I removed the Snap install of Jami, and installed from jami-all_amd64.deb. This worked perfectly.
There seems to be an issue somewhere... in Snap..?
Anyway, herewith I report my findings, and hope they are of use.
I will now test the Wi-Fi issue using the .deb install.
Good news!
Having removed and reinstalled my upgraded from 20.04LTS, and installed a fresh downloaded Ubuntu 22.04LTS on my HP EliteBook 850 G4, and still had the "going to sleep" problem, I decided on a different tack.
So I removed Ubuntu, and replaced it with Linux Mint 21.1.
Guess what! Jami didn't go to sleep overnight!
I'll keep testing, but it kinda smells a little bit like and Ubuntu / HP issue with Wi-Fi on Jami... maybe?
Edited by James BealeFollowing on from mine of last week (21 March), I think I may have a result.
Until the 23rd March I was using an HP EliteBook 850 G4 laptop. On the 22nd and 23rd I had again experienced the "Jami going to sleep" problem overnight, even though on the morning of the 21st, after re-installing with Linux Mint, I had not.
On the 26th March I got a hold of another laptop, this time an HP EliteBook 840 G2. I wiped and installed Linux Mint on it also. I installed Jami, and restored from backup.
Every morning since then I have logged the following:
Green dot on profile. Call succeeds. Messages flow.
I therefore surmise that either my Wi-Fi adaptor on the 850 is faulty (unlikely, as everything works, apart from Jami going to sleep), or there is some hardware/Jami incompatibility there.
@sblin Sébastien, I'm willing to undertake some further testing for you, if there is a way of tracing such an issue. Any thoughts? Or do we just chalk this one up to experience, and close the issue without any further ado?
-
Yeah... I don't have a clue on why it goes to sleep.
But I think we may check two other things:
- We can check
lsof -p JAMI_PIDto check if the number of files is growing... - Maybe the syslog says something with the faulty device?
Cause even if you don't have this anymore, the issue still exists (but not reproducible by us)... as it should never be necessary
- We can check
Hi Sébastien
I continue to hunt this issue down.
To reiterate, I'm using this machine for testing:
- HP EliteBook 850 G4
I have also tested with:
- HP EliteBook 840 G2
The "going to sleep" problem did not exist on the 840, only the 850.
I can find no faults with my hardware or operating systems. I have used:
- Ubuntu
- Linux Mint
- Debian
- openSUSE
All the system logs are clear of errors, and the hardware all performs as expected.
All installations under the above operating systems exhibit the same fault, i.e., Jami "goes to sleep" overnight.
I am now running the system under Debian.
Given that there are no faults exhibited in the syslogs, and
lsof -p JAMI_PIDdoesn't seem to show anything untoward to my untrained eye, the issue must be some kind of Jami compatibility with the hardware's "deep sleep" capabilities.To that end I began switching off parts of this in BIOS, viz.:
BIOS: Advanced > Power Management Options:
- Extended Idle Power States = off
- Runtime Power Management = off
- Deep Sleep = off
- Power Control = off
This didn't seem to entirely remove the problem, so I made sure that the NetworkManager WiFi Power Saving was explicitly disabled:
- create the file wifi-powersave-off.conf in /etc/NetworkManager/conf.d:
# File to be place under /etc/NetworkManager/conf.d[connection]# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).wifi.powersave = 2
Again, the problem wasn't completely eradicated, so I introduced a cron job:
- @hourly systemctl restart NetworkManager
Over the last two nights Jami has been stable. We'll see if that holds.
After much testing, I think it’s time to draw a line under this. I have proven
- there is no fault with my laptop (HP HP EliteBook 850 G4)
- there is an issue with Jami going to sleep when the laptop is on Wi-Fi
- the issue persists across multiple operating systems
- the work-around is to run a cron job every 3 hours (root: systemctl restart NetworkManager)
- the issue does not show up on another laptop I’ve tried
Therefore I am closing the issue today.
Post Scriptum
In the last few weeks, Jami on WiFi on the HP EliteBook 850 G4 has been operating without the need for toggling the network or it's own connection.
In that time, there have been updates to both Ubuntu and Jami. Somewhere within those updates lies the answer, or rather the fix, for the issue I reported.
Oh well...
-
there was a lot of changes, but I don't think it's related (just in case https://git.jami.net/savoirfairelinux/jami-client-qt/-/wikis/Changelog)
Anything happening with this rather significant issue? Multiple Ubuntu 22.04 LTS clients testbed and it fails fairly consistently although I have gotten it to work on some devices (Ubuntu/Android/IOS). Snap V 20231128.0 293.
Send a msg to a user. User accepts the conversation. Swarm is added to the invitations pane. Goes in "waiting until user connects to sync convo" death spiral forever. No amount of HUPing jami, logging out/back in changes this status.
The new swarm scheme is a great idea but at this point basic solo device user P2P just doesn't work (at least for me). I've been on Tox for a long time and would love to transition to Jami which seems to be better supported and is being actively developed which Tox is not. But it just doesn't seem very stable or reliable yet. I see that there is an enterprise version which implies a level of maturity that is not apparent in the Jami app I am using. Thanks in advance!
Hi
In the last post I made, I reported that the issue had appeared to have gone away. At the time I thought that the various updates to both Ubuntu and Jami must have done this unintentionally.
Suffice to say that I reported that my laptop install of Jami did not require toggling on/off/on at any point for several weeks.
Since that time, now around 5 months ago, I have intermittently been using my laptop and have had no issues.
On my desktop and Android tablet Jami is faultless. In my Jami settings I have:
- OpenDHT = all disabled
- Turn = enabled In addition to the above on the tablet:
- Run in background = enabled
I have also discovered that, for some unknown reason, the snap install is less co-operative than the .deb install variant. I doubt this is anything to do with Jami itself.
I also use the F-Droid install variant on Android.
As far as Apple goes, I don't have any, but nobody I know has had unmitigated success on those platforms. I believe the issue is backgrounding, and the inability to disable this within the OS. One person even reported that Jami had "disappeared" without his intervention from his iPhone after a period of inactivity.
The issue which you seem to be seeing, "waiting until user connects" never going away, I have seen from my Ubuntu desktop to a friend's Android. I think the issue here is probably the lack of knowledge/willpower of the user in question. Android needs tweaking to ensure that it doesn't force Jami to become backgrounded. Other friends using Android have no issues.
I am a big fan of Jami, and would encourage you to use it, and to encourage others too. Do, please, also consider sending Jami a donation. Many small ones add up to large!
Hope this helps you.
All the best.
-
Hello James and thank you for the response. I'm encouraged about the future of Jami since there seems to be at least a few who are very committed to it's success. And just the fact that there is an active forum like this for the app is encouraging. I am a retired Systems Engineer and have worked as a Field Engineer supporting under development software from very early stages to maturity for decades. Working directly with developers to figure out why functions don't work and get the issues resolved for my customers. In my old age I am far less willing to invest/waste my time on anything that isn't at least half-way stable and I no longer use anything that doesn't have an active development team and user group. Since Jami has a revenue generating enterprise branch and seeks to become a corporate standard I'm willing to stick with it at least for a while longer. Slack is pretty much the gold standard (at least for me) in that space. Tox is what I use for secure messaging although Tox leaves a lot to be desired. Jami is not nearly as stable or reliable as Tox and is light years away from being as good as slack.
Being a five 9's IT engineering manager, I'll throw out a few undeniable facts. Ubuntu shifted to the snap model some years ago. If the snap install is "less cooperative" than the .deb (or any other) variant then that is a major fail. *NIX is the standard for corporate enterprises. Having to screw around finding a repository to serve up a Jami version that will actually work is unacceptable. I am running 20231128.0 V293 which the snap store says is the latest. On my android tablet the Jami app is also the latest in the play store. I have no regard for Macs or Microsoft and do not have any of that gear here. I do not currently have any other Linux distros and no UNIX platforms here. One IOS device although it is a production iPhone.
User documentation for Jami seems to be lacking or else I just can't find it. For developers, Jami is very well documented. I have tried the various setting combinations and Jami seems to work equally unreliably regardless of how the connection settings are configured. I currently have everything turned on and run through a VPN. I have a large test bed, all running Ubuntu 22.04 LTS and can easily perform tests. There is no "lack of knowledge/willpower" at play here. A caveat would be that a high level of knowledge to install and get Jami working should not be required. Instant messengers are not rocket science.
The fact that person X is intermittently using an app with "no problems" is irrelevant to me. I've spent a few days actively trying to get Jami to work and best case, it is flaky and unreliable. In the worst case it is completely unusable. I'm willing to stick with Jami a while longer so long as there is a development team actively working to make Jami reliable and stable. However, asking for "donations" for a project that so far has very limited value strikes me as presumptuous. My time has a very high value so that's the donation I am making. And I will only be investing my time so long as I see productive progress when I do my testing. With all due respect, the Jami version I am currently testing is junk. I will not do further testing until the next version is released. That said, if the developer team chimes in to offer suggestions on how to get my test configuration to work I would be very eager to work with them.
Based more on gut instinct than provable fact, my take is that the long lag (often infinity) between getting two peers to "sync" is due to problems in the swarm server cluster. My test clients are side-by-side. Literally. No amount of bouncing processes clears these "stalls". I have two peers that seem to communicate with each other very reliably. I have another peer on the same network (but on WiFi not e-net) that reliably fails to "sync". However, they are able to do the initial message connection protocol. The android tablet, also on the same WiFi network can reliably communicate with some peers and others stay in the "waiting to sync" death spiral.
I have not been able to identify the secret sauce that allows some devices to work fine and others to be extremely unreliable.
In summary, I would very much like to be a huge fan of Jami and I am willing to invest more of my time to forward that objective. But unfortunately, Jami has a LONG way to go. Given the level of maturity required by the Ubuntu team, the snap version of Jami that makes it to the Ubuntu LTS release list could be quite old. I would have tested the .deb version but the download page is broken. I'm not at all interested in testing nightly compiles.
I very much appreciate your feedback and the work that the Jami Dev team is doing. Looking forward to the day when Jami is "ready to play the Palace".
Thank you for your very interesting and considered input. I'm sure the developers will take in board what you've written. For me, I cannot find anything which is better than Jami, and all the instances I'm aware of (aside from Apple) all perform as expected. I remain a Jami enthusiast. It does all I need.
-
D'accord avec @JamesBeale "Merci pour votre contribution très intéressante et réfléchie. Je suis sûr que les développeurs prendront en compte ce que vous avez écrit. Pour moi, je ne trouve rien de meilleur que Jami, et toutes les instances que je connais (à part Apple) fonctionnent toutes comme prévu. Je reste un passionné de Jami. Il fait tout ce dont j'ai besoin" Espérons que cette campagne permettra d'améliorer ce qui doit l'être. (https://forum.jami.net/t/une-campagne-de-donation-pour-jami/2292/2?u=verojean)
Très intéressant commentaire de @TheOriginalEasyrider "Bonjour James et merci pour la réponse. Je suis encouragé par l'avenir de Jami car il semble y en avoir au moins quelques-uns qui sont très engagés dans son succès. Et le simple fait qu’il existe un forum actif comme celui-ci pour l’application est encourageant. Je suis un ingénieur système à la retraite et j'ai travaillé comme ingénieur de terrain dans le support de logiciels en cours de développement depuis les tout premiers stades jusqu'à la maturité pendant des décennies. Travailler directement avec les développeurs pour comprendre pourquoi les fonctions ne fonctionnent pas et résoudre les problèmes pour mes clients. Dans ma vieillesse, je suis beaucoup moins disposé à investir/perdre mon temps sur quelque chose qui n'est pas au moins à moitié stable et je n'utilise plus rien qui n'a pas d'équipe de développement et de groupe d'utilisateurs actifs. Étant donné que Jami a une branche d'entreprise génératrice de revenus et cherche à devenir une norme d'entreprise, je suis prêt à m'y tenir au moins pendant un certain temps. Slack est à peu près la référence (du moins pour moi) dans ce domaine.
Tox est ce que j'utilise pour la messagerie sécurisée bien que Tox laisse beaucoup à désirer. Jami n'est pas aussi stable ou fiable que Tox et est à des années-lumière d'être aussi bon que Slack.
En tant que responsable de l'ingénierie informatique de cinq 9, je vais évoquer quelques faits indéniables. Ubuntu est passé au modèle Snap il y a quelques années. Si l'installation instantanée est "moins coopérative" que la variante .deb (ou toute autre), alors c'est un échec majeur. *NIX est la norme pour les entreprises. Devoir chercher un référentiel pour proposer une version de Jami qui fonctionnera réellement est inacceptable. J'utilise 20231128.0 V293 qui, selon le Snap Store, est le dernier. Sur ma tablette Android, l'application Jami est également la dernière en date du Play Store. Je n'ai aucun respect pour les Mac ou Microsoft et je n'ai aucun de ces équipements ici. Je n'ai actuellement aucune autre distribution Linux ni aucune plate-forme UNIX ici. Un appareil IOS bien qu'il s'agisse d'un iPhone de production.
La documentation utilisateur pour Jami semble faire défaut, sinon je ne la trouve tout simplement pas
https://docs.jami.net/fr/user/index.html
. Pour les développeurs, Jami est très bien documenté. J'ai essayé les différentes combinaisons de paramètres et Jami semble fonctionner de manière tout aussi peu fiable, quelle que soit la configuration des paramètres de connexion. J'ai actuellement tout activé et je passe par un VPN. J'ai un grand banc d'essai, tous exécutant Ubuntu 22.04 LTS et je peux facilement effectuer des tests. Il n’y a pas de « manque de connaissances/volonté » en jeu ici. Une mise en garde serait qu'un niveau élevé de connaissances pour installer et faire fonctionner Jami ne devrait pas être requis. Les messageries instantanées ne sont pas compliquées.
Le fait que la personne X utilise par intermittence une application sans « aucun problème » ne m'importe pas. J'ai passé quelques jours à essayer activement de faire travailler Jami et, dans le meilleur des cas, c'est fragile et peu fiable. Dans le pire des cas, il est totalement inutilisable. Je suis prêt à rester avec Jami encore un peu tant qu'il y a une équipe de développement qui travaille activement pour rendre Jami fiable et stable. Cependant, demander des « dons » pour un projet qui a jusqu'à présent une valeur très limitée me paraît présomptueux. Mon temps a une très grande valeur, c'est donc le don que je fais. Et je n'investirai mon temps que tant que je constaterai des progrès productifs lors de mes tests. Avec tout le respect que je vous dois, la version de Jami que je teste actuellement est indésirable. Je ne ferai pas de tests supplémentaires avant la sortie de la prochaine version. Cela dit, si l'équipe de développeurs intervient pour proposer des suggestions sur la façon de faire fonctionner ma configuration de test, je serais très impatient de travailler avec eux.
Basé davantage sur l'instinct que sur des faits prouvables, mon point de vue est que le long décalage (souvent infini) entre la "synchronisation" de deux pairs est dû à des problèmes dans le cluster de serveurs Swarm. Mes clients de test sont côte à côte. Littéralement. Aucun processus de rebond n'efface ces « blocages ». J'ai deux pairs qui semblent communiquer entre eux de manière très fiable. J'ai un autre homologue sur le même réseau (mais sur WiFi et non sur e-net) qui ne parvient pas à se « synchroniser » de manière fiable. Cependant, ils sont capables d'effectuer le protocole de connexion du message initial. La tablette Android, également sur le même réseau WiFi, peut communiquer de manière fiable avec certains pairs et d'autres restent dans la spirale de la mort « en attente de synchronisation ».
Je n’ai pas réussi à identifier la sauce secrète qui permet à certains appareils de fonctionner correctement et à d’autres d’être extrêmement peu fiables.
En résumé, j'aimerais beaucoup être un grand fan de Jami et je suis prêt à investir davantage de mon temps pour atteindre cet objectif. Mais malheureusement, Jami a un LONG chemin à parcourir. Compte tenu du niveau de maturité requis par l'équipe Ubuntu, la version instantanée de Jami qui figure sur la liste des versions d'Ubuntu LTS pourrait être assez ancienne. J'aurais testé la version .deb mais la page de téléchargement est cassée. Je ne suis pas du tout intéressé à tester les compilations nocturnes.
J'apprécie beaucoup vos commentaires et le travail effectué par l'équipe Jami Dev. J'attends avec impatience le jour où Jami sera "prêt à jouer au Palace"
Edited by orevlucanje
