详细参考：
http://blog.csdn.net/ylyuanlu/article/details/7743409
http://stackoverflow.com/questions/13086766/how-to-filter-mac-addresses-using-tcpdump
嘛~一般抓包之后用wireshark看比较舒服，于是推荐结合wireshark使用。
tcpdump的用法比较简单（或者是我用的比较简单）
-i：抓某个指定接口的数据包（详细列表可以用tcpdump -D获得）
-w：输出到指定文件（方便使用wireshark查看内容）
然后的就是源地址，源端口，目标地址，目标端口等，这几个参数没有“-”，直接写，例如
tcpdump -i eth0 src 192.168.1.1 dst port 80
这样就会抓到来源是192.168.1.1，目标端口是80的数据包了。
mac地址的抓包要麻烦一些，暂时没研究通，上面给出的第二个连接是一篇国外的相关资料，看得懂的可以看看
嗯，表示从大概4月23号进去了，交易市场是btcchina（https://btcchina.com），看着价格从400多涨到现在的700，感觉都已经疯了，但是仔细想想……感觉还是会涨的样子……
暂时来说，还是留着吧……
其实这个东西很久以前就想搞的了，一直没动手，直到最近总在外面跑，有时候就考虑连回家里，于是稍微动了一下手。
选nginx是因为这个服务器够轻型，做前端最好了，而且做前端的话以前也做过，有经验。
上连接：
http://blog.csdn.net/kunoy/article/details/8239653
http://blog.csdn.net/jinhill/article/details/2573777
签证书什么的感觉略微有点麻烦了，于是果断的用了openvpn的easyrsa，这套脚本帮我很轻松的完成了证书的签署。主要用到了build-ca build-key-server build-key，根据名字就看出来了，生成ca证书，生成服务器证书，生成私有证书。这部分根据不用的系统，生成的证书在不同的位置，详情再自行Google之。我是在openwrt上做的，签好的证书在/etc/easyrsa/keys下。
如果真心想认真学习签证书的话还是去做多点的Google吧。
证书和密钥到手，这时候比较推荐导出一下客户端证书，使用以下命令
openssl pkcs12 -export -inkey client.key -in client.crt -CAfile ca.crt -chain -out client.pfx
就能得到一份可以导入的私有证书了。（暂时我只找到这种笨办法）
证书都准备好之后就是服务器的配置了。
先要处理一下openssl.conf，主要是这几行
dir = /etc/easy-rsa/keys # top dir database = $dir/index.txt # index file. new_certs_dir = $dir/newcerts # new certs dir certificate = $dir/ca.crt # The CA cert serial = $dir/serial # serial no file private_key = $dir/ca.key # CA private key RANDFILE = $dir/.rand # random number file countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = match localityName = optional commonName = supplied emailAddress = optional
上半部分是证书文件的位置，下半部分是认证哪些内容是相同，自己看着修改。
openssl弄好之后就是重头戏了，nginx本身的配置。
默认的配置文件里有https服务器的实例，参照着就能弄好一个认证服务器端证书的，只要稍微加上几行就能加上私有证书的认证了。
# HTTPS server
server {
listen 443;
server_name Router;
charset utf8;
ssl on;
ssl_certificate /etc/easy-rsa/keys/ferrets.imzone.in.crt;
ssl_certificate_key /etc/easy-rsa/keys/ferrets.imzone.in.key;
ssl_client_certificate /etc/easy-rsa/keys/ca.crt; #客户端证书认证所需要的ca证书
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_verify_client on; #启用客户端证书认证
location / {
proxy_pass ;
proxy_redirect default;
}
location /transmission {
proxy_pass ;
proxy_redirect default;
}
}嗯，像上面一样的配置文件我就是做的代理服务器，转发到192.168.1.1和192.168.1.1:9091，方便远程管理路由和transmission。
感觉一下子强力了好多啊。
参考：http://blog.chinaunix.net/uid-26960488-id-3227305.html
http://httpd.apache.org/docs/2.0/mod/mod_autoindex.html
今天在路由上装了个apache，因为硬件比以前的rg100a好太多了，想跑点强力点的web服务器，也算是练练手。
跑起来之后开了autoindex，一看，乱码了，这蛋疼得，换回去ie（ie切换字符编码略方便，Chrome简洁掉了），切换编码一看，用utf8好了。果然是编码的问题，于是上网搜，怎么才能使用特定的字符编码。一搜就出来了，可以在httpd.conf里面加上一个autoindex的选项来指定字符编码
IndexOptions Charset=UTF-8
参考：http://www.openwrt.org.cn/bbs/forum.php?mod=viewthread&tid=1456
最近在另外一台机器上开了一个pptp的VPN，于是重操旧业，折腾起pptp来。
但是有个很蛋疼得问题是，电脑不知为何连不上。同时，iPod使用同一个路由，但是iPod却能连上。
于是研究了半天，后来才知道这个。
后来是用tcpdump在路由上抓包，才发现了这个问题。
顺便贴上以下记录
从wan抓到的包
11:04:10.898392 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [S.], seq 450513921, ack 3307070933, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 1], length 0 11:04:10.900618 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [.], ack 157, win 3456, length 0 11:04:10.907780 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [P.], seq 1:157, ack 157, win 3456, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux) 11:04:10.911337 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [P.], seq 157:189, ack 325, win 3992, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(6016) PEER_CALL_ID(52009) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0) 11:04:10.936723 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 0, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:10.955328 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [.], ack 349, win 3992, length 0 11:04:13.956479 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:16.963507 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 2, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:19.972620 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 3, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:22.982073 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 4, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:25.990972 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 5, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:27.115016 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [.], ack 373, win 3992, length 0 11:04:28.999748 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 6, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:32.009025 IP 10.1.12.41 > 10.1.145.203: GREv1, call 52009, seq 7, length 37: LCP, Conf-Request (0x01), id 1, length 23 11:04:34.947339 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [.], ack 389, win 3992, length 0 11:04:34.947441 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [F.], seq 189, ack 389, win 3992, length 0 11:04:35.950801 IP 10.1.12.41.1723 > 10.1.145.203.50116: Flags [.], ack 390, win 3992, length 0
从lan抓到的包
11:08:17.425044 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [S.], seq 1960838183, ack 194080576, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 1], length 0 11:08:17.426306 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [.], ack 157, win 2920, length 0 11:08:17.437070 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [P.], seq 1:157, ack 157, win 2920, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux) 11:08:17.444973 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [P.], seq 157:189, ack 325, win 3456, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(1408)PEER_CALL_ID(22594) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0) 11:08:17.488828 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [.], ack 349, win 3456, length 0 11:08:17.494178 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [.], ack 373, win 3456, length 0 11:08:41.767662 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [.], ack 397, win 3456, length 0 11:08:41.880301 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [.], ack 413, win 3456, length 0 11:08:41.882110 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [F.], seq 189, ack 413, win 3456, length 0 11:08:42.871931 IP 10.1.14.156.1723 > 192.168.11.9.50131: Flags [.], ack 414, win 3456, length 0
发现有gre的包到了路由那里就没有转发过来了。于是上网查了一下：
解决办法是安装 kmod-gre kmod-ipt-conntrack-extra kmod-ipt-nat-extra iptables-mod-conntrack-extra
然后在防火墙中启用gre的转发
在iptables中打开gre的转发
之后就能连上了。
按照惯例，先上参考：
http://www.right.com.cn/forum/thread-46811-1-1.html
嗯，因为在学校的话有内部网络，而内部网络里面有自己的dns服务器，于是就出现了许多奇奇怪怪的域名（私有）
比如说*.ustb这种域名（不知这顶级域名被注册了没有，啧啧啧啧）
于是就出现问题了，这种失手，dnsmasq的转发有时候会有问题（已经设置了转发到本地dns服务器，但是总是对本地域名解析失败，不知为何）
今天就又出现了类似的问题，一怒之下，上网一搜，ok，出来了，恩山的神人真多。
方法就是在
网络-接口-LAN 页面的下半部
里面有dns的设定，切换到高级选项页，下面有个空“dhcp-选项”
在里面填入
6,dns1,dns2
可以将指定的dns服务器推送给客户端。
参数里面的“6”由
dnsmasq --help dhcp
得到。
原文链接：http://scarygliders.net/2010/02/23/hacking-around-the-japanese-buffalo-wzr-hp-g300n/
修复自己的AG300H的时候又查询到了这篇文章，觉得真的有必要翻译过来（翻译的不好希望不要见怪）。也方便一下国人，感觉国内关于buffalo的文章好少啊。
[题外话]乱入一张Philipp Klaus童鞋的AG300H的TTL针脚定义图（需要登上长城技能），这也让我好找一番，在Google翻了良久才找到这么一张，果然还是国外的友人折腾的东西多啊，不过又是因为在picasa网络相册，又要出塞一番才能得到想要的东西。顺便鄙视一下百度，全球最大的中文搜索引擎，对中文以外的东西就完全是个渣渣啊。
~~~~~~~~~~~~~~~~~~~~~~~~下面才是正文（大量节选）~~~~~~~~~~~~~~~~~~~~~~~~~~
blah blah blah blah （原文中真的好多废话，看来作者是个爱表达自己感情的人） 继续阅读
摘录自http://blog.csdn.net/wind19/article/details/4986458
原文中还提到了使用nohup的方法，不过我觉得还是screen比较方便，就剪掉了nohup的部分，想看的话点连接过去看。
开始使用Screen
简单来说，Screen是一个可以在多个进程之间多路复用一个物理终端的窗口管理器。Screen中有会话的概念，用户可以在一个screen会话 中创建多个screen窗口，在每一个screen窗口中就像操作一个真实的telnet/SSH连接窗口那样。在screen中创建一个新的窗口有这样 几种方式：
1．直接在命令行键入screen命令[root@tivf06 ~]# screen
Screen将创建一个执行shell的全屏窗口。你可以执行任意shell程序，就像在ssh窗口中那样。在该窗口中键入exit退出该窗口，如果这是该screen会话的唯一窗口，该screen会话退出，否则screen自动切换到前一个窗口。
2．Screen命令后跟你要执行的程序。[root@tivf06 ~]# screen vi test.c
Screen创建一个执行vi test.c的单窗口会话，退出vi将退出该窗口/会话。
3．以上两种方式都创建新的screen会话。我们还可以在一个已有screen会话中创建新的窗口。在当前screen窗口中键入C-a c ，即Ctrl键+a键，之后再按下c键，screen 在该会话内生成一个新的窗口并切换到该窗口。
screen还有更高级的功能。你可以不中断screen窗口中程序的运行而暂时断开（detach）screen会话，并在随后时间重新连接（attach）该会话，重新控制各窗口中运行的程序。例如，我们打开一个screen窗口编辑/tmp/abc文件：[root@tivf06 ~]# screen vi /tmp/abc
之后我们想暂时退出做点别的事情，比如出去散散步，那么在screen窗口键入C-a d （直接断开连接也可以的），Screen会给出detached提示：
暂时中断会话
半个小时之后回来了，找到该screen会话：[root@tivf06 ~]# screen -ls There is a screen on: 16582.pts-1.tivf06 (Detached) 1 Socket in /tmp/screens/S-root.
重新连接会话：[root@tivf06 ~]# screen -r 16582
看看出现什么了，太棒了，一切都在。继续干吧。
你可能注意到给screen发送命令使用了特殊的键组合C-a。这是因为我们在键盘上键入的信息是直接发送给当前screen窗口，必须用其他方式 向screen窗口管理器发出命令，默认情况下，screen接收以C-a开始的命令。这种命令形式在screen中叫做键绑定（key binding），C-a叫做命令字符（command character）。
可以通过C-a ? 来查看所有的键绑定，常用的键绑定有：C-a ? 显示所有键绑定信息
C-a w 显示所有窗口列表
C-a C-a 切换到之前显示的窗口
C-a c 创建一个新的运行shell的窗口并切换到该窗口
C-a n 切换到下一个窗口
C-a p 切换到前一个窗口(与C-a n相对)
C-a 0..9 切换到窗口0..9
C-a a 发送 C-a到当前窗口
C-a d 暂时断开screen会话
C-a k 杀掉当前窗口
C-a [ 进入拷贝/回滚模式
嗯，这猫功能比以前的那只多太多了（问题也多了好多！）。
最开始的时候，因为防火墙而导致只能直接连电脑，经一层modem之后就马上出问题，而且是稳定的30%丢包，折腾了我好几天。总怀疑是华为做的手脚，比如说华为的路由加其它交换机就会有问题什么的……
接着，折腾了一下子之后发现有大量的安全设置，包括在ppp口上阻挡80，21，23口等，我就心想，我擦嘞，居然这么淫荡，在这里动手脚，于是马上全部关掉，又慢慢看其他页面。
接着就顺手关掉了防火墙，然后突然一下子，丢包什么的好了，网络也通畅了，马上收到一大堆push通知。一阵神清气爽。原来一直是这个问题。因为下面带了几台电脑，于是连接数，ICMP连接，半开连接什么的都超了，所以被ban，关掉之后好了。
又继续研究，发现这个MT800居然还有telnet控制台，太神奇了。不过进去以后和之前在学校里面摸到的那些路由的系统不一样，开始还以为是限制了，后来才发现是系统不一样，差别有点大，厂家还是老老实实的给了root权限。不过看到了很多相似之处。于是又猛的一阵研究，折腾到两点多，才睡去了。
最近自己重新做固件嗯，因为某些癖好（算是吧，因为太钟爱于https了），一直在启用luci的https，可是不知道为什么，uhttpd的TLS插件无法启用，于是蛋疼了，我擦嘞，不了个是吧，不带这样玩啊…
于是只能启用不安全的uhttpd，让我一阵纠结，心里总是没有安全感…
一晃打开了transmission-web，突然想起了以前看到过的一个老外写的blog，说想远程管理transmission，但是transmission又没有密码保护（现在的版本好像有了），于是就用个nginx做前端，加上密码认证，就可以避免别人过来搞东搞西了。
这给了我启发，为什么不用nginx做SSL的前端呢？效果是一样的啊，顺带transmission的远端管理也可以做了，一举双得。
于是我动手了
首先是重新编译了一次nginx，因为官方编译的nginx没有包含ssl支持
然后启动了普通版的uhttpd，开始监听之后，修改nginx的配置，打开ssl支持，加上证书个密钥（因为用的是以前的证书，所以不用重新签），再写个proxy_pass（这个似乎有点问题，如果写到了location /path/ 中之后出现了问题，似乎是东西显示不完全，格式有点乱，后来写到 location / 中就没有问题了）
顺便把transmission的web管理加上，reload一次之后就完全没问题了。除了载入速度略有下降（transmission的web管理速度慢了稍微有点多）
附上一下配置文件
server {
listen 443;
server_name Router;
charset utf8;
ssl on;
ssl_certificate /etc/ssl/CA/keys/luci_school.crt;
ssl_certificate_key /etc/ssl/CA/keys/luci.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
proxy_pass ;
proxy_redirect default;
}
location /transmission {
proxy_pass ;
proxy_redirect default;
}
}