Mac 與 PC 鍵盤對應

What firewall ports need to be open for AirPlay to work?

The ports that need to be opened are:
 

Port Number	Type	Protocol	RFC	Used by
80	TCP	HTTP	2616	AirPlay
443	TCP	HTTPS	-	AirPlay
554	UDP / TCP	RTSP	2326	AirPlay
3689	TCP	DAAP	-	iTunes Music Sharing / AirPlay
5297	TCP	-	-	Bonjour
5289	TCP / UDP	-	-	Bonjour
5353	UDP	MDNS	-	Bonjour / AirPlay
49159	UDP	MDNS (Windows)	-	Bonjour / AirPlay
49163	UDP	MDNS (Windows)	-	Bonjour / AirPlay

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