Profile cover photo
Profile photo
陈少举
8,718 followers -
Twitter@chenshaoju
Twitter@chenshaoju

8,718 followers
About
少举's posts

Post has attachment
ofo在长沙搞了一个被破坏的共享单车的公益展览,免费,虽然是ofo搞的,但是一样有其他的共享单车被破坏的展示。
用过一段时间的ofo,不过因为经常碰到车牌被损坏以至于不知道单车编号而无法解锁的车辆,后来干脆转用了摩拜。
PhotoPhotoPhotoPhotoPhoto
4/16/17
18 Photos - View album

Post has attachment

Post has shared content
UPDATE: As of this morning we have lost DNS routing to our domains and Gerrit is now offline - with little doubt as a reaction to our blog post yesterday. The blog post in its entirety is pasted below.

A fork in the road

Last week, we released the final CM-13.0 releases, updated to the latest security patches, in anticipation of what follows.

Yesterday, Cyanogen Inc (Cyngn) announced that they were shutting down the infrastructure behind CyanogenMod (CM). This is an action that was not unpredictable given the public departure of Kondik (cyanogen himself) from the company, and with him our last remaining advocate inside Cyngn’s leadership.

In addition to infrastructure being retired, we in the CM community have lost our voice in the future direction of CM – the brand could be sold to a third party entity as it was an asset that Kondik risked to start his business and dream. Even if we were to regroup and rebuild our own infrastructure, continuing development of CM would mean to operate with the threat of sale of the brand looming over our heads. Then there is the stigma that has grown to be attached to anything named ‘Cyanogen’. Many of you reading this have been champions of clarifying that the CM product and CyngnOS were distinct, yet the stain of many PR actions from Cyngn is a hard one to remove from CM. Given CM’s reliance on Cyngn for monetary support and the shared source base, it’s not hard to understand why the confusion remains.

It will come as no surprise that this most recent action from Cyngn is definitely a death blow for CyanogenMod.

However, CM has always been more than the name and more than the infrastructure. CM has been a success based on the spirit, ingenuity and effort of its individual contributors – back when it was Kondik in his home, to the now thousands of contributors past and present.

Embracing that spirit, we the community of developers, designers, device maintainers and translators have taken the steps necessary to produce a fork of the CM source code and pending patches. This is more than just a ‘rebrand’. This fork will return to the grassroots community effort that used to define CM while maintaining the professional quality and reliability you have come to expect more recently.

CM has served the community well over its 8 long years. It has been our home, bringing together friends from all over the world to celebrate our joy of building and giving. Its apt then that on this Eve of a holiday we pay our respects. We will take pride in our Lineage as we move forward and continue to build on its legacy.

Thank you & Goodbye,
The CyanogenMod Team

Post has attachment

Post has attachment

Post has attachment

Post has attachment
好久没在G+上发点啥了。

最近买了一个XBOX One S的手柄,有点意思,支持蓝牙功能,可以连接到Windows 10的计算机上玩游戏。

试了一下狂野飙车8,流畅度不错,这个蓝牙的抗干扰性能还不错,开着WiFi居然没啥影响。
Photo

Post has attachment
记一次诡异的家用路由导致UDP丢包的现象
昨天发了一条推文,描述了所遇到的大概现象:
https://twitter.com/chenshaoju/status/751029190971895808

昨天下午,接到一位客户的反馈,无法连接上敝司的一台服务器。

敝司做CS类软件,客户端通过本机的2669端口向服务器的2668端口发送UDP数据包,而客户端的本机的2669端口则是固定的。

首先,怀疑是客户计算机操作系统的Windows网络栈或协议栈损坏,在执行了 netsh 相关命令后,重启,并没有效果。

于是,通过 ip.cn 获取了客户的公网IP,在服务器上用Wireshark抓包,结果并没有抓到来自客户端的数据包。

然后,开始怀疑是客户的计算机上安装的360软件,360从某个版本开始带了一个类似网络防火墙的功能,会拦截应用发往外网的数据包。

在客户卸载了360后,仍然不行。这是陷入了一个谜团,于是在客户端和服务端同时使用Wireshark抓包。

通过抓包分析,客户端的确发出了到服务器的数据包,但是服务器并没有收到。

于是想起Windows SDK中提供了一个网路测试工具,分别是 simplec.exe 和 simples.exe ,可以向任意端口发送TCP/UDP的数据包。

使用该工具,在客户端上发送数据包,到服务器上,结果抓包抓到了!

但是为什么我们的软件发出去的数据包会被丢弃?

于是开始怀疑是否是路由器导致的。

用户使用的是一个很简单的D-LINK DIR-605L,在关闭了AGL过滤、防欺骗等安全设置后,仍然无效。

最后发现,用户启用了DMZ,并指向了局域网中为 192.168.1.10 的IP,在客户的计算机上Ping此IP,不通,可能并没有此IP地址。

在取消了该DMZ设置后,重启路由器,问题解决。

查到了D-LINK的固件源码地址 http://tsd.dlink.com.tw/GPL.asp ,目前还暂不清楚为什么DMZ会导致该问题。

EDIT:
  后记:可能的原因,是因为我司的软件在客户端使用的原端口是固定的,均为UDP 2669。可能路由器的DMZ功能对于固定源端口的数据包处理有问题,导致数据包在经过路由器时被丢弃或者被转发到了错误的IP上引起的。

Post has attachment

Post has attachment
Wait while more posts are being loaded