依云'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 包。

新家新路由器。

为了玩 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 在此。

最近 #archlinux-cn 又流行玩 teeworlds 了，然而我却连不上那个服务器。

情况很奇怪。我能 ping 通服务器 IP，TCP 连接也正常，UDP traceroute 也表现得很正常（对关闭端口能够完成，对开放端口会在最后一跳开始得到一堆星号），并且我连接的时候，服务器能看到我在连接。也就是说，TCP 和 ICMP 都正常，UDP 上行正常，下行出了状况。

难道是有防火墙？首先呢，我能连接其它服务器，说明我这边没有问题；大部分人能连接上服务器，说明服务器那边也没有问题。所以，问题出在路上。也确实有另外的北京联通用户连不上这个服务器。但是很奇怪啊，为什么单单只是这一个 IP 的 UDP 包丢失了呢？

于是继续试验。从最简单的开始，用 netcat / socat 尝试通讯。方向反过来，我监听，服务器那边连接。端口是我在路由器上做过端口映射的。结果是正常的。再来，服务器那边监听，我往那边发，果然我就收不到包了。按理说，UDP 双方是对等的，不应该换了个方向就出问题呀。难道是因为端口映射？Wireshark 抓包看到本地使用的端口号之后，在路由器上映射一下，果然就通了！

然后，我注意到了一件十分诡异的事情：虽然我和服务器能够通讯了，但是我的 Wireshark 上只显示了我发出去的包，却看不到回来的包！我抓包时按服务器 IP 做了过滤，所以，回来的包的源 IP 不是服务器的地址！

重新抓包一看，果然。服务器 IP 是 202.118.17.142，但是回来的包的源 IP 变成了 121.22.88.41……看起来这是联通的设备，在下行 traceroute 时能够看到有节点与它 IP 相似（121.22.88.1）。原来又是这著名的「联不通」又干坏事了 -_-|||

虽然 socat 接收 UDP 时不介意源 IP 变化了，但是 teeworlds 介意啊。并且 NAT 那边也会不知所措。所以，首先得告诉路由器把来自这个 IP 的 UDP 包全部扔给我：

ssh 192.168.1.1 iptables -I FORWARD -i ppp0.2 -p udp -s 121.22.88.41 -j ACCEPT

于是数据包有了。接下来是修正源 IP。我试过 SNAT，无效。这东西似乎只对本地发出的包有用？于是我又用 netfilter_queue 了。这东西很强大呢～一个简单的 Python 脚本搞定：

#!/usr/bin/env python3

from netfilterqueue import NetfilterQueue
from scapy.all import *

def main(pkt):
  p = IP(pkt.get_payload())
  # print('recv', p)
  p.src = '202.118.17.142'
  p.chksum = None
  p[UDP].chksum = None
  pkt.set_payload(bytes(p))
  # print('fixed to', p)
  print('.', flush=True, end='')
  pkt.accept()

conf.color_theme = DefaultTheme()
nfqueue = NetfilterQueue()
nfqueue.bind(1, main)
try:
  nfqueue.run()
except KeyboardInterrupt:
  pass

然后是 iptables 命令：

sudo iptables -I INPUT -s 121.22.88.41 -p udp -j NFQUEUE --queue-num 1 --queue-bypass

scapy 这个神奇的网络库在 Arch 官方源里叫「scapy3k」。Python 的 netfilterqueue 模块需要用我自己修改过的这个版本。

2017年7月30日更新：Python 的依赖有点麻烦，所以我又写了个 Rust 版本，放在 GitHub 上了。

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

>>> 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 里的。

创建并配置一个新的网络命名空间

公司 VPN 用的网段是 192.168.1.0/24，而我家里的网络，就像大多数人的一样，也是 192.168.1.0/24。网段冲突了。当然啦，隔离得相当好的 lxc 可以解决这个问题。可是它隔离得太好了，我可不想再多维护一套环境。那么，就只隔离网络好了！

正好之前看到 iproute2 套件可以管理网络命名空间。那么，就用它啦。

首先，创建一个名为 vpn 的网络命名空间：

ip netns add vpn

现在如果进去看的话，会发现里边只有一个孤零零的 lo 网络接口，所以里边是一片与世隔绝的黑暗。我没有其它的网络接口给它用。桥接当然是可以尝试的，只是需要更改已有的网络配置。所以还是用另外的方案吧。弄根网线来，把里边和外边连接起来好了。

创建一对 veth 接口。这就是我们的「网线」～

ip link add vpn0 type veth peer name vpn1

一端留外边，另一端移到 vpn 里边去：

ip link set vpn1 netns vpn

接好网线的两端：

ip link set vpn0 up
ip netns exec vpn ip link set vpn1 up

好了，现在两个网络之间可以通信了～当然，只是链路层。为了使用 TCP/IP，我们得分配 IP 地址。在外边的这个就不需要 IP 地址了，因为我要把它接到一个网桥上，网桥自己有 IP 的。

brctl addif br0 vpn0

这里 br0 是我已有的网桥（给 lxc 用的那个）。如果你没有的话，就自己按以下方法弄一个。我用的是 bridge-utils 里的 brctl 命令。iproute2 也可以做的。

brctl addbr br0
ifconfig br0 192.168.57.1
iptables -t nat -A POSTROUTING -s 192.168.57.1/24 -j MASQUERADE

最后的 iptables 命令是做 NAT 啦。当然内核的 IPv4 转发功能还要开启的。

vpn0 这端弄好了，再给 vpn1 分配 IP，并设置相关路由表项：

ip netns exec vpn ip address add dev vpn1 192.168.57.101/24
ip netns exec vpn ip route add default via 192.168.57.1

现在就可以在里边连 VPN 啦～

ip netns exec vpn openvpn ...

当然也可以去里边开个 zsh 用

ip netns exec vpn zsh

不过要注意如果跑 GUI，或者连接 D-Bus 的话，需要手动把相关环境变量移进去。虽然是独立的网络命名空间，但是因为共享了文件系统，所以虽然看不到在监听的 UNIX 套接字，但是连起来还是没有问题的。X 和 D-Bus 都可以良好工作的。

export DISPLAY=:0 LANG=zh_CN.UTF-8 LANGUAGE=zh_CN:zh_TW
export GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
# 如果在 tmux 里的话
export TMUX=1

再加上 mount 命名空间吧

我这里在里边得用 IP 地址，因为我的 DNS 是 127.0.0.1，在里边当然是用不了的。怎么办呢？我不想改 DNS 服务器地址，因为里外的文件系统是共享的。那就再加上 mount 命名空间吧，这样就可以 bind mount 一个修改过的文件到 /etc/resolv.conf 上了。

其实呢，ip netns 是通过把网络命名空间（/proc/<pid>/ns/net）bind mount 到文件来实现命名空间的持久化的（不然使用这个命名空间的进程都退出，该命名空间就销毁了）。其文件位于 /run/netns 下。对于 mount 命名空间我们可以手工这么做：

mkdir -p /var/run/ns
mount --bind /var/run/ns /var/run/ns
# 命名空间只能 bind mount 到 private 挂载的文件系统上
mount --make-private /var/run/ns
# 随意找个普通文件就行。一般是用空文件；我这样可以省一个文件～
cp /etc/resolv.conf /var/run/ns

然后用 unshare 建立新的 mount 命名空间，并进入之前的 vpn 网络命名空间（当然用 nsenter 进入也是可以的）：

unshare --mount=/var/run/ns/resolv.conf ip netns exec vpn zsh

创建了之后就可以用 nsenter 进去玩儿了：

nsenter --mount=/var/run/ns/resolv.conf --net=/var/run/netns/vpn zsh

可以在里边各种 bind mount，不会影响外边的哦：

# 在新的命名空间里边
mount --bind /var/run/ns/resolv.conf /etc/resolv.conf
vim /etc/resolv.conf

组合更多的命名空间

当然也可以组合更多种的命名空间的。我还试过 pid 命名空间，不过 pid 命名空间比较特殊：它在 fork 后才生效，当 init 进程（pid=1 的进程）退出之后所有位于此 pid 命名空间的进程都会被杀死，并且再也进不去了。所以不是很好玩的啦。

创建与进入的命令如下：

unshare --mount-proc -f --pid=/var/run/ns/pid --mount=/var/run/ns/resolv.conf nsenter --net=/var/run/netns/vpn su - lilydjwg
# 进入时用 -t 选项，或者重新 bind mount 文件（不然新进程会在原 pid 命名空间）
nsenter -t 9416 --mount=/var/run/mountns/resolv.conf --net=/var/run/netns/vpn --pid su - lilydjwg

后记

除了可能偶尔连接公司 VPN 会用到这个技术之外，我又给其找到了一个更好的使用场合：Wine QQ！于是本地的 nginx 日志里终于不会再有 /srv/http/cgi/reccom 找不到的提示了，CGI 服务也不会被不必要地启动了。

2016年5月13日更新：把自用的脚本放在 Gist 上了。

2015年9月13日，我的博客流量突然少了很多：

因为博客突然被百度标记为「安全联盟提醒您：该页面可能已被非法篡改！」（后边那个峰的流量来源于知乎，与此事件并无关联。）

然而我一直未发现任何异常。我使用了 Google 站长工具，Google 也没说有任何异常。所以我以为这不过是百度又发了什么神经。毕竟它也说，「有一个网友举报」。「安全联盟」那里可以申请解封，但是需要出卖手机号等隐私。更神奇的是，它要求你修正问题，却连是什么问题都不清楚。「安全联盟」的客服表示，这事他们也不清楚。

然而几天前，又有网友报告我的博客跳转到了奇怪的页面。第一次有人报告时我只当用户系统或者网络的问题，虽然我也疑惑，恶意软件或者 ISP 插广告不至于插 CJB 的广告啊。但是对方并没有能力来调查此事。这次总算是遇到了一个会抓包的读者了。于是让报告者 @xuboying 帮忙抓包，这才真相大白。

简单地说，确实有页面在传输过程中被篡改了。至于是不是非法的，就得问「有关部门」了。

事情是这个样子的：我有一篇文章嵌入了 GitHub Gist。而 GitHub Gist 的域名 gist.github.com 被污染，其中一个污染 IP 为 216.234.179.13。这大概是 CJB 的源服务器地址。

本来呢，嵌入 GitHub Gist 的代码是这样子：

<script src="https://gist.github.com/lilydjwg/0bfa6807b88e6d39a995.js"></script>

当解析到 216.234.179.13 之后，最奇妙的事情发生了：

1. CJB 使用了自签名、过期、弱密钥的证书。火狐会嫌它太弱而不可覆盖地拒绝，其它主流浏览器也会因为证书问题而报错。小米浏览器会询问用户是否接受有问题的证书（普通用户哪里懂这个啊，估计大都会选择接受吧）。一旦接受，则进入下一步。
2. 该服务器在访问时会返回一句复合了 HTML 和 JavaScript 的脚本，修改window.location到 CJB 的主页。而引入 GitHub Gist 的方式恰好是 JavaScript 脚本，于是它得到执行，跳转到 CJB 主页去了……（不过现在只会返回空白页了。）

后来百度取消了那个「被非法篡改」的提示，不过权重依然很低，不注意看根本找不到我博客唉。

知道是 GitHub gist 的原因之后就可以很快找到遇到同样问题的人了，比如：

• 【吐槽】gist.github.com疑遭中间人攻击 - ahdung - 博客园
• 部分网站跳转CJB问题求教.................._firefox吧_百度贴吧
• 为什么访问 XDA 总被跳转至 cjb.net？ - V2EX

人们对 TCP 的误解

因为我们的教育总是只教人「怎么做」，而根本不管「为什么这么做」，所以造成了很多误解。

今天（恰巧是今天）看到有人在 SegmentFault 上问「TCP server 为什么一个端口可以建立多个连接？」。提问者认为 client 端就不能使用相同的本地端口了。理论上来说，确定一条链路，只要五元组（源IP、源端口号、目标IP、目标端口号、协议）唯一就可以了，所以这不应该是技术限制。而实际上，Linux 3.9 之后确实可以让客户端使用相同的地址来连接不同的目标，只不过要提前跟内核说好而已。

当然，你不能使用同一个 socket，不然调用connect连接的时候会报错：

[Errno 106] (EISCONN) Transport endpoint is already connected

man 2 connect里说了：

Generally, connection-based protocol sockets may successfully connect() only once; connectionless protocol sockets may use connect() multiple times to change their association.

想也是，一个 socket 连接到多个目标，那发送的时候到底发给谁呢？TCP 又不像 UDP 那样无状态的，以前做过什么根本不管。

那用多个 socket 就可以了嘛。服务端其实也一直是用多个 socket 来处理多个连接的不是么，每次accept都生成个新的 socket。

>>> import socket
>>> s = socket.socket()
# since Linux 3.9, 见 man 7 socket
>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
>>> s2 = socket.socket()
>>> s2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
>>> s.bind(('127.0.0.1', 12345))
>>> s2.bind(('127.0.0.1', 12345))
# 都可以使用同一本地地址来连接哦
>>> s.connect(('127.0.0.1', 80))
>>> s2.connect(('127.0.0.1', 4321))

连上去之后 netstat 的输出（4568 进程是上边这个程序，另两个进程一个是 nginx，另一个是我的另一个 Python 程序）：

>>> netstat -npt | grep 12345
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.1:4321          127.0.0.1:12345         ESTABLISHED 18284/python3
tcp        0      0 127.0.0.1:12345         127.0.0.1:4321          ESTABLISHED 4568/python3
tcp        0      0 127.0.0.1:80            127.0.0.1:12345         ESTABLISHED -
tcp        0      0 127.0.0.1:12345         127.0.0.1:80            ESTABLISHED 4568/python3

当然你要是连接相同的地址会报错的：

OSError: [Errno 99] Cannot assign requested address

那个五元组已经被占用啦。

同时创建连接：恰巧你也在这里

有时候，我们不能一个劲地等待。主动出击也是可以的，即便对方并没有在等待。

这个在 TCP 里叫「simultaneous open」，用于 TCP 打洞。但是比起 UDP 打洞难多了，因为那个「simultaneous」字眼：必须同时调用connect，双方的 SYN 包要交叉，早了或者晚了都是会被拒绝的。

所以手工就办不到啦，在本地测试也不容易办到。我本地的系统时间是使用 NTP 同步的，再用一个时钟也和 NTP 同步的 VPS 就可以啦，我这里延迟 80ms 左右，足够那两个 SYN 「在空中会面」了。以下是代码：

#!/usr/bin/env python3

import time
import sys
import socket
import datetime

def wait_until(t):
  deadline = t.timestamp()
  to_wait = deadline - time.time()
  time.sleep(to_wait)

s = socket.socket()
s.bind(('', 1314))

if sys.argv[1] == 'local':
  ip = 'VPS 的地址'
else:
  ip = '我的地址'

t = datetime.datetime(2015, 8, 19, 22, 14, 30)
wait_until(t)
s.connect((ip, 1314))

s.send(b'I love you.')
print(s.recv(1024))

当然，我是公网 IP。在内网里包就不容易进来啦。

然后双方在约定的时间之前跑起来即可，结果是这样子的：

# 本地
>>> python3 t.py local
b'I love you.'

# VPS 上
>>> python3 t.py remote
b'I love you.'

一个人也可以建立 TCP 连接呢

如果你没有 VPS，或者没有公网 IP，也是有活动可以参与的哦。即使只有一个 socket，也可以自己连接到自己的：

>>> import socket                                                               
>>> s = socket.socket()
>>> s.bind(('127.0.0.1', 1314))
>>> s.connect(('127.0.0.1', 1314))
>>> s.send(b'I love you.')
11
>>> s.recv(1024)
b'I love you.'

netstat 输出：

>>> netstat -npt | grep 1314
tcp        0      0 127.0.0.1:1314          127.0.0.1:1314          ESTABLISHED 8050/python  

（失眠了，干脆起来写文。）

调试时经常会有抓包的需求。通常，我在本地用图形界面的 Wireshark 来抓包及解析，而对于远程服务器，因为没有图形界面，只好使用 tcpdump 抓包到文件然后复制到本地拿 Wireshark 看了，这样就不能实时查看抓到的包了。当然 tcpdump 也可以实时输出，但是信息太少、难以阅读，功能也过于简单，比如我要跟踪流啊、不同的流用不同的颜色高亮啊、添加注释啊、时序分析啊，tcpdump 完全没办法做到。实际上复杂一点的协议解析它都做不到。

一直没去研究 Wireshark 如何从标准输入读取网络包数据。大概是某天下意识地按了一下Alt-h看到了 Wireshaark 的 man 手册，才知道原来 Wireshark 支持这么多参数！图形界面的程序支持各种可选参数的可不多见。Wireshark 指定-i -就可以从标准输入读取数据，不过要同时指定-k，不然得在图形界面里点「Start」开始抓包。

那怎么把抓到的数据包发送到标准输出呢？实际的抓包操作不是 Wireshark 直接执行的。Wireshark 又不是 360，既然能以普通用户身份执行需要特权的操作，那么就会有一个无图形界面的工具来辅助。它就是 dumpcap。查阅其 man 手册可知，把抓到的数据输出到标准输出的选项是-w - -P（-P 指定使用 pcap 格式，不然会使用 pcap-ng 格式，Wireshark 不认）。还可以给定其它选项，比如只抓 lo 网络设备上的包用-i lo，或者指定一个过滤器如-f 'port 1234'（具体语法见pcap-filter的 man 手册）。一定要记住不要把传输抓包数据的数据包也抓到了哦～

比如：

ssh lxc-debian sudo dumpcap -P -w - -f "'not port 22'" | \
  wireshark -i - -k

这样就可以实时看到远程主机上的网络包了～通过 ssh 执行命令时引号得用双层的。使用 sudo 是因为我那个 Debian 的 dumpcap 没有特权。

有个需求，保存一个网页里的所有图片。

看上去是件简单的事情，拿火狐的 DownThemAll 扩展下载不就好了么。

然后发现那个网页仅限移动版访问。好吧，装个 UserAgent Switcher。然后发现它是通过 JavaScript 检测 UA 的，而 UserAgent Switcher 只改了 HTTP 头里的 UA。好吧，换个 muzuiget 的 User Agent Overrider。然后发现那些图片是动态加载的，DownThemAll 根本看不到地址。后来知道「查看网页信息」的「媒体」选项卡里也是可以保存图片的，不过那里显示的图片也不全……

于是我怒了，放弃继续尝试不同的工具，决定用程序员的方式来解决问题。

我管你怎么加载的，你总归是要从网络上下载图片不是么？那我就拿个代理把你访问过的所有图片全部保存下来好了 :-)

打开 mitmproxy 文档页，发现并没有现成的保存文件的功能。但是没关系，可以写脚本。看看示例，迅速写了以下不到二十行代码：

#!/usr/bin/mitmdump -s

from __future__ import print_function

import os
from urlparse import urlsplit

from libmproxy.protocol.http import decoded

def response(context, flow):
  with decoded(flow.response):
    if flow.response.headers['Content-Type'][0].startswith('image/'):
      url = urlsplit(flow.request.url)
      name = os.path.basename(url.path)
      with open(name, 'wb') as f:
        f.write(flow.response.content)
      print(name, 'written')

当然这是最终结果。不过和初版差别不大，毕竟就这么点儿代码。思路也很简单，凡是经过代理的图片都存起来。有点粗暴，但是好用。

代理脚本跑起来。然后启动一个全新的 Google Chrome，一个没有任何缓存存在的实例：

google-chrome-stable --proxy-server=http://localhost:8080 --user-data-dir=new

访问目标页面，启用移动版模拟并刷新，就可以看到各种图片都被保存下来了～～

UDP 套接字是可以使用 connect 系统调用连接到指定的地址的。从此以后，这个套接字只会接收来自这个地址的数据，而且可以使用 send 系统调用直接发数据而不用指定地址。可以再次调用 connect 来连接到别的地方。但是在 Python 里，一旦调用 connect 之后，就再也回不到最初的能够接收从任意地址来的数据的状态了！

这是 Python 的 API 限制，没办法给 connect 方法传递到 AF_UNSPEC 地址簇（在 C 代码里写死了的）。C 里边就可以做到的（代码来自这里）：

int disconnect_udp_sock(int fd) {
 struct sockaddr_in sin;        

 memset((char *)&sin, 0, sizeof(sin));
 sin.sin_family = AF_UNSPEC;
 return (connect(fd, (struct sockaddr *)&sin, sizeof(sin)));
}

不过既然是 Python 的限制，拿 ctypes 就可以绕过了嘛，有些麻烦就是了：

from ctypes import CDLL, create_string_buffer

def disconnect(sock):
  libc = CDLL("libc.so.6")
  buf = create_string_buffer(16) # sizeof struct sockaddr_in
  libc.connect(sock.fileno(), buf, 16)

AF_UNSPEC 的值是 0，所以把一个和 struct sockaddr_in 一样长的全零缓冲区传给 connect 就可以了 :-)