PPPoE on Cisco ISR 871W 以及debug输出分析

周末的时候翻出来了一台Cisco 871W 路由器,为了榨干闲置设备的每一份能力,我用这个设备替代了家里的一台家用级小路由器实现了PPPoE 接IPv4 + Tunnel Broker方式接入 IPv6 + 多SSID WiFi。

本文记录的是这个小方案的第一部分,实现PPPoE拨号(以及对PPPoE过程的一些研究),后续几天空闲时再继续写后面的部分。

871W是一台相对老的路由器(已经停售),但是本文中用的软件是相对比较新的IOS15.1,配置命令对其他使用IOS15的ISR路由器可以作为参照。

:arrow:  *本文(以及本blog中其他正文部分文字)涉及内容仅代表个人,与公司及日常工作完全无关。

总体想要达到的目标

  • PPPoE拨号连接到Internet (本文)
  • 保证IPv4 到互联网的连通 (对内网做DHCP,在出口做NAT) (已实现,待续)
  • 多SSID 提供WiFi接入,以便将家里的实验设备和日常设备分开 (已实现,待续)
  • 通过tunnel broker实现IPv6接入, 包括WiFi也要有IPv6支持 (已实现,待续)
  • 对IPv6 提供基本的安全保护,禁止外界访问内部的IPv6地址 (已实现,待续)
  • 其他企业级设备能支持但是家用级设备不支持的功能…… (待开发……)

使用的设备

Cisco ISR 871W 路由器,软件版本Cisco IOS Software 15.1(4)M8

拓扑及连线

非常简单,就不画图了,871W上的Fa4 (WAN口)连接 ONU的一个以太口,Fa0口连接家里的PC。

设备配置

用ISR路由器实现PPPoE拨号

注意:我用的ISP服务是包月的,因此完全没有考虑“不用时”自动断线的问题。

参考Configuring PPP over Ethernet with NAT,但是由于我使用的IOS是15.1版,因此命令有些细微却别,比如我完全没有做vpdn-group那部分。

配置如下,Fa4口为WAN口连光猫(ONU):

上面配置是通过pap方式发送PPPoE的用户名密码,实测北京联通的光纤接入可用。用chap方式倒是不行,推测应与ISP那端的设置有关(后面通过debug命令得到了证实)。

接通之后执行”show interface dialer 0″可以up/up状态,并能看到获取的IP。

对PPPoE更多的一些探索及debug命令

如果好奇PPP的认证过程,可以试试看”debug ppp authentication“命令,想看看PPP的协商过程可以用”debug ppp negotiation”。

注意:生产网慎用debug命令,自己自学(折腾)就多看看debug命令的输出吧…… LCP和NCP (IPCP)到底都做了些什么,在debug的输出里面看的很清楚。

有两篇文档可以作为辅助,以便更容易的读懂debug的输出:

  1. Troubleshooting PPP (CHAP or PAP) Authentication
  2. Understanding debug ppp negotiation Output

执行”clear ppp all”命令可以强制打断并重建PPPoE连接。

首先想看看研究一下为啥chap失败,执行debug ppp negotitation之后再执行”clear ppp all”得到了一堆的输出,摘录一段在这里:

参考Understanding debug ppp negotiation Output这里可以知道PPP的协商过程是如下图所示:

PPP phase transitions
PPP phase transitions

上面debug输出的就是Establishing到Down的这段,原因其实就是LCP协商失败。

上面输出比较重要的两段单独拿出来看看:

” I CONFREQ”是ISP那边送来的,大概意思就是说我要用PAP方式做验证好不好?MTU是1492。”O CONFNAK”是我的router在说”我要用CHAP做验证,MTU 1500″。而且这个过程在不断重复,这要是在现实生活中估计俩人早就该打起来了……好在对”Magic Number”两边还是能好好的协商的……

在经过多次之后失败后(我这里看到的是15次)debug输出中会出现这样一句:

如果说”CNFNAKs”是路由器“稍显含蓄”的表达对部分协商的内容拒绝且我同意的方式是下面的,你看看如何;那”CONFREJ”表示路由器“真急了”,直接说对下面这些你说的我不同意。

根据上面看到的结果,乖乖的把验证方式修改成pap,然后再看看debug的输出:

这回协商的过程就客气多了,先是两边统一好了magic number(部分debug输出过程省略),之后的“对话过程如下”:

  1. ISP那边的设备说“MRU 1492, PAP验证 magic number是…”
  2. 我这边的路由器回答“部分不同意(CONFNAK),MRU 1500如何?”
  3. ISP那边的设备说”MRU 1500, PAP验证,magic number是…”
  4. 我这边的路由器确认方案(CONFACK)并复述了一遍方案

再之后进入了进入”AUTHENTICATING”状态,使用配置好的用户名密码做了身份验证,收到确认后就进入到了”UP”状态了。

再往后就是NCP (IPCP)协商阶段,从ISP那边拿到IP地址等参数了。

对配置的进一步的小改进-调整MTU

如果想要在LCP协商过程中直接接受ISP那边提出的MRU,那么可以在dailer接口下设置 “ppp mtu adaptive”,那么LCP协商阶段就会减少一次“讨价还价”,直接按ISP那边提供的MRU 1492。debug输出如下(完全没有协商使用1500的过程):

然后Dialer接口 上设置ip mtu 1492 (前面其实已经设置了),对内的接口上设置“ip tcp adjust-mss 1452”,具体原因可以参考这里:Cisco IOS IP Application Services Command Reference

实际测试时,我使用的北京联通的网络看似是接受1500的,不修改成1492没有影响我上网使用。仅供参考。

【bash script】在树莓派上用HC-SR501红外感应器触发USB摄像头拍照

5-1假期闲的没事继续折腾树莓派。这次是尝试模拟一个防盗报警器,用HC-SR501 被动红外动作感应器 (Passive Infrared/PIR motion sensor)来触发USB camera拍照。大概的思路就是如果被动红外动作感应器被触发时,则调用USB摄像头连续拍照N次。

使用的设备:

  • 树莓派
  • HC-SR501 被动红外动作感应模块 (工作电压5V,信号输出未触发0V ,触发时3.3V)
  • USB摄像头 (我使用的是Logitech C920,其实完全不用这么高端的……)
  • LED x1
  • 470Ω 电阻 (与LED串联作为保护)
  • 杜邦线
  • 面包板

物理连线

连线之前的考虑:

  1. 许多传感器都没有电源接反的保护,接之前请务必再三确认正确再连接。
  2. 不同设备的数据输出不一定是3.3V的,有些有可能用5V表示1。我是先用万用表又验证了HC-SR501的数据输出是3.3V才敢连接树莓派的GPIO接口的。如果电压不匹配还非要去连接,则行为很可能异常,甚至损坏硬件。

线路连接:

HC-SR501连接树莓派 接线示意图
HC-SR501连接树莓派 接线示意图
HC-SR501连接树莓派 电路图
HC-SR501连接树莓派 电路图
  • HC-SR501的电源连接树莓派5V输出,GND连接树莓派的GND,中间的data连接树莓派的GPIO接口,我使用的是11口 (GPIO 17)。
  • USB摄像头连接树莓派的USB接口 (我是实际是连接到USB hub上了)
  • 根据需要有可能要调整HC-SR501上的电位器来调节触发距离和延时
  • 根据需要有可能要调整HC-SR501上的跳线位置来设置允许多次重复触发

检查连线:

目视确认面包线连接正确并且牢固,使用lsusb查看系统是否识别出了USB摄像头,使用 ls /dev/video*  检验USB摄像头的编号。

 实现所用的bash脚本

下面脚本其实是通过轮询的方式每间隔1秒(可调)通过sysfs方式查询一下sensor的状态,然后复制sensor状态到另外一个GPIO接口;如果sensor是被触发,则调用fswebcam来实现拍照。

脚本中我尽量将不同功能拆成函数了,尽管这样效率并不是最高的。在init_led和init_sensor函数中,尽管只有1个报警用的LED和1个sensor,我还是用循环的方式去做初始化,这也不是最优的方法。这样做主要是为了以后做多个sensor和多个LED故意预留的。

HC-SR501传感器是通过3.3V输出来表示被触发时的“1”,这个电压驱动LED也足够,我实际测试了,即使不没有树莓派,1个LED连接到HC-SR501的data输出已经可以实现灯光告警,但是在这个时候LED的光线不够亮,而且不连接树莓派也没法去调用USB摄像头拍照了 :-?  ……

实验后考虑的改进

  1. 如果不想在屏幕上看到每次拍照时执行的细节,可以考虑为fswebcam加上-q参数,将脚本中的fswebcam命令修改成如下:

  1. 树莓派的SD卡空间有限,图片的贮存位置在脚本中默认写的是/tmp目录,当然通过Linux挂载NFS/Samba (NT Folder)/云端等等对这段脚本而言,都仅仅是在系统中的某个目录。因此这里就没有特别去在图片存储方面再多考虑了,利用Linux系统本身的能力即可实现将存储“网络化/云端化”。
  2. 本文是用bash脚本方式实现功能的,上面代码只是做功能演示,效率并不高。如果用C去写一段代码,当传感器被触发后,用中断的方式触发告警动作可能会是比轮询更好的选择。留待以后有时间再去琢磨。
  3. 这次我使用的HC-SR501 传感器并不足够敏感。做完所有测试之后,我故意试了试从远处以很慢的速度接近传感器,其实只要足够慢是可以不触发报警的……如果真的要用来做防盗报警器,估计还需要用更灵敏的传感器,甚至将不同种类的传感器进行结合使用。

总体而言,这其实是一个非常非常简单的实验。这个实验中使用的传感器也应该是几乎最简单最入门的了,只有0(未触发)和1(触发)两个状态。写这个脚本仅是利用树莓派将传感器告警与后续动作连接起来。至于后续动作是亮个LED灯,还是拍照,甚至是打出去电话、记录日志、发短信、带动继电器做通/断电动作等都是可以实现的。等日后有更实际些的应用再看怎么做了。

对比用shell script和C语言API操作Raspberry Pi GPIO的速度

对Raspberry Pi的GPIO在shell script里面可以直接用sysfs的方式进行操作,也可以调用gpio命令来进行操作,还可以用API来进行操作。今天做了个实验对比sysfs方式、第三方gpio命令以及C语言API操作对效率的影响。

昨天写的文章里面提到了用GPIO来控制LED灯的显示,今天其实是突发奇想,想看看用第三方gpio命令来操作和直接操作sysfs的效率到底有多大的区别。

物理连线

连线和昨天写的文章里面的连线方法基本一样,只是在GPIO管脚和GND之间跨接了一个可以测频率的万用表(UNI-T UT136D)。

Shell Script 响应速度测试

测试脚本

 方法1:直接调用sysfs控制通断

脚本中默认没有注释掉的就是方法1,相当于用下面命令来操作gpio实现让电路通断:

实测频率在1.1kHz左右。目测LED基本感觉不到闪烁。

测试结果照片如下,最后两位数字在不断跳动。

万用表测试GPIO接口频率 (Shell Script)
万用表测试GPIO接口频率 (Shell Script)

方法2:用shell脚本中的函数调用sysfs控制通断

相当于用下面命令来通过自定义函数gpio_ben操作gpio,实现电路通断:

实测频率在750Hz左右。目测LED基本感觉不到闪烁。

方法3:用gpio外部命令来控制通断

相当于用下面的命令来通过gpio外部命令来操作gpio,实现电路的通断:

实际频率在40Hz左右。目测LED能感觉到一些闪烁。

方法4:用通过函数调用gpio外部命令控制通断

相当于用里阿敏的命令来通过函数调用gpio外部命令来操作,实现电路的通断:

和方法3测到的结果基本一致40Hz左右,目测LED 能感觉到一些闪烁。

Shell Script测试结论

总结一下测试的结果:

方法 方法1:直接用shell内部命令调用sysfs 方法2:使用函数通过shell的内部命令调用sysfs 方法3:使用gpio外部命令控制 方法4:通过函数调用gpio外部命令
响应频率 约1.1 KHz 约 750 Hz 约 40 Hz 约 40 Hz
 占空比 约 53-54% 约 60%-61%  约49% -51%  约50%-51%

和预期一致,使用shell的内部命令(echo和重定向符等)调用sysfs明显效率比使用第三方的命令效率要高。只不过效率高出的比例(27倍!)确实超乎意料。

有些超出预期的是在相对足够快的时候使用shell函数对效率产生的影响也能比较明显的表现出来,方法1和方法2使用的命令是一致的,只是方法2通过函数调用了那些命令。效率相差了几乎40%!

为了进一步验证,我又利用万用表测试占空比的功能进行了补充测试,得到的结果见上面表格。分析shell代码,我估计是因为shell脚本进入和退出函数时占用了相对不少的时间,以至于直接影响到了频率和占空比。这也说明在shell中使用函数其实是要消耗不少资源的。

用函数编写脚本逻辑上会清晰一些,但是就像当年上学时学过的一样,比较“面向机器”、“面向过程”、“面向对象” 编程逻辑上依次可能会一个比一个清晰,但是牺牲的是运行效率。

另外需要特别说明的是频率和占空比测试时使用的不是专业的示波器,只是一个带有频率测试功能的万用表,因此只写了大概的数值。而且在测试频率时不是空载的,电路中带着电阻和LED。但是测得数值的差别已经足够可以反映出来运行效率的差距了。

用C语言代码来测试gpio

其实本文主要想写的是shell脚本来做gpio操作的测试,临写完时觉得还是该试试看gpio到底能”跑多快”。参考例子写了一段C代码编译之后测试,跑出的结果真是甩出shell脚本N条街……要想追求速度还是要上C啊……不知道汇编去操作会不会更快些……

使用WiringPi C API测试

代码如下:

测试的频率达到了4.5-4.6 MHz,占空比46%-47%。测试结果的照片如下:

万用表测试GPIO响应频率 (C语言API方式代码编译之后结果)
万用表测试GPIO响应频率 (C语言API方式代码编译之后结果)

测试使用C语言代码通过文件操作调用sysfs

代码如下:

其中

这一行我试用了O_SYNC, O_DSYNC, O_ASYNC分别测试,占空比基本都保持在50%正负不到1%的接近理想状况。频率结果如下:

O_ASYNC 175-185 kHz
O_DSYNC 168-177 (偶尔有看到超过180 kHz的情况)
O_SYNC 168-177 (偶尔有看到超过180 kHz的情况)

实际测试时结果相对不稳定,数值跳动的比较厉害,由于手头没有示波器,看不出来实际输出的波形和频率。

C语言程序测试的结论

使用C语言WiringPi API来操作gpio看似是几种方法中响应时间最快的,但是占空比距离理想值的50%有3%-4%的差距。(和预期的一样) 使用C语言对sysfs操作速度仍远超过shell脚本;占空比最接近理想值的50%,但是没有使用Wiring Pi API调用gpio响应时间短。

对比Shell Script和C语言程序测试结果

使用语言 C语言 Shell脚本
 调用方法  wiring Pi API  直接文件操作sysfs  直接文件操作sysfs 使用函数操作sysfs 外部gpio命令 通过函数调用外部gpio命令
测试响应频率  4.5-4.6 MHz  168-185 KHz  1.1 KHz  750 Hz  40 Hz  40 Hz
 测试占空比  46%-46%  非常接近50%  53%-54%  60%-61%  49-51%  50%-51%
相对最慢方法的大致”速度倍数”  11万倍以上  4千倍以上  27.5倍  18.75倍  1 *最慢  1 *最慢

所有测试时,肉眼都能感觉出来作为参照的LED灯要比常亮的状态下要略微暗一点点。在40Hz的时候能相对明显的感觉出来LED灯在快速闪烁。

目前看来要想追求速度,用C代码调用API写gpio是效率最高的。有机会试试汇编再做对比。

谨以此文对今日所作测试做一些记录。

【bash脚本】通过Linux sysfs调用GPIO实现LED显示Raspberry Pi内存占用率

这几天弄了个树莓派(Raspberry Pi)玩,装了个Linux。树莓派的GPIO其实非常容易调用,甚至可以直接通过Linux的sysfs来读写GPIO接口的状态,周末空闲的时候写了段bash Shell Script来控制LED灯来展示Linux的内存占用率。这只是个很简单的bash脚本,主要来示意一下如何通过Linux sysfs来调用GPIO来操作LED,通过修改脚本其实可以实现更多的功能,例如显示CPU的温度是否过高等。

我使用的硬件设备:

  1. Raspberry Pi
  2. LED x3 (不同颜色)
  3. 470Ω 电阻 x3 (用来为LED降压)
  4. 杜邦线 (母-公) x3 (用来连接树莓派的GPIO到面包板)
  5. 面包板 x1

第一步:用gpio命令验证物理连线

gpio命令是需要安装WiringPI之后才有的,默认系统不带。安装之后用root权限(sudo)执行 gpio readall,将得到类似下面的结果:

Phy对应的是针脚的位置, GPIO对应的是GPIO的编号。需要注意两点:

  1. 实际执行这个命令后Raspberry Pi显示的GPIO编号很可能和我的不一样,要仔细看好然后再看看要用哪个编号。
  2. GPIO的编号和物理针脚不一定是顺序对应的,比如我这次要用的是针脚11, 12, 13,对应的GPIO编号是17, 18, 27。当然如果要用wiringPi的逻辑pin的话就是0, 1, 2,但是我这次不打算用wiringPi,只用sysfs来实现对LED的控制。

第二步:连接线路

注意:连线前断电,连好之后请再三确认之后再通电!

Raspberry Pi Control LED by using GPIO
Raspberry Pi Control LED by using GPIO
GPIO LED 树莓派 面包板接线示意图
GPIO LED 树莓派 面包板接线示意图
GPIO 连接LED 电路图
GPIO 连接LED 电路图

连接好线之后,请再次目视检查确认线没接错,特别是0v (GND)一定不要接错!再三确认之后再通电,进入Raspberry Pi的命令行界面测试接线是否正确。刚刚接好线的时候LED是不会像上图那样亮起来的,可以执行下面命令看看LED是否会亮(注意要有root权限):

修改GPIO的数字,依次测试。如果一切正常,那么三盏LED灯会依次亮起来,记住每个数字对应的LED的颜色。

第三步:编写脚本通过sysfs调用GPIO实现用LED灯展示内存占用率

我写的脚本如下,如果你愿意,你可以随意使用/修改后再使用/分发。

上面的脚本实现每10秒钟检查一次内存占用率(利用free命令),如果可用率高于60%,那么亮绿灯;如果可用率低于30%,则亮红灯。在30%到60%之间时亮橙色灯。在退出程序后,LED都会灭掉。

将上面脚本保存为.sh后缀,然后chmod +x赋予执行权限,再执行就可以了。

对上面的脚本稍加修改也可以实现用LED监控树莓派的CPU温度等等,这里就不一一列举代码了。用Shell获取树莓派的CPU/GPU温度可以参考这里:Raspberry Pi onboard temperature sensors

fail2ban on Ubuntu

本文主要介绍如何使用 fail2ban 来削弱针对ssh的猜密码攻击。Ubuntu上自带的 fail2ban 默认规则有些小问题,看似不能直接生效。本文对系统自带 fail2ban 规则做了些修改,实际在Ubuntu Linux 14上测试可用。

清明假期的时候闲的没事将主机从AWS迁移出来了,blog平台也换成了WordPress。新的主机在所在的网段被无聊的人扫来扫去(有种回到校园网的感觉),而且有不少尝试对ssh的攻击,本着“不折腾不会死”的做死精神,在新的主机上启用了fail2ban。

新的主机跑的是Ubuntu Linux的,使用系统默认配置的fail2ban之后发现其实是不生效的。上网搜了一下发现不少人在抱怨fail2ban不能用。这周末自己闲在家里稍微研究了一下,原来是Ubuntu默认安装的fail2ban规则和系统auth.log产生的log不能匹配造成的。

简单记录一下让Ubuntu Linux上的fail2ban来阻挡ssh猜用户名/密码的攻击方法:

  1. 保证机器的时间正确(时区也看看),安装fail2ban(参考这里)。
  2. 启用ssh证书认证(对,这个和fail2ban没任何关系,但总比用密码认证安全些),具体参考这里: How To Set Up SSH Keys
  3. 看一下/var/log/auth.log中的sshd的报错,我这里放几个我遇到的比较典型的(student是随便一个用户名,10.1.1.1是任意的一个ip,example.com是任意的域名):
    • Invalid user student from 10.1.1.1
    • Received disconnect from 10.1.1.1: 11: Bye Bye [preauth]
    • Address 10.1.1.1 maps to example.com, but this does not map back to the address – POSSIBLE BREAK-IN ATTEMPT!
    • reverse mapping checking getaddrinfo for example.com [10.1.1.1] failed – POSSIBLE BREAK-IN ATTEMPT!
  4. copy /etc/fail2ban/filter.d/ssh.conf /etc/fail2ban/filter.d/bad-ssh.conf
  5. vi (或者你任何喜欢的文本编辑器,别和我争论这点,我是习惯用vi了)bad-ssh.conf,修改成以下内容:

  1. 修改/etc/fail2ban/jail.local,增加下面一段内容

    1. [optional] 修改 /etc/fail2ban/action.d/iptables-blocktype.conf,我是认为直接drop就好了,对这种无聊的攻击没义务发icmp port unreachable回去

    1. 执行service fail2ban restart,注意观察/var/log/fail2ban.log和auth.log,再有攻击发生会能看到类似下面的日志:

如果想要测试自己写的正则表达式是否正确,可以使用fail2ban自带的”fail2ban-regex”来测试,从auth.log中找出自己想匹配的一条日志,然后执行一下这个命令来试试看自己写的表达式是否会匹配即可。例如下面的例子:

需要注意,如果日志里面有中括号([])等特殊字符,记得要用正则表达式的转义字符”\”来匹配。要想匹配的更准确些,还可以考虑用上”$”(行尾)”^”行首等等……正则表达式怎么写就不多说了,网上的教程一大堆……

最后还是要多废话几句,fail2ban不能完全阻止所有的针对ssh的攻击,只能靠暂时封禁来削弱这种攻击的强度。定期看系统日志,发现潜在异常并且根据日志来进行相应的调整是系统管理员必须要做的事情。

在CME上更换Cisco IP Phone的背景图片

终于可以趁着端午节假期休息一天了……这段时间真是忙坏了

整理一下最近做的一件有意思的事情:如何利用ISR路由器上的Cisco Unified Communications Manager Express来更换IP电话的背景图片。

先来一张更换之后的实际效果图:

配置CME的步骤我就略过不说了,没有任何特殊的地方。
要更换IP电话背景图片需要先制作图片,建议先查询一下Cisco IP电话的说明手册,看看想要更换图片的IP电话支持的图片大小是多少,不同电话支持的图片大小可能是不一样的。

上面照片中的是Cisco 7945 IP电话,支持的背景图片大小是320×212,为此需要准备2个图片,一个大小是320×212作为实际背景图片,另外一个大小是80×53 (长和宽都是原始图片的1/4)作为预览图片。

接下来需要将图片文件传送到路由器的flash中,经过后续的一些步骤之后,IP电话就可以通过tftp方式找到这些文件。 一般是将图片存放在flash中的”Desktops/320x212x16/” 其实放在哪里都无所谓,等一下可以通过配置TFTP服务器的时候指明文件位置。

使用文本编辑器编写一个名为List.xml的文件(注意文件名大小写),内容类似下面的内容,传送到图片文件同一个目录里面:
<CiscoIPPhoneImageList>
<ImageItem Image=”TFTP:Desktops/320x212x16/Cisco_Logo_s.png” (预览图文件名)
URL=”TFTP:Desktops/320x212x16/Cisco_Logo.png”/> (实际背景图文件名)
</CiscoIPPhoneImageList>
文件可以写很多段,以便同时支持多个背景图片文件

接下来在路由器上做配置
tftp-server flash:/Desktops/320x212x16/Cisco_Logo.png alias Desktops/320x212x16/Cisco_Logo.png (实际图片文件)
tftp-server flash:/Desktops/320x212x16/Cisco_Logo_s.png alias Desktops/320x212x16/Cisco_Logo_s.png (图片预览)
tftp-server flash:/Desktops/320x212x16/List.xml alias Desktops/320x212x16/List.xml (配置文件)

针对7945来说alias后面的目录名是固定的,文件名除了List.xml之外其余都是上传图片文件的文件名,不同路由器可能是不同的;具体可以查询Cisco文档,或者在路由器上做debug tftp event(注意尽量不要在生产网设备上执行debug命令)来看电话试图请求哪个文件。 有些网上的案例文档没有给出alias及随后的参数,实际测试表面这个参数是必须的,因为启动CME之后默认的tftp-server文件目录不一定是flash了,电话配置的xml文件也不一定是存在flash里面的嘛。

完成上面步骤之后剩下的步骤只需要在电话上操作,按下电话上的配置按钮,选择1. User preference,然后选2. Background (不同电话可能不一样),这时电话会对路由器发起tftp请求(如果在路由器上启用了debug tftp event这时就会看到电话首先请求List.xml文件,然后请求图片预览文件),然后在电话上就可以看到默认的背景图片以及新传送到tftp-server上的图片了。 在电话上选中想要用的图片,然后在点save就可以了。之后即使重新启动电话选中的图片也不会丢失。

需要注意,所有的图片文件都会保存在电话的flash里面,如果想要从电话中删除这些自定义的图片,则需要重置电话恢复出厂设置才可以。

给家里也做了IPv6接入

IPv6很多年前就玩过了,多年前曾经还在学校工作时,就给学校的所有学生宿舍接入了IPv6的网络。几周前发现新的Linksys E4200 1.0.02 版本的firmware可以支持IPv6 RD了,当时就升级了firmware。国庆节在家闲着休息,能玩的游戏都玩过一遍之后忽然想起来E4200路由器还是有些东西可以玩玩的……

Linksys E4200 1.0.02的release note中的一条:

- Added support of Native IPv6 and 6rd tunnel Internet connections

配置方法如下:
用浏览器登录到管理界面:
image

6rd Tunnel的配置可以根据要接入的Tunnel给的参数来设置,我使用的是Hurricane Electric Free IPv6 Tunnel Broker。Tunnel申请过程我就略去了,有一点建议:按照HE自动分配的tunnel通常都是最好的,别光看地理位置。比如看地理位置感觉香港和日本应该都是速度快的,实际traceroute和ping下来的结果并不是这样的。

申请之后的会看到下面的界面,画红色框的是将要用到的参数。

image

将Routed /64地址填写到Prefix(里面注意去掉地址最后的”::/64″),Prefix Length写为64,;将Server IPv4 Address填入到Linksys E4200配置界面里面的Border Relay框里面, IPv4 Address Mask写成32
注意同时将IPv6-Automatic选成Disable,6rd Tunnel为Manual Configureation。最后点击Save Settings

image

配置结束之后可以在管理界面看到是否可以成功连接:点击status,然后再点击Router(默认就是选择这个)

image

然后在页面的最下面可以看到(如果显示是在connecting,等一会儿点Refresh再试试看) :

image

之后回到PC上:ping ipv6.google.com

image

最后一个要解决的问题是动态IP的问题。大多数ISP不会给用户固定IP,Hurricane Electric的解决办法是通过一个URL即可实现动态更新tunnel的配置,下面两个URL都可以:

https://<USERNAME>:<PASSWORD>@ipv4.tunnelbroker.net/nic/update?hostname=<TUNNEL_ID>

https://ipv4.tunnelbroker.net/nic/update?username=<USERNAME>&password=<PASSWORD>&hostname=<TUNNEL_ID>

Username和Password是注册Tunnel时候自己选择的用户名密码,Tunnel ID是一串数字在上面第二和第三个图片中可以看到。

Optimization WordPress Plugins & Solutions by W3 EDGE