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.

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

注册gcm推送,120秒就会超时。导致手机一直唤醒,严重bug #27

Closed
MichaelHu55 opened this issue Oct 26, 2017 · 60 comments

Comments

@MichaelHu55
Copy link

commented Oct 26, 2017

这几版的ssrr在手机连上后,按*##426##,120秒会自动以close关闭长连接,导致gcm一直重连。
而用shadowsocks则没有此问题,希望能修复。

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 26, 2017

10-27 01:35:37.723 net=1: Received com.android.chrome 0:1509039337356386%0f493ae6f9fd7ecd []
10-27 01:35:37.392 net=1: Sent com.android.chrome
10-27 01:35:36.889 net=1: Connected
10-27 01:35:34.315 net=1: Queued GCM com.android.chrome
10-27 01:35:34.247 net=1: Close err:FIN time:179
10-27 01:35:34.237 net=1: Sent Close
10-27 01:33:31.640 net=1: Received com.android.chrome 0:1509039211263613%0f493ae6f9fd7ecd []
10-27 01:33:31.292 net=1: Sent com.android.chrome
10-27 01:33:24.131 net=1: Received com.android.chrome 0:1509039203783947%0f493ae6f9fd7ecd []
10-27 01:33:23.817 net=1: Sent com.android.chrome
10-27 01:32:34.500 net=1: Connected
10-27 01:32:26.234 net=1: Close err:FIN time:120
10-27 01:32:26.223 net=1: Sent Close
10-27 01:30:25.935 net=1: Connected
10-27 01:30:19.858 net=1: Close err:FIN time:189
10-27 01:30:19.846 net=1: Sent Close
10-27 01:28:18.023 net=1: Received com.android.chrome 0:1509038897667874%0f493ae6f9fd7ecd []
10-27 01:28:17.685 net=1: Sent com.android.chrome
10-27 01:27:10.397 net=1: Connected
10-27 01:27:04.504 net=1: Close err:FIN time:120
10-27 01:27:04.471 net=1: Sent Close
10-27 01:25:04.144 net=1: Connected
10-27 01:24:58.040 net=1: Close err:FIN time:120
10-27 01:24:58.021 net=1: Sent Close
10-27 01:22:57.192 net=1: Connected
10-27 01:22:46.420 net=1: Close err:FIN time:121
10-27 01:22:46.414 net=1: Sent Close
10-27 01:20:45.273 net=1: Connected
10-27 01:20:44.388 net=1: Close err:FIN time:46
10-27 01:20:44.382 net=1: Sent Close
10-27 01:20:44.320 net=1: Endpoint network 0 != active one: starting parallel connection
10-27 01:19:58.108 net=0: Connected
10-27 01:19:57.591 net=0: Mobile Network Class [3]
10-27 01:19:56.586 net=0: Reconnect on network change -1 DISCONNECTED
10-27 01:19:56.288 net=-1: Close err:FIN time:82
10-27 01:19:56.245 net=-1: Network down, already disconnected
10-27 01:19:56.234 net=-1: Sent Close
10-27 01:18:34.155 net=1: Connected
10-27 01:18:24.612 net=1: Close err:FIN time:122
10-27 01:18:24.594 net=1: Sent Close
10-27 01:16:21.953 net=1: Connected
10-27 01:16:15.417 net=1: Close err:FIN time:122
10-27 01:16:15.372 net=1: Sent Close
10-27 01:14:13.346 net=1: Connected
10-27 01:14:07.479 net=1: Close err:FIN time:121
10-27 01:14:07.462 net=1: Sent Close
10-27 01:12:05.995 net=1: Connected
10-27 01:11:58.446 net=1: Close err:FIN time:121
10-27 01:11:58.432 net=1: Sent Close
10-27 01:09:56.638 net=1: Connected

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Oct 28, 2017

有开启分应用代理吗?GCM服务有进入分应用代理的列表吗?

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 28, 2017

开了,已经确认了,只要play服务或者play框架,这两个任意一个进了分应用代理列表,gcm就会走代理。只要走了代理,120秒必定重连,ssr会发rst。导致gcm重连。已经用过n个版本的ss和ssr和ssrr测试。问题一样。说明这个bug很有可能是ss一直就有的。希望您能搞定,万分感谢

@lucifer9

This comment has been minimized.

Copy link

commented Oct 31, 2017

服务器那边 timeout 设置的是多少啊

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

600.和服务器无关

@lucifer9

This comment has been minimized.

Copy link

commented Oct 31, 2017

用 openconnect 测试没有这个问题
看来确实是 ss 系列特有的
不知道是 libev 那边就出现了,还是到 Android 这边才出来的

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

应该只有android版才需要gcm吧。而且这个问题隐藏得很深啊。以前都没有人关注。

@lucifer9

This comment has been minimized.

Copy link

commented Oct 31, 2017

确实很难注意到啊
因为一般都是推送不及时才会去查这个
现在 2 分钟主动断一次再重连,推送反而更及时了...

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

是的。推送没有问题。手机睡不着了。一个小时待机最少4个电。省电好用的gcm。不再省电了。

@lucifer9

This comment has been minimized.

Copy link

commented Oct 31, 2017

没觉得待机很费电啊
昨晚基本上是 0.8 每小时
大法的 XZ1C,没有越狱

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

你看下gcm记录。待机太久。重连次数太多。就会暂停重连。也就是说会直接不连了。不连的时候待机就还好。但是也收不到gcm推送了。

@lucifer9

This comment has been minimized.

Copy link

commented Oct 31, 2017

7.0 以上系统的话
放半个小时自己也就打盹去了一样没推送
估计是因为这个所以一直也没感觉到问题
无论如何现在 2 分钟断一次肯定是不正常的
希望能有人 review 一下代码

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Oct 31, 2017

我现在就得的8.0,我且pnf root这个软件将,wifi下心跳设成1分钟。然后待机一晚上。gcm不会断,推送一切正常。就是耗电。

@gqbre

This comment has been minimized.

Copy link

commented Nov 1, 2017

@MichaelHu55 手机设定 电池使用情况 是怎么样的?显示为 Play服务 耗电吗?

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Nov 1, 2017

gcm走了代理,耗电只会被统计到ssr里去。所以看不到play服务耗电。电池使用情况可以明显看到间隔很短的频繁唤醒。已经用黑域将所有第三方软件停止运行测试过 了。

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Nov 1, 2017

@MichaelHu55 你是什么ROM?我在华为的EMUI上重现不出来,可能是华为对play的控制比较好。

@lucifer9

This comment has been minimized.

Copy link

commented Nov 2, 2017

小米 6 MIUI 9 最近一个开发版,还是会 120 秒断一次

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Nov 2, 2017

一加3t 氧8.0

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Nov 2, 2017

你下个pnf root, 这个软件,看下play 服务的详情。还有play服务要走代理,才能重现

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Nov 2, 2017

我发现EMUI会自动阻止GCM联网.....关屏就断网了...所以重现不出来

ORZ........看来这个issue需要更多测试反馈了.

@lucifer9

This comment has been minimized.

Copy link

commented Nov 2, 2017

@Akkariiin 不加白名单的话不仅仅是关屏断网,直接就给杀了吧

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Nov 2, 2017

不需要关屏啊,不关屏的时候也是120秒就重连

@lucifer9

This comment has been minimized.

Copy link

commented Nov 3, 2017

耗电问题确实存在。xz1c 不插卡,Wi-Fi 环境下用 shadowsocks(r) 待机 6 小时耗电 3%。同样用 openconnect 几乎没有耗电。

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Nov 3, 2017

shadowsocks,ssr,ssrr都有这个问题。

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Nov 3, 2017

@MichaelHu55 EMUI好像只能给前台应用加白名

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Nov 3, 2017

另外TG貌似是可以收到GCM推来的消息的

@MichaelHu55

This comment has been minimized.

Copy link
Author

commented Nov 3, 2017

国外的社交类,视频类,只要是有推送需求的,一般都支持完整的gcm。比如,youtube,whatsapp,telegram,facebook,twitter等等。全内的微信也支持,淘宝,微博国际版都支持。微信支持不完整,只要微信是有后台的,休眠的情况下可以接到gcm。国外的软件就不需要,没有后台照样收。

@hyxxsfwy

This comment has been minimized.

Copy link

commented Nov 4, 2017

MIUI 国际版,确认有相同的问题,GCM 两分钟重连一次。

@lucifer9

This comment has been minimized.

Copy link

commented Nov 5, 2017

周末用 米6 最新开发版测试,手机装 anyconnect,所有流量都转发服务器。服务器 1 在国内,与国外的服务器 2 用 ss-redir + iptables 的方式翻墙。此时可以观察到手机上还是 120s 断一次。两台服务器都是用的 shadowsocks-libev 3.0.8,chacha20-ietf-poly1305 + tls 混淆。

之后更改配置,使 服务器 1 和 服务器 2 用 ocserv/strongswan 通过 VPN 方式连接,这时手机上就看不到 120s 中断的 log 了。

以上 Wi-Fi,4G 都测试过,现象一致。

可见这个中断至少是 libev 版本本身就有的。python 版本是不是也这样希望有人也测试下,我这边要到下周才有机会再搭类似的环境了。

当然了,话又说回来,这个对于耗电的影响,肯定还是得单独测试。而且不同手机,不同系统肯定还都不一样。所以要是不是强迫症,或者很纠结使用时间的话,暂时无视即可。至少 ss(r) 系列的易用性足以抵消这个 bug 了。

@mianganing

This comment has been minimized.

Copy link

commented Dec 6, 2017

我也有这个问题

@xydche

This comment has been minimized.

Copy link

commented Dec 7, 2017

我的开始也这样,后来发现服务端timeout就是120,改成600就好了

@zhudatou630

This comment has been minimized.

Copy link

commented Dec 7, 2017

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Dec 9, 2017

@xydche 所以其实是连接长时间无活动导致服务器主动断开连接的吗?这样的话应该要程序自己发心跳包才对。

@zhudatou630 修改服务器timeout就是改py服务器端配置文件中的那个timeout。

@ankino17

This comment has been minimized.

Copy link

commented Dec 9, 2017

_20171209120731
_20171209120721
_20171209120727
@Akkariiin 最好允许用户修改Android客户端的timeout值 可以在客户端加一个选项 手动更改timeout
600秒我觉得有点小 wifi环境下28分钟是很省电的

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Dec 14, 2017

嗯,timeout这个东西不是客户端一个人说了算的。需要客户端和服务器同时改大,然后实际的timeout是以创建连接的客户端和服务器中小的那一个为准。 @vovoa17

@Akkariiin Akkariiin added wontfix and removed need more info labels Dec 14, 2017

@Akkariiin Akkariiin closed this Dec 14, 2017

@mianganing

This comment has been minimized.

Copy link

commented Dec 20, 2017

请问怎么修改安卓客户端的timeout

@real-neo

This comment has been minimized.

Copy link

commented Dec 20, 2017

我的使用情况是,GCM会每10分钟断开一次重连,即使是设置了SS/SSR客户端电池不优化也无济于事。据madeye所说,客户端默认是600秒timeout。

There are many possible reasons causing this ~120s timeout. e.g., Routers, NAT, VPS, ss-server settings. From Android client side, the timeout is 600s, which should be large enough.
Actually, don't worry about reconnection every 120s. It won't cause any problem.

@mianganing

This comment has been minimized.

Copy link

commented Dec 20, 2017

我的手机联通 120s 断开后重连基本连不上了,FCM不推送,家里的路由R7000梅林固件装了SSR,也是120s断开
后来手动修改/koolshare/ss下的配置文件tiemout 3000,VPS也成3000,现在wifi下一切正常再也没断过 ,FCM也正常了,但是手机网络一次也没正常过,收不到FCM推送

@mianganing

This comment has been minimized.

Copy link

commented Dec 20, 2017

联通 4G
MT管理器打开 classes.dex 搜 ShadowsocksNatService ,打开后搜 600 改成3000 ,反编译 ,然后重新安装,(VPS也改成3000),现在测试了90分钟 在没sent close过 FCM 推送正常,终于可以愉快的玩耍了;
放一晚 在看看,过两天发个 PNF ROOT 的截图上来

@real-neo

This comment has been minimized.

Copy link

commented Dec 21, 2017

移动 4G
我也按照你说的方法试了下用MT管理器修改classes.dex,将600改为了1800,服务器也为1800,但实测GCM连接在持续28mins之后发送sent client HB收不到ack alarm,导致GCM主动断开重连,然后可以收到消息。
这应该是移动网络的问题,目前还不知道移动 4G的长连接时长是多少。

@Akkariiin

This comment has been minimized.

Copy link
Member

commented Dec 22, 2017

也许可以修改这个延迟的默认设置

@buguniaogu

This comment has been minimized.

Copy link

commented Jan 17, 2018

@Akkariiin 问一下,发现gcm在国内可以用,但稳定性怎么样?设置不代理gcm,可行么?(edit: 看了一下,gcm直连不怎么稳定,过)

@zzzop

This comment has been minimized.

Copy link

commented Mar 29, 2018

这个没有办法解决了吗

@real-neo

This comment has been minimized.

Copy link

commented Mar 29, 2018

较为有效的办法是,自己fork一份代码,修改timeout参数编译使用,修改服务端timeout配合,并选择合适的网络。

@zzzop

This comment has been minimized.

Copy link

commented Mar 30, 2018

@questionyu timeout不是600秒吗,为啥两分钟断一次

@real-neo

This comment has been minimized.

Copy link

commented Mar 30, 2018

两分钟的这个timeout应该是服务端设定的,会影响到手机的连接

@PixelGe

This comment has been minimized.

Copy link

commented Apr 10, 2018

我不知道是不是fcm引起,但是ssrr确实费电,只要挂,耗电肯定第一

@real-neo

This comment has been minimized.

Copy link

commented Apr 10, 2018

SS/SSR/SSRR的费电并非由其本身引起,而是因为其接管了系统流量,系统自动将所接管的流量的耗电计算在了代理软件上。实测开启与否以上三个代理软件,耗电并无明显差异(在翻墙WiFi下测试)。

@JackRBlack

This comment has been minimized.

Copy link

commented Aug 20, 2018

我这边也有这个问题,每30秒重连一次…

@ankino17

This comment has been minimized.

Copy link

commented Aug 20, 2018

screenshot 2018 8 21 01_48_36
ss-server 和 ss-local 的超时值至少大于600

@zzw6776

This comment has been minimized.

Copy link

commented Aug 21, 2018

楼上的老哥能发下你的ssrr吗 我的自己改完了没效果

@ankino17

This comment has been minimized.

Copy link

commented Aug 21, 2018

我用的是自编译ss 很久不用ssrr了
但道理是一样的 更改ss-local的启动参数 -t

@zzw6776

This comment has been minimized.

Copy link

commented Aug 21, 2018

我也是醉了..我之前看评论改的都是ShadowsocksNatService ,然后一直没效果,刚刚认真看了下你给的这个文件的名字,估计一个是nat模式,一个是vpn模式的..难怪我改了没效果....谢啦

@KiddiePi

This comment has been minimized.

Copy link

commented Aug 26, 2018

我也遇到这个问题了,不过跟大家的解决办法都不一样。我这里最后测试是因为搭建ss服务器的方法有问题,我用google的outline搭建ss服务器会出现这个问题,基本每60s报close错误(不知道原因)。而用其他如秋叶等的方法搭建ss服务器,就没有这类问题。有相同问题的,可能搭建方法或者你购买的ss本身有问题。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.