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

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

[Akkariiin]

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

[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频繁就不正常

我也有这个问题

[xydche]

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

[zhudatou630]

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

…

在 2017年12月7日，下午7:00，xydche ***@***.***> 写道： 我的开始也这样，后来发现服务端timeout就是120，改成600就好了 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#27 (comment)>, 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

请问怎么修改安卓客户端的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.

联通 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的长连接时长是多少。

[buguniaogu]

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

[zzzop]

这个没有办法解决了吗

[whosneo]

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

[zzzop]

@questionYu timeout不是600秒吗，为啥两分钟断一次

[whosneo]

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

[PixelGe]

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

[whosneo]

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

[JackRBlack]

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

[ankino17]

ss-server 和 ss-local 的超时值至少大于600

[zzw6776]

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

[ankino17]

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

shadowsocksr-android/src/main/scala/com/github/shadowsocks/ShadowsocksVpnService.scala

Line 270 in ad7af09

, "-t", "600"

[zzw6776]

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

[KiddiePi]

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