Open shadowlmd opened 6 years ago
Same with verbosity=2:
[17894][2018-06-13 22:33:00.484717 local] New connection 127.0.0.1:52048 -> 127.0.0.1:10995
[17894][2018-06-13 22:33:00.484793 local] epoll_mod(6,0x00000007,8,8,8000200f)
[17894][2018-06-13 22:33:00.484843 local] net_accept_new_connections: cfd = -1
[17894][2018-06-13 22:33:00.484944 local] fd=8 state=39 ready=1030 epoll_ready=5
[17894][2018-06-13 22:33:00.484982 local] END processing connection 8, flags=33554435
[17894][2018-06-13 22:33:00.485017 local] readv from 8: 105 read out of 262144
[17894][2018-06-13 22:33:00.485056 local] readv from 8: -1 read out of 262144
[17894][2018-06-13 22:33:00.485087 local] socket_server_writer: written 0 bytes to 8, flags=0x02000011
[17894][2018-06-13 22:33:00.485120 local] trying to determine connection type
[17894][2018-06-13 22:33:00.485164 local] tcp opportunistic encryption mode detected, tag = efefefef, target=2
[17894][2018-06-13 22:33:00.485197 local] ext_rpcs_execute: fd=8, op=00000000, len=40
[17894][2018-06-13 22:33:00.485228 local] tcp_rpcs_flush_packet: padding with 0 bytes
[17894][2018-06-13 22:33:00.485260 local] received mtproto packet of 40 bytes
[17894][2018-06-13 22:33:00.485291 local] nowhere to forward user query from connection 8, dropping
[17894][2018-06-13 22:33:00.485322 local] ext_rpcs_execute: cannot forward mtproto packet
[17894][2018-06-13 22:33:04.246232 local] fd=8 state=39 ready=1031 epoll_ready=8197
[17894][2018-06-13 22:33:04.246372 local] socket 8: disconnected (epoll_ready=2005), cleaning
[17894][2018-06-13 22:33:04.246433 local] epoll_del(6,0x00000002,8,0,00000000)
[17894][2018-06-13 22:33:04.246500 local] Closing connection socket #8
[17894][2018-06-13 22:33:04.262808 local] fd=3 state=39 ready=1028 epoll_ready=1
[17894][2018-06-13 22:33:04.262895 local] net_accept_new_connections: cfd = 8
[17894][2018-06-13 22:33:04.262971 local] <8 send buffer was 2626560, now 16777216
[17894][2018-06-13 22:33:04.263038 local] >8 receive buffer was 1062000, now 16777216
Looks like it's account-specific issue. The same account cannot connect via MTProxy even from Android client. And I can connect from Windows client.
Looks like it's account-specific issue.
Can't agree, I have the same issue on 2 VPS from one provider.
ext_rpcs_execute: cannot forward mtproto packet
But on another provider (Vultr in my case) MTProxy works and I can connect without problems.
In same time, python realization of MTProxy works on this 2 VPS.
Well, in my case it is definitely user-specific issue because all other users are connecting just fine with any client: Android, Windows, Linux. And this particular user cannot connect with any of the clients, always generating this error.
A have the same problem.
[15514][2018-06-27 12:35:21.698168 local] New connection 80.83.x.x:30731 -> 188.168.x.x:xxx [15514][2018-06-27 12:35:21.716658 local] trying to determine connection type [15514][2018-06-27 12:35:21.716693 local] tcp opportunistic encryption mode detected, tag = efefefef, target=4 [15514][2018-06-27 12:35:21.716715 local] ext_rpcs_execute: cannot forward mtproto packet [15514][2018-06-27 12:35:23.718152 local] socket 8: disconnected (epoll_ready=2005), cleaning [15514][2018-06-27 12:35:23.718207 local] Closing connection socket #8
Problem no longer reproduces since the latest Telegram update or after the recent downtime. I'm not sure if anything of this is related, but user successfully connects from any client now.
The same issue is now happening again.
I have the issue.
./mtproto-proxy -h
[2358][2019-03-11 05:38:33.503383 local] Invoking engine mtproxy-0.01 compiled at Mar 11 2019 04:12:05 by gcc 4.4.7 20120313 (Red Hat 4.4.7-23) 64-bit after commit 2c942119c4ee340c80922ba11d14fb3b10d5e654
cat proxy-multi.conf
force_probability 10 10
default 2; proxy_for 1 149.154.175.50:8888; proxy_for -1 149.154.175.50:8888; proxy_for 2 149.154.162.24:80; proxy_for 2 149.154.162.36:80; proxy_for -2 149.154.162.24:80; proxy_for -2 149.154.162.36:80; proxy_for 3 149.154.175.100:8888; proxy_for -3 149.154.175.100:8888; proxy_for 4 91.108.4.150:8888; proxy_for 4 91.108.4.171:8888; proxy_for 4 91.108.4.207:8888; proxy_for 4 91.108.4.192:8888; proxy_for 4 91.108.4.142:8888; proxy_for 4 91.108.4.138:8888; proxy_for 4 91.108.4.160:8888; proxy_for 4 91.108.4.165:8888; proxy_for 4 91.108.4.187:8888; proxy_for 4 91.108.4.216:8888; proxy_for -4 149.154.165.109:8888; proxy_for -4 149.154.164.250:8888; proxy_for 5 91.108.56.134:8888; proxy_for 5 91.108.56.186:8888; proxy_for -5 91.108.56.134:8888; proxy_for -5 91.108.56.186:8888;
the verbosity log
Hello,
I've noticed that Windows Desktop client cannot use MTProxy for some reason. After starting server with
--verbosity=1
I could see this in console:Only happens with Windows client (1.3.7), Linux version connects just fine, and so does Android client.