MacOS Desktop Telegram Client fails to complete installation

[davidfavor]

1) Installed Mobile Telegram App + all seems well.

2) Using a OnePlus device, so have to use a QR Code scanning App -> Scan presented QRcode -> Click URL.

3) Now I'm presented with the same message as Desktop App, which says - Open phone App + Scan image.

4) I'm then thrown into the phone App with the same message as step 3, then...

5) This loop continues forever.

6) Clicking the "Or login using your phone number" can't be used either, as SMS code never arrives.

7) This continuous loop seems like a bug. Let me know how to complete a MacOS installation + login (escaping this loop), if this isn't a bug.

Thanks.

[Aokromes]

what telegram desktop version are you using?

[davidfavor]

MacOS v4.0.2 downloaded from Telegram site yesterday.

[iam-TJ]

I believe I'm seeing the same thing with the Linux desktop client downloaded today, 2022-08-07 (tsetup.4.0.2.tar.xz).

I extracted it and executed ./Telegram - the window prompts "Start Messaging". Lower-left corner is a rotating spinner that never settles. Press the button and see a Telegram logo rotating spinner with "Scan from Mobile Telegram" instructions. The Telegram logo spinner never changes (I assume it should be replaced by the QR-code?)

Go to my Lineage OS device, install Telegram from Fdroid. Sign up. Do the Settings > Devices > Scan QR code but as there is nothing to scan on desktop I'm rather stuck!

Desktop OS is Debian 11 Bullseye amd64 with KDE/Plasma desktop environment. The local network is IPv6 only (no IPv4) but I have a DNS64/NAT64 gateway that works fine for all other services.

In Desktop application's Settings > Connection Type I've tried altering the default option of "Try connecting through IPv6" which is initially selected, as well as choosing "Disable proxy" although there is no proxy on the network.

Connection type continuously shows Default (connecting...)

ss -tunp doesn't show any outgoing connections from the Telegram process.

I suspect there's a DNS resolution failure but as I do not know what hostnames it will be querying its difficult to debug much further at present. I'll look at the source code.

[john-preston]

@iam-TJ There is no dns resolving going on for the Telegram API. You can enable DebugLogs by typing “debugmode” from your keyboard in Settings (like a cheat code in a game) and then relaunch the app and try generating the QR code for a couple of minutes. Then you can send me .zip-ed ~/.local/share/TelegramDesktop/DebugLogs to t.me/preston, using web.telegram.org, for example.

[iam-TJ]

@john-preston thanks for the swift response. Logs sent.

Are you sure about no DNS name resolution? I only looked superficially so far but the strace showed that something in the process reads /etc/hosts repeatedly. I ran out of time to enable a debug log of systemd-resolved.

The strace did reveal the process is attempting to connect to IPv6 addresses in my local DNS64/NAT64 range [update: something is getting a recvmsg that contains those], as well as external global IPv6 addresses, e.g:

connect(56, {sa_family=AF_INET6, sin6_port=htons(443), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2001:67c:4e8:f002::a", &sin6_addr), sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress)

The -EINPROGRESS above repeats endlessly which I am presuming is a symptom related to the spinners and lack of established connection.

Testing the IPv6 shown above I see:

$ ping -6 -n -c 2 2001:67c:4e8:f002::a
PING 2001:67c:4e8:f002::a(2001:67c:4e8:f002::a) 56 data bytes
64 bytes from 2001:67c:4e8:f002::a: icmp_seq=1 ttl=46 time=63.8 ms
64 bytes from 2001:67c:4e8:f002::a: icmp_seq=2 ttl=46 time=48.4 ms

$ tracepath -6 2001:67c:4e8:f002::a
 1?: [LOCALHOST]                        0.021ms pmtu 1420
 1:  apu2.local                                            0.478ms 
 1:  apu2.local                                            0.335ms 
 2:  2a01:7e00:e001:eec0::1                               42.064ms 
 3:  2600:3c0f:7::1704                                    48.126ms 
 4:  2600:3c0f:7:35::21                                   55.089ms 
 5:  2a01:7e00:6666:ff11::2                               47.098ms 
 6:  2600:3c0f:7:42::1                                    41.541ms 
 7:  2a01:7e00:7777:5::2                                  41.638ms asymm  6 
 8:  RT.TC2.AMS.NL.retn.net                               47.764ms 
 9:  RT.TC2.AMS.NL.retn.net                               70.379ms asymm  8 
10:  no reply
11:  no reply
12:  no reply
...

Looking at the Telegram logs themselves I think I see the problem but you'll know better than me. If only it is this easy!

There are four connection attempts in log_10_45.txt, two of each to IPv4 and IPv6 destinations. Of each pair, one is to port 80 and the other to port 443. Both IPv4 connection attempts fail with -EADDRNOTAVAI (99) "Network Unreachable". It looks like as soon as both of those IPv4 attempts fail the attempts on IPv6 are abandoned and it loops around and tries the same four again... repeatedly. Possibly the "immediate restart" mentioned in SessionPrivate::waitConnectionFailed() around line 1200 in mtproto/session_private.cpp ?

[john-preston]

@iam-TJ Should they be available on your machine? Those requests to those IPv4.

[iam-TJ]

@john-preston No, the network has no IPv4 at all.

 $ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

The only IPv4 that will work is host-name DNS resolution that hits the gateway DNS64/NAT64 (bind and tayga).

[ilya-fedin]

2. Using a OnePlus device, so have to use a QR Code scanning App -> Scan presented QRcode -> Click URL.

You should use the scanner integrated in the mobile Telegram app, not a third-party application. So when you open the URL in the browser, it asks you again to open phone app and scan QR code with it (as you did not that).

[iam-TJ]

@ilya-fedin Good spot; I didn't see the implications of that. @john-preston do you want me to move my experience to a new issue to avoid confusion?

[john-preston]

@iam-TJ I've replied to your logs in Telegram - there is 8 second timeout on connection and an IPv6 connection to a required IPs can't be established in that timeout on your system, idk why. But that way it doesn't work 😞

[iam-TJ]

@john-preston I've done some network analysis that may give us a clue.

TLDR: Telegram host 2001:067c:04e8:f002::a is not responding to TCP SYN to ports 80 or 443.

Understanding my network topology. apu2 is my local gateway/router with its LOCAL bridge facing the LAN and WAN interface connected to a Starlink dish. Because Starlink only operate IPv4 there is a wireguard tunnel to a Linode VPS in London. The tunnel is the default route and carries only IPv6 traffic. Due to the overhead of the tunnel there is TCP MSS clamping to MTU, and MTU set to 1420 on the apu2 egress and VPS ingress :

host <-> LAN (IPv6) <-> apu2.LOCAL -> (apu2.wireguard-tunnel) -> apu2.WAN -> Starlink -> VPS.eth0 -> (VPS.wireguard-tunnel) -> VPS.eth0 -> Internet

When doing tcpdump on VPS what is obvious is there is no reply to the TCP SYN packets sent to the Telegram IPv6 address. On the host I am trying both telnet and openssl s_client:

$ ping -c 1 -n -6 2001:067c:04e8:f002:0000:0000:0000:000a
PING 2001:067c:04e8:f002:0000:0000:0000:000a(2001:67c:4e8:f002::a) 56 data bytes
64 bytes from 2001:67c:4e8:f002::a: icmp_seq=1 ttl=46 time=56.9 ms

--- 2001:067c:04e8:f002:0000:0000:0000:000a ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 56.914/56.914/56.914/0.000 ms

$ telnet -6 2001:067c:04e8:f002:0000:0000:0000:000a 80
Trying 2001:67c:4e8:f002::a...
^C

$ openssl s_client -msg -debug -6 -connect [2001:067c:04e8:f002:0000:0000:0000:000a]:443
^C

and on the VPS gateway I see the ping reply but no replies to the TCP connections to ports 80 or 443:

$ sudo tcpdump -ni eth0 host 2001:067c:04e8:f002:0000:0000:0000:000a
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:05:34.767288 IP6 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1 > 2001:67c:4e8:f002::a: ICMP6, echo request, id 64975, seq 1, length 64
11:05:34.780772 IP6 2001:67c:4e8:f002::a > 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1: ICMP6, echo reply, id 64975, seq 1, length 64
...
11:08:31.453377 IP6 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1.47758 > 2001:67c:4e8:f002::a.80: Flags [S], seq 4120251664, win 64800, options [mss 1360,sackOK,TS val 4137525001 ecr 0,nop,wscale 7], length 0
11:08:32.480022 IP6 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1.47758 > 2001:67c:4e8:f002::a.80: Flags [S], seq 4120251664, win 64800, options [mss 1360,sackOK,TS val 4137526032 ecr 0,nop,wscale 7], length 0
11:08:34.533328 IP6 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1.47758 > 2001:67c:4e8:f002::a.80: Flags [S], seq 4120251664, win 64800, options [mss 1360,sackOK,TS val 4137528080 ecr 0,nop,wscale 7], length 0
...
11:10:10.723474 IP6 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1.38610 > 2001:67c:4e8:f002::a.443: Flags [S], seq 1688375545, win 64800, options [mss 1360,sackOK,TS val 4137624278 ecr 0,nop,wscale 7], length 0
11:10:11.743466 IP6 2a01:7e00:e001:ee80:145d:5eff:feb1:1df1.38610 > 2001:67c:4e8:f002::a.443: Flags [S], seq 1688375545, win 64800, options [mss 1360,sackOK,TS val 4137625297 ecr 0,nop,wscale 7], length 0
...

[iam-TJ]

As further confirmation I tried telnet and s_client directly from the VPS - same result:

$ telnet -6 2001:067c:04e8:f002:0000:0000:0000:000a 80
Trying 2001:67c:4e8:f002::a...
^C
$ openssl s_client -msg -debug -6 -connect [2001:067c:04e8:f002:0000:0000:0000:000a]:443
^C

[iam-TJ]

Thinking aloud here but... when connection attempts fail wouldn't it be worth the client testing with a ping to be able to make an informed guess as to the problem (yes, the ping could be answered by another host but generally it'd be OK).

if ( connectionFailed && ping(connection)) { logAndGiveUserTheClue(); }

[iam-TJ]

Thanks to @john-preston who prodded the server administrators and now the desktop client can connect successfully over IPv6. Turned out there was some kind of network/firewall block on my (Linode VPS) IPv6 /56 delegation(s).

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!