分类目录归档：网络

对各种网络问题的研究

使用rsync

发表评论

参考：http://acman.bluenest.net/wordpress/archives/113

最近新入手只硬盘，准备将数据从一个硬盘迁移到另外一个硬盘，然后发现了rsync这个神奇的东西。

rsync的用法大体来说是

rsync 来源 目标

不同的是，来源和目标可以是绝对路径，或者是“协议://用户名@服务器地址”等等

可以选择用作本地或者远端的同步。当然，你也可以选择使用映射的方式，将远端的文件夹映射到本地，然后像本地操作一样使用rsysc，又或者，使用rsync自带的协议。

使用映射这个的方法就不说了，说说自带的rsync协议的用法：

你可以直接使用参数的形式或者使用一个配置文件（当然是配置文件这个比较方便），下面是配置文件的写法

address = 10.1.1.100 # 你要把rsyncd開在哪個ip上,建議不要開在public ip
pid file = /var/run/rsyncd.pid # pid file 所在,ubuntu可能可以省,不過個人習慣加上去
use chroot = yes # 這個建議加上去,因為可以限制只能對下面設定的目錄進行同步
log file = /var/log/rsyncd.log #記錄檔

#下面是設定哪些路徑可以跟遠端同步
[backup] # 命名,此名稱為遠端連線時要用
path = /home/acman/bin/ # 路徑
read only = false #是否為唯讀,此為否,代表遠端不只能抓,也能改;如果是 read only = true ,就代表遠端只能抓不能改
uid = 1000 # 連線時使用的帳號uid
gid = 100 # 連線時使用的帳號群組 gid
hosts allow = 10.1.1.100 #允許那個遠端ip連線過來
#[path2] 如果有其它路徑,就再用[…]開始設另一個

使用rsync –daemon –config=FILE来启动rsync服务器。

然后客户端连接服务器：

最簡單的使用方法,在客戶端下指令:
rsync -av 10.1.1.100::backup backup/
# 第一個backup要和設定檔的[…]中的設定一致;後面的backup/就看你要備份到哪裡了

如果你設定 read only = false的話,你還可以反向備份,就是把客戶端的東西備份上去:
rsync -av mydata/ 10.1.1.100::backup/mydate
這樣就會把客戶端的mydata目錄,直接備到server上的/home/acman/bin/mydata/底下了;這邊要注意的是,如果你是這樣下指令:
rsync -av mydata/ 10.1.1.100::backup/
那它會把mydata底下的檔案,備份到 /home/acman/bin/底下,不會另開一個目錄

rsync這個指令的好處是它會自行比對兩端的資料是不是一樣,只會傳輸有變動的資料
當然還有其它功能,如砍遠端檔案,或是忽略特定檔案或目錄等等

2.另外如果你不想要多開一個rsyncd服務的話, rsync指令也允許通過ssh來進行傳輸;不需要做上面那些設定:
只要遠端有開sshd,就可以備份遠端檔案或是將本地檔案備份過去
指令下法一樣,不過多了 “-e ssh”,如下:
rsync -e ssh -av 10.1.1.100::backup backup/

……
……
……

结果还是磁盘映射的方式比较方便啊。

在OpenSSH Server中禁用单个用户的密码登陆

最近发现有人老尝试登陆我的路由，让我感到非常不高兴。

于是稍微再网上做了一下搜索，找到了这个帖子，里面指出了解决办法：

1：直接禁用了该用户的密码。这个显然不符合我们的要求，禁用了之后luci不就废了么？

2：在sshd_config的最后，加上这么一段：

Match User myusername
PasswordAuthentication no

然后重启sshd，再次登陆的时候，就收到了提示，

Permission denied (publickey,keyboard-interactive)

OK了~

再去看系统日志，满屏的

Jan 17 11:53:04 Ferrets-Router auth.info sshd[9868]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:05 Ferrets-Router auth.info sshd[9870]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:05 Ferrets-Router auth.info sshd[9872]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:06 Ferrets-Router auth.info sshd[9874]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:07 Ferrets-Router auth.info sshd[9876]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:08 Ferrets-Router auth.info sshd[9878]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:08 Ferrets-Router auth.info sshd[9880]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:09 Ferrets-Router auth.info sshd[9882]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:10 Ferrets-Router auth.info sshd[9884]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:11 Ferrets-Router auth.info sshd[9886]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:11 Ferrets-Router auth.info sshd[9888]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:12 Ferrets-Router auth.info sshd[9890]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:13 Ferrets-Router auth.info sshd[9892]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:13 Ferrets-Router auth.info sshd[9894]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:14 Ferrets-Router auth.info sshd[9896]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:15 Ferrets-Router auth.info sshd[9898]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:16 Ferrets-Router auth.info sshd[9900]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:16 Ferrets-Router auth.info sshd[9902]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:17 Ferrets-Router auth.info sshd[9904]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:18 Ferrets-Router auth.info sshd[9906]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:18 Ferrets-Router auth.info sshd[9908]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:19 Ferrets-Router auth.info sshd[9910]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:20 Ferrets-Router auth.info sshd[9912]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:21 Ferrets-Router auth.info sshd[9914]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:21 Ferrets-Router auth.info sshd[9916]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:22 Ferrets-Router auth.info sshd[9918]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:23 Ferrets-Router auth.info sshd[9920]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:23 Ferrets-Router auth.info sshd[9922]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:24 Ferrets-Router auth.info sshd[9924]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:25 Ferrets-Router auth.info sshd[9926]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:26 Ferrets-Router auth.info sshd[9928]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:26 Ferrets-Router auth.info sshd[9930]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:27 Ferrets-Router auth.info sshd[9932]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:28 Ferrets-Router auth.info sshd[9934]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:28 Ferrets-Router auth.info sshd[9936]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:29 Ferrets-Router auth.info sshd[9938]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:30 Ferrets-Router auth.info sshd[9940]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:31 Ferrets-Router auth.info sshd[9942]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:31 Ferrets-Router auth.info sshd[9944]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:32 Ferrets-Router auth.info sshd[9946]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:33 Ferrets-Router auth.info sshd[9948]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:33 Ferrets-Router auth.info sshd[9950]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:34 Ferrets-Router auth.info sshd[9952]: Disconnecting: Too many authentication failures for root [preauth]
Jan 17 11:53:36 Ferrets-Router auth.crit sshd[9954]: fatal: Read from socket failed: Connection reset by peer [preauth]

这孩子还是没放弃呢……不过毫无疑问，破解密码这种事情就别妄想了。

在OpenWrt的WiFi上使用非英文字符作为SSID和密码

1条回复

最近又给同学刷了一只路由，在设置wifi的时候突然来了兴致，不如用中文来做SSID吧~然后就干了，在luci上使用中文写了SSID，然后应用之后，发现luci的页面上能够正确的显示中文，但还到了windows上就变成了一串英文，然后用手机一搜，哟~中文哎。

显然是字符编码的问题了。

总所周知，windows使用的是GB的字符编码，而Linux一般使用的是UTF-8，除非你手动改成了GB。用Linux做底层的Android果然跟随了Linux的步伐，编码使用了UTF-8，而Openwrt的Luci也用的是UTF-8的编码，如此一来，便解释得通了。

用notepad++打开/etc/config/wireless，编码切换到GB，将SSID改成了中文，保存，然后重启WiFi，然后一搜：

中文SSID

果了个然，于是中文的SSID就出来了，别人看到都觉得很惊奇。这时候就可以给你的WiFi一个有趣的SSID，比如之前看到的“网络无法连接”，估计可以让相当一部分的人放弃连接你家WiFi的念头。

另外一件很有趣的事情就是，虽然使用了GB编码的SSID，但是Ubuntu却表示我能够正确的认出中文的SSID，并显示出来。UTF-8编码的中文SSID，Ubuntu同样能够正确地显示中文，这实在太不可思议了。

===========================接下来就是把密码给玩坏===============================

最初的时候，就尝试直接使用GB的编码来写中文密码。ok，windows说他能连上。但是Linux表示我们 UTF-8的编码没法通过密码验证。

问题就来了，怎么办呢？

把密码换成UTF-8如何？

然后Ubuntu就表示，嗯，我们没问题！

中文WiFi密码

啧……这可难办了，难道就没有两者都能兼容的办法么？

然后在来回切换编码的时候，我发现了一个问题，UTF-8转成GB之后是乱码，但是看起来却都是正确的中文字符……要不旧直接用这个乱码来试试连接吧……Windows说：没问题！然后就连上了。

GB编码下的SSID和密码

GB编码下的SSID和密码

UTF-8编码下的SSID和密码

UTF-8编码下的SSID和密码

乱码密码

乱码密码

看来连接是没有问题呢～

也就是说使用GB编码的SSID和UTF-8编码的中文密码是最优的组合～无论linux和windows都可以连接到。

最后就是客人的问题……

移动设备的话估计没什么问题，但是捧着运行着Windows的电脑过来的孩子……有的麻烦了呢……

==============================追加移动设备的研究================================

很可惜的是，android和IOS都可以认出UTF-8编码的SSID，但是无法认出GB编码的SSID，只能看到一串乱码，这个实在是太糟糕了。微软你赶紧投奔UTF-8的怀抱吧。

与此同时，测试了UTF-8编码的密码，Android和IOS都能够使用中文密码来连接，但是IOS在输入密码的时候，只能输入英文字符，所以，需要使用复制粘贴的方法，来完成密码的填写。Android的话，可以强制切换键盘来输入中文。

另外的就是，即使使用中文字符，也必遵循WPA2密码最少8个字符的原则，所以最短密码是八个中文字，而不是4个中文字。

等我以后能装OSX的之后再补上MAC的研究报告。

使用tcpdump抓包

发表评论

详细参考：

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地址的抓包要麻烦一些，暂时没研究通，上面给出的第二个连接是一篇国外的相关资料，看得懂的可以看看

最近的Bitcoin价格都快疯了

2条回复

嗯，表示从大概4月23号进去了，交易市场是btcchina（https://btcchina.com），看着价格从400多涨到现在的700，感觉都已经疯了，但是仔细想想……感觉还是会涨的样子……

暂时来说，还是留着吧……

在Nginx中使用客户端证书认证

发表评论

其实这个东西很久以前就想搞的了，一直没动手，直到最近总在外面跑，有时候就考虑连回家里，于是稍微动了一下手。

选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。

感觉一下子强力了好多啊。

让Apache的AutoIndex使用特定的字符编码

发表评论

参考：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

openwrt的gre穿透

发表评论

参考：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的转发

在iptables中打开gre的转发

之后就能连上了。

在openwrt中指定对lan的dns服务器

发表评论

按照惯例，先上参考：
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

得到。

[国外搬运]破解日版buffalo的路由

发表评论

原文链接：http://scarygliders.net/2010/02/23/hacking-around-the-japanese-buffalo-wzr-hp-g300n/

修复自己的AG300H的时候又查询到了这篇文章，觉得真的有必要翻译过来（翻译的不好希望不要见怪）。也方便一下国人，感觉国内关于buffalo的文章好少啊。

[题外话]乱入一张Philipp Klaus童鞋的AG300H的TTL针脚定义图（需要登上长城技能），这也让我好找一番，在Google翻了良久才找到这么一张，果然还是国外的友人折腾的东西多啊，不过又是因为在picasa网络相册，又要出塞一番才能得到想要的东西。顺便鄙视一下百度，全球最大的中文搜索引擎，对中文以外的东西就完全是个渣渣啊。AG300H TTL针脚定义

~~~~~~~~~~~~~~~~~~~~~~~~下面才是正文（大量节选）~~~~~~~~~~~~~~~~~~~~~~~~~~

blah blah blah blah （原文中真的好多废话，看来作者是个爱表达自己感情的人） 继续阅读 →