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.

Sign up for GitHub

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

Jump to bottom

Signal desktop app says "Disconnected" with active Internet connection #6393

Closed
ATL-Flaneur opened this issue Apr 30, 2023 · 94 comments
Closed

Signal desktop app says "Disconnected" with active Internet connection #6393

ATL-Flaneur opened this issue Apr 30, 2023 · 94 comments
Labels
Bug

Comments

@ATL-Flaneur
Copy link

ATL-Flaneur commented Apr 30, 2023 •
edited
Loading

  • [x ] I have searched open and closed issues for duplicates
  • [x ] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Bug Description

Signal desktop app says "Disconnected" on a machine with an active Internet connection.

Steps to Reproduce

  1. Launch Signal
  2. Get yellow box: "Disconnected. Check your network connection. Click to reconnect."
  3. Click box.
  4. Text changes to: "Connecting… Shouldn't be long"
  5. Go back to 2.

This is the first time I've had this problem. Perhaps not coincidentally, we're staying at a place with T-Mobile 5G Internet service. Oddly, the Signal app on my WiFi-only iPad is not experiencing this problem and sends/receives Signal messages just fine. It's only my MBP that the app can't connect.

Screenshots

Screenshot 2023-04-30 at 12 19 52

Platform Info

Signal Version:

Signal 6.16.0 production (Apple silicon)

Operating System:

MacOS 13.3.1 (22E261)

Linked Device Version:

Link to Debug Log

debuglog.txt
@indutny-signal
Copy link
Contributor

Sorry about this. I took a look at your log and I see that the Electron reports to us that your online status changes all the time.

It might help us to isolate this to just Electron specifically. In order to so, could you install Electron Fiddle and load and run this gist with it https://gist.github.com/indutny-signal/28067d3147e7348ac713530dbd103cd1 ? It should display something like:

image

but if you'll keep running it for longer time - it should display "offline"/"online" status changes as well.

Thanks!

@ATL-Flaneur
Copy link
Author

ATL-Flaneur commented May 11, 2023 •
edited
Loading

We're back from vacation and no longer dealing with the T-Mobile hot spot, so unfortunately I can't test this.

Most other applications on the MBP were working fine. My VPN app wouldn't connect, which makes me think there was some kind of ISP-level filtering happening.

I'll try running this status app if the issue happens again.

@mkurz
Copy link

mkurz commented May 19, 2023

Having the same problem when connecting via USB to my phone (USB tethering)
I am using Linux.
#3867 might be related.

@mkurz mkurz mentioned this issue May 19, 2023
Open
@PeterBeu
Copy link

Problem started for me immediatly after auto-updating 6.18.1 -> 6.19.0 on Windows. I was able to use the client fully 10 seconds before applying the update. Now it will not connect.

Exitting Signal is leaving 3-4 processes running.

Attempting to downgrade back to 6.18.1 throws an SQL version error.

@ebcdic
Copy link

ebcdic commented May 25, 2023

I'm having a similar problem and it seems to be IPv6-related. On my Mac:

$ curl -4 -k https://textsecure-service.whispersystems.org/
{"code":404,"message":"HTTP 404 Not Found"}
$ curl -6 -k https://textsecure-service.whispersystems.org/
[hangs indefinitely]

And turning off IPv6 on the Mac makes the problem the the Signal app go away.

However, if I run those curl commands on my router (pfsense), they both work just fine, which suggests it's a problem with my Mac or my network, though most (at least) sites work fine with IPv6. I suggest others who encounter this problem try disabling IPv6 to see if it works for them.

@BOFH90
Copy link

BOFH90 commented May 25, 2023

same problem on my Mac since the last update couple hours ago. IPv4 works fine. I also use a pfSense router (sg-2100).

@rcmcronny
Copy link

I have the same problem and my ipv6 works, only signal seems to have an issue since the update to 6.19.0

@mkurz
Copy link

mkurz commented May 26, 2023

For me this problem occurs when using USB tethering (Android<->Linux Laptop). When unplugging the USB cable and switching to a Wifi hotspot instead it works (no other network or wifi networks are active. Both time

  • curl -4 -k https://textsecure-service.whispersystems.org/ and
  • curl -6 -k https://textsecure-service.whispersystems.org/ both return
{"code":404,"message":"HTTP 404 Not Found"}

so for me it does not matter that IPv6 is active.
Maybe Signal/electron does not consider network connections via USB?

@mkurz
Copy link

mkurz commented May 26, 2023

For Linux users, this might be related:

@scottnonnenberg-signal
Copy link
Contributor

All, thanks for your investigations. We aren't able to reproduce this, so we need more information - we need as much information as you can tell us about your network setup.

And direct curls like what @ebcdic did are extremely useful too - in that case, we know it's not specific to Signal Desktop - it's a computer/network or even Signal Server problem. All of this data helps us narrow things down.

Otherwise, we're just waiting for an Electron upgrade. But I just did a scan across Electron bugs, and didn't see anything like this. So we may need to raise this with them, and we need a lot of very specific detail to do that.

@ebcdic
Copy link

ebcdic commented May 26, 2023

I've raised this on the pfsense forum but not had any response yet. The only thing I can think of that might affect IPv6 in this way is an MTU discovery problem, but it seems like it may not be the same problem for everyone.

@BOFH90 - are you in the UK? If so what ISP are you using?

@scottnonnenberg-signal
Copy link
Contributor

What do you see when you going directly to signal servers? This is what I see:

$ curl -6 -k https://chat.signal.org/
curl: (7) Couldn't connect to server
$ curl -4 -k https://chat.signal.org/
{"code":404,"message":"HTTP 404 Not Found"}

There may be a problem with ipv6 connectivity, at the routing layer.

Closed
2 tasks
@ebcdic
Copy link

ebcdic commented May 27, 2023

What do you see when you going directly to signal servers?

Same as with textsecure-service.whispersystems.org. IPv4 gets 404, IPv6 hangs. Both get 404 when run from the router.

This is what I see:

$ curl -6 -k https://chat.signal.org/
curl: (7) Couldn't connect to server

That's odd, it's what you'd get if you didn't have IPv6 enabled on your computer.

@ebcdic
Copy link

ebcdic commented May 27, 2023

Reducing the MTU on my Mac to 1492 fixes the problem (on the Mac - but my phone has the same problem when connected to my home wi-fi. @BOFH90 does it fix it for you?

@BrokenMouseNA
Copy link

Not working with Windows 10,
Signal v6.19.0 curl is not working and cant connect as well.
curl -4 -k https://chat.signal.org
{"code":404,"message":"HTTP 404 Not Found"}
curl -6 -k https://chat.signal.org
no response

@BOFH90
Copy link

BOFH90 commented May 27, 2023

Reducing the MTU on my Mac to 1492 fixes the problem (on the Mac - but my phone has the same problem when connected to my home wi-fi. @BOFH90 does it fix it for you?

Yes, just tested and seems to be the case. Its working fine with 1492 and IPv6 atm.

@BOFH90
Copy link

BOFH90 commented May 27, 2023

I've raised this on the pfsense forum but not had any response yet. The only thing I can think of that might affect IPv6 in this way is an MTU discovery problem, but it seems like it may not be the same problem for everyone.

@BOFH90 - are you in the UK? If so what ISP are you using?

I´m in Germany and using a small ISP called GreenFiber. I already had a bad experience with them setting up my own pfSense-Box and not their provided one.

@ebcdic
Copy link

ebcdic commented May 27, 2023

I reverted my router to the previous version, and it still doesn't work - so presumably the update was a red herring.

@norstbox
Copy link
Contributor

I just did a scan across Electron bugs, and didn't see anything like this

@scottnonnenberg-signal this issue is most likely caused by a change in the default behavior of Node 17 when resolving DNS. Some workarounds and more info can be found here: nodejs/node#40537.

Problem manifests itself because ipv6 connectivity is still far from perfect and Happy Eyeballs is not enabled by default in Node 18.

@jon-signal
Copy link
Contributor

Hi, folks! I'm Jon from Signal's server engineering team, and I wanted to let you all know that we're looking into this.

@ebcdic @BOFH90 the path MTU discovery angle seems very interesting, and I'm asking folks in some other threads to try the same to see if it's universal. I'm wondering if there's some common piece of network hardware filtering out ICMP somewhere, though the geographic distribution of people reporting this problem is surprising. More data will help narrow things down.

With that in mind, for those of you for whom an MTU adjustment helps, I have a few follow-up questions:

  1. What was your initial MTU before you opted for 1492?
  2. Are you comfortable sharing both IPv4 and IPv6 traceroutes to chat.signal.org?
  3. This is a stretch, but are comfortable sharing packet captures (or, if you feel you have the expertise, your own analysis of packet captures) to see if we can figure out where things are going wrong? We'd be looking for ICMP "destination reachable" and "fragmentation needed" (types 3 and 4 respectively) packets—or the absence thereof—and any un-ACKed TCP packets.

I recognize some of this stuff can be more revealing than you may want to share publicly; you can also share this information with me directly at my-first-name at signal dot org.

Thank you for your patience and all the debugging so far!

@BOFH90
Copy link

BOFH90 commented May 28, 2023 •
edited by jon-signal
Loading

My network Hardware is a Netgate SG-2100 and some Mikrotik-Switches running SwOS. On the SG-2100 i created a "allow all" rule for ICMP v4 and v6 to and from all with the highest priority. For IPv6 i use SLAAC with "Router Advertisment" on pfSense enabled and Assisted Router mode (RA Flags | manged, other stateful|, Prefix flags | onlink, auto, router)

  1. The MTU in my Client (MacBook Pro M1 with CalDigit TB4 Dock and 2.5G Ethernet) was 1500 and on my Netgate SG-2100 is 1492 on the WAN and 1500 on the LAN Interface.
  2. Yes, i reverted to MTU 1500 and Signal not working to run the Traceroute:
    traceroute IPv6:
traceroute6: Warning: chat.signal.org has multiple addresses; using 2600:9000:a61f:527c:d5eb:a431:5239:3232
traceroute6 to chat.signal.org (2600:9000:a61f:527c:d5eb:a431:5239:3232) from 2a0f:ff00:220:e700:9c8f:1c3f:1b95:b835, 64 hops max, 12 byte packets
 1  gateway  0.750 ms  0.405 ms  0.332 ms
 2  2a0f:ff00:1338::1  8.028 ms  8.420 ms  7.940 ms
 3  2001:978:2:8::11:1  8.719 ms  9.031 ms  8.769 ms
 4  * * *
 5  2001:978:2:2c::18:2  16.160 ms  16.129 ms  16.594 ms
 6  2a01:578:0:ff::1d9  16.198 ms
    2a01:578:0:ff::1d8  15.776 ms
    2a01:578:0:ff::1de  16.601 ms
 7  2a01:578:0:ff::1  17.623 ms
    2a01:578:0:ff::2  15.095 ms
    2a01:578:0:ff::67  15.263 ms
 8  2a01:578:0:9005::5  15.322 ms
    2a01:578:0:9005::1  15.968 ms  18.225 ms
 9  2a01:578:0:9005::7  22.269 ms
    2a01:578:0:9005::c  16.148 ms
    2a01:578:0:9005::b  15.247 ms
10  2a01:578:0:9005::1b  16.073 ms
    2a01:578:0:9005::1f  16.052 ms
    2a01:578:0:9005::1b  16.154 ms
11  2a01:578:0:9005::2c  15.872 ms
    2a01:578:0:9005::2e  15.359 ms
    2a01:578:0:9005::2f  16.385 ms
12  2a01:578:0:9005::28  15.465 ms
    2a01:578:0:9005::27  15.550 ms
    2a01:578:0:9005::2a  16.181 ms
13  2a01:578:0:9002::2a  19.312 ms
    2a01:578:0:9002::28  15.191 ms  15.945 ms
14  2a01:578:0:9002::30  18.701 ms
    2a01:578:0:9002::2b  25.233 ms
    2a01:578:0:9002::2f  20.527 ms
15  2a01:578:0:9002::1c  16.382 ms
    2a01:578:0:9002::1d  20.852 ms
    2a01:578:0:9002::22  24.891 ms
16  2a01:578:0:9002::b  21.241 ms
    2a01:578:0:9002::7  18.952 ms
    2a01:578:0:9002::c  15.609 ms
17  2a01:578:0:9002::4  15.607 ms
    2a01:578:0:9002::5  16.205 ms
    2a01:578:0:9002::1  17.445 ms
18  2a01:578:0:ff::a  21.429 ms
    2a01:578:0:ff::8  19.402 ms
    2a01:578:0:ff::9  19.005 ms
19  2a01:578:0:ff::1e7  15.962 ms
    2a01:578:0:ff::1e3  16.259 ms
    2a01:578:0:ff::1e5  20.469 ms
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *

traceroute IPv4:

traceroute: Warning: chat.signal.org has multiple addresses; using 76.223.92.165
traceroute to chat.signal.org (76.223.92.165), 64 hops max, 52 byte packets
 1  gateway 1.703 ms  0.513 ms  0.403 ms
 2  bng.core.greenfiber.de (45.155.142.1)  7.814 ms  9.136 ms  8.349 ms
 3  te0-16-0-18.ccr41.ham01.atlas.cogentco.com (149.6.142.161)  9.186 ms  8.534 ms  8.526 ms
 4  be2815.ccr41.ams03.atlas.cogentco.com (154.54.38.205)  15.863 ms  16.106 ms  15.928 ms
 5  a100-row.demarc.cogentco.com (149.14.82.82)  15.691 ms  15.976 ms  15.973 ms
 6  * * *
 7  * * *
 8  * * *
 9  54.239.114.101 (54.239.114.101)  21.522 ms
    54.239.114.145 (54.239.114.145)  15.362 ms
    54.239.114.159 (54.239.114.159)  14.970 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  150.222.249.245 (150.222.249.245)  15.595 ms
    52.93.130.127 (52.93.130.127)  15.511 ms
    150.222.249.251 (150.222.249.251)  19.503 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  52.93.0.78 (52.93.0.78)  15.992 ms
    52.93.0.120 (52.93.0.120)  15.749 ms
    52.93.0.122 (52.93.0.122)  17.074 ms
22  * * *
23  * * *
  1. I´m not that comfortable sharing a packet capture from my home.

Thank you for your help.

@PeterBeu
Copy link

Issue was Pv6 ISP-related. 6.19.0 is connecting as expected now.

I just did a scan across Electron bugs, and didn't see anything like this

@scottnonnenberg-signal this issue is most likely caused by a change in the default behavior of Node 17 when resolving DNS. Some workarounds and more info can be found here: nodejs/node#40537.

Problem manifests itself because ipv6 connectivity is still far from perfect and Happy Eyeballs is not enabled by default in Node 18.

This could explain why the issue surfaced immediately after updating. Thanks!

@norstbox norstbox mentioned this issue May 29, 2023
Closed
2 tasks
@ddur
Copy link

ddur commented May 29, 2023 •
edited
Loading

#6439 (comment)

Issue is at better_sqlite3.node
Error: Error: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by [REDACTED].unpacked/node_modules/@signalapp/better-sqlite3/build/Release/better_sqlite3.node)

@kodama12
Copy link

same prob windows 10 after upgrading 6.19

QR code won't charge either if i reinstall the app.

@BOFH90
Copy link

BOFH90 commented May 29, 2023

Seems to be a problem with MTU Path Discovery and pfSense.
I checked wireguard and the Router Advertisments showed a MTU of 1500, but my PPPoE Interface has 1492.
I patched pfSense Radvd to always send out 1492 via RA and now all my Clients are working fine and can connect to Signal.

@ebcdic
Copy link

ebcdic commented May 29, 2023

@BOFH90 radvd should broadcast the MTU of the interface, so setting the MTU of your LAN interface in the pfsense graphical interface should have the same effect without having to patch anything.

@indutny-signal
Copy link
Contributor

Sorry, but it looks like the original issue is back. I'll keep you posted on our progress in resolving it.

Closed
@wendybujalski
Copy link

I am experiencing this same issue on Windows 10 running the Signal desktop app version 6.26.0

@RX14
Copy link

RX14 commented Aug 23, 2023 •
edited
Loading

Hi, I run my own network and I have a short ipv6 path to amazon, so I might be of some use debugging this issue. From my debugging I think it is likely something on amazon's end is droping ICMPv6 packet too big messages, breaking PMTUD.

My route to chat.signal.org:

mtr -rwb -c 1 chat.signal.org
Start: 2023-08-23T13:34:38+0200
HOST: uiharu.iscute.moe                                                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a11:f2c0:acac:10::1                                                                            0.0%     1    0.6   0.6   0.6   0.6   0.0
  2.|-- flag.shinra.systems (2a0d:1a40:7a02::1)                                                         0.0%     1   12.4  12.4  12.4  12.4   0.0
  3.|-- core1.fra1.as207960.net (2a0d:1a40:7900:8::1)                                                   0.0%     1   14.2  14.2  14.2  14.2   0.0
  4.|-- xe05-cr02-fra01.ifog.ch (2a0c:9a40:1030::1)                                                     0.0%     1   14.5  14.5  14.5  14.5   0.0
  5.|-- decix1.amazon.com (2001:7f8::407d:0:1)                                                          0.0%     1   15.7  15.7  15.7  15.7   0.0
  6.|-- 2a01:578:0:8002::183                                                                            0.0%     1   14.5  14.5  14.5  14.5   0.0
  7.|-- 2a01:578:0:8102::645f:631                                                                       0.0%     1   16.9  16.9  16.9  16.9   0.0
  8.|-- 2a01:578:0:11::6d                                                                               0.0%     1   16.5  16.5  16.5  16.5   0.0
  9.|-- ac88393aca5853df7.dualstack.awsglobalaccelerator.com (2600:9000:a507:ab6d:4ce3:2f58:25d7:9cbf)  0.0%     1   15.3  15.3  15.3  15.3   0.0

I have a 1400 MTU link between hop 1 and 2 on this link. I have verified that ICMPv6 packet too big messages are being sent back from another machine:

ping -s 1400 2a11:f2c0:acac:10::1
PING 2a11:f2c0:acac:10::1(2a11:f2c0:acac:10::1) 1400 data bytes
From 2a0d:1a40:7a02::1 icmp_seq=1 Packet too big: mtu=1400
1408 bytes from 2a11:f2c0:acac:10::1: icmp_seq=2 ttl=52 time=118 ms

When I don't have TCP MSS clamping enabled on my router (2a11:f2c0:acac:10::1) then curl -6 -k -v https://chat.signal.org/ will hang. When MSS clamping is enabled, the issue disappears.

Here is a tcpdump of connections. The first dump is with MSS clamping enabled (working), and the second is without MSS clamping, relying on PMTUD and ICMP delivery:

13:17:16.721807 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [S], seq 1737552093, win 64800, options [mss 1440,sackOK,TS val 4027709925 ecr 0,nop,wscale 7], length 0
13:17:16.738334 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [S.], seq 3202106923, ack 1737552094, win 65535, options [mss 1340,sackOK,TS val 2394619425 ecr 4027709925,nop,wscale 8], length 0
13:17:16.738424 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 4027709941 ecr 2394619425], length 0
13:17:16.742283 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 4027709945 ecr 2394619425], length 517
13:17:16.758277 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [.], ack 518, win 261, options [nop,nop,TS val 2394619445 ecr 4027709945], length 0
13:17:16.940592 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [.], seq 1:2657, ack 518, win 261, options [nop,nop,TS val 2394619628 ecr 4027709945], length 2656
13:17:16.940654 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 2657, win 494, options [nop,nop,TS val 4027710144 ecr 2394619628], length 0
13:17:16.941610 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [P.], seq 2657:3571, ack 518, win 261, options [nop,nop,TS val 2394619628 ecr 4027709945], length 914
13:17:16.941673 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 3571, win 501, options [nop,nop,TS val 4027710145 ecr 2394619628], length 0
13:17:16.943888 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [P.], seq 518:644, ack 3571, win 501, options [nop,nop,TS val 4027710147 ecr 2394619628], length 126
13:17:16.959698 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [.], ack 644, win 261, options [nop,nop,TS val 2394619646 ecr 4027710147], length 0
13:17:17.050741 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [P.], seq 3571:3622, ack 644, win 261, options [nop,nop,TS val 2394619738 ecr 4027710147], length 51
13:17:17.050742 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [P.], seq 3622:3691, ack 644, win 261, options [nop,nop,TS val 2394619738 ecr 4027710147], length 69
13:17:17.051124 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 3691, win 501, options [nop,nop,TS val 4027710254 ecr 2394619738], length 0
13:17:17.051183 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [P.], seq 644:746, ack 3691, win 501, options [nop,nop,TS val 4027710254 ecr 2394619738], length 102
13:17:17.051289 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [P.], seq 746:815, ack 3691, win 501, options [nop,nop,TS val 4027710254 ecr 2394619738], length 69
13:17:17.066914 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [.], ack 746, win 261, options [nop,nop,TS val 2394619754 ecr 4027710254], length 0
13:17:17.066916 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [.], ack 815, win 261, options [nop,nop,TS val 2394619754 ecr 4027710254], length 0
13:17:17.159351 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [P.], seq 3691:3729, ack 815, win 261, options [nop,nop,TS val 2394619845 ecr 4027710254], length 38
13:17:17.159790 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [P.], seq 3729:3887, ack 815, win 261, options [nop,nop,TS val 2394619845 ecr 4027710254], length 158
13:17:17.159791 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [P.], seq 3887:3925, ack 815, win 261, options [nop,nop,TS val 2394619846 ecr 4027710254], length 38
13:17:17.159941 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 3925, win 501, options [nop,nop,TS val 4027710363 ecr 2394619845], length 0
13:17:17.160233 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [F.], seq 815, ack 3925, win 501, options [nop,nop,TS val 4027710363 ecr 2394619845], length 0
13:17:17.174743 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.48382: Flags [F.], seq 3925, ack 816, win 261, options [nop,nop,TS val 2394619862 ecr 4027710363], length 0
13:17:17.174816 IP6 uiharu.iscute.moe.48382 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 3926, win 501, options [nop,nop,TS val 4027710378 ecr 2394619862], length 0

13:20:12.838466 IP6 uiharu.iscute.moe.49512 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [S], seq 3052941568, win 64800, options [mss 1440,sackOK,TS val 2177835737 ecr 0,nop,wscale 7], length 0
13:20:12.853196 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.49512: Flags [S.], seq 692329973, ack 3052941569, win 65535, options [mss 1440,sackOK,TS val 2268849587 ecr 2177835737,nop,wscale 8], length 0
13:20:12.853292 IP6 uiharu.iscute.moe.49512 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 2177835752 ecr 2268849587], length 0
13:20:12.857183 IP6 uiharu.iscute.moe.49512 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 2177835756 ecr 2268849587], length 517
13:20:12.873118 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.49512: Flags [.], ack 518, win 261, options [nop,nop,TS val 2268849607 ecr 2177835756], length 0
13:20:13.099023 IP6 ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https > uiharu.iscute.moe.49512: Flags [P.], seq 2857:3571, ack 518, win 261, options [nop,nop,TS val 2268849833 ecr 2177835756], length 714
13:20:13.099078 IP6 uiharu.iscute.moe.49512 > ac88393aca5853df7.dualstack.awsglobalaccelerator.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 2177835998 ecr 2268849607,nop,nop,sack 1 {2857:3571}], length 0

Notice how the connection hangs in the broken connection around the time the first large packet is sent by the working connection. Also notice the hole in the sequence numbers in the broken connection, and the subsequent ACK with selective ack sent due to the missing packet. The packet which should be retransmitted is still not delivered after 10 seconds, implying a MTU issue.

Due to this, I can only conclude there is a firewall dropping ICMPv6 packet too big on the path. I believe that firewall to be on amazon's side, since the other hops on the path are pure transit providers and are unlikely to be running firewalls in the forwarding path.

@jon-signal
Copy link
Contributor

Thanks, @RX14. We've come to the same conclusion and are already working with Amazon to resolve the issue. This additional testing is very helpful, and we really appreciate the detailed investigation!

@ca-boh
Copy link

ca-boh commented Sep 5, 2023

This just started to happen to me.....random, frequent yellow box: "Disconnected. Check your network connection. Click to reconnect."

Seems to also happen with desktop WhatsApp...

@scottnonnenberg-signal
Copy link
Contributor

We're tracking this connectivity issue here: #6476

@AndrewBendigo
Copy link

Hello, I found this page because Signal app on my Macbook air was cycling the disconnected message on and off. It occurred as I set up a new computer. I checked the old computer - also happening for the first time. Shut down Signal on the old machine and the problem vanished. Thought that observation might help.

@scottnonnenberg-signal
Copy link
Contributor

@AndrewBendigo You'll probably see some decryption errors as well. You had two Signal Desktops conflicting with each other, each trying to connect and booting the other. You should probably unlink that Desktop, and link them again from your phone - if you re-link to the same account, you won't lose any old messages.

@reebalazs
Copy link

Just for the record I had the Disconnected message appearing and disappearing forever, also loosing messages. The reason was that I migrated my Mac to a new one. So the Signal app on the new machine inherited the same id from the one on the old machine. Unlinking the machine and linking them separately fixed the problem.

@pwaller pwaller mentioned this issue Nov 14, 2023
Closed
@khuopio
Copy link

khuopio commented Jan 2, 2024

The same issue is with me on Windows 11, with ipv4/6 connectivity providet by Telenet in Belgium. If I enable F-Secure Freedome VPN terminating to Finland, the problem goes away.

@grammophone
Copy link

grammophone commented Jan 10, 2024 •
edited
Loading

I just got this behavior on my Signal running on Windows 10. It is happening with all network connections; mobile hotspot, wifi's, everything. The proof that I have internet despite what Signal says is this very comment.

@scottnonnenberg-signal
Copy link
Contributor

@grammophone Signal had a short outage in the last hour, sorry for the inconvenience. The good news is that you weren't seeing a Desktop bug there!

@grammophone
Copy link

Thank you for looking after the issue, @scottnonnenberg-signal !

@landsolar
Copy link

Manjaro user here
Signal 6.43.2

Not connecting when USB tethering with Azilink on the phone (abd based tethering). Firefox or Chromium are working fine.

Here is the ovpn file content used on the laptop:

dev tun

remote 127.0.0.1 41927 tcp-client
ifconfig 192.168.56.2 192.168.56.1
route 0.0.0.0 128.0.0.0
route 128.0.0.0 128.0.0.0
socket-flags TCP_NODELAY
keepalive 10 30
dhcp-option DNS 192.168.56.1

Tests:

$ curl -6 -k https://chat.signal.org/
curl: (7) Failed to connect to chat.signal.org port 443 after 134 ms: Couldn't connect to server
$ curl -4 -k https://chat.signal.org/
{"code":404,"message":"HTTP 404 Not Found"}

@jamiebuilds-signal
Copy link
Member

@landsolar Could we get a debuglog?

@landsolar
Copy link

app.log
main.log

@indutny-signal
Copy link
Contributor

@landsolar Thank you for the log! Did you save this log right after turning on the tether mode? The connection to our server appears to be healthy at glance.

@landsolar
Copy link

landsolar commented Jan 22, 2024 •
edited
Loading

The log show only tether connection. I did not use other connection type since 2 weeks.
image

I use azylink on android on usb

Signal Desktop connect fine if I use my phone Hotspot on the same line

@indutny-signal
Copy link
Contributor

Ah, I see it now. Thanks! We will take a look.

@Apikorus
Copy link

On an Apple M3 MacBook Pro running Sonoma 14.3
WiFi should be strong in a faculty office at a major research university
The message flashes with a periodicity of approximately 3s
I am apparently able to use Signal while this is happening, but the flashing is a little irritating and so I'd appreciate a bug fix if the problem is with Signal.

Screenshot 2024-01-27 at 3 03 34 PM

@ayumi-signal
Copy link
Contributor

Hi @Apikorus, sorry this is happening for you.

  • Can you please share a debug log when this situation is happening?
  • Regarding your app/computers setup -- is there a chance you've copied your data directory between multiple computers? We've seen periodic disconnections happen in that case as the multiple installs try to simultaneously connect.

@Apikorus
Copy link

Apikorus commented Jan 29, 2024 via email

@ayumi-signal
Copy link
Contributor

@Apikorus Thanks for the logs!

It looks like the same desktop linked instance is trying to connect:

WARN  2024-01-29T19:05:53.149Z SocketManager: authenticated socket closed with code=4409 and reason=Connected elsewhere

This can happen when you copy Signal data folders between computers to install, such as with MacOS Migration Assistant or just copying folders around.

You can resolve this by relinking the computers. This would preserve your existing messages on the computers.

  1. Use your primary device to unlink the Desktop instances. On your primary Signal iOS or Android go to Settings -> Linked Devices and unlink the Desktop instance(s).
  2. On each computer, the app will prompt the banner "Unlinked; relink to continue". Proceed with the relink and that computer will be fixed.
  3. Repeat for other computers. (Note there's a max of 5 linked devices.)

@Apikorus
Copy link

Apikorus commented Jan 29, 2024 via email

@ayumi-signal
Copy link
Contributor

ayumi-signal commented Jan 29, 2024 •
edited
Loading

@Apikorus The first (primary) device is always an iOS or Android device, so you need to find the original mobile phone you used to first install Signal. On the mobile app, access Settings -> Linked Devices to unlink the desktop instances.

@Apikorus
Copy link

Apikorus commented Jan 29, 2024 via email

@ayumi-signal
Copy link
Contributor

@Apikorus I cannot see any picture you may posted, but on the iOS Linked Devices page there's a top right Edit text button, when pressed it will reveal the delete buttons next to each linked device.

@Apikorus
Copy link

Apikorus commented Jan 29, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug
Milestone
No milestone
Development

No branches or pull requests