依云's Blog

最近公司弄了 Wi-Fi 登录。就是那个叫 captive portal 的东西。

Android 早就会在连接 Wi-Fi 时检测网络是不是要登录了，为此 Google 弄了个 /generate_204 的 URL。小米、高通、USTC、v2ex 也都提供了这个东西，方便广大中国大陆 Android 用户使用。（我发现我的 Android 使用的是高通的地址，没有用 Google 的。）

但我使用的 Arch Linux 自行开发的 netctl 网络管理工具没这种功能。火狐倒是不知道什么时候加上了，不过使用的地址 http://detectportal.firefox.com/success.txt 是返回 200 的。

所以我启动火狐就可以看到要登录的提示了。然而问题是，其它程序不知道要登录啊。像 offlineimap、openvpn、rescuetime 这种还好，会自己重试。可每次网络需要登录的时候 dcron 就会给我发一堆邮件告诉我我的 git pull 都失败了……当然还有我老早就注意到的 pkgstats，经常会因为启动过早而无法发送统计数据。

所以呢，得想个办法，等连上互联网之后再跑那些脚本啊服务什么的。

检测是不是连好了很简单，不断尝试就可以了。但我需要一个系统级的 Condition 对象来通知等待方可以继续了。然而我只知道 Linux 有提供信号量。难道要自己弄共享内存来用么？

去 #archlinux-cn 问了一下，farseerfc 说试试命名管道。我想了想，还真可以。只有读端的时候进程就会阻塞，一旦有写端就能成功打开了。当然没有读端的打开写端会打不开，不过没关系，反正这进程也不能退出，得一直拿着这个文件描述符。

没想到很少用到的命名管道有意想不到的用法呢。我以前还为了不阻塞而专门写了篇文章呢。

于是负责检测网络连通的 check-online 和等待网络连好的 wait-online 都写好了。

check-online 应当是个服务。那就交给 systemd 吧。然后……systemd 不是有个 network-online.target 么？正好可以让 check-online 来达成这个目标呢，多合适呀。

于是服务写好了。测试了几天，大成功！不仅 wait-online 很好地工作了，而且我发现 openvpn 和 pkgstats 自动排到 network-online.target 后边去了。nginx 的 OSCP staple 经常因为 DNS 失败而无法成功，我也可以在联好网之后去 reload 一下它了。（不是强依赖，我可不希望连不上网的时候我本地的 wiki 也访问不了。）

整个项目就叫作 wait-online，在 GitHub 上，欢迎送小星星哦～Arch Linux 包可以从 [archlinuxcn] 仓库 安装 wait-online-git 包。

最近开始用 Firefox nightly 了。它使用 GTK 3，于是对 GTK 3 主题的不满也逐渐表现出来了。

首先是选中的文本，以及菜单项。默认的那个蓝色太深了，我还是更喜欢 GTK 2 mist 主题那个浅蓝色。

然后，我是使用亮色主题的，黑黑的 tooltip 提示框太违和。而且边距那么大，多浪费空间啊。改成 GTK 2 时代那种简单的样子好了。

最后，那个又细又黑的滚动条好讨厌。改掉改掉！

最终效果图（好不容易才把这么多东西截到一张图里喵）：

~/.config/gtk-3.0/gtk.css 代码：

/* For Adwaita {{{1
 */
/* scrollbars {{{2
 */
scrollbar {
  border-radius: 0;
  background-color: #eaeaea;
}
scrollbar slider {
  background-color: #bfbfbf;
  border-color: transparent;
  border-width: 4px;
  min-height: 10px;
  min-width: 10px;
  border-radius: 0;
}
scrollbar slider:hover, scrollbar slider:active {
  background-color: #bfbfbf;
}
/* tooltip {{{2
 */
tooltip {
  border: 1px solid #808080;
  background-color: rgba(254,254,228,0.9);
  border-radius: 0;
  padding: 0;
}

tooltip * {
  color: #000;
  padding: 0;
}
/* others {{{2
 */
*:selected, menuitem:hover {
  background-color: #d6e9f8;
  color: currentColor;
}

/* Vim modeline {{{1
 * vim:se fdm=marker:
 */

磁盘空间不够用了，或者只是洁癖发作想清理了，可以用 ncdu 来查看到底是什么文件占用了磁盘。ncdu 基于 ncurses，对比 du，更方便交互使用，对比 baobab 这类的 GUI 的工具，ncdu 可以在服务器、Android、树莓派、路由器等没有或者不方便有图形界面的地方跑。

但是呢，我现在有很多很多不同时间的备份，我想知道，是什么东西突然用掉了我好几百兆的空间？我是不是需要把它排除在备份之外？

所以呢，我需要一个支持对比的工具。

本来我是打算什么时候有空了自己写一个的，然而我注意到 ncdu 可以把大小信息保存在文件里。其实我只要对比两个 ncdu 产生的文件，然后照着输出一个差异文件就可以了嘛。不用自己遍历文件树，不用自己做界面，多棒！而且也不一定要像我这样有不同时间的备份才有用。可以定时跑一跑 ncdu，把导出的文件保存起来，将来随时取用。

于是有了 ncdu-diff 脚本。

然而事情总是不那么顺利。输出文件拿给 ncdu 加载的时候，ncdu 报错了——它不支持负数。我给它加了支持，然后再加载，BOOM！ncdu 挂掉了……有符号整型和无符号整型的事情，还有格式化输出的事情……总之花了一天，它终于不崩溃了。补丁也放在同一仓库了。

从上图可以看出，Android 的 app 越更新越大……以及深入之后可以发现，微信的动画表情占了我好多好多的空间，我去删掉它们……

给 Arch Linux x86_64 现成的包：下载, 签名。

新家新路由器。

为了玩 teeworlds，需要 root 权限操作 iptables。我上网找了一堆方案，无果。最后想着，先把自动更新 DNS 的脚本写了吧。

于是研究 API。通讯协议是 JSONRPC 2.0，授权是一个 token。先用从网页取得的 token 调 API，成功～然后我还在想，怎么拿 root shell 呢。结果去看了一下登录后返回的数据：

注意看右下角！「open_dropbear」！

于是：

>>> c.api_request('xapi.basic', 'open_dropbear')
[D 08-05 19:28:36.145 connectionpool:243] Resetting dropped connection: localhost
[D 08-05 19:28:36.640 connectionpool:396] http://localhost:8080 "POST http://192.168.99.1/ubus/ HTTP/1.1" 200 None
{'status': 0}

然后就：

>>> ssh root@192.168.99.1
The authenticity of host '192.168.99.1 (192.168.99.1)' can't be established.
RSA key fingerprint is SHA256:............................................
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.99.1' (RSA) to the list of known hosts.
root@192.168.99.1's password:


BusyBox v1.22.1 (2017-03-10 15:06:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

        ____      _____
       |  _ \    |_   _|__  __ _ _ __ ___
       | | | |_____| |/ _ \/ _` | '_ ` _ \
       | |_| |_____| |  __/ (_| | | | | | |
       |____/      |_|\___|\__,_|_| |_| |_|

 -----------------------------------------------------
 From BARRIER BREAKER (3.2.1.5900, r39558)
 -----------------------------------------------------
  * By D-Team 2015 present
 -----------------------------------------------------
root@newifi:~#

WTF，就这么简单！

顺便附上我写的简单客户端：

from requestsutils import RequestsBase

class NeWifi(RequestsBase):
  baseurl = 'http://192.168.99.1/'
  token = '00000000000000000000000000000000'

  def api_request(self, cat, name, args={}):
    req = {"jsonrpc":"2.0","id":1,"method":"call","params":[self.token,cat,name,args]}
    ans = self.request('/ubus/', json=req).json()
    return ans['result'][1]

  def login(self, password):
    password = base64.b64encode(password.encode('utf-8')).decode('ascii')
    ans = self.api_request("session","xapi_login",{"username":"root","password":password})
    self.token = ans['ubus_rpc_session']

  def get_wan_info(self):
    return self.api_request('xapi.net', 'get_wan_info')

requestsutils 在此。

吶，昨天说到VPS被报告有攻击行为，后来异常流量被逮到了，经过追查，真相大白。

前天（还是前天，因为又过了一天）分析了异常流量的时间分布之后，发现该流量从上午9点多开始，一直持续。于是我又 netstat -npt 了一下，看到了大量对各网络公司IP 80端口的连接。它还在呢！其实我早该 htop 瞅一眼的说。

发现三四个「php /tmp/tmp」进程，每个进程有大量连接。试图通过 /proc/PID/fd 取得它打开的文件失败，因为都是空的……然后，为了中止攻击，我停了 php-fpm 服务，杀掉了所有 php 进程。杀完才后悔，我连它是哪个用户跑的都没看呢 -_-||| 心急就忘记了应该发 SIGSTOP 信号的。

时间上与任何 cron job 都不匹配。不过我还是检查了可能的 PHP 脚本任务，并没有发现异常。这时 VPS 的主人 Edison 说，是不是 WordPress 的锅？于是他去扫描了一下 WordPress。这个 WordPress 是数年前 Edison 手工部署的，后来并没有怎么用。并不是通过软件仓库安装，所以 dpkg 没有检查出异常，也因此没有任何更新，年久失修。结果检查出来好多个后门。

这些后门都是在 PHP 脚本里加一两句话，对某个特定的 POST 参数进行求值（eval）。简单有效的后门呢。也难怪我怎么都没有找到恶意程序，原来是直接从网络提交过来的，通过 php-fpm fork 了进程出来。

嗯，就是这样。并没有多么神秘，也没能拿到攻击脚本。这件事充分地说明了我坚持不使用 WordPress 是个无比正确的决定 :-)

其实呢，这种攻击对于 Linux 来说是很奇怪的。就像作为 Python 使用者，SQL 注入对我来说是很奇怪的一样。最不安全的也并不是 PHP，而是 WordPress，核心逻辑上的漏洞不补，再怎么从细枝末节上修补也是软弱无力的。

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊？

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊？

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊？

嗯，重要的事情要说三遍。现在互联网越来越险恶，竟然还有著名软件项目不知道 W^X 这个常识我也是醉了……

一点安全常识，给不懂的人：

• 任何时候，尽力做到权限最小化（不要学360拿 suid 跑 GUI）
• Web 网站，用户可写目录一定不能被执行，能够执行的目录执行者一定不能有写权限（你看我的 MediaWiki 曾经暴露在外网那么久也只是招来了一些 spam，从来没人能远程执行代码）
• 尽量使用发行版提供的软件包，及时更新，特别是对于没有充分时间关注和维护的东西

还有，我还挺想念 systemd 的，直接 systemctl status 就能知道进程属于哪个服务了。而且可以几行配置就把不需要的权限干掉～

刚刚遇到一件很囧的事情：我在 /run/user/1000/cache 挂载了我的 SSD，用作火狐和 neocomplete 的缓存。/run/user/1000 这个目录是 systemd 为用户创建的，用来放那些只在运行时有用的文件，比如 pid 文件啦、套接字啦之类的。把挂载点放这里，很显然可以避免为其在磁盘上创建目录，又不必和 /tmp 里的一堆临时文件混在一起。

然而这一次，出大事了！我的火狐启动不了了！我的 Vim 也报了一堆错！细看下来，发现 /run/user/1000/cache 没了……

因为需要 root 权限，/run/user/1000/cache 是在 /etc/rc.local 里挂载的。这一次，它抢先挂载了 /run/user/1000/cache，然后我登录，systemd 帮我挂载了 /run/user/1000。就是下边这个样子：

├─/run                           run        tmpfs          rw,nosuid,nodev,relatime,mode=755                                                shared
│ ├─/run/user/1000/cache         test       zfs            rw,xattr,posixacl                                                                shared
│ └─/run/user/1000               tmpfs      tmpfs          rw,nosuid,nodev,relatime,size=804780k,mode=700,uid=1000,gid=1000                 shared
│   └─/run/user/1000/gvfs        gvfsd-fuse fuse.gvfsd-fus rw,nosuid,nodev,relatime,user_id=1000,group_id=1000                              shared

WTF！这样我就访问不到它了呀！我一开始还以为我的 SSD 又出什么状况了呢，结果是这样，挂载上了，但是访问不到……而因为访问不到，所以也没法卸载……

当然啦，我可以先把 /run/user/1000 和下边的那个 gvfs 给卸载掉。但那样做，我不确定 systemd、PulseAudio、D-Bus 它们会有多生气。bind mount 也尝试了，然而并没有什么用。它只能用来访问被挂载点掩蔽的文件，访问不到被挂载点掩蔽的挂载点。

然后我想到了之前玩过的网络命名空间。当然这次需要的是之前没仔细探索的挂载命名空间了。

直接 sudo unshare -m 进去，findmnt -o+PROPAGATION 发现全部都是 private 的，也就是 umount 了不影响外边。于是我就可以把 /run/user/1000 这个树卸载掉啦。然后 mount --make-shared /run/user/1000/cache 把它变成 shared 状态，再卸载，应该就可以把外边那个也卸载掉了吧？

No。失败了。研究了半天 unshare、mount_namespace 的文档之后确认，把 private 的挂载点变成 shared 之后，会创建一个新的「共享组」，而只有在同一个「共享组」里的挂载点才会相互传播。所以，unshare 你别把我的挂载点都变成 private 了好么？

文档下翻，它还真有这么个选项：

sudo unshare -m --propagation shared

然后里外执行这条命令，确认一下「shared:」后边那个数字是一致的：

# cat /proc/self/mountinfo | grep zfs
282 281 0:47 / /run/user/1000/cache rw shared:137 - zfs test rw,xattr,posixacl

没问题了。先 mount --make-private /run/user/1000 等把它们变成私有的，卸载掉，再把 /run/user/1000/cache 给卸载掉。来外边一看，果然被卸载掉啦～

（然后我还是为其在磁盘上专门建立个目录防止出问题好了。zfs，不知道怎么写 systemd 的 .mount 文件。）

鼠标中键，就是左键和右键之间的那个键啦。常见的鼠标上它在滚轮上。所以你知道了，滚轮是可以往下按的哦。如果是触摸板并且没有中键的话，可以配置双指点击来作为中键使用的（synclient ClickFinger2=3）。

中键具有以下好用的功能哦～（括号里是适用的场景）

• 粘贴选择区，不用按复制和粘贴的快捷键了～不过选择区的寿命通常比较短，只适合快速的粘贴操作。另见 X Window 中的剪贴板一文。（Linux 桌面、macOS 终端、gpm）
• 在后台新标签页打开链接（火狐、Google Chrome 等浏览器都支持）
• 关闭标签页（基本上也是用于网页浏览器。我自己的 GVim 也支持）
• 定位滚动条，可以快速地定位到开头、结尾，或者之前的位置。不需要拖来拖去的麻烦。可惜 GTK 3 里这个功能不好用的了。（GTK 2、Qt）
• 移动画布（GIMP、Inkscape 等作图软件、GNOME 的文档查看器 Evince）

这只是比较通用的功能。我的 Awesome 还配置了使用中键关闭窗口呢（「关闭标签页」语义的扩展）。火狐的一些菜单项也支持中键点击，比如书签菜单，右键的「查看图像」菜单，比如前进/后退按钮，以及在它上边点击右键出来的历史记录项目。

总结一下中键的语义：

• 在可以粘贴的地方，粘贴
• 在打开对象时，打开新对象而不取代已有者
• 在打开的对象本身上时，关闭之
• 在可定位对象上，移动之

我在用 offlineimap。用着用着就发现一个问题：偶尔 offlineimap 会卡在网络上不动弹了。跟 getmail 一个德性……

但是 offlineimap 又跟 getmail 有点不一样，它是持续运行着的。虽然非要把之前那个 killhung 程序拿来用不是不可以，但我还是重新弄了一个更优雅的方案：systemd watchdog。

我的 offlineimap 本来就是用 systemd 服务的方式来跑的，所以很适合这样的改造呢。只是，当我瞅了一眼源码之后，我就放弃了 patch offlineimap 的打算。很难在合适的地方添加 watchdog 相关的代码。

既然从内部着手不好做，那就从外部写一个 wrapper 好了，反正 offlineimap 跟 getmail 不一样，正常情况下一直在输出东西，就把这个作为它的「心跳」特征好了。当然这个 wrapper 还可以给其它程序用。

于是，watchoutput 程序诞生了！稍微改一下 offlineimap 的 .service 文件，像这样子就好了：

[Unit]
Description=Offlineimap Service

[Service]
Type=notify
ExecStart=.../watchoutput /usr/bin/offlineimap
TimeoutStopSec=3s
SyslogIdentifier=offlineimap
Restart=on-failure
WatchdogSec=70
LimitCORE=0

[Install]
WantedBy=default.target

加上LimitCORE=0是为了阻止重启的时候由于 SIGABRT 信号导致 coredump，浪费磁盘空间。

用了几天之后，终于观察到一次由 watchdog 触发的重启：

12月 19 12:26:53 lilywork offlineimap[21623]:  Establishing connection to imap.exmail.qq.com:993 (main-remote)
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Watchdog timeout (limit 1min 10s)!
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Killing process 21623 (python3) with signal SIGABRT.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Killing process 21625 (offlineimap) with signal SIGABRT.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Main process exited, code=dumped, status=6/ABRT
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Unit entered failed state.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Failed with result 'core-dump'.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Service hold-off time over, scheduling restart.
12月 19 12:28:03 lilywork systemd[687]: Stopped Offlineimap Service.
12月 19 12:28:03 lilywork systemd[687]: Starting Offlineimap Service...
12月 19 12:28:04 lilywork systemd[687]: Started Offlineimap Service.

没过几天，我又给这个 watchoutput 的脚本找到另外的用处：自动重启网络。

我家里的笔记本连 Wi-Fi 不知怎么，这些天经常会卡住（只发不收，一直处于 ARP 找网关的状态）。内核之前报过一次错，现在也没反应了。

于是：

[Unit]
Description=Watch for network availability

[Service]
Type=notify
ExecStart=.../watchoutput --retry-on-exit 2 --wait-before-retry 30 --ignore-stderr \
    -- ping -i 30 192.168.1.1
Restart=on-failure
WatchdogSec=70
StandardOutput=null
StandardError=journal
LimitCORE=0
SyslogIdentifier=watch-network

[Install]
WantedBy=default.target

拿 watchoutput 监控 ping 网关的输出，每30秒 ping 一次，如果70秒还没反应就重启它自己。然后我们还需要重新连接网络。在 /etc/systemd/system 下建立 netctl-auto@wlan0.service.d 目录，并在其下建立一个 watchdog.conf 文件，给 netctl-auto@wlan0.service 服务增加一项配置：

[Unit]
PartOf=watch-network.service

这样当 watch-network.service 重启的时候，netctl-auto@wlan0.service 就会自动重启了～

要说哪个 shell 最复杂难学，我肯定回答 zsh。而要说哪个 shell bug 最多，毫无疑问是 bash 了。shellshock 这种大家都知道的我就不说了。bash 有很多很诡异的角落，昨天我亲身碰到一个。

我有一个 Python 程序 A，会使用 subprocess 带 shell=True 跑一行 shell 命令。那条命令会在后台跑另外一个 Python 程序 B。诡异的事情是，当我向 B 的进程发送 SIGINT 时，无法结束它，以及它下边带的一个 tail 进程。一开始我还没注意到 B 的进程本身没有被 SIGINT 杀死，是在无效的情况下被 A 用 SIGKILL 杀死的。我只看到那个 tail 程序还活着。所以我去处理了一下 KeyboardInterrupted 异常，来结束掉那个 tail。

结果很诡异：KeyboardInterrupted 异常并没有发生。通过 strace 观察可以看到，B 进程在读 tail 的输出，然后收到了 SIGINT，然后接着读 tail 的输出……我一开始还以为这个和 PEP 475 相关，以为是 Python 自动重启了被中断的系统调用，所以没来得及处理信号（Python 的信号并不是及时处理的）。然后就去仔细看文档。结果文档告诉我，如果注册了信号处理函数，并且它抛出异常的话，那么被中断的系统调用是不会被重试的。所以这就不对了。

然后我又测试了直接在终端运行 B，而不是通过 A 去运行。本来我开发的时候就是这么测试它的，也没遇到什么怪异的现象。结果确实没有什么怪异的事情发生：即使我使用 kill 命令只给 B 发送 SIGINT 信号，Python 的 KeyboardInterrupted 逻辑会被触发，然后它主动杀掉 tail 进程。（使用 Ctrl-C 的话，B 和 tail 都会收到 SIGINT 信号的。）

疑惑的时候，我又想到了拿 SIGINT 去杀那个不死的 tail 进程，这才发现它也出现奇怪的行为了：正在读 inotify 的文件描述符呢，来了个 SIGINT 信号，然后它接着读 inotify 去了……跟 B 出现的问题一样。我又去查了 tail.c 的源码，也没发现它对 SIGINT 有特殊的处理啊。

难道是继承过来的？man 7 signal 了一下，果然：

During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.

所以 tail 和 B 继承了一个「忽略 SIGINT」的行为。（nohup 就是用的类似的手段啊。）

于是 strace -f 了整个从 A 开始的进程树，最后发现这问题和 Python 并没有什么关系，而是 bash 的错！

A 是用 shell=True 调用的命令，所以它调用了 /bin/sh。系统是 CentOS，所以 /bin/sh 是指向 bash 的。所以这里实际上调用了 bash，而它的处理有问题。

要重现这个 bug 很容易：

bash -c 'sleep 1000 &'

然后这个 sleep 进程就会忽略 SIGINT 和 SIGQUIT 了。我也不明白 bash 这是想要做什么。

之前也遇到过另外几个 bash 的 bug（或者是 feature？）——

1. 在终端中，在脚本中执行交互式 bash 时，第一个 bash 进程会将自己设为前台进程组，导致后来的进程收到 SIGTTIN 或者 SIGTTOU。很神奇，两行同样的命令，第一条和后边的行为不一致。

2. 在 bash 中，执行不带 shebang 的 shell 脚本时，脚本会在当前 bash 进程内执行，造成 history 命令的行为异常。

3. 这个是听说的。输出失败时，未写入目标的内容仍留在缓冲区内，会在奇怪的地方冒出来。

以后还是尽量避开 bash 吧。有 zsh 用 zsh，有 dash 用 dash；它们都没有本文提到的这些问题。

首先看看你的网卡和驱动组合是否支持这样的操作。

>>> iw list | grep -A2 combinations:
        valid interface combinations:
                 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
                   total <= 3, #channels <= 2

上边这个输出说明支持，并且频道可以不一样。

然后，添加一个用途 AP 的网络接口，并配置 IP 地址。我的无线网络接口名字是 wlan0，因为我通过创建空 /etc/udev/rules.d/80-net-setup-link.rules 文件的方式禁用了 systemd 的网络接口改名。

sudo iw dev wlan0 interface add wlan0_ap type __ap
sudo ifconfig wlan0_ap 192.168.17.1

配置 NAT：

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo iptables -w -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADE

配置 DHCP。我用的是 dnsmasq。它本来是作为 DNS 缓存用的，但是也支持 DHCP，那就用它了：

interface=wlan0_ap
no-dhcp-interface=wlan0
dhcp-range=192.168.17.50,192.168.17.150,12h

注意不要在其它只提供 DNS 服务的接口上提供 DHCP 服务，以免出现冲突。

然后就可以开启热点啦。hostapd 配置如下：

interface=wlan0_ap
driver=nl80211
ssid=名字
channel=1
hw_mode=g
ieee80211d=1
country_code=cn
ieee80211n=1
ieee80211h=1
ignore_broadcast_ssid=0
auth_algs=1
wpa=2
wpa_passphrase=secret
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

最后把它们跑起来就可以了。

为了方便使用，我创建了个 systemd 服务 wlan0_ap.service：

[Unit]
Description=Setup wlan0_ap
Before=hostapd.service
After=sys-subsystem-net-devices-wlan0.device
After=iptables.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/iw dev wlan0 interface add wlan0_ap type __ap
ExecStart=/usr/bin/ip address add dev wlan0_ap 192.168.17.1/24
ExecStart=/usr/bin/iptables -w -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADE
ExecStop=-/usr/bin/iptables -w -t nat -D POSTROUTING -s 192.168.17.0/24 -j MASQUERADE
ExecStop=/usr/bin/ip address delete dev wlan0_ap 192.168.17.1/24
ExecStop=/usr/bin/iw dev wlan0_ap del

[Install]
WantedBy=hostapd.service

systemctl enable wlan0_ap 之后就可以直接 systemctl start hostapd 来启动了～当然也很容易停止服务：systemctl stop hostapd wlan0_ap。我的 dnsmasq 总是开启的，所以就不用加依赖了。还有 ipv4_forward 我也是早就写到配置文件 /etc/sysctl.d/99-sysctl.conf 里的。