分类目录归档:网络

对各种网络问题的研究

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

最近又给同学刷了一只路由,在设置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价格都快疯了

嗯,表示从大概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 (原文中真的好多废话,看来作者是个爱表达自己感情的人) 继续阅读

有用的Screen(在ssh、telnet断开之后继续执行程序)

摘录自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 [ 进入拷贝/回滚模式

继续阅读

家里猫烧了,换了个华为的MT800,又有的玩了

嗯,这猫功能比以前的那只多太多了(问题也多了好多!)。

最开始的时候,因为防火墙而导致只能直接连电脑,经一层modem之后就马上出问题,而且是稳定的30%丢包,折腾了我好几天。总怀疑是华为做的手脚,比如说华为的路由加其它交换机就会有问题什么的……

接着,折腾了一下子之后发现有大量的安全设置,包括在ppp口上阻挡80,21,23口等,我就心想,我擦嘞,居然这么淫荡,在这里动手脚,于是马上全部关掉,又慢慢看其他页面。

接着就顺手关掉了防火墙,然后突然一下子,丢包什么的好了,网络也通畅了,马上收到一大堆push通知。一阵神清气爽。原来一直是这个问题。因为下面带了几台电脑,于是连接数,ICMP连接,半开连接什么的都超了,所以被ban,关掉之后好了。

又继续研究,发现这个MT800居然还有telnet控制台,太神奇了。不过进去以后和之前在学校里面摸到的那些路由的系统不一样,开始还以为是限制了,后来才发现是系统不一样,差别有点大,厂家还是老老实实的给了root权限。不过看到了很多相似之处。于是又猛的一阵研究,折腾到两点多,才睡去了。