Kubernetes + Flannel: UDP packets dropped for wrong checksum – Workaround

Recently I noticed some DNS queries in my Kubernetes cluster time out, causing apps to crash. I looked into the issue, reported to the kernel network team and applied the workaround.

Symptom

My Kubernetes cluster is built with Flannel overlay network with vxlan backend. The idea is that each node (machine) gets a private IP subnet to further allocate to pods. When a cross-node packet is to be sent, it was sent to the vxlan virtual interface, encapsulated in a UDP (regardless of the original protocol) packet and routed to the other node, where it is received by another vxlan interface and extracted.*

Kubernetes clusters provide Service resource. One of the many types of Service allows you to use a single virtual IP to represent multiple pods, some times across nodes. This is implemented with kube-proxy component, which utilizes the IPVS feature in Linux Kernel.

Now, when I make a DNS query on the host (it should be the same from inside containers, but with more hops) using dig against CoreDNS’ service IP, it always times out. It works fine if I query one of the backend pod’s IP instead.

Diagnosis

I used tcpdump to capture the packet, and noticed that the encapsulated UDP packet had a bad UDP checksum.

06:22:23.699846 IP (tos 0x0, ttl 64, id 7598, offset 0, flags [none], proto UDP (17), length 133)
    192.3.59.220.25362 > 147.135.114.20.8472: [bad udp cksum 0xd2ae -> 0x245b!] OTV, flags [I] (0x08), overlay 0, instance 1
IP (tos 0x0, ttl 63, id 33703, offset 0, flags [none], proto UDP (17), length 83)
    172.19.192.0.13169 > 172.19.195.166.53: [udp sum ok] 41922+ [1au] A? www.google.com. ar: . OPT UDPsize=4096 (55)

Further test on the receiving end shows that the packet is transferred, but dropped on the target node. That makes it certain that the checksum is what caused the DNS query to time out with no response.

A little more Googling shows that this could be caused by “Checksum offloading“. That means if the kernel wants to send a packet out on a physical ethernet card, it can leave the checksum calculation to the card hardware. In this case, if you capture the packet from kernel, it will show a wrong checksum, since it has yet to be calculated; but, the same packet captured on the receiving end will have a different and correct checksum, calculated by the sender’s network card hardware.

Workaround

I tried to use ethtool to disable TX (outgoing) checksum offloading on flannel.1 (vxlan virtual interface), and the query works again. So my guess is the kernel driver miscalculated / forgot to calculate the checksum with offloading turned on; when it’s off, it used kernel code to calculate the correct checksum before sending it to the actual outgoing network card.

To temporarily turn off checksum offloading:

sudo ethtool -K flannel.1 tx-checksum-ip-generic off

I used a systemd service to automatically do this after the interface appears. Note that the interface was created by flannel after kubelet is run, so you can’t simply execute it at boot time, e.g. in /etc/rc.local.

You can use the following code to create the service /etc/systemd/system/xiaodu-flannel-tx-off.service, then enable and start it. (The service file can be downloaded using this link.)

sudo tee /etc/systemd/system/xiaodu-flannel-tx-off.service > /dev/null << EOF
[Unit]
Description=Turn off checksum offload on flannel.1
After=sys-devices-virtual-net-flannel.1.device

[Install]
WantedBy=sys-devices-virtual-net-flannel.1.device

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K flannel.1 tx-checksum-ip-generic off
EOF
sudo systemctl enable xiaodu-flannel-tx-off
sudo systemctl start xiaodu-flannel-tx-off

For systemd >= 245, they added TransmitChecksumOffload parameter to *.link unit. You can read the docs and try it out yourself, or just use the service above.

* If you want to learn more about how Flannel and Kubernetes networking works under the hood, I strongly suggest that you read this blog post, which gives an step-by-step demonstration of how a packet is sent from one pod to another.

记一次杯具与恢复的全过程(安卓修改屏幕分辨率)

我手里有一个三星的安卓平板(SM-P601),分辨率是 2560×1600,像素密度 320,经常被某些傻X APP 认为不是移动设备。今天刚发现可以通过一个 wm 命令来临时修改分辨率,于是手贱改了个 640×360,然后悲剧发生了:因为我是在 Terminal Emulator 里 Root 修改的,没有开 ADB,然后屏幕小到看不全,也没法打 wm reset,重启也不管用。借助万能的谷歌,终于坎坷的恢复回去了。下面记录一下各种坑……

第一关:怎么启用 ADB?

在网上搜了一下,果然有蛋疼的老外跟我一样蠢,在没开 ADB 的情况下修改了分辨率,还改不回去了,例如 XDA 的这位仁兄,然后他找出了如何通过 Recovery 强制启用 ADB 的方法:

我用的是 TWRP,首先长按电源键重启,并按住 Home + 音量加进入 Recovery(不同设备组合键也不一样)。然后在 Mount 中挂载 System,再进入 Advanced – Terminal,并使用 vi /system/build.prop 加入以下行:

persist.service.adb.enable=1                                                    
persist.service.debuggable=1
persist.sys.usb.config=mtp,adb

如果不会使用 vi 或者觉得麻烦,可以用 File Manager 把 /system/build.prop 拷到 /sdcard,然后利用 TWRP 的 MTP 把它复制到电脑上修改,然后再拷贝回去。

重启系统后,电脑上使用 adb devices 可以看到设备了,然而后面显示 unauthorized,无法进入 adb shell……于是进入第二关。(如果你的设备版本较低无需 ADB 授权,或以前授权过这台电脑,可以直接跳到最后。)

第二关:怎么授权 ADB?

还是没办法进行屏幕操作。一般连上 ADB 之后都会有个“是否允许 USB 调试”的提示,点允许就授权好了。于是又放狗一搜,果然也有 StackOverflow 的老外解决了这个问题。

首先找到你电脑上的 adbkey.pub 公钥,位置可能在 $ANDROID_SDK_HOME 环境变量对应的位置(如果安装过 SDK)、C:\Users\用户名\.android(Windows 默认)或 ~/.android(其它系统默认)。找到之后,改名为 adb_keys,并利用 TWRP 的 MTP 传输到手机的 /sdcard(也就是内部存储)根目录。

然后回到 TWRP 的 Advanced – File Manager,找到 /sdcard/adb_keys 并复制到 /data/misc/adb 目录下。重启手机即可连接 ADB。

如何正确地修改分辨率?

在系统中进入 adb shell,在修改分辨率时要保证屏幕是关闭(锁屏)状态,所以最好不要在 Terminal Emulator 命令行中修改。

要恢复默认的分辨率,根据系统版本不同对应的命令是:

  • am display-size reset(< Android 4.3)
  • wm size reset(≥ Android 4.3)

然后如果要修改分辨率或密度(density),使用的命令是:

  • am display-size 1080x720
  • am display-density 240
  • wm size 1080x720
  • wm density 240

第二次自己做字幕,这次是脱口秀

Wow,离第一次做美剧字幕已经过去接近五年了,简直是时间飞逝……

Update: 后来又做了几集不同的视频字幕,也把链接放在这里:

  • Last Week Tonight S03E13 – AcFun, BiliBili(需登陆)
  • 柯南秀:明星填问卷 2016.06.16 – BiliBili
  • 鸡毛秀街头采访:川普粉丝有多死心塌地? – BiliBili
  • 赛金花深夜秀:近距离观察 – 川普接受党内提名 – BiliBili

更多视频可以参见我的 AB 站个人主页:

我已经加入阿尔法小分队字幕组,主要做 Last Week Tonight 的字幕。小分队主页:http://space.bilibili.com/60058


前两天又找到一个空闲时间,于是做了一集美国脱口秀的字幕,剧集是 Last Week Tonight with John Oliver(上周今夜秀)的 S03E13。这次只做了中文字幕,因为实在懒得把英文都打出来。把30分钟脱口秀的中文字幕输入到编辑器里,花了大概10个小时,之后做轴和压制大概各1小时。

这次没有传别的地方,只传了AB站。下面是B站的Flash播放器外链,也可以点击这里去B站看。(外链请进入全文查看) Continue reading “第二次自己做字幕,这次是脱口秀”

奇文共赏,关于ShadowsocksR事件

题注:本文记录的是一项发生在 2015 年 8 月的真实事件。博主是原版 Shadowsocks 用户,下面原文的全文可以在文末的地址看到。无论读者是出于因为什么原因看到这篇文章,是 Google 搜索的还是听人忽悠来的,请搞明白文章的背景。另外,希望读者能保持一定的理性,不要“精虫上脑”、一听到“妹子”就管不住自己。互联网上一条狗也可以假装是妹子

因为这篇文章引来的麻烦浪费了我太多时间,本文关闭评论并不再更新。想 DDoS 攻击的请便,反正已经用上了 CDN。有些人傻呵呵的以为自己“攻击”了几个小时,其实服务器才用了 1Mbps 的带宽,建议不要浪费绳命,让自己投入到更有意义的事情中。

16.12.25 更新:说好不更新的,结果还是更新了,堕落到跟某些**一样的水平。

看看这智商真捉鸡啊!正常人都能看懂上面一段斜体的因果关系:因为删一些脑残粉的评论太烦,所以关评;因为被人 DDoS,所以上了 CF。分开两句话的内容也能合成出“正义使者攻击反动网站,博主胆小如鼠关闭评论”的大标题,跟官媒学的这一套也是可以的。还真把自己当什么大V,让脑残粉群起攻之,胆小如鼠的博主都真的笑、笑出声了。

最后加一句:原版 Shadowsocks 软件并没有停更,而且也加入了某些反检测、反攻击的新特性。你们教主很多代码也都是直接 merge 过去的,点开 Commits 就能看到了。要用哪个版本是每个人的自由,但是请不要歪曲事实。还是开头那句话,只是记述真实事件,供参考。


个人建议使用原版 Shadowsocks 软件,比较安全。

以下内容,黑色为 ShadowsocksR 作者的原文,蓝色为本博客(微博 @_小噗)的评论。

背景:某作者([email protected])用了[email protected]的shadowsocks-csharp(现在叫shadowsocks-windows)的代码,原始代码是GPL的,然而新作者发布了二进制但不开源,原作者吐槽了一下,新作者发了这么一篇然后撂蹶子走了。

本版本作为此分支最后一个版本,本分支不再进行维护,也删除了升级提示。

说过的开源承诺一定会兑现,不过兑现得有点偏早了,(GPL要求你从发布的时候就要公开源代码,没有早晚之说)本版本预期的目标只实现了小部分,之后的也不再去实现了。两个可公开的预期目标:1.实现让原版TCP协议过渡到更安全的协议;(小弟才疏学浅,比TCP协议更安全的是啥协议?四层除了TCP和UDP,还准备发明个TCPS?)2.实现让原作者与本版本竞速发布,让使用者受惠。(一口源代码喷在了屏幕上)不过黑脸既然当不下去了,就不当了,爱咋整咋整。(小盆友你几岁啦)至于署名问题,你不怕脑残党来查水表但我怕,你以为这是常用网名么,就算倒台了还要考虑脑残粉随便人肉砍人什么的。

另外,如果你发现某个需求是很有必要的,但和作者说了这个需求但作者不做,和你说“NO”,怎么办?(好问题,接着看)正如三个月前我就和作者说过UDP功能很有用,但作者就说PC上用UDP不如路由器上做。结果呢,那就自己做一个,把功能实现出来,(到这为止都说的非常好呀)把其它人的需求也引发出来,进而通过市场压力迫使作者把这个功能做出来就行了。(哈哈哈哈哈,为什么作者一直在说“市场压力”呢,我们继续赏文)但是你说你不会写代码,或者你写的实现不太好?没关系,我也是新手,我读的经济学,(当当当当!揭晓了!)我不是程序猿,开始动手改代码前我的C#才学了一星期,连select模型是啥也不知道,就算现在也不知道epoll是什么玩意儿,写的代码只能让机器能跑。你要是觉得和我联系也没有问题的话,那就发邮件到mmgac001[at]gmail[dot]com (诚心的打码)

现在的功能看起来这么“完善”,估计还是会继续三个月以前的状况了,不过呢,反正用户不是我,我继续去搞外汇套利得了。(替计算机界惋惜,失去了这么一个不可多得的经济学人才)

下面本噗来强调一下文中的亮点:

1. 最大的亮点,你给作者说了需求作者不做,你该怎么办?是的,如果对你很重要,你就自己做一个,这个是完全正确的。下一步,最好的做法——把你的代码PR给上游!如果你很懒,如果你不会(学经济的嘛),你就把它开源到你的GH上,让作者自己来merge!可是这位经济老兄,不但不开源(GPL violation),还要“市场竞争”,要“逼迫”作者更新……简直亮瞎了朕的狗眼,你说腾讯用了ffmpeg然后违反协议被挂在官网,那是因为怕竞对抄袭,您老这软件也不要钱,用您自己的话说,学了一个周csharp,我感觉写出的代码也就那样,有什么值得背负千古骂名闭源的?最大的可能就是,作者根本不懂开源、git、github这一套,就是小孩子心理自己做了一个方案然后挂出来炫耀而已了。(还有幸被某知名SB博客推荐了一下……于是才有了这一套事。)本噗的建议,外行想掺和开源这一套是好的,但是先把基础知识学好,不是随便写个代码发出来就是造福人类的,你只造福了用你软件的那点儿人,但是让上游作者很心痛。

2. 作者在文中说要切换到“比TCP更安全的协议”,在issue#28里说发现了ss协议的漏洞。虽然我没认真的看过ss协议,但是基本就是对IP层和TCP/UDP层的简单包装。作者可能不是科班出身,不知道现在国际上用的上网协议就这两种……TCP/UDP over IP……接下来,还是那句老话,发现了漏洞为什么不提出来呢?为什么非要在自己的闭源软件里实现呢?今天可以闭源发布客户端,明天就可以在里面加个病毒“造福”你的用户呀,这就是市场嘛。

总之,本噗还是那句话,外行人来自学计算机、写代码,大家都是欢迎的,但是千万不要做这种让内行外行都唾弃的事。GPL就是其它行业中所谓的“合同”,你在下载软件或源代码的时候就等于签订了合同,违反合同无论在哪一行都是不能接受的。

更新:有人给我指出,四层还有个“SCTP”……只想说,grow up吧孩子……任何人只要乐意,都可以在四层自己发明一个协议,你甚至可以在三层发明个IP协议的替代品,然后自己搭个全球互联网……然而操作系统不支持有个卵用啊…… http://stackoverflow.com/questions/2153700/what-kind-of-sctp-support-is-there-on-various-windows-versions

原文:https://github.com/breakwa11/shadowsocks-rss/blob/6623ad7806839562055bf7894320e8e628e88f94/readme.md