Messages are not sent #8365
Comments
|
What kind of messages? Something changed between 4.30.3 and 4.30.4 in sending sms messages, is it that or are you talking about Signal messages? |
|
Signal messages, sorry for not specifying.
Sent from BlueMail
…On Nov 14, 2018, 12:33, at 12:33, johanw666 ***@***.***> wrote:
What kind of messages? Something changed between 4.30.3 and 4.30.4 in
sending sms messages, is it that or are you talking about Signal
messages?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#8365 (comment)
|
|
Related #8305? |
|
You're getting a generic bad-network exception: 2018-11-14 11:25:44.858 GMT+01:00 I Job: [990f8750-0d23-4891-b773-035aa4e1796e] PushMediaSendJob :: Retrying after a retryable exception. (Time since submission: 1156363 ms, Run attempt: 4, isStopped: false)
2018-11-14 11:25:44.858 GMT+01:00 I Job: org.thoughtcrime.securesms.transport.RetryLaterException: javax.net.ssl.SSLException: Write error: ssl=0xec2d26c8: I/O error during system call, Connection reset by peer
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobs.PushMediaSendJob.deliver(PushMediaSendJob.java:183)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobs.PushMediaSendJob.onPushSend(PushMediaSendJob.java:95)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobs.PushSendJob.onSend(PushSendJob.java:71)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobs.SendJob.onRun(SendJob.java:49)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobs.MasterSecretJob.onRun(MasterSecretJob.java:18)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobmanager.Job.doWorkInternal(Job.java:95)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobmanager.Job.doWork(Job.java:61)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at androidx.work.Worker$1.run(Worker.java:95)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at java.lang.Thread.run(Thread.java:764)
2018-11-14 11:25:44.858 GMT+01:00 I Job: Caused by: javax.net.ssl.SSLException: Write error: ssl=0xec2d26c8: I/O error during system call, Connection reset by peer
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.org.conscrypt.NativeCrypto.SSL_write(Native Method)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.org.conscrypt.NativeSsl.write(NativeSsl.java:414)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.org.conscrypt.ConscryptFileDescriptorSocket$SSLOutputStream.write(ConscryptFileDescriptorSocket.java:623)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.okio.Okio$1.write(Okio.java:76)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.okio.AsyncTimeout$1.write(AsyncTimeout.java:155)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:176)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.okio.RealBufferedSink.write(RealBufferedSink.java:46)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.internal.http.Http1xStream$FixedLengthSink.write(Http1xStream.java:288)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:176)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at com.android.okhttp.okio.RealBufferedSink$1.write(RealBufferedSink.java:198)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.api.crypto.DigestingOutputStream.write(DigestingOutputStream.java:29)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.api.crypto.AttachmentCipherOutputStream.write(AttachmentCipherOutputStream.java:59)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.internal.push.PushServiceSocket.uploadAttachment(PushServiceSocket.java:623)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.internal.push.PushServiceSocket.sendAttachment(PushServiceSocket.java:387)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.api.SignalServiceMessageSender.createAttachmentPointer(SignalServiceMessageSender.java:840)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.api.SignalServiceMessageSender.createAttachmentPointers(SignalServiceMessageSender.java:821)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.api.SignalServiceMessageSender.createMessageContent(SignalServiceMessageSender.java:368)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:214)
2018-11-14 11:25:44.858 GMT+01:00 I Job: at org.thoughtcrime.securesms.jobs.PushMediaSendJob.deliver(PushMediaSendJob.java:174)
2018-11-14 11:25:44.858 GMT+01:00 I Job: ... 10 moreWhat's your network like during this time? Is it flaky at all? Are other network-using apps working on your phone? Are you running a VPN or anything? Thanks! |
|
It's happened on two separate WiFi networks that were working normally for every other app and device and while on 4G data in the center of a major European city. No VPN running at the time. |
|
So it has happened again. I was connected to a vpn when it happened, so I tuned off the vpn and it didn't work. I soft rebooted to data, still didn't work, then I shutdown the phone and booted it up again and it still didn't work. It is still not sending 32 minutes later. Debug log after soft reboot: Debug log after shutdown and boot: I saw this mentioned in #8374 is there anything other information I can provide to help solve this issue? |
|
I have the same problem since I updated to 4.29.7 (I downloaded the apk, because I don't have Google/GApps). I updated to 4.30.7 some days ago, but that didn’t change anything. In addition to messages not being sent, the app won’t backup messages. I’m going to return to the last working version, 4.24.8, and see if I can backup messages with that. Edit: Here is the debug log. |
|
@scytho: Your device info, Android version and a debug log would be really helpful... you can add this information by editing your post. |
|
After it happening a few more times I believe it happens after sending a reply via the notification, but not every time I send reply that way. |
|
I’ve added the debug log. I forgot to mention that I can receive messages, and I can send messages with Signal Desktop. I see those on my phone, too. It’s only when sending messages from my phone that the circle keeps spinning. |
Can confirm this is the same for me. |
I looked at both of these logs, and I didn't see any evidence of messages that failed to send? Every message that was sent completed successfully. The logs spanned from: (The hard reset extends log coverage to 2018-11-22 15:25:47.820 GMT+01:00) Did the incident happen before this window? If it happened during this time, can you confirm whether the recipient received the message that appeared to be stuck? |
|
@scytho You're having a totally separate issue. It seems like you're using Signal without Google Play Services, but something is wrong with the persistent websocket connection. Specifically, I believe there were changes submitted between 4.24.8 and 4.29.7 that changed how this connection was kept alive, and there appears to be a bug. I've opened #8402 on your behalf. |
|
I've been having this problem on and off for a few months. Previously, I was able to resolve it by clearing all data and uninstalling and reinstalling Signal. It worked for about a month this time, but now I'm experiencing the problem again. Rebooting and turning WiFi and mobile data off and back on have no effect. SMS send/receive is fine as is Signal receive. Link to logs below. Tried to send message at 12:56 and uploaded the logs at 12:58. https://debuglogs.org/cdc31b3d7d5579adc19c4a8f8fb73aafca4035193eeef4a07784070923a315c0 |
|
@quantalume It looks like your problems are stemming from a situation where you failed to send a message due to poor network a few days before, and WorkManager never rescheduled your message send. I'm currently in a dialog with the WorkManager team to try to get these issues resolved, and in the meantime I'm going to try to think of mitigations. |
|
Im reporting the same issue, cannot send messages, but i can recieve them. Im using lineage 15 without google apps running the latest apk from the signal website. Last working version is 4.25.10. Also, reinstalling and rebooting doesnt solve it. log: https://debuglogs.org/457e879f73fe1a4d7cfeed7fc4fed60c58a6d8fd05e14b59d57d1750cfd148f3 |
|
@greyson-signal: Thanks. Can you see anything in my log regarding the backups not working? |
|
@grayson-signal: another note that is weird, |
|
LineageOS 15 with MicroG, behaviour after updating the app: Mobile data: WiFi: When changing from mobile data to WiFi all pending messages are immediately sent. |
|
@throwaway189 @CFPrulez I can't do anything without a debug log. Please go to |
I see that the job to run the backup is submitted but never run. Please open a separate ticket and describe the backup problem in more detail. |
https://debuglogs.org/12d9c10fa1dfd64bb3612647e9d01fb5e37e433ce7ed80f724106264747bbe33 (App was stopped and restarted several times, sometimes switched between mobile and wifi (e.g. to send debug log)). |
@greyson-signal I thought my first debug log was enough, anyway heres the newest log where the problem is still occuring, any messages send thru the mobile app are stuck on pending, but it can recieve messages, the desktop client functions normally and can send messages. Let me know if theres anything else i can do to assist, thank you for helping , its very appriciated! :) |
|
@throwaway189 Are you able to send messages on your mobile device when connected to wifi? It looks you and @CFPrulez have a near-identical device+OS combo. @CFPrulez For whatever reason, the system doesn't think you have an active network connection when connected to mobile data. It's difficult to say if this is a WorkManager-layer problem, or a problem with Lineage's implementation of the system JobScheduler. I happen to have an original OnePlus One, and Lineage OS 15 is available for it, so I'm going to try to flash it on there when I get some time and see if this is a device/OS issue. (Also @throwaway189 you're correct, the first log was enough. There's so many people in this thread that I lost track, apologies.) |
No need to flash, I could solve the problem, your analysis was the final hint. I think because of firewall restrictions the network check failed on mobile data (indicated by a "x" in the status bar next to "H+") -- all other messenger (including earlier versions of Signal) do (did) not care about that. |
|
@greyson-signal sending via wifi doesnt work, if have disabled my firewall. As a note though, my wifi and data always have an X because i turned of googles connectify check, resulting in the wifi and data always thinking they dont have a connection, while they work fine. |
|
I tried the same, I disabled AFWall+. Now I can send messages via WiFi. All of a sudden downloads I tried to start ages ago are coming in now (Threema updates). Normally, with AFWall+ enabled, I can send messages and do everything, there is only that cross in the status bar next to the mobile symbol, as described by CFPrulez, because I have AFWall+ block the service that checks for an internet connection. |
|
@throwaway189 @scytho That's almost certainly it. The system JobScheduler won't even attempt a job if it thinks there's no network, so if you've changed something to make the system think there's no network, then jobs won't run. |
|
I reenabled AFWall+ and was still able to send a message (via WiFi). |
|
After messing with afwall here, it seems to work again(when disabled), whats the name of the service that should be allowed in afwall? |
|
@greyson-signal is there anything that caused this behavior, because earlier signal versions didnt mind this. |
For me it is a single entry with a huge list of services (Android system, advanced settings, setup wizard, Call manager, Keyring, LineageOS settings, combined location services, poweroff alarm, Dev Tools etc.). Allowing/Disallowing this entry decides whether the connectivity check fails or succeeds. |
The migration to API 26, which requires that we use JobScheduler to run jobs in response to network changes. This was done in Signal 4.29.x. |
|
Ah, i see, anyway thanks for helping us find the issue, its very appriciated!!!! @CFPrulez thanks, seems to be working here to. |
|
Is there really no alternative? Take K-9 and Threema, they are still working. |
|
its sort of a bummer because the "Android System" is combined with half of Samsungs Bloatware and who knows what's running in those packages. |
|
I had he same behavior on three different (Samsung, Sony, Motorola) mobiles, with (Gapps free) custom ROMs (Android 8.1 - 9.0) installed and using AFWall+. Thanks to the hints in this thread, I was able get encrypted messages to work as mentioned from people before:
After rebooting the devices the cross next to the mobile networking symbol was gone and Signal was able to send encrypted messages again. But I accidentally found another workaround:
In my case, no other permissions are required to bring back sending encrypted messaged with Signal. |
|
It's a real bummer that Signal now requires Android System to be able to communicate with the network. It's either allowing the phone to repeatedly phone home to google or be able to use Signal. Great.. |
|
If there isn’t any way around that, I can just as well install GApps or microG and use WhatsApp. |
|
To be clear, JobScheduler isn't part of Google Play Services or anything -- it's part of the Android OS. Non-GApps phones can use it too. Now that all apps in the Play Store are forced to target API 26 and above, the only way to be notified of network changes is to use JobScheduler. Sounds like @revuwa gave plenty of good tips on how to configure your firewall appropriately. Regardless, OP's issue seems to be with a specific phone model having trouble making network requests randomly after an update. I don't know if there's much action for us to take here, so I'm going to close this. |
|
@greyson-signal while it might not be part of job schedular, privacy-savvy android users block the "Android System" (collection of) processes at the firewall level because among other unknown things, it phones home to google repeatedly, that's how it does the connectivity check. Because it's a system process these checks cannot be sent through a VPN easily, maybe with a always-on one, but I haven't checked. As a privacy conscious user, ANYTHING to do with google is an immediate no in my book, I don't want any of my devices doing as much as establishing a TCP connection to google servers. Or facebook, for that matter. In light of recent revelations and scandals this has proven to be a wise choice indeed. If the price to use signal is repeatedly announcing to google (and whoever cares to listen) whenever I have wifi enabled on the android device then personally I'll stop using the Signal app, and I'm sure other privacy-conscious users (sort of the whole point with Signal really) will move in the same direction. There is only one application which has stopped sending messages with that API 26 mininum level change that you have mentioned, and it is Signal. Every other app is, supposedly, subject to the very same restriction, and yet all of them keep working as before. This tells me that there ought to be an alternative to how Signal is currently delivering messages. Unfortunately it seems to me that privacvy-conscious users who refuse to run google spyware on their devices will once again get the shaft from Signal with this change, which is unfortunate since we are precisely those who most ardently supported the philosophical aims of the project. |
|
ACK, thanks. That’s what I intended to say. Signal to me feels somewhat like Firefox. Both are getting more and more uncool, seriously degrading in those feature departments I chose both for in the first place. It sucks, profoundly. And, yep, Threema doesn’t need JobScheduler. Maybe because it offers polling (?) as an alternative to push messages. |
|
I'm with you, guys. However, it is correct to close this issue as the problem has been solved. There should be a new issue like "Signal does not work with 'Android System' having no internet" where this problem can be addressed. |
|
Hi, you don't have to allow that in your firewall, you can just disable captive portal mode. ... In Pie:
After the reboot, the network check is disabled and you can send messages without any Google connection. .... |
|
According to the AFwall+ wiki[1]: [1]https://github.com/ukanth/afwall/wiki/FAQ#61-what-is-androids-captive-portal-check |
|
it seems that When i try to send a picture it's only in "pending"-state.... |
|
Cancelling the JobScheduler's tasks As this issue occurs because of signal offloading sending its messages to JobScheduler which then gets blocked by the firewall, I was wondering if it could be (temporarily) resolved by canceling signal's jobs that are currently registered in JobScheduler. That way signal can be restored to a 'fresh install' state, internet-connectivity-wise, and we know that signal does work for a while after a fresh install. The list of pending jobs can be accessed via This is after a reboot, without Signal running in the background. Note that there's also a 'FullBackupJob' in the list, which would explain why the backups also stop working when sending messages stops working: I guess JobScheduler tries to send those messages out first and do the backup afterwards. Canceling those jobs is not very straightforward though, and AFAIK has to be done through The IJobScheduler's functions are in android's source code. The link is for android v6; for a different version, the 'marshmallow-release' in the URL needs to be changed to 'nougat-release' or whatever your version is (this matters because the functions order differs between the versions). The cancelAll() function is the third in the source code, and does not require any arguments, so it's called like this: However, the jobs list in Links: |
|
This happened to me today for the 3rd time with an almost 5 day lag with other messages sent and received just fine. This is still an issue. I'm out. I can't trust this app if it can't handle sending a message. |
|
@thomasfrandsen This ticket is largely about people having issues with firewalls and stuff on their phone, or the specific phone model OP used. Does that apply to you? If not, would love to see a debuglog to see why your messages are stuck. |
Bug description
Messages will not send. Fixed by rebooting phone. The second time it happened I had to reboot and turn the WiFi on and off.. Started after updating to Android Pie.
Steps to reproduce
Unfortunately I'm not sure how to reproduce this bug. It just happens after a while and I haven't figured out anything identifiable.
Actual result: Messages don't send.
Expected result: Messages should be sent.
Device info
Device: Nokia TA-1043 (6.1 Europe)
Android version: 9.0.0
Signal version: 4.30.4
Link to debug log
https://debuglogs.org/601c1e2779dcbf2b7714b3f603b5e7bc1ec0dc571d4a650c3616240d30c70b40
The text was updated successfully, but these errors were encountered: