依云's Blog

首先 iw list 看是否支持。如果支持，那就

iw dev wlan0 interface add p2p0 type __p2pdev

这样其实并不会多出一个叫 p2p0 的网络接口。iw dev 能看到多了个「Unnamed/non-netdev」设备。不执行这个也可以连接上 WLAN Direct，但是当前的 managed Wi-Fi 连接会断掉。执行之后再连接，managed 连接会持续，iw dev 里会有两个 Unnamed，不知道何故。另外这个 type __p2pdev 加上去了我就不知道怎么删除了。试了几个命令，结果搞得内核 oops 了……

然后是 wpa_supplicant 配置文件：

ctrl_interface=/run/wpa_supplicant_p2p
ap_scan=1

device_name=起一个名字
device_type=1-0050F204-1

driver_param=use_p2p_group_interface=1

wpa_supplicant 跑起来。注意这里的接口名还是那个 managed 接口的。

wpa_supplicant -i wlan0 -c p2p_config.conf

然后 wpa_cli 连过去操作：

wpa_cli -p /run/wpa_supplicant_p2p

首先用 p2p_find 开启搜索。这时候对端设备能够看到自己了。使用 p2p_connect 对端MAC pbc go_intent=0 连接，在对端接受连接即可。go_intent=0 是让对方作为 group owner，这样对端 Android 才会提供 DHCP 服务（否则要本地提供了）。

然后就可以给自己添加 IP 地址了。此时是可以用 dhcpcd 的，然而直接跑的话它会抢走默认路由，所以知道地址范围之后手动加一个好了：

ip a add 192.168.49.22/24 dev p2p-wlan0-1

Android 设备的地址是 192.168.49.1。

之后就可以用 adb connect 然后 scrcpy 了。

PS: Android 很喜欢四十几的 IP 段呢。USB 网络共享是 192.168.42.129/24，Wi-Fi 网络共享是 192.168.43.1/24，而 WLAN Direct 是 192.168.49.1/24。不知道蓝牙网络共享是多少呢。

PPS: scrcpy 在我的 XZ2C 上运行完美，但是在 MIUI 10 上需要去开发者选项里开启选项「USB 调试（安全设置）」，否则会是「只读模式」，只能看，所有交互操作无效。

参考资料

• en:developers:p2p:howto [Linux Wireless]
• OMAP Wireless Connectivity NLCP WiFi Direct Configuration Scripts - Texas Instruments Wiki

运维同事为了收集日志，配置程序将日志写入一个命名管道。然后他在外边拿 tail -f 去读，结果发生了灵异事件。通过 strace 可以看到，tail 进程读取了日志，但是却并没有再输出来。但是如果不启动输出日志的程序，而是在实例启动之后再进去往管道里写数据，却又是可以立即得到 tail 的输出的。

很奇怪的行为，一群人在那里研究半天，猜测是不是环境变量造成的啊，是不是放后台组执行造成的啊，是不是 XYZ 啊。——典型的「霰弹枪式」除错法。

我当时也被带沟里了。于是跑去尝试复现，接着去读 tail 的源码。花了好久才明白这是一个很简单的问题：tail -f 的语义首先是 tail 这个词本身——先读文件最末尾的数据（默认是十行），然后再是 -f 选项的语义，即在文件更新时接着读取数据并输出。所以，当程序往里边写日志时，管道写端一直没关闭，tail 就一直读不到文件结束，也就无法确定最后十行是什么。当他们测试的时候，因为使用的是 echo shell 命令，打开文件、写入数据、关闭。这样 tail 一下子就读取到了文件末尾，然后把数据输出来了。接下来就是边读边输出了。

其实这种使用方法本身就很奇怪了，以至于这个执行流是兼容许多系统的 tail 的各种分支里，最最不常规、无可奈何的那一个分支。你都用管道了，cat 一下嘛。如果怕遇到管道被 reopen 的情况，就在 while true 里 cat 就好。

这个事件中，我也是见识了很多人解决问题的奇怪思路：「我猜猜猜。猜对了哦耶，猜错了，哎呀编程好难啊，Linux 系统好难啊……」猜你妹啊！你长的是大脑又不是骰子，用逻辑一步一步地取得结果不好吗！

有一个小游戏——猜数字。比如甲确定一个 1 到 1000 之内的整数，然后乙来猜。每当乙给出一个猜测时，甲回应猜对了，还是过大或者过小。如果乙知道什么叫二进制的话，乙可以保证在十次之内猜中的。

计算机系统和编程世界里，最棒的一点是确定性和逻辑性。虽然经常也不是像上例那样完全确定的，但至少比起人类社会要容易确定得多。特别是在有源码的时候。所以解决问题的路线也很简单，顺着问题的症状一路回溯，确认然后排除那些没有问题的部分，逐步缩小问题所在的范围，直接你看见它。就跟上边的猜数字游戏或者地毯式搜索一样。每一次猜测都是带着排除一部分没有问题的地方而去，而不是明明有证据表明某个地方不可能有问题，你还偏偏怀疑问题在那里，做无用功。

就像调查一个凶案，这些人放着有作案嫌疑的人不管，非要费劲地去调查那些有相当好的不在场证明的人。

Arch Linux 中文社区这边也有很多这种人。出了问题描述不清楚症状。新手嘛，没经验也没学习过如何描述事实，讲不清楚也没什么，引导对方获取截屏、日志，逐步排查问题就好了嘛。可就是有些热心人，喜欢提出自己的猜测。重点是：都不尝试证实猜测是否属实，就急着上解决方案。结果就是，我询问细节事实的消息没人理，求助者试试这个，试试那个，最终问题能否解决，就跟买彩票能否中奖一样，全凭运气。

前两天我又看到了基于子序列匹配的字符串过滤工具 fzf 的绚丽效果了。实际上我很早就听说了这个工具，只是懒得动手配置。此次提及，我发现 fzf 已经在官方软件源里了，而我也正好有时间，所以打算试一试。

然后呢，Arch Linux CN 群组里艾穎初提到 skim 这么一个工具。了解了一下，这个就是 Rust 版本的 fzf，并且在 archlinuxcn 源里也有（git 版本，即 skim-git）。这太好了，就是它了！

skim 的操作很简单。文章开头的链接里已经有效果演示了。常用的也就是输入子序列去过滤，然后再输入一个进一步过滤，直到看到想要的。使用 ! 前缀可以反向过滤，^ 匹配开头 $ 匹配结尾。Ctrl-p/n 来上下移动。提示符那里也支持通常的行编辑。

到现在为止，我自行实现了 sk-cd、sk-search-history、sk-vim-mru 三个功能。另外使用了自带的 completion.zsh 文件。由于各种不满意，没有使用自带的 key-bindings.zsh 文件（也就包含 cd 和历史命令搜索功能啦）。

completion.zsh 里目前有两个功能。kill 时通过 ps 补全进程 pid。这个想法很好，以后我可能专门做一个通用的方便 strace 啊 lsof 啊 gdb 啊之类的用。

另一个是遇到两个星号（**）时按 Tab 补全，查找并替换成当前目录下的文件。

我实现的 sk-cd 是从 autojump 取目录列表，然后喂给 skim。于是就成了交互式的 autojump～这是一个我很需要的功能。原来我都是通过 Tab 补全列出可能的项，然后再 Tab 过去选的，有些慢也有些麻烦。

sk-search-history 就是在历史命令里找东西。因为遇到特殊字符时无法正确地加载预览，我并没有开启预览功能。反正找到的命令只会放在命令行上，并不会自动执行的，选错了可以及时取消。

以上两个功能分别绑定到 Alt-s d 和 Alt-s r 上。我使用 Alt-s 作为 skim 快捷键的开头，以便保留 zsh 原本的快捷键，避免冲突，特别是以后可能会有更多功能被加入。我在 Vim 里，也是类似的做法，Alt-q 是 easymotion 的开头快捷键，Alt-d 是 denite 的开头快捷键。

sk-vim-mru 仅仅是个命令了。使用的数据是 mru.vim 的历史记录文件。然后做了两个函数：vim-mru 使用 Vim 编辑文件，vv-mru 使用我自己的 vv 命令在已有的 gVim 里编辑文件。

我做的版本和 skim 自带版本，最大的差别在于，我的版本会尽量使用全部的窗口空间，而 skim 自带的总是会使用 40% 窗口高度。（所以我有个函数用来获取当前光标位置，有需要的可以自己拿去用。）

如果你想用我的配置，可以 wget https://github.com/lilydjwg/dotzsh/raw/master/plugins/sk-tools.zsh 回去，然后 source 一下就好。有需要的话（比如数据来源、键绑定等）可以自行修改。

2018年09月17日更新：我尝试了一下把 sk-search-history 映射到 Ctrl-r 上，然后很快就放弃了。因为 skim 的结果是不可预测的，而默认的 Ctrl-r 的结果是完全可预测的（只要还记得；当然你不能开（那个让我在服务器上误杀过进程的）实时历史共享）。可预测性对提高效率非常关键，因为你不需要中断思维，停下来等结果。

很早之前，我在《Linux「真」全局 HTTP 代理方案》中介绍了 redsocks 方案。不过它只处理了 TCP，并没有处理 UDP，DNS 也是采用强制 TCP 的方式来处理的，再加上它本身还要将请求转发到真正的代理客户端，延迟比较高。然后，还可以结合 Wi-Fi 分享 或者网络命令空间，玩点更有趣的。

首先要有支持的代理客户端，比如 ss-redir。这个就不用多介绍了，配置好、跑起来即可。以下假设此代理跑在 127.0.0.1 的 $PPROT 端口上。

然后，TCP 的代理设置。使用的是和 redoscks 一样的方案。这个比较简单，除了有一点需要注意：DNAT 到 127.0.0.1 时，需要设置内核选项net.ipv4.conf.all.route_localnet=1。

最麻烦的是 UDP 的代理，使用的是 TPROXY。首先，需要把要走代理的数据包路由到本地。以下假设我们给要代理的数据包打上标签 1。那么执行：

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

那个 100 是路由表的编号，可以自己选一个喜欢的。

然后，对于转发流量（来自局域网或者另外的网络命名空间），直接把需要代理的数据包扔给 TPROXY 目标，并且打上对应的标签即可。而对于本地产生的流量，不仅要带有对应的标签，而且需要在 OUTPUT 链打上一个（与之前不同的）标签，触发 reroute check 才行。

最后，对需要代理的数据包设置 iptables 规则：

比如来自网络命名空间或者局域网的 IP 段 192.168.57.0/24 全部走代理：

iptables -t nat -A PREROUTING -p tcp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j DNAT --to-destination 127.0.0.1:$PPROT
iptables -t mangle -A PREROUTING -p udp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j TPROXY --on-port $PPROT --on-ip 127.0.0.1 --tproxy-mark 1/1

其实 Linux 是支持文件的创建时间的呢。不过不是所有文件系统都支持，比如 ext4、xfs、btrfs 都支持，zfs、vfat、ntfs 不支持。

但是呢，用户基本上是看不到的。文件系统有记录，但是没有 API 可以获取到这个数据。所以你用 stat 命令的话，会看到「创建时间」一行总是「-」。用 debugfs 搞 ext4 是可以的，但是那个需要 root 权限，并且一不小心会搞坏文件系统。

最近，我阅读内核源码时，忽然发现内核已经通过 4.11 版本引入的 statx 系统调用支持获取创建时间了。字段名里用的是 btime（birth time），没有用 crtime（creation time），也没有用大写的 Btime 呢。

但是 glibc 并没有支持，所以要用 syscall 函数来调用。也不是很复杂。不过我正着手用 Rust 实现的时候，却在内核源码树里找到了 samples/statx/test-statx.c 这么个文件。原来有现成的啊！

gcc 编译一下，还真好用：

>>> statx /
statx(/) = 0
results=fff
  Size: 224             Blocks: 0          IO Block: 4096    directory
Device: fe:01           Inode: 96          Links: 17
Access: (0755/drwxr-xr-x)  Uid:     0   Gid:     0
Access: 2018-07-11 13:33:08.659477830+0800
Modify: 2018-03-30 15:06:02.645864827+0800
Change: 2018-03-30 15:06:02.645864827+0800
 Birth: 2017-06-19 21:07:53.653467000+0800

2019年09月03日更新：现在（coreutils 8.31）stat 命令已经支持创建时间了。

VBox 可以从一个指向本地硬盘的 vmdk 文件启动虚拟机。

首先，为了避免使用 root 运行 VBox，我们需要给自己访问磁盘的权限。我即将启动的是位于 sda5 上的 openSUSE。它使用 UEFI 启动，所以 UEFI 分区的权限也是需要的。创建 vmdk 文件的时候需要读取分区表，因此，还需要 sda 的权限：

sudo setfacl -m u:${USER}:rw /dev/sda{,1,5}

然后我们创建 vmdk 文件。使用-partitions 1,5选项的话，只有这两个分区能在虚拟机里访问，别的分区读的时候是全零，写入操作会被忽略。-relative选择使用分区设备名（sda1、sda5），这样创建好之后 VBox 不再需要对整块硬盘 sda 的权限了。另外会附带创建一个名字以 -pt.vmdk 结尾的文件。它是单独的分区表。如果是 MBR 启动的话，是可以直接在虚拟机系统里更新引导器的，不影响外边的系统。不过我这次是使用 UEFI 启动，所以用不上了。

VBoxManage internalcommands createrawvmdk -filename hostdisk.vmdk -rawdisk /dev/sda -partitions 1,5 -relative

创建好之后就可以撤销对 sda 的权限了：

sudo setfacl -b /dev/sda

然后去 VirtualBox 界面那边创建新虚拟机，并「启用 EFI」。另外，可以在存储设置里，把「控制器: SATA」的「使用主机输入输出 (I/O) 缓存」启用，似乎这样 I/O 会快一点。

VBox 的 EFI 并不像电脑的那样，按 F12 可以选择启动项。因此，它会启动默认的那个，也就是 /EFI/Boot/bootx64.efi。如果你想启动的系统不是这个的话，就把它的 efi 文件复制过来覆盖它。比如我是这么做的：

cd /boot/EFI/Boot
sudo cp ../opensuse/grubx64.efi bootx64.efi

如果是 Windows 10 并使用 MBR 启动的话，可以在虚拟机里用如下命令更新 MBR，干掉原来用于多启动的 grub：

bootsect /nt60 c: /mbr

做好之后就可以启动啦～

对于设备的权限设置，重启之后会丢失的。需要的时候再加上好了。

PS: openSUSE 自带了 VBox 的驱动啊，不过剪贴板共享不能用，大概只有显示驱动没带上服务。

PPS: 启动没一会儿就通知我更新出现错误，一看软件源设置，果然是 HTTP 的，被垃圾鹏博士劫持了。

刚听说就已心动，无奈当时并不支持 Linux。后来由于一些事情耽搁到现在，终于到手了～

显示器整体尺寸是31cm×27cm，其中显示屏尺寸不到26cm×21cm（请注意：手工测量有误差）。分辨率是2200x1650。也就是200dpi多，和我的 Kindle Paperwhite 一代差不多的。

显示器下方是两个纸盒，里边是Y形线（照片中没有）、简易支架（那根根子）、螺丝和仅几百M的驱动U盘。

Y形线是附加了USB电源线的HDMI线。信号走HDMI，电源走USB，所以需要额外占用一个USB口。当然接充电器上也是可以的，只是在电脑边接个充电器更不方便。

工作时，USB端口的电流为30～50mA左右，并不像说明书上说的需要2A那么多，挺省电的。对比之下，我的罗技鼠标接收器也需要15mA左右的电流呢。

线都接上之后，屏幕会闪几下，然后就可以用了。只是每隔几分钟会弹出提示信息，要求安装并运行所谓的「驱动」。下图是默认的 floyd 模式：

为了更多的模式，以及最重要的，别显示那个提示信息，需要安装并运行大上提供的软件。

软件是为 Ubuntu 提供的，但是 Arch 下也可以使用。下载并解包，将得到的三个文件「PaperLikeHD」、「ResChange」、「DS.ico」放到/usr/local/sbin/下，然后sudo PaperLikeHD 运行，会弹出一个包含一列按钮的窗口。不给 root 权限是不行的，会什么也不做就退出。

但是这样还不够。我使用的时候它总是报告找不到显示器。客服不肯告诉我它到底使用什么机制检测的，所以我 strace 又反汇编看了一下，最后发现它在找 /dev/i2c-* 设备文件，而我的系统上没有它们。看了一下一堆以 i2c 开头的内核模块，最后发现只要加载 i2c-dev 模块就好了。大上的软件需要一些时间来检测，等一会儿它就会在终端打开出「setting...50」这样的文字，这时就好了。

过程中我还专门启动到 Ubuntu live 系统里测试来着。后来才知道原来是自己的手速太快，软件还没检测到，其实等等就好 (╯‵□′)╯︵┻━┻

从图片中可以看到，floyd 模式的显示很粗糙。这是因为它实际上只有二阶灰阶，通过不同密度的点来近似不同的灰度。虽然显示有很严重的颗粒感，但是它响应飞快，常规打字操作时几乎感觉不到延迟，很适合写作和阅读文本。而真正的二阶灰阶模式 A2，只有黑白两色，虽然依旧反应快速，但是因为非黑即白，只能用来读纯文本，任何阴影或者灰色的字都不好处理。

16灰阶的 A16 模式，显示清晰、层次丰富，但是响应速度非常慢。也不是非常啦，除了屏幕大小外，无论显示效果还是响应速度都跟我的 Kindle 一样的。而与 Kindle 不同的是，它会在更新时将更新区域变黑再显示，造成闪烁。在此模式下使用鼠标非常非常费力，任何非静止的元素（比如火狐载入中的动画、时钟、光标移动）都挺分散注意力的。

以上都是所谓的「可变分辨率模式」。另外有个「固定1100x825模式」，也就是使用一半的分辨率。至于另一半去了哪里，看看它所支持的模式就能猜到了：

• A5，也就是五灰阶。这是用四个墨滴来显示一个像素，每个墨滴只有黑与白两种状态。
• A61，所谓的61灰阶。也是用四个墨滴来显示一个像素。不过每个墨滴竭尽所能有16种状态，也不知道大上是怎么组合出这61灰阶的。

也不知道大上为什么把这两种墨滴用法叫作「可变分辨率模式」和「固定1100x825模式」。哪里可变了，又哪里固定了呢？这两种模式切换时，会调用「ResChange」程序，它会影响当前的显示器布局，需要重新使用 xrandr 进行设置。

以下是各种模式显示这个灰阶测试网页的照片：

A2 模式：

A16 模式：

floyd 模式：

A5 模式：

A61 模式：

半分辨率下，清晰度做出了很大的牺牲。以下是 A16 和 A61 模式显示 PaperLikeHD 软件自身界面的效果对比：

在 A2、A5、floyd 模式下，可以调节对比度，也就是墨滴到底显示为黑还是为白的阈值，以在显示不同的页面时都能将文本与背景良好区分开。

和 Kindle Paperwhite 不同的是，它没有背光。在晚上的时候，屏幕偏暗，附加一个台灯光源比较好。不过它的屏幕也不像 Kindle 那样偏黄。

这篇文章最终定稿，就是在 PaperLikeHD 上完成的，使用的是 floyd 模式。我个人觉得半分辨率的几个模式很鸡肋。目前觉得，写作用 floyd 模式，文本阅读使用 A2 模式，网页阅读使用 A16 模式，这样最好了～

floyd 模式还有个问题：在显示某些图片时（比如我的 Awesome 桌面壁纸），那些墨滴颗粒会不断地抖动，就像风在吹沙粒一样……

最后，这里是大上的官网链接。

最近学 wzyboy 搭了一套 collectd + Graphite + Grafana 监控。collectd 和 Grafana 都比较好搞，Arch 官方源里有。但是 Graphite 就没有了。

我没有使用 Python 2 版、带 Web 前端的 Graphite 包，而是使用 graphite-api 提供 Web API，python2-carbon 存储数据。它们在 AUR 上有，其中 python2-carbon 是相当危险的（现在已经改了）。

为什么危险呢？

首先，最明显的，carbon 服务以 root 用户运行。它本身没有任何使用 root 权限的必要，所以专门创建一个 carbon 用户更好。

其次，它运行起来之后，我发现是监听 0.0.0.0 的。这个也无必要：我的 collectd 就在本地呢。

最后，也是最吓人的：它默认开启了接收 pickle 数据的端口。Python pickle 模块的文档一打开，就能看到红色的警告，告诉人们不能接收不信任来源的 pickle 数据。而我曾经工作过的公司也发生过通过 pickle 注入代码的事情：攻击者发现了一个对外网开放的 Redis 服务，刚好那个 Redis 是给 Celery 用的。攻击者于是往里边写了条自己构造的 pickle，在解析时调用 curl 命令向其服务器报告IP、端口和当前UNIX用户的信息。

这接口，开在外网，就是远程代码招行；开在本地，就是本地提权。很危险的。

为了防止各种漏洞被利用，一个未雨绸缪的办法就是：权限最小化。本来这是件比较麻烦的事情，好在 systemd 提供了许多现成的配置项，使得给 carbon 这种服务加固简单易行。

首先创建用户，写一个 sysusers 文件就可以了：

u carbon - "carbon service" /var/lib/carbon

然后，它需要使用文件系统的某些部分。那么别的就用不着访问了，比如 /home。而 /dev、/tmp 这些，自己用自己的就好。连 / 也不让写，也不允许获取任何新特权了。其实使用 carbon 用户它本来就写不了 / 也没有任何特权了，但以防万一嘛，要是哪里来个本地提权漏洞呢？

[Unit]
Description=Graphite/Carbon
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/carbon-cache.py --config=/etc/carbon/carbon.conf start
User=carbon

PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
CapabilityBoundingSet=

ReadOnlyPaths=/
ReadWritePaths=/run
ReadWritePaths=/var/log/carbon
ReadWritePaths=/var/lib/carbon

[Install]
WantedBy=multi-user.target

限制文件系统的访问，systemd 配置起来很方便，我打包的时候喜欢尽量加上。

完整的 python2-carbon 服务配置和打包脚本在这里。

以及，这里是 Arch Linux 中文社区的编译机的 Grafana。

咱买了一个录音笔，效果比使用笔记本话筒录音好多了还省电。当然啦，我也曾试过使用手机录音，结果是，没能录多久就中断了（Android 就是这么不靠谱）。

我的录音需要记录较为准确的时间信息。录音笔怎么知道现在是什么时间呢？还好它没有跟风，用不着联网！

它带了一个小程序，叫「录音笔专用时间同步工具」（英文叫「SetUDiskTime」，可以搜到的）。是一个 EXE 文件，以及一个 DLL 文件。功能很棒，没有广告，没有推荐，也不需要注册什么乱七八糟的账户，甚至都不需要打开浏览器访问人家官网。就弹一个框，显示当前时间，确定一下就设置好时间了。这年头，这么单纯的 Windows 软件还真是难得呢。

然而，它不支持我用的 Linux 啊。虽然我努力地保证这录音笔一直有电，但是时间还是丢失了几次，它的FAT文件系统也脏了几次。每次我都得开 WinXP 虚拟机来设置时间，好麻烦。

Wine 是不行的，硬件相关的东西基本上没戏。拿 Procmon 跟踪了一下，也没什么复杂的操作，主要部分就几个 DeviceIoControl 调用，但是看不到调用参数。试了试 IDA，基本看不懂……不过倒是能知道，它通过 IOCTL_SCSI_PASSTHROUGH 直接给设备发送了 SCSI 命令。

既然跟踪不到，试试抓 USB 的包好了。本来想用 Wireshark 的，但是 WinXP 版的 Wireshark 看来不支持。又尝试了设备分配给 VBox 然后在 Linux 上抓包，结果 permission denied……我是 root 啊都被 deny 了……

那么，还是在 Windows 上抓包吧。有一个软件叫 USBPcap，下载安装最新版，结果遇到 bug。那试试旧版本吧。官网没给出旧版本的下载地址，不过看到下载链接带上了版本号，这就好办了。去 commit log 里找到旧的版本号替换进去，https://dl.bintray.com/desowin/USBPcap/USBPcapSetup-1.0.0.7.exe，就好了～

抓好包，取到 Linux 下扔给 Wireshark 解读。挺小的呢，不到50个包，大部分还都是重复的。很快就定位到关键位置了：

一个 0xcc 命令发过去，设备回复「ACTIONSUSBD」，大概是让设备做好准备。然后一个 0xb0 命令，带上7字节数据发过去，时间就设置好了。简单明了，不像那些小米空气净化器之类的所谓「物联网」，通讯加密起来不让人好好使用。

那么，这7字节是怎么传递时间数据的呢？我首先检查了UNIX时间戳，对不上。后来发送这个字串看上去挺像YYYYMMDDHHMMSS格式的，只是明显不是当时的时间。啊，它是十六进制的嘛！心算了几个，符合！再拿出我的 Python 牌计算器，确定年份是小端序的16位整数。

好了，协议细节都弄清楚了，接下来是实现。我原以为我得写个 C 程序，调几个 ioctl 的，后来网友说有个 sg3_utils 包。甚好，直接拿来用 Python 调，省得研究那几个 ioctl 要怎么写。

#!/usr/bin/env python3

import os
import sys
import struct
import subprocess
import datetime

def set_time(dev):
  cmd = ['sg_raw', '-s', '7', dev, 'b0', '00', '00', '00', '00', '00',
         '00', '07', '00', '00', '00', '00']
  p = subprocess.Popen(cmd, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
  dt = datetime.datetime.now()
  data = struct.pack('<HBBBBB', dt.year, dt.month, dt.day,
                     dt.hour, dt.minute, dt.second)
  _, stderr = p.communicate(data)
  ret = p.wait()
  if ret != 0:
    raise subprocess.CalledProcessError(ret, cmd, stderr=stderr)

def actionsusbd(dev):
  cmd = ['sg_raw', '-r', '11', dev, 'cc', '00', '00', '00', '00', '00',
         '00', '0b', '00', '00', '00', '00']
  subprocess.run(cmd, check=True, stderr=subprocess.PIPE)

def main():
  if len(sys.argv) != 2:
    sys.exit('usage: setudisktime DEV')

  dev = sys.argv[1]
  if not os.access(dev, os.R_OK | os.W_OK):
    sys.exit(f'insufficient permission for {dev}')

  actionsusbd(dev)
  set_time(dev)

if __name__ == '__main__':
  main()

家里和公司电脑连接，因为厌倦了一个个做端口映射，有些还因为安全原因得走 ssh，所以决定弄个 VPN。之前使用过 OpenVPN，然而现在懒得再去配置 OpenVPN 的证书了，所以决定尝试一下新东西。

首先，去 WireGuard 官网上转了一圈，结果还是没弄明白怎么配置。后来尝试了一下 demo，把服务端和客户端的脚本分别看了一下，才弄明白。其实在 WireGuard 里，客户端和服务端基本是平等的，差别只是谁主动连接谁而已。双方都会监听一个 UDP 端口。双方都需要一对密钥。双方都需要把对方的公钥加进来。最后一步，谁主动连接，谁就是客户端。因为家里路由器有公网 IP，我做了端口映射，所以我当然是从公司连家里方便了，用不着麻烦的打洞脚本。

首先 pacman -S wireguard-tools 安装。这也会安装上 WireGuard 的内核模块。然后使用熟悉的 ip 命令添加并配置 WireGuard 的网络接口：

# 生成密钥对
wg genkey | tee privatekey | wg pubkey > publickey

sudo ip link add dev wg0 type wireguard
sudo ip address add dev wg0 192.168.58.1/24
sudo wg set wg0 listen-port 60010 private-key privatekey
sudo ip link set wg0 up

这是我家里的配置。使用的是网段 192.168.58.0/24，因为 56 是 vbox 虚拟机用的，57 分配给 lxc 和我的网络命名空间了。指定了一下监听的端口号。我把之前给 mosh 配置了转发的端口号中最高的那个挪用了。

公司里也是同时的配置，只是不需要指定监听端口号，然后把家里那边设置成 peer，并且连过去（相同的命令我没写）：

sudo wg set wg0 private-key privatekey peer 这里是公钥 endpoint 家里的IP:60010 allowed-ips 0.0.0.0/0 persistent-keepalive 180

allowed-ips 指定过来的 IP。这里没怎么限制。persistent-keepalive 是为 NAT 设置的。WireGuard 本来很安静，不需要说话的时候就不说话，但是要往 NAT 后边的主机发送信息，需要经常通信，让 NAT 记得对应的映射关系。

然后家里那边也需要添加一下公司这边的公钥：

sudo wg set wg0 peer YiyFylL+1Dr3j2Cyf0lwXQYz2qaNwm3XyV5YvMFp3Vs= allowed-ips 192.168.58.2/32

IP 限制加上也是没有问题的。这里就不用加上 endpoint 了，它连过来的时候自然就知道了。WireGuard 是支持漫游的，也就是说，双方不管谁的地址变动了，WireGuard 在看到对方从新地址说话的时候，就会记住它的新地址（跟 mosh 一样，不过是双向的）。所以双方要是一直保持在线，并且通信足够频繁的话（比如配置 persistent-keepalive），两边的 IP 都不固定也不影响的。

最后，用得不错，可以把这几条命令写到一个 systemd service 文件里，就可以不用每次敲一串命令了，也可以做到联网后自动启动。

刚刚找了一下，其实之前使用的证书什么的还在，而且还没过期。而且因为弄 nghttpx，用了一下 xca，比 easy-rsa 好用很多呢。不过 WireGuard 的双向漫游很棒啊～