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

[MichaelHu55]

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

[MichaelHu55]

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]

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

[MichaelHu55]

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

[lucifer9]

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

[MichaelHu55]

600.和服务器无关

[lucifer9]

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

[MichaelHu55]

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

[lucifer9]

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

[MichaelHu55]

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

[lucifer9]

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

[MichaelHu55]

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

[lucifer9]

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

[MichaelHu55]

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

[gqbre]

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

[MichaelHu55]

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

[Akkariiin]

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

[lucifer9]

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

[MichaelHu55]

一加3t 氧8.0

[MichaelHu55]

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

[Akkariiin]

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

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

[lucifer9]

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

[MichaelHu55]

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

[lucifer9]

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

[MichaelHu55]

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

[Akkariiin]

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

[Akkariiin]

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

[MichaelHu55]

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

[hyxxsfwy]

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

[lucifer9]

周末用 米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 了。

[wuchjun]

一加3 氧8.0复现这个问题，所以我说怎么8.0这么耗电。最近推送也不即时了才专门测试看了一下日志，用路由版就好好的

[fishmacs]

@wuchjun 用路由版就好好的 路由版是什么？

[wuchjun]

@fishmacs路由器上装的ssr

[zhudatou630]

Sony XZP Oreo 也出现这个问题 感觉8.0的耗电增加了，不过7.x时候没去看过gcm的日志，不清楚是否gcm心跳的原因

[zhudatou630]

@MichaelHu55  问一下sent client hb 和 sent close 表达的意思一样吗？ 在wifi下一直显示的是sent client hb

[MichaelHu55]

不一样，sent client hb正常。sent close频繁就不正常

[ghost]

我也有这个问题

[xydche]

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

[zhudatou630]

你是用什么改的呢？需要root吗？现在手里的机子没有root

在 2017年12月7日，下午7:00，xydche notifications@github.com 写道：

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/shadowsocksrr/shadowsocksr-android/issues/27#issuecomment-349934368, or mute the thread https://github.com/notifications/unsubscribe-auth/AZE20jNZGFpxygdeXRAwcvB_92uNNRQeks5s98VCgaJpZM4QHE02.

[Akkariiin]

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

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

[ankino17]

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

[Akkariiin]

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

[ghost]

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

[whosneo]

我的使用情况是，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.

[ghost]

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

[ghost]

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

[whosneo]

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

[Akkariiin]

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

[buguniaogu]

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

[zzzop]

这个没有办法解决了吗

[whosneo]

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