首页 > 拆机刷机 > 正文

[N56U/N65U/N14U]Padavan固件学习与研究
2015-09-11 00:40:50   来源:   评论:0 点击:

2014-02-13 15:14 1私讯连结最近使用了N56U刷入了Padavan, 有鉴于还算不错用, 因此逐步撰写Padavan学习文件和一些想法 如有错误, 多所难免, 希望指证! 欢迎讨论和学习 实话实说, 只说明有用到和知道的(
最近使用了N56U刷入了Padavan, 有鉴于还算不错用, 因此逐步撰写Padavan学习文件和一些想法
如有错误, 多所难免, 希望指证! 欢迎讨论和学习..
实话实说, 只说明有用到和知道的(有的我真的连碰都没碰过=.=""), 没用到的就略过了=_="..
IPv6我就没有全部测过了, 而且我在测试DHCPv6目前出了包...
Padavan一直发出这个讯息:
dhcp6c[1429]: advertise contains no prefixes status
还在查怎么一回事...XD
全部的测试建构于固定IP和DHCP配发的环境下..
我没有PPPoE, 没得试!...SORRY...
=====================================================================
Padavan f/w是针对ASUS部分机种的第三方优化方案, 基于Linux-based kernel(大多都是BusyBox solution), 比起原厂f/w提供与众不同的GUI和模组. Padavan f/w对于部份机种的支持系因为仅针对于MIPS-based CPU solution调校, 它并不能支持ARM-based CPU架构.
Link: http://code.google.com/p/rt-n56u/
从官方网站进去后, 可以直接看到Padavan主要系针对N56U的RT3662 solution进行优化与调校, 从左边f/w选单下载所需的Padavan f/w:

尾部单字: dlna, aria, base等代表同样的f/w, 但是自带的模组各有不同, 可以从changelog查看Padavan f/w自带了哪些模组以及移除掉原本存在的模组:

根据官方网站描述, Padavan f/w提供如下列表的多种特征, 其中包含了硬件加速(Hardware Acceleration)的支持, 真正呼叫RT3xxx ASIC driver去执行相关的硬线加速电路:

当刷新成Padavan f/w并且登入它的GUI接口后, 便可以看到与原厂非常不同且简约清新的操作画面:

GUI的操作简单易懂, 且相当直觉.虽然Padavan f/w移除掉QoS模组(和IPv4 H/W NAT一起工作会出现问题), 但也增强了许多特性, 包括了Monitoring的强化以及硬件加速的特征.

Hardware Components
根据N56U的硬件设计, 主要包括了: RT3662F SoC, DDR2 RAM buffer, 802.11n 2.4GHz RF PHY和1Gb/s ASIC Switch logic.

从上图的PCB照片可以看到几个主要的IC元件组成, RT3662F这个SoC为主要的中央单元, 包括了一颗MIPS-based CPU操作, SoC负责与其他元件通讯与协调, 从如下的方块图可以看出SoC包括了各种不同的任务区块:

由于无线单频的情况下, 另外透过一条PCIe lane接入一颗2.4GHz的802.11n Wireless PHY(RF/BBP/MAC): RT3092. 实体连接(PHY port linking)接入了一颗Realtek的Switch chip: RTL8367M, SoC与Switch之间的host-bus频宽为1Gb/s. RT3662本身SoC高效的主要特征包含了Frame Engine元件, Frame Engine让SoC兼任了NPU的各种操作, NPU使得traffic进入SoC时, 引入fast-path直接由特定的ASIC进行处理, 而不用透过cpu port的slow-path送到CPU去handle, 大幅提升吞吐量操作(900~950Mbps).

为了让traffic透过fast-path传入, 这个前提是packet的格式必须是ASIC能够识别的, 当然! wireless traffic全部不能被ASIC加速电路操作, 因此它会提升CPU loading. 从Frame Engine可以看到一个关键的部分: PPE(Packet Processing Engine). 这个模组即为大幅提升吞吐量的ASIC重要元件, PPE等于担当了NPU的责任, 因此它可以负载标准的ethernet packet. PPE包括以下的相关特征:

ASIC的PPE虽然提供了这些特征, 但必须视f/w加载的driver而定, driver加载将会初始化上述的特征并且执行运作. 从PPE可以看出除了对标准IPv4 packet的加速, 也包括了PPPoE加速的支持(without MPPE), 在一般家用环境上, PPE能够大幅提升WAN端效能, 因为居多使用者接入PPPoE协定来连结因特网(Internet). PPE能承载的频宽大约1Gb/s的吞吐量. PPE提供对H/W QoS的加载, 在Padavan f/w因为某些原因已将QoS module移除, 而且原厂的module似乎是software-based, PPE的QoS实际上没有任何作用.

Wireless本身SoC已经具备, 不过在单频的情况下(5GHz), 为了能够支持2.4GHz频带另外接入了2.4GHz Wireless PHY(RT3092), 但是从Wireless进入的traffic全部无法被PPE加载, 请注意! Wireless与Wired网络不是同个层级下的硬件架构. 无线流量会被CPU全部handle, 要注意高负载的情况, 比方说多个wireless clients, 大量的multi-threading网络环境(N65U的情况可能不同, 它的硬件架构有些不一样).

N56U包括了一颗128MB的DDR2-800 RAM, 不算多也不算少, 请谨慎注意RAM的负载量, 尤其是USB Application, 因为caching的情况下会大幅占用RAM buffer, 并且提升CPU loading.

CPU是所有SoC的心脏, 也是最重要的处理单元, CPU必须负载各种业务, OS本身的操作, packet的处理, 兼任内部debug等..RT3662内置了一个MIPS-based CPU: 74Kc, clock为500MHz, 这是一颗用的相当广泛的泛用化single-thread CPU, 不具备FPU.

CPU本身不算太好, 但也不至于太差, 足以负载300M的无线网络流量, 但是要注意的是! 请尽可能避免使用VPN, 因为它是完全的software-based, 加解密操作都要交给CPU执行, 由于RT3662是74Kc, 不是高性能版本(74Kf), 要小心负载量, 因为他能够操作的VPN吞吐量很低, 在MPPE工作后, 会大幅提高CPU loading.

Padavan System
在进入Padavan系统后, 可以看到非常值观的GUI接口. 其中左半部为context menu.

这边将会重点说明: VPN, Monitor, Wireless, LAN/WAN, Firewall. 其它部分仅会快速带过. 系统本身仅提高两种语言: 
本地化语言(Russia)以及国际语言支持(English)

Network Map可以说是一个dashboard, 提供了基本的整体资讯, 让使用者快速了解当前的网络环境.

使用者可以设定GUI管理的存取控制, 允许WAN端(Inbound)存取哪些管理服务(Administrative traffic), 与原厂f/w不同的地方是port range.

比较不能理解的是, 与原厂f/w一样都是一次只能一个User存取GUI, 其它User无法同一时间登入, 它没有允许限制一次可以登入的连线数量. 有时带来了不便, 比方说在进行网络调整的时候, 2台电脑以上进入GUI检查却只能一台使用, 这样的限制不会提升安全性, 只会徒增困扰.

AP模式的切换在Padavan提供两种模式使用: Wireless Router Mode (Default) 和 Access Point Mode (AP)

默认的情况下是一个Router Mode, 这代表了除了L2功能之外,还包括了L3/L4或著以上的功能, 例如IP routing, NAT, DHCP等. 而AP mode就是单纯的L2 Bridge, 它仅具备有关L2的转发功能. 在这个模式下, SPI Firewall, Routing和NAT等都会全部被关闭掉.
一个如下图的案例, 当PC client发出DHCP请求时, 中间的Router处于Router/NAT或著AP/Bridge mode下不同情况的操作.

当Router/NAT mode的情况下, PC cient发出DHCP请求(UDP, 67-68, 广播), 中间的Router会直接接收这个请求并且最后配发IP给该client, 那对于DHCP Server来说将永远不会收到这笔DHCP请求, 因为它已经被处于Router mode的Router给处理掉; 反之, 当Router被设定为AP/Bridge/Transparent mode情况下, 将会把client端的DHCP请求记录直接转发到DHCP Server, 而DHCP Server就会收到该请求并且进行后续动作, 完整一个DHCP的操作.

AiDisk & USB Application
AiDisk是一个精灵模式, 它与USB Application是完全关联的, 用于配置连接在N56U上的USB储存装置. 除非有必要, 否则建议尽可能不要使用它, 因为他会大幅消耗内存, 并且额外消耗CPU time.

如果需要使用的话, 必须选择如下的选项以利内存回收, 否则被cached的内存将会很慢释放:

下图为当使用USB Drive做为N56U上的附加储存装置(Add-in Storage)进行FTP的存取操作时, CPU使用率以及系统内存负载情况:

从上图可以看出, 除了系统内存上cached memory消耗很大之外, CPU也占用一定程度的使用率(CPU Usage). 这是使用SanDisk的低阶随身碟16GB的情况下, 流量大约4~9MB左右, 下图记录了一小段时间的吞吐量情况:

针对USB Application的管理, Padavan提供了基础的RBAC, 可以简单新增/修改/删除使用者帐户, 并且调整当下的目录存取权限:

Padavan允许USB储存装置挂入以下的存取服务, 包括常见的FTP服务:

Padavan也允许透过特定的USB装置提供其相关服务: USB Printer提供打印机服务和接入3G/4G(LTE) USB装置使用Wireless WAN功能:

以下为Padavan针对储存装置(USB Storage)提供的相关组态设定, 有些设定是针对机械式的储存装置:

Note(s):
1. Padavan支持NTFS格式的档案系统(File System).

2. 如下为使用500GB USB Drive连接至N56U进行FTP操作的最大I/O极限:

从上图来看, 受限于CPU的影响. I/O接口15~22MB之间, 无法再拉升, 因为Administrative Traffic是无法扔入PPE加速.
[UPDATED, 201402131744] How to use Transmission?
在Padavan提供了一个现成的套件工具:Transmission, 这个工具可以用来支持BitTorrent协定的P2P传输, 包含了对magnet的支持. 利用该工具可以使Padavan直接操作BitTorrent协定进行P2P资料交换传送至安装在USB上的储存媒体(建议机械式硬盘). 使用前必须要先在储存媒体上建立transmission的空目录:

当指定的目录生成后, 开启Torrent Transmission服务, 它包含了Incoming Port(inbound)以及内置的WebUI登入接口所使用的RPC Port:

之后再从SPI Firewall允许这项服务(Transmission)存取:

到System Log的Port Forwardinh进行观察, 发现会多出几笔纪录:

使用者不须手动设定Port forwarding去做DNAT转发, 只需在SPI Firewall开启相关服务将会自动新增相关的转发纪录. 使用PRC Port指定Public IP登入WebUI, 是一个精简的交互式操作环境:

从上图可以看到已经成功开始操作BitTorrent协定的资料通讯了. 接下来使用System Info的CPU monitor观察负载情况:

从WebUI进行相关组态的设定, 检查CPU的负载以及网络吞吐量:

可以发现对CPU的冲击其实不小, 当torrent(s)数量愈多, 排程的下载任务愈多, 相对造成CPU loading也会随之增长, 使用时须注意负载情况.
Transmission版本的韧体可以提供高阶的GUI操作接口, 而且UI的操作更为友善, 设定项目也较为丰富:


Software-based VPN
VPN Server与VPN Client可以配置VPN的连接环境, 他能支持如下的VPN协定:

配置上并不困难, 居多使用这可能会配置PPTP或著L2TP, OpenVPN较麻烦一点. 由于VPN是完全的software-based, 加密的操作会对CPU造成重大打击:

VPN对CPU的杀伤力极强, N56U并没有独立的ASIC来负责VPN的加解密操作, 虽然Padavan使用上不困难, 在没有必要的情况下, 并不建议使用, 额外使用x86 CPU的独立NAS获取的效益更佳(ex: SYNOLOGY, QNAP, etc...).
MPPE encryption is software processed by router CPU and is very hard, max 24-25Mbit/s. PPTP w/o MPPE ~170Mbit/s
当然! 可以选择完全不加密, 吞吐量会提高许多, 不过几乎没有使用者会这样做, 除非不在乎安全性问题.
[UPDATED, 201402181941] How to setup the PPTP Server?
使用VPN可以使得Remote Network与Local Network看起来就像是在同一个LAN下, 彼此透过一条专属的tunnel相互通讯. 在Padavan支持了几种VPN通讯模式, PPTP是最简单的通讯模式, 设置PPTP是相当易用的. 在设置PPTP让远端网络通讯, 可以看到如下图的相关设定:

其中可以设定验证模式以及加密强度, 默认是使用MPPE-128加密, 这个加密方法对大幅提升CPU loading并且改进安全性. 往下则可以设定基本的帐户资讯, 设定帐号以及该帐号之密码:

除此之外可以设定VPN client指派的IP位址, 按照默认会与LAN绑在同一个网段下, 如需要隔离则可以更改Allocate Subnet for VPN Tunnel的配发网段, 这将会把VPN client绑在其他网段下:

完成这些设定后, client便可以透过相关的应用程式与设置PPTP VPN的Padavan连线, 从System Log可以查看连线中的过程:

使用MPPE-128加密通讯用的tunnel. 通讯完成后, Routing table会出现改变, 它会增加一个固定的VPN client的routing:

而client部分, Routing table也同样出现一些变化: routing的增加以前不同的计量(Mertic)变化:

从VPN的连线资讯可以看到一个被建立的session存在, 包括了指派的IP资讯:

VPN的通讯使得Routing table增加了新的default route(0.0.0.0/0)并且为最高优先(Metric最低), 因此所有的通讯会转发到这条default route, 这代表一个虚拟的PPTP tunnel已经被建立. Ralink RT3662并没有实作相关的VPN硬线加解密(enc/dec)电路, 请注意CPU loading的负载:

当启用MPPE-128去加密tunnel后, 会造成网络效能上的打击, 吞吐量会出现明显的下降, 并且CPU loading会大幅提升. PPTP虽然简单易用, 不过先前需评估当前的网络情况而定, 如果使用者的网络相当快速(>100M), 将不得不注意当前的系统资源负载情况. Padavan所有的VPN都是software-based, 加解密模式的启用会对网络效能造成打成, 只有选择不进行加解密的操作获得大幅改善, 不过安全性会受到影响.

Resource Monitoring
Padavan比起原厂f/w多出两个重要的Monitor: CPU和Memory. 这两个Monitor对于使用者来说是非常有帮助的, 随时可以监控当前的机器负载状况为何?! 下图为顶部直观的资源占用原件表示CPU和内存的使用率情况:

CPU Usage的资源监视器:

Memory Usage的资源监视器:

一个与原厂f/w相同的部分, Traffic Monitor依然是存在的, 方便使用者查看当前的网络流量负载情况, 并且提供几种时段的查询:


Wiresless 2.4/5GHz
Padavan提供两个频段的无线网络调整: 2.4GHz和5GHz. 并且提供Guest, Bridge, Filter, RADIUS验证以及进阶的专业设定:

使用Guest AP可以建立特属的Guest连线, 用于阻断与LAN的连线并且允许孤立Guest之间的通讯(即不允许). 虽然不具备Captive Portal机能, 但也是个简单的Guest访问机制的实现.

Isolaion between Guest AP and LAN: 用来决定是否阻断与LAN的通讯.
Set AP Clients Isolated: 孤立Guest之间的通讯 (即Guest之间不能直接相互连线).
透过Bridge机能可以实现AP与AP之间的串接以延长通讯距离, Pradavan允许如下几种方式实现:

可以使用WDS或著建立Server-Client的主从架构, 不过这些并非是一种标准的Mesh架构, 也没有提供相关的AP Load-balancing, 但不失为一种延长通讯距离的简单方案, 并且成本较低.
Padavan允许使用进阶的RADIUS验证提供远端验证存取, 前提是必须有RADIUS Server的存在, 如果使用Windows Server, 需放行这台AP的连线, 即新增一个RADIUS Client并且允许连线.

设定完RADIUS连线, 也需将验证方式调整为RADIUS的验证存取:

虽然Padavan撤掉了QoS模组, 但对于Wireless所支持的QoS依然按照标准支持, 相容了对WMM规范(802.11e)的支持.

在Padavan无法做任何调整, 比方说你无法重写优先权顺序(Priority), 这边优先权并不是一般所讲的伫列(Queue)优先权, 而是同一个排列下不同的优先级, 可以使用上层支持QoS的设备重写顺序(如果存在的话). 如下图使用FortoGate改写DSCP(相容COS)重写优先级:

下图为以太网络(Ethernet)规范定义的802.1P与无线网络的WMM QoS优先权的COS对应:

也可以参考UBNT对于WMM QoS标准记载的相关文件: UniFi - How is QoS and prioritization handled?
http://community.ubnt.com/t5/UniFi-Frequently-Asked-Questions/UniFi-How-is-QoS-and-prioritization-handled/ta-p/412487
一般默认的情况下为BE(Best Effort), 大家都是公平同等, 公平竞争, 即不会重排列的FIFO(有些traffic会例外, 例如Administrative Traffic).
由于DSCP, COS, TOS等的QoS设置对于一般使用者甚至MIS都过于艰涩难懂, 因此居多情况下几乎都不会去用它. 在Padavan的设定中, 没有使用到可以完全忽略这个WMM QoS项目. DSCP, COS, TOS等..., 容易被硬件实作(Hardware-based), 因此大多的L2 switch或著具备NPU机能的switch logic都存在这类的H/W QoS机制. 在RT3662F SoC的Fame Engine也是没有例外:

不管是SoC内置的5GHz频段以及外接2.4GHz的PHY(RF/BBP/MAC), 经过ADC/DAC=>MAC之后, 还原成封包(packet)进行后续的处理并没有特定AP/NP logic操作, CPU(MIPS 74Kc)必须承载这个业务, 以致CPU资源会有一定程度的消费:

5GHz和2.4GHz WiFi traffic会同时消费CPU资源, 这有可能会大幅提高loading, 因此需要注意这个情况, PPE不能够加载这些traffic以减轻CPU负担. 下图为2.4GHz WiFi client存取FTP服务时, 消耗的CPU loading以及吞吐量输出情况:

在WAN的设定中有一个Hardware offload NAT/Routing IPv4的设定项目, 其中有两个看起来像是WLAN的PPE加速:

但Wireless client与AP(Padavan)取得通讯上网后, 却不是那么一回事! CPU(MIPS 74Kc)依然要被消费资源去操作无线流量. 事实上, 该选项选择WLAN一起被offload到NPU看起来更像是当traffic请求WAN端时(inbound), 进行NAT(DNAT)转发并且交由PPE操作:

在N56U的无线方案是以SoC内置加上外连的Wireless PHY(RF\BBP\MAC)一起双频(Dual-band)输出, 由于外连的2.4GHz PHY(RT3092)操作traffic, 将无线信号进行转换经过基频单元(BBP)的ADC/DAC转换输出到MAC还原为封包资料, 但是有关TCP/IP stack相关的操作无法在这个2.4GHz PHY处理, 它必须送到SoC的CPU(MIPS 74Kc)进行后续业务操作(AP/NP), 在同时输出5GHz和2.4GHz的情况下, CPU业务将有可能变得很繁重, 所幸Frame Engine中的PPE大幅承载了以太网络(Ethernet)标准IPv4流量以减轻负担, 否则无疑是雪上加霜. 在另一款的N65U将2.4GHz PHY变更了设计:

从原本的RT3092(RF/BBP/MAC)更换为RT3352, 而SoC采用RF3883F(MIPS 74Kc, 500MHz), 这样的变更使得情况变的不同! RT3352与RT3883F本质上是同类型的, 都属于SoC. RT3352主要用于2.4GHz的Wireless承载, 比起N56U的RT3662+2.4GHz PHY(RF/BBP/MAC), 2.4GHz的业务完全是由RT3352来负责, 由于内置了一颗CPU(MIPS 24Kc, 400MHz), 因此将由本身的CPU来负责2.4GHz无线频段的开销, 对于主要CPU(Main CPU; RT3883F)来说, RT3352就像是一颗协处理器(Co-processor), 极大的程度减轻了主要CPU去负载该业务的开销. RT3883F+RT3352就像是双CPU架构, 只是RT3352负载2.4GHz无线频段的业务, 而RT3883F仅负责5GHZ无线频段.

LAN&WAN Configuration
Padavan的LAN以及WAN的设定与原厂f/w稍微有一些变化, 不过基本上都是一致. Padavan的WAN的设定允许选择不同类型的连线, 除了PPPoE之外也包括了VPN连线:

除了IPoE(标准IPv4封包交换)以及PPPoE之外, 其余连线类型皆无法透过内置的PPE进行加速, 必须注意! VPN连线是会严重打击网络性能. PPPoE能够被PPE负载是该SoC的一个高效特征, 虽然同时支持的sessions数量有限, 但大多情况下几乎可以受益于PPE的良好表现.
PPTP and L2TP cannot HW_NAT offloaded for RT3662. Only IPv4/IPv6 and PPPoE (up to 900Mbit/s) => IPv6加速目前没包含

不论来自LAN或著WAN的traffic, 在默认的情况下, 都可以排入NPU操作以提高网络性能. 在一个LAN之间的相互传送资料下, 这是一个简单的L2转发(forwarding), 它不会经过SoC, 仅会在switch logic之间相互转发frame(高效能), 只有当routing到非同一个网段下才有可能经由switch logic转发到SoC进行操作, 在Padavan操作下即为LAN=>WAN的转发. 由于外部网络(Internet)并不会知晓LAN网段的IP range(Private IPs), 基于安全性以及资料保证会建立一个table记录public IP以及Private IP之间的对应, 即为NAT转换, 下图为来自Fortinet教育文件的一张NAT转发概念图:

上图看到内部的192.168.1.0/24会透过外部网络看的到的Public IP: 172.20.120.14透过NAT转发出去, 为了让远端网络能够识别来源为何?! 表头(Header)的Source会从192.168.1.x/24替换为172.20.120.14(Src Port乱数对应LAN的IP的Src Port)后送出去, 这种基于来源端的转换, 可称为SNAT(Source-NAT); 将表头的来源掉包为Public IP, 因为上层Gateway有这笔Public IP的routing. 在上图的范例, 包括了使用built-int Sniffer进行相关的packet追踪, 结果如下每笔记录列出:

一般大量的NAT转换意谓对应的table size也会水涨船高, 这表示所需内存空间更大, 转发效率更为重要. N56U所使用的RT3662F SoC, 它所对应的家用环境, 一般情况下并不会遭遇到大规模的NAT转发, 例如同时存在7~8万个sessions; 因此足以应付大多的应用: P2P, 线上影音等.. 在SoC提供的Frame Engine, 期内置的PPE加速器能够支持TCP和UDP封包格式(依存限制), 并且提供基于ASIC的H/W NAT转发, 从Padavan的WAN设定下可以看到相关项目:

从Hardware offload NAT/Routing IPv4最后一个Disable即表示关闭H/W NAT, 此时会将所有的NAT转发不会经由fast-path, 而是引入较慢的slow-path传送到CPU进行操作, 其效率会比基于ASIC的H/W NAT转发相差3~4倍以上. 当启用或关闭H/W NAT之后, 可从System Log查看相关执行纪录:

根据以下两张图, 比较了H/W NAT开启与关闭的不同情况下所表现的吞吐量, 当关闭H/W NAT的情况下(LAN=>WAN):

可以看到Downlink常常出现一堆高峰值, 但整体而言并不平坦, 相对的; 他依赖非常多的CPU资源, 从CPU Load可以看到这是满载的情况下, 过重的负载会影响整个网络性能, 使其受到打击. 而在启用H/W NAT后则出现不一样的变化(LAN=>WAN):

Downlink可以是非常的平坦, 不会随便一堆CPU的I/O中断而受影响, 这是H/W NAT启用后由Frame Engine的PPE负责封包的转发及操作, 他维持了整体网络环境的高效益, 并且巨观地提升网络I/O吞吐量, 一般如果不是debug或著测试用途请勿关闭H/W NAT. 下图是用FGT200B对N56U监控的Traffic Monitor, 左右为CPU和H/W Acceleration负载时的不同流量情况(LAN=>WAN):

由于没有开启Jumbo frame, 用FTP传输大型档案, PPE加速的情况下频宽卡在一定程度就无法再上去; 使用FGT200B监控CPU负载traffic的吞吐量还不算太差, 不过这时CPU已经完全满载(100%), GUI操作会有明显的延迟情况.
[UPDATED, 201402140031] PPE vs. QoS vs. Non-QoS
这边刷入原厂f/w启用QoS比较Non-QoS与PPE加速不同的差异, 在QoS的设定如下图所示, 一个默认的流量塑形和新增的优先权:

使用FTP传输大型档案, 取得不同的吞吐量情况, 如下图所示:

可以看到PPE加速永远保持最好的情况, 并且CPU loading是最低的, GUI操作是平滑顺畅的. 重点在于启动QoS以及一般CPU负载的差异, 当启动QoS后, 吞吐量比起未启动QoS有所下降, 但是基本上都保持在200Mbps以上, 足以应付100~150Mbps的因特网(Internet), 虽然两者在这样的吞吐量情况下(>200Mbps), CPU loading已达100%, 并且GUI操作出现明显的延迟感.
Note(s):
设定默认的流量塑形, 调整在100(推荐)~150Mbps避免CPU负担过重的吞吐量能有效改善网络效能以及GUI操作平滑顺畅.

(非常愚蠢的转圈圈技术...!!)

当一个SNAT的请出转送出去之后, 即反方向(Reversed)转发回来源端, 根据NAT建立的table找查出对应的Client并且送回, 这是一个情况. 那么, 由外部网络对N56U下某一个client进行某种请求, 比方说是FTP(20, 21)请求, 这会是另一种情况, 外部网络必须要能正确请求内部网络下的某一个client, 在Padavan的设定下透过Port Forwarding去指派对应.

外部网络的来源请求N56U下的某一个client, 并且对应FTP资料服务(21), 由于外部网络只会知道WAN的Public IP, 因此让WAN IP与被请求的client进行对应即可, 请求是FTP服务, 双方的port没有任何改变, 让WAN IP对应LAN client并且使用FTP port. 在System Log的Port Forwarding会出现该笔的对应纪录:

如下为来自Fortinet教育文件的案例图, 使用Port Forwarding:

外部网络由于只会知道172.20.120.14这笔Public IP, 并不知晓内部网络的192.168.1.110这笔纪录, 但是外部网络依然可以正确存取到该client的资源. Port Forwarding实现了这个结果, 172.20.120.14<==>192.168.1.110进行对应并且使用80 port存取Web资源. 当外部网络直接存取172.20.120.14, 使用80 port请求时, 透过Port Forwarding直接转发到192.168.1.110, packet的header中的DST(目的端)会被替换, 这样的操作即为对目的端的NAT转发, 可称为DNAT(Destination NAT), 由于他是一个Public IP以一个固定port(fixed port)去对应LAN的其中一个client IP, 为固定且静态的一对一, 因此又可称为Static NAT. 在上图的范例, 包括了使用built-int Sniffer进行相关的packet追踪, 结果如下每笔记录列出:

当你需要将某一台client暴露在外部网络下, 即为全部的port与Public IP完全对应, 请使用DMZ(Demilitarized Zone).

只能指定一台client作为DMZ, 这是很合理的, 因为只有一个WAN IP去完全对应一个client. 但是一个例外的情况会存在, Administrative Traffic以及Port Forwarding(DNAT)的转发, 其优先权会完全高过DMZ的转发. 优先级如下:
Administrative Traffic => Manual DNAT Traffic => DMZ Traffic
因此从System Log进行观察, 发现Port Forwarding table顺序也是如初一辙:

从上图可以看出有两笔转发纪录的port是一模一样的, 192.168.1.1:21和10.2.150.190:21, 这说明了在DNAT转发的过程中必定会发生冲突. 由上往下按照优先级, 属为Administrative的192.168.1.1必定是最高优先权, 因此在DNAT转发的过程中将永远不会抵达10.2.150.190:21. 
这种情况的发生在启用USB Application的时候可能会碰到, 开启的服务(Service), 比方说FTP(21), Padavan在操作的过程中直接DNAT转发对应到192.168.1.1:21的Administrative的IP去直接存取USB Drive, 而使用者又在Manual Port Forwarding设定的相同的Port转发指向不同的client IP, 这时就会形成所谓的Port冲突(Port Conflict). 其结果就是Manual Port Forwarding的client将永远不会被抵达, 要解决这种冲突情况只有转发不同的port或著停用相关的Router Service才可以避免发生; 按照上图的范例, 为了存取10.2.150.190:21, 将192.168.1.1:21为FTP的Router Service关掉即可:

Padavan支持DDNS主要针对来自PPPoE或著ISP使用DHCP配发的IP提供Domain Name的转发. 提供对如下主流的DDNS服务:


在Padavan对于LAN提供的MTU大小支持允许扩展到16K, 这种超出IPv4标准以太网路封包大小1500bytes称为Jumbo Frame:

虽然可以将MTU大小拉到16K, 不过要注意的是client同样开启Jumbo Frame后, 他有机会提高LAN网段下的I/O吞吐量(双方都要开启).

但是却可能会导致LAN=>WAN之间的通讯异常, 这并非为f/w带来的问题(issue), 而是硬件限制所引发的. 确实, RTL8367M号称支持16KB的MTU大小, 可是RT3662F的SoC可不是这样:

从上图来看, 这完全是硬件问题所导致的, SoC根本不支持超过4KB的MTU大小的packet. 强制client启用超过4KB的Jumbo Frame只会导致LAN=>WAN的通讯可能会有异常的情况. 对于Jumbo Frame大小的建议, 请于client使用默认的IPv4标准以太网路封包大小即可(1500bytes).
Note(s): Administrative Traffic的packet不支持Jumbo Frame, 因此需要使用USB Application的服务, 请勿于client端开启Jumbo Frame.

不管是WAN或著LAN当设定的对于Router(N56U)的本地IP后, 会自动产生一笔固定的静态路由(直接连结), 他的优先权是最高的. 并且当WAN IP设定完成后, 会立即产生一笔0.0.0.0/0的Default Route, 这个默认的路由会指向Gateway. 从System Log的Routing Table进行观察:

10.2.129.0/24以及192.168.1.0/24分别为WAN以及LAN的本地网段; 127.0.0.0这是默认会产生的loopback, 永远生效. 如果请求的目的端(DST)并不属于上述的网段, 将会自动透过default(0.0.0.0/0)转发到10.2.192.100的Gateway(UG)往上请求, 因此可以看出Iface的接口是对向WAN的eth3接口, br0则是Port1~4的LAN.
当对于一个目的端的请求并非来自Gateway之后, 而是从LAN往下寻找, 例如LAN网下接一台Router, 往下请求的网段为192.168.2.0/24. 由于Padavan下没有这笔路由, 因此必须要自行加入让Padavan得知有这笔资讯, 否则他将会往上层Gateway(UG, 10.2.129.100)转发, 结果就是永远无法抵达(Unreachable). 从Route设定下加入需要的静态路由, 如下图所示:

在增加192.168.2.0/24的静态路由指向192.168.1.101的Gateway(UG), 使用System Log的Routing Table进行观察:

可以发现有了这笔的路由纪录, 因此下次对于192.168.2.0/24请求将会转发至下层的Gateway(UG, 192.168.1.101)进行访问. 使用静态路由保证了特定路由的转发, 避免不可抵达(Unreachable)的情况发生.

Padavan提供STP(Spanning Tree Protocol)的基本功能, 用来预防异常的L2 loop情况发生(同一层).

按照默认, 这个功能是启动的.


IPv6 Connection
在IPv4中, IP寻址长度是由四组8字节成一组32位元长的一串二进制数字. 为了理解以便于计算, 将其转换为十进制格式, 如下的范例所示:

由于IPv4的寻址空间不足应付现今的需求, IPv6解决了这个问题. 它提升了寻址长度; 相对的, 计算上也变得较为复杂, 如下图的范例:

IPv6是由8组16位元长组成128位元的一长串二进制数字. 为了理解以便于计算, 将其转换为十六进制格式(8001.0DB8.AC10.FE01::). IPv6还附带了首码(prefix)用于区隔网络前缀(network prefix)和接口ID(interface identifier). 一台client取得的IPv6位址是独一无二, 一个Unicast形式:

network prefix为routing prefix和subnet id组成, 而interface id则可以用来表示client真正的唯一位址, 用以作为识别. subnet id可以被用来对本地网络切割数个子网段.
一个案例取得了一个LAN网段所使用的IPv6网络前缀: 1234:5678:9012:0200::/56, /56为routing prefix, network prefix=64. 规划8个子网段.
1. 得知subnet id为64 - 56 = 8, 可用来切割数个子网络.
2. 计算关键部分: 存在subnet id那一段16位元长的十六进制字串(:200:).
3. 将存在subnet id的十六进制字串转成二进制字串. :200: => 0000 0010 0000 0000
4. 取得subnet id的那一部分用于计算子网络( [ 和 ] 符号选取): 0000 0010 [0000 0000]
5. 规划所需的子网络, e.g., [0000 0001]~[0000 0008]规划8个子网络=>0000 0010 [0000 0001]~0000 0010 [0000 0008] => 201~208
6. 转换为十六进制, 再全部组成为真正的IPv6网段: 1234:5678:9012:201::~1234:5678:9012:208::
7. 配合subnet id相关的计算后, 附带network prefix(/64): 1234:5678:9012:201::/64~1234:5678:9012:208::/64
最终, 这便是规划出来所需的8个IPv6子网段(1234:5678:9012:201::/64~1234:5678:9012:208::/64).

Padavan提供了基本的IPv6网络功能, 使用者可以藉以设定完成IPv6通讯, 支持的IPv6通讯模式如下:

其中DHCPv6包括了不同的IP取得方式: SLAAC和Stateful的DHCPv6指派

SLAAC与Stateful DHCPv6差别会在于header其中的两个flag设定不同(M, O flags).

DHCPv6部分需要上层网络设备支持, 如果是固定IP的情况下, 可以选择最快的SLAAC直接由上层委派IPv6位址于WAN端或著设定Native Static, 请注意固定IP的情况下LAN网段的规划部分, 它会涉及到基本的子网络切割(IPv6没有Subnet mask概念, 它是用prefix长度).
一般大多属于PPPoE的使用者则需要申请Tunnel建立IPv6通讯.
有关IPv6的H/W offloading由于可能的bug情况, 现已被强制关闭掉, 因此现在都是交给CPU(MIPS 74Kc)去handle.

[UPDATED, 201402141253] How to setup IPv6-over-IPv4 tunnel with Tunnel Broker?
通常采用浮动制IP配发的用户, 由其是使用PPPoE连线的, 为了使用IPv6会应用Tunnel Broker技术建立一条IPv4 tunnel封装IPv6封包转发到IPv6网络, 这样看起来就像是两个环境同时运作一样(Dual-stack).

对于终端的client用户来说, 一般会下载专属的Tunnel Broker拨接软件来建立tunnel; 而另一种方式就是透过支援IPv6的网络设备来建立tunnel, 这需要视该网络设备所能提供的IPv6机能而定. Padavan对于IPv6支持了IPv6-over-IPv4 tunnel使用Tunnel Broker与IPv6网络连线:

在透过Padavan设定IPv6 with Tunnel Broker之前, 必须先申请Tunnel Broker的连线资格取得相关的连线资讯, 这边使用HE申请tunnel资格:

当完成申请取得资格后, 可以免费建立5个tunnel. 对于一台N56U来说, 只需要一个即可.

建立一条tunnel之后, 可以查看相关的连线资讯, 包括了服务器端, 用户端, 首码, IPv6 DNS以及配发的LAN网段资讯:

从Routed IPv6 Prefixes资讯看出允许两种网段分配形式: 自动设定(autoconfig, Routed /64)和手动切割(Routed /48). 针对Padavan使用手动切割. 点击对手动切割的指派去配发一组固定的IPv6网段, 用于LAN网段的规划. 首码为/48这代表了有存在subnet id的可能, 此为routing prefix, 将network prefix扣除routing prefix取得subnet id(64 - 48=16).
一个范例为2001:470:cdcf::/48, network prefix为64, 取得subnet id(16)后, 取得存在subnet id的那段二进制字串用来规划子网段.
1. 2001:470:cdcf:[0000]::/48, subnet id长度不小, 因此可以很弹性规划, 这里简单设定为: 2001:470:cdcf:[0001]::/48
2. 已经应用了subnet id来规划子网段, 将原本的首码(/48)更改为/64: 2001:470:cdcf:[0001]::/64
3. 2001:470:cdcf:[0001]::/64此为所需的一组IPv6组网段, 可将其配置在Padavan的IPv6设定里.

将相关的资讯填入至Padavan的IPv6设定里, 首先设定有关Tunnel Broker的端点资讯以及WAN端的部分:

其中一个关于MTU的资讯, 可以从HE的网站取得该数值设定(Default: 1480):

接下来配置有关LAN的IPv6网段部分, 请注意LAN的网段规划:

按照刚刚的LAN网段计算的范例, 可将2001:470:cdcf:1::/64填入, LAN IPv6 Address填入自订的Unicast位址(2001:470:cdcf:1::1), 此为对于LAN的上层Gateway, 然后填入LAN网段的首码(Prefix, 64), 完成这些设定后将其套用. 可从Network Map查看相关的组态资讯:

最后进行基本的连线测试以确定Padavan设定的IPv6是否正常通讯, 这边使用FGT80C设定固定IPv6位址连线测试:

于client端使用tracert进行追踪:

虽然经过不少节点, 但是最终与Padavan设定的IPv6成功通讯, 完成一个连线的过程(ICMP).
Note(s):
1. 使用DHCPv6(stateless)配发IPv6可以取得IPv6 DNS资讯; SLAAC(RA only)则不会!

SPI Firewall (Stateful Packet Inspection Firewall)

Padavan提供所谓的SPI Firewall机能, 这个Firewall具备一些基本的防护能力, 包括Filter(Port, MAC, URL), DoS, SYN Flood Prevention等.
SPI表示Stateful Packet Inspection, 对当前traffic穿入(Inbound/Outbound)防火墙(Firewall)时进行相关的封包检测, 防火墙可以截取有关封包的资讯,例如SRC, DST, SRC_Port, DST_Port, Protocol(TCP/UDP/ICMP, etc)等..., 透过这些资讯进行封包检测(Packet Inspection), SPI能够处理何种程度得视该硬件以及软件的机能而定. 

SPI只是一个封包探测的检测过程(部分packet), 它没有涉及到特制化的样版清单匹配(白名单)以及异动封包内容的操作. 在中高阶的防火墙产品会涉及到的封包检测(Packet Inspection)可能不单单只是一个单纯的SPI, 它可能还会牵涉到清单匹配(pattern-matching, ex: White-list), 内容检查(Content Inspection; basic or complete content)等, 因此对于系统效能以及系统内存使用会非常敏感.

不同形式的检测方式对于系统资源消耗也因此有所差异, 精准度也不一样:

大量的检查(Inspection)会严重影响防火墙性能, 涉及到特殊的清单匹配或著内容检查没办法只是单纯的L3/L4 NPU直接加载.., CPU会承载业务或著其他专属特制化的ASIC来分担相关操作, 分离式架构在中高阶的防火墙产品是比较常见的.

在Padavan无法提供复杂的Firewall Inspection, 但提供了基本的SPI机能, 适应于一般家用环境. Padavan对于SPI Firewall的实作使用了iptables来达成基本的实作, 提供单纯的允许(Allow)和阻挡(Block):

DoS Attacks Protection请参阅如下wiki:
http://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%AD%E6%9C%8D%E5%8A%A1%E6%94%BB%E5%87%BB
SYN Flood Attack(DoS, 攻击网络频宽)请参阅如下wiki:
http://zh.wikipedia.org/wiki/SYN_flood
在Netfilter中可以允许VPN穿透形式以及ALG服务的启用或关闭, 另外包括了NAT Loopback. 其中一个项目: Maximum Connections; 它会牵涉到PPE的最大承载sessions数量, 一般情况下, 请勿随意调整.

其他URL, MAC, LAN to WAN filter则是不同用途的过滤功能; MAC Filter请使用在同一层的L2转发环境下(MAC无法经过L3设备转发出去).
Note(s):
1. 基于iptables的实作, 可以透过linux command查看相关资讯: 使用Administration的Console和SSH的CLI环境, 如下为GUI的Console:
iptables -L -v -n

相关热词搜索:固件 Padavan

上一篇:5G 2G的7620老毛子Padavan固件
下一篇:Wavion WBS-2400简要拆解分析

分享到: 收藏