RK3188 取得Root權限方法 (Tromsmart T428)

方法:

1 打開 USB Debugging (Settings –> Developer Options)

2 透過USB連接你的RK3188裝置到你的電腦.

3 此時電腦將會通知偵測到新的硬體,請下載下面網址所提供之驅動程式並安裝之:

https://www.dropbox.com/s/uqisjj4hqftlaxa/GEEKBUYING_Rockchip_Batch_Tool_v1.6.rar (password: GEEKBUYING.COM)

4 安裝完驅動程式之後,請下載下面的root工具:

https://www.dropbox.com/s/cddnevg1f5ftobg/RK3188_ROOT.rar (password: GEEKBUYING.COM)

5 解壓縮後,請點擊“ TPSparkyRoot.bat” 完成所指示的步驟後重新開機.你的設備就已經取得root權限了!

虛擬網卡 TUN/TAP 工作原理

TUN/TAP是一個虛擬網卡的介面，在 Linux 以及 window$ 上面都有支援
一些 VPN projects 像是 OpenVPN 都是基於這個介面實現 tunneling 的機制

tun (network TUNnel) 虛擬的是 點對點 設備
-simulates a network layer device
-layer 3 packets, such as IP packet
-used with routing

tap (network TAP) 虛擬的是 乙太網路 設備
-simulates an Ethernet device
-layer 2 packets, such as Ethernet frames
-used to create a network bridge

下圖是原作者麻利輝所畫的簡圖 (請查閱Reference中的網頁)



以下就已建立好的 VPN 連線來探討封包流經的順序：

1. Outgoing

首先，應用程式會利用 tun 這個網卡將資料送到 VPN 的 peer去
而這個應用程式正是圖中的「使用tun/tap驅動的進程」
在經過 TCP/IP protocol stack 之後來到 tun (Virtual NIC Part) 成為 VPN 封包

下一步，「數據處理進程(OpenVPN)」
會由 tun ( Char device Part) read 出剛剛的VPN封包
再次丟往 TCP/IP protocol stack，最後到達 Real NIC 而送往「物理鏈路」(外部網路)

下圖是就原圖所做的一點更動，明確表示出資料流的順序


2. Incoming

從物理鏈路收到給 OpenVPN 的封包，
接下來此封包經過 protocol stack 被拔掉一層層的 headers
最後就是原始封包的 data payload 部份，也就是 VPN"封包"

OpenVPN 再把這個 VPN"封包"經由 tun (Char device part) write 到 Virtual NIC

Virtual NIC 收到封包後，再把他送往 protocol stack
最後就回到使用 tun interface 的應用程式

圖例與 outgoing 一樣，只是數字順序相反


[Reference]
虛擬網卡 TUN/TAP 驅動程序設計原理 by 麻利輝
http://www.ibm.com/developerworks/cn/linux/l-tuntap/index.html
TUN/TAP - Wikipedia
http://en.wikipedia.org/wiki/TUN/TAP

Hairpin NAT

In the below network topology a web server behind a router is on private IP address space, and the router performs NAT to forward traffic to its public IP address to the web server behind it.

The NAT configuration would look like below:

/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.1.2
add chain=srcnat out-interface=WAN action=masquerade

When a client out on the Internet with IP address 2.2.2.2 establishes a connection to the web server, the router performs NAT as configured.

1. the client sends a packet with a source IP address of 2.2.2.2 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 2.2.2.2.
3. the server replies to the client's request and the reply packet has a source IP address of 192.168.1.2 and a destination IP address of 2.2.2.2.
4. the router determines that the packet is part of a previous connection and undoes the destination NAT, and puts the original destination IP address into the source IP address field. The destination IP address is 2.2.2.2, and the source IP address is 1.1.1.1.

The client receives the reply packet it expects, and the connection is established.

When a client on the same internal network as the web server requests a connection to the web server's public IP address, the connection breaks.

1. the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
3. the server replies to the client's request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.

The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.

To fix the issue, an additional NAT rule needs to be introduced on the router to enforce that all reply traffic flows through the router, despite the client and server being on the same subnet. The rule below is very specific to only apply to the traffic that the issue could occur with - if there are many servers the issue occurs with, the rule could be made broader to save having one such exception per forwarded service.

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.2 protocol=tcp dst-port=80 \
  out-interface=LAN action=masquerade

With that additional rule, the flow now changes:

1. the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. It also source NATs the packet and replaces the source IP address in the packet with the IP address on its LAN interface. The destination IP address is 192.168.1.2, and the source IP address is 192.168.1.1.
3. the web server replies to the request and sends the reply with a source IP address of 192.168.1.2 back to the router's LAN interface IP address of 192.168.1.1.
4. the router determines that the packet is part of a previous connection and undoes both the source and destination NAT, and puts the original destination IP address of 1.1.1.1 into the source IP address field, and the original source IP address of 192.168.1.10 into the destination IP address field.

The client receives the reply packet it expects, and the connection is established.

However, the web server only ever sees a source IP address of 192.168.1.1 for all requests from internal clients regardless of the internal client's real IP address. There is no way to avoid this without either using a router that can do application level DNS inspection and can rewrite A records accordingly, or a split DNS server that serves the internal clients the internal server IP address and external clients the external server IP address.

This is called - among other terms - hair pin NAT because the traffic flow has clients enter the router through the same interface it leaves through, which when drawn looks like a hair pin.

Time Zone data

http://www.iana.org/time-zones

關閉/啟用 IPv6 臨時位址 (temporary address, privacy extensions)

Windows Vista/7/8/Server 2008:

netsh interface ipv6 set privacy state=disabled store=active

netsh interface ipv6 set privacy state=disabled store=persistent

輸入之後，馬上生效，不需重開機。如果需要啟動，則只要將上述指令中的 disabled 改為 enabled 即可。

IPv6 環境已經沒有 NAT 這回事了(至少目前是這樣)，使用 global IPv6 位址連上 internet 之後，就可以與其他人互通。

一般來說 IPv6 位址 (128 bits) 由 Prefix 和 Interface ID 所組成。 Prefix 可視為網路編號，因此除非網路改號，否則是不變的。而 Interface ID 一般是用 EUI-64 的方法，參照 MAC 位址來產生的，所以只要是利用同一張網路卡，其 Interface ID 也就不會變。

因此，雖然 IPv6 在 internet 直接互連可以增加效率、非常便利，但一直使用相同的位址，很容易被壞人盯上。所以 RFC 4941 定義了 IPv6 Privacy Extension，讓 IPv6 host 可以隨機產生 Interface ID，定期更換，以提高安全性。這樣的位址又有人稱為臨時位址 (temporary address)。

因此，雖然 RFC 裡面建議預設不要啟動，但常用的作業系統 (Windows, Mac, Linux) 都會優先使用臨時位址連線。

REF:http://hlchang.com/?p=919#more-919

HINET IPV6 DNS

IPv6 DNS: 2001:b000:168::1

[轉] 寬頻網絡部署IPv6探討

　　雖然IETF的IPv6工作開始於1990年，但截至目前為止IPv6還是很少被用於個人業務上。雖然各國政府/機構一直在推動采用服務提供商部署IPv6，但是沒有真正的商業上的驅動力，一方面沒有新的應用需要IPv6，另一方面普遍認為IPv6的引入成本太高。上述原因導致了服務提供商很少關註在住宅寬帶網絡中引入IPv6。但是，隨著公網IPv4地址的枯竭，智能手機和M2M設備的迅速普及，越來越多的人認識到需要通過引入IPv6來維持業務增長並為客戶提供完善的服務。

　　從技術角度看IPv6與IPv4是不兼容的，並且IPv6中的一些新概念會改變寬帶網絡的運作模式：

　　IPv6的尋址方式：單播：LLA（鏈路本地地址），GUA（全球單播地址）和ULA（本地唯一地址），組播尋址，廣播尋址的取消

　　IPv6報頭的變化：例如下一個報頭，等

　　SLAAC：無狀態地址自動配置，不需要使用DHCPServer

　　缺省路由器支持使用路由器通告（RA）

　　DHCPPD：通過DHCP的前綴委派為家庭網絡分配前綴地址

　　鄰居發現（ND），MLD（組播偵聽發現）等通過ICMP支持

　　盡管這些改變都有很好的理由，但是這些概念會影響IPv6如何在住宅用戶網絡部署，網絡中各個網元對IPv6的支持程度也不盡相同。

　　2終端設備硬件/操作系統

　　PC：MACOS，Linux，WindowsVista/Windows 7具有良好的IPv6支持，而Windows XP可工作在雙棧模式，Windows 98不支持IPv6

　　手機終端對IPv6的支持剛剛開始（Symbian，iPhone，Android等）

　　VoIP系統對IPv6的支持較較差

　　IPTV系統/機頂盒對IPv6的支持較差

　　CPE/家庭網關

　　在新的xDSL/GPON/以太網設備上開始支持IPv6

　　接入節點

　　DSL/GPON/以太網設備：大多數廠商開始支持IPv6。

　　匯聚/邊緣/核心網絡設備

　　大多數設備很早就開始支持IPv6，有些已經部署了一段時間。

　　固定移動業務邊緣節點（BNG/ BRAS，媒體網關GGSN/ PGW）

　　BNG/BRAS：大多數廠商支持基於IPv6的PPPoX，IPoE（DHCPv6/ DHCPv6 PD）和LNS

　　GGSN/PGW：大多數廠商都支持3GPPR8和R7的IPv6架構

　　應用

　　最終用戶應用程序：是否能在合適的操作系統上運行，是否能夠運行IPv6API從而支持IPv6網絡連接

　　網站：是否支持IPv6尋址和連接

　　CDN：是否支持IPv6尋址和連接

　　上述因素對引入IPv6的影響取決於運營商所選擇的網絡設計。接下來會具體分析在在固定/移動網絡中的引入IPv6的場景，因為大多數組播IPTV平臺還沒有準備好向IPv6遷移而大多數IPTV方案不需要使用公網IPv4地址，所以分析將集中在建立單播IPv6連接上。

　　PPPoE網絡中引入IPv6

　　在使用PPPoE的電信網絡環境中如何支持IPv6在寬帶論壇的TR–187中有明確定義。在PPPoE/L2TP網絡中引入IPv6不會對接入和匯聚網元產生任何影響。IPv6PPP會話認證方式與IPv4一樣使用PAP/CHAP或option82，並且IPv4和IPv6會話的認證可以在同一個認證階段同時進行。由於PPPoXIPv6CP只定義鏈路本地地址，全球IPv6地址通常由DHCP或SLAAC分配。在使用IPv6路由型家庭網關的情況下，在家庭網關和BNG/BRAS之間需要下列機制確保IPv6連接。

　　PPPoEIPv6CP用於鏈路本地地址分配（LLA）

　　DHCPv6的前綴委派（IA- PD）用於獲取局域網地址前綴

　　無狀態DHCPv6用於獲取其他配置參數

　　當部署numberedRG模型時，有狀態的DHCPv6（IA-NA）用於獲取家庭網關的IPv6地址。而部署unnumbered RG模型時，則不是必需的

　　使用路由器通告分配默認網關

　　采用路由型家庭網關PPP模型時，建立IPv6連接的典型流程如下圖所示：

圖1IPv6PPPoE接入– 路由型RG：DHCPv6 PD

　　另一種用於提供IPv6PPPoE連接的方法是使用橋接型家庭網關，也稱為主機模型。為確保在這個模型下的IPv6連接，在終端設備（通常是個人電腦）和BNG/BRAS之間需要執行下列機制。

　　PPPoEIPv6CP用於鏈路本地地址分配（LLA）

　　SLAAC用於為主機獲得全球單播IPv6地址

　　無狀態DHCP用於獲取其他的配置參數

　　使用路由器通告分配默認網關

　　采用橋接型家庭網關PPP模型時，建立IPv6連接的典型流程如下圖所示：

　　

圖2IPv6PPPoE接入– 橋接型RG：SLAAC

　　提供PPPoE業務時，使用N:1VLAN或1:1VLAN的結構對於部署IPv6還是IPv4沒有區別。在采用PPPoE的寬帶網絡中引入IPv6只對BNG和CPE/RG產生影響，對CPE/RG具體影響取決於家庭網絡使用橋接模式還是路由模式。采用RADIUS進行認證/計費/COA時，還需要RADIUS支持一些新的屬性。

　　IPoE網絡中引入IPv6

　　在電信網絡中支持IPv6IPoE在寬帶論壇中的TR–177中有詳細定義。引入IPv6IPoE對網絡的影響主要取決於部署的VLAN模型是1:1模型還是N:1模型，以及家庭網絡選擇橋接型還是路由型部署模式。

　　當采用1:1VLAN模型時，可以從VLANID判斷家庭身份。因此引入IPv6時，只要現有的設備支持基本的IPv6轉發機制，無論是接入網絡還是匯聚網絡都不需要有任何變化。而采用N:1VLAN模型時，接入節點至少要支持LDRA（輕量級的DHCPv6中繼代理），以確保BNG/BRAS知道收到的DHCP請求是從哪個用戶發出的。同時，接入節點最好能夠支持anti-spoofing。

　　使用IPv6路由型家庭網關部署DHCPv6，在家庭網關和BNG/BRAS之間需要執行下列機制以確保IPv6連接。

　　DHCPv6的前綴委派（IA-PD）：為家庭網關分配唯一的IPv6前綴在家庭網絡中使用。

　　如果使用numberedRG模型，為家庭網關分配DHCPv6廣域網地址

　　從BNG收到有效路由器通告後，設定BNG鏈路本地地址作為下一跳缺省路由

　　采用路由型家庭網關IPoE模型時，建立IPv6連接的典型流程如下圖所示：

圖3IPv6IPoE接入（xDSL/FTTx接入）-路由型RG：DHCPv6 PD

　　當部署橋接家庭網關模型來支持IPv6IPoE時，對網絡的影響取決於是采用DHCP還是SLAAC為終端設備分配地址。采用DHCP時，橋接型家庭網關IPoE模型與路由型家庭網關IPoE模型的主要區別是只對主機分配一個IA地址而不需要DHCPPD地址。值得關註的是要確保家庭網絡中的IPv6設備之間的通信在本地完成的，不通過BNG。

　　而采用SLAAC則會帶來一系列新的問題。在N:1的VLAN部署模型中，BNG不知道路由器請求消息是從哪個用戶發來的，因此BNG不知道在路由器通告消息發送哪個前綴。為了解決這個問題，接入節點需要在路由器請求消息中增加一個線路標識選項，就像對DHCPv6所做的一樣。與此同時，BNG/BRAS需要確保對應的路由器通告消息可以被接入節點轉發到正確的用戶處。

　　由於接入網絡的split-horizon的轉發行為，重復地址檢測（DAD）消息不會被送給鄰近的用戶，BNG需要支持DAD代理功能幫助確保DAD功能正常工作。因為這些問題仍在IETF討論，因此目前很少有BNG/接入設備支持這種場景。

　　移動網絡中引入IPv6

　　移動網絡中的IPv6連接場景在3GPPR7/R8等規範中定義得很清楚。建立IPv6連接所涉及的主要網元是UE和GGSN/PGW。

　　在移動網絡中提供IPv6連接，在UE和GGSN/PGW之間需要運行下列機制：

　　SLAAC（路由器請求/路由器通告）使用/64地址提供IPv6連接

　　在創建的PDP響應中的PCO選項中提供DNS信息

　　從GGSN/PGW收到有效路由器通告後，設定GGSN/PGW的鏈路本地地址作為下一跳缺省路由

　　3GPP從R8開始定義了一種機制，在單一的PDP/BearerContext上使用PDPtype(IPv4IPv6)同時分配IPv4和IPv6地址。有了這一機制，引入IPv6時不需要額外創建PDP Context。然而，在R8之前，每種PDN類型（IPv4和IPv6）都需要一個PDP Context，這會降低GGSN的可擴展性。

　　

圖4移動網絡引入IPv6

　　在解決IPv4公網地址耗盡的問題和逐步引入IPv6的過程中有很多可能性，也會有很多部署的實際問題，阿爾卡特朗訊一直使用ISOCORE第三方獨立實驗室驗證在各種IPv6部署場景下的部署細節。阿爾卡特朗訊將會通過細致的技術驗證工作幫助固定和移動運營商在從IPv4向IPv6遷移的過程中做出正確的選擇，並從技術和業務上解決多種緯度的問題。