特殊MAC地址---官方保留

IEEE Std 802.1D and IEEE Std 802.1Q Reserved Addresses

Group MAC address value	Organization using the value	Standard using the value	Notes
01-80-C2-00-00-00	IEEE 802	IEEE Std 802.1D IEEE Std 802.1Q	IEEE Std 802.1D Bridge Group Address
01-80-C2-00-00-01	IEEE 802	"	IEEE MAC-specific control protocols
01-80-C2-00-00-02	IEEE 802	"	IEEE Std 802.3 Slow Protocols multicast address
01-80-C2-00-00-03	IEEE 802	"	IEEE Std 802.1X PAE address
01-80-C2-00-00-04	IEEE 802	"	IEEE MAC-specific control protocols
01-80-C2-00-00-05	IEEE 802	"	Reserved for media access method specific use
01-80-C2-00-00-06	IEEE 802	"	Reserved for future standardization
01-80-C2-00-00-07	IEEE 802	"	Reserved for future standardization
01-80-C2-00-00-08	IEEE 802	"	Provider Bridge group address
01-80-C2-00-00-09	IEEE 802	"	Reserved for future standardization
01-80-C2-00-00-0A	IEEE 802	"	Reserved for future standardization
01-80-C2-00-00-0B	IEEE 802	"	Reserved for future standardization
01-80-C2-00-00-0C	IEEE 802	"	Reserved for future standardization
01-80-C2-00-00-0D	IEEE 802	"	Provider Bridge MVRP address
01-80-C2-00-00-0E	IEEE 802	"	Std 802.1AB Link Layer Discovery Protocol address
01-80-C2-00-00-0F	IEEE 802	"	Reserved for future standardization

Standard Group MAC Addresses

Group MAC address value	Organization using the value	Standard using the value	Notes
01-80-C2-00-00-10	IEEE 802	IEEE Std 802.1D	All LANs Bridge Management Group Address (deprectated)
01-80-C2-00-00-11	IEEE 802	IEEE Std 802.1E	Load Server Generic Address
01-80-C2-00-00-12	IEEE 802	IEEE Std 802.1E	Loadable Device Generic Address
01-80-C2-00-00-13	unassigned
01-80-C2-00-00-14	ISO/IEC JTC1/SC6	ISO/IEC 10589	All Level 1 Intermediate Systems Address
01-80-C2-00-00-15	ISO/IEC JTC1/SC6	ISO/IEC 10589	All Level 2 Intermediate Systems Address
01-80-C2-00-00-16	ISO/IEC JTC1/SC6	ISO/IEC 10030	All CONS End Systems Address
01-80-C2-00-00-17	ISO/IEC JTC1/SC6	ISO/IEC 10030	All CONS SNARES Address
01-80-C2-00-00-18	IEEE 802	IEEE Std 802.1B	Generic Address for All Manager Stations
01-80-C2-00-00-19	unassigned
01-80-C2-00-00-1A	IEEE 802	IEEE Std 802.1B	Generic Address for All Agent Stations
01-80-C2-00-00-1B	ISO/IEC JTC1/SC6	ISO/IEC 9542	All Multicast Capable End Systems Address
01-80-C2-00-00-1C	ISO/IEC JTC1/SC6	ISO/IEC 9542	All Multicast Announcements Address
01-80-C2-00-00-1D	ISO/IEC JTC1/SC6	ISO/IEC 9542	All Multicast Capable Intermediate Systems Address
01-80-C2-00-00-1E	ISO/IEC JTC1/SC6	ISO/IEC 8802-5	All DTR Concentrators MAC Group Address
01-80-C2-00-00-1F	unassigned
01-80-C2-00-00-20 — 01-80-C2-00-00-2F	IEEE 802	IEEE Std 802.1Q	Reserved for use by Multiple Registration Protocol (MRP) applications

01-80-C2-00-00-30 — 01-80-C2-00-00-3F	IEEE 802	IEEE Std 802.1ag	Destination group MAC addresses for CCM and Linktrace messages
01-80-C2-00-00-40 to 01-80-C2-00-00-4F	IETF	TRILL	Group MAC addresses used by the TRILL protocols
01-80-C2-00-00-40 — 01-80-C2-00-00-FF	unassigned
01-80-C2-00-01-00		ISO/IEC 9314-6	Ring Management Directed Beacon Multicast Address
01-80-C2-00-01-01 — 01-80-C2-00-01-0F	ISO/IEC JTC1/SC25		Assigned to ISO/IEC JTC1/SC25 for future use
01-80-C2-00-01-10	ISO/IEC JTC1/SC25	ISO/IEC 9314-6	Status Report Frame Status Report Protocol Multicast Address
01-80-C2-00-01-11 — 01-80-C2-00-01-1F	ISO/IEC JTC1/SC25		Assigned to ISO/IEC JTC1/SC25 for future use
01-80-C2-00-01-20	ISO/IEC JTC1/SC25	ISO/IEC 9314-2	All FDDI Concentrator MACs
01-80-C2-00-01-21 — 01-80-C2-00-01-2F	ISO/IEC JTC1/SC25		Assigned to ISO/IEC JTC1/SC25 for future use
01-80-C2-00-01-30	ISO/IEC JTC1/SC25	ISO/IEC 9314-6	Synchronous Bandwidth Allocation Address
01-80-C2-00-01-31 — 01-80-C2-00-01-FF	ISO/IEC JTC1/SC25		Assigned to ISO/IEC JTC1/SC25 for future use
01-80-C2-00-02-00 — 01-80-C2-00-02-FF	ETSI		Assigned to ETSI for future use
01-80-C2-00-03-00 — 01-80-C2-FF-FF-FF	unassigned

Group MAC Addresses Used in ISO 9542 ES-IS Protocol

Group MAC address value	Organization using the value	Standard using the value	Notes
09-00-2B-00-00-04	ISO/IEC JTC1/SC6	ISO 9542	All End System Network Entities Address
09-00-2B-00-00-05	ISO/IEC JTC1/SC6	ISO 9542	All Intermediate System Network Entities Address

Locally Administered Group MAC Addresses Used by IEEE Std 802.5
(IEEE Std 802.5 Functional Addresses)

Group MAC address value	Organization using the value	Standard using the value	Notes
03-00-00-00-00-08	IEEE 802	IEEE Std 802.5	Configuration Report Server (CRS) MAC Group Address
03-00-00-00-00-10	IEEE 802	IEEE Std 802.5	Ring Error Monitor (REM) MAC Group Address
03-00-00-00-00-40	IEEE 802	IEEE Std 802.5	Ring Parameter Server (RPS) MAC Group Address
03-00-00-00-01-00	IEEE 802	ISO 9542	All Intermediate System Network Entities Address
03-00-00-00-02-00	ISO/IEC JTC1/SC6, IEEE 802	ISO 9542, and IEEE Std 802.5	All End System Network Entities Address, and Lobe Media Test (LMT) MAC Group Address
03-00-00-00-04-00	IEEE 802	IEEE Std 802.1B	Generic Address for all Manager Stations
03-00-00-00-08-00	IEEE 802	ISO/IEC 10030	All CONs SNARES Address
03-00-00-00-10-00	IEEE 802	ISO/IEC 10030	All CONs End System Address
03-00-00-00-20-00	IEEE 802	IEEE Std 802.1E	Loadable Device Generic Address
03-00-00-00-40-00	IEEE 802	IEEE Std 802.1E	Load Server Generic Address
03-00-00-40-00-00	IEEE 802	IEEE Std 802.1B	Generic Address for all Agent Stations

Raspberri-Pi Debian Tuning

Speedup CPU:
we can easily modify the cpu work frequency modifying the config.txt file. Just edit /boot/config.txt
arm_freq=900
i always use this hack and my rpi run without problem
Change scheduler/elevator at boot time:
we use more responsive/less disk io usage scheduler:
modify the /boot/cmdline.txt 
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootflags=commit=120,data=writeback elevator=deadline rootwait quiet
Tuning sysctl.conf:
as manual say, sysctl.conf is the “Configuration file for setting system variables”... well there are lot of variables you can put inside this file and for everyone we can write a book.
Our goal is to gain more speed and tell our system to use less io/ram. Let’s put in the /etc/sysctl.conf:
vm.dirty_background_ratio = 20
vm.dirty_expire_centisecs = 0
vm.dirty_ratio = 80
vm.dirty_writeback_centisecs = 1200
vm.overcommit_ratio = 2
vm.laptop_mode = 5
vm.swappiness = 10
Removing unused services:
Removing services is a must to do for every system or computer, i have see some linux server with 256Mb of RAM with bluetooth, pcmcia etc etc service enabled... or pc with 100% cpu busy to run some 3d tube screensaver installed by default... also in Debian RaspberryPi official distro...
Automatically startx on boot:
I didn't use session/desktop manager like gdm, xdm or slim, it’s take ram and slow down starting up. Simply way is to use inittab:
vi /etc/inittab
1:2345:respawn:/bin/login -f root tty1
/dev/tty1 2>&1 (default is 1:23:respawn:/sbin/getty 38400 tty1)
and add this to .bash_profile on root home:
if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then
  exec startx >/dev/null 2>&1
fi 

libiconv: 字元集碼編轉換

from:http://www.jollen.org/blog/2006/09/libiconv_1.html

實作 Linux 系統程式時，常需要做「Unicode 與 Big5」間的字元編碼轉換；嵌入式 Linux 的應用也經常會遇到這樣的需求，例如我們原則上會將文件存成 Unicode，當程式執行時，再決定要輸出成 Unicode 或 Big5 (or GBxxxx)，這時就要使用到 GNU 的 libiconv 專案。

GNU libiconv 用來做字元間的編碼轉換，已經廣泛被使用在 GNU/Linux 系統中，例如 PHP 的 iconv 系統即是使用 GNU libiconv。libiconv 要移植到 ARM9 平臺上也是非常容易的。GNU libiconv 的官方首頁是:http://www.gnu.org/software/libiconv/

把 libiconv 套件解開並編譯後，可以在 src/ 目錄下找到 iconv 執行檔，這是 libiconv 為我們寫好的一個字元轉碼 (conversion) 工具，這個工具相當的實用，比如以 jollen 的網站來說，jollen.org 的網頁是以 unicode 儲存，但是我們發佈的頁面是以 big5 編碼為主，我們所使用的轉換工具便是 iconv。

iconv 的使用可以參考 http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html，我們舉一個例子來說明，比如我想把 big5.txt 文件 (Big5 encode) 轉換成 Unicode (UTF-8)，那麼只要執行：

$ iconv -f BIG5 -t UTF-8 big5.txt

就可以了，參數 -f 指定來源編碼，參數 -t 指定目的編碼，編碼後的字串會輸出到 stdout。字元集 BIG5 也可以寫成 BIG-5，或是 BIG-FIVE，或是 BIGFIVE；要怎麼知道 iconv 可以處理 (接受) 哪些字元集 (character set )，只要執行 'iconv -l' 就可以查詢了，輸出結果會是一大票的字元集列表。

這是使用 iconv 工具的方式，假如要自己寫程式的話也是非常簡單的，因為 libiconv 裡頭只有 3 個函數：

iconv_t iconv_open (const char* tocode, const char* fromcode)：開啟 libiconv。
size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft, char* * outbuf, size_t * outbytesleft)：執行轉碼。
int iconv_close (iconv_t cd)：做完轉碼後關閉 libiconv。

libiconv-1.xx/src/iconv.c 本身就是一個很棒的範例了，大家可以參考。

關於 gettext

關於 gettext (一、簡介)

關於 gettext (二、一個例子)

關於 gettext (po-mode 使用)

TCP offload engine (TOE)

from:http://www.kernelchina.org/node/611
延伸閱讀:Competitive Comparison Intel® I/O Acceleration Technology vs. TCP Offload Engine

TCP減壓引擎，第一次聽說這個名詞，但是並不是一個新的概念了，若干年前聽說過設備廠商在研究在FPGA之中實現TCP Stack，但是後來沒有聽到任何的產品出來，應該是路由設備to host的traffic不多，而對於FW設備，中間的TCP Proxy實現過於復雜，工程上不可能實現。

現在的所謂TOE實現我理解主要用於host的interface之中，用於為Gbits以及10Gbits接口場景中為CPU減壓，例如部署在數據中心內部的服務器，CPU雖然越來越快，但是對於洶湧澎湃的Traffic來說，還是有些力不從心。

上面是TOE應用前後協議棧的差別，我覺得畫的有點絕對，TCP Stack不太可能完全實現在interface之中，其實TOE主要實現如下的offload：

1.TCP/IP Checksum offload

CPU可以不用計算checksum而由網卡計算

2.CPU不用考慮數據的分段了，估計是直接將socket送過來的buf交給網卡。

如果是僅僅實現上述功能TOE是很可能工程化實現的。

在另一篇文檔中提到了TOE的一些優勢，但是我的分析，這個可能是要實現TOP替代整個TCP之後的優勢。

1.減少中斷：不用每個報文都產生中斷，如果10G接口這個對於CPU是很大的開銷。

2.減少memory拷貝次數，很多時候網卡的buffer和app的可以直接共享。

3.協議處理的節約，這個是當然的了。

* http://en.wikipedia.org/wiki/TCP_offload_engine

Understanding UUID

通用唯一識別碼 (Universally Unique IDentifier, UUID) 或是全域唯一識別碼 (Globally Unique IDentifier, GUID) 是一個 128 bits 的整數，並保證其在時間與空間的分佈都是獨一無二的。UUID 由開放軟體基金會 (OSF) 標準化後用在他們的 DCE 系統上，後來在微軟的 COM 系統上發揚光大。除此之外在許多地方也都可以看到 UUID 的身影，如 Linux 上的分割表/區塊裝置就是以 UUID 來標示，或是 RSS 的  標籤也可以使用 UUID，實際上 UUID 是標準的 URN 表示法之一，你可以在任何需要標示單一物件的地方使用 UUID。

UUID 的文字形式為一個 8-4-4-4-12 的十六進位表示，共有 16 個 bytes，有人說使用 UUID 不方便人類辨識，但了解 UUID 的組成後你還是可以從這個表示法看出一些端倪來。本文參考的是 IETF 版本的 RFC 4122。

UUID 共有四個版本，第 13 個字元的位置就是表示版本號。第一種是以時間和網路卡號組成，時間是以一百奈秒為單位，網路卡號理論上是不會重複的，再加上 clock_seq 這個每次開機重設一次的亂數欄位，就算時間回朔了也不會重複，代號是 1。第二種和第四種是以命名空間加上一個 hash 組成的，分別可以使用MD5 或是 SHA1 演算法，算出來後就填到空位中，代號是 3 跟 5。第三種是全亂數組成，代號是 4。

因此我們可以在不同的情境選用不同的 UUID，也可以從 UUID 看出版本跟時間等資訊，如4ef17586-f187-11df-8xxx-xxxxxxxxxxxx 看到第三個區塊是 11df 就可以知道是最近產生的以時間卡號為基礎的 UUID，時間 1dff1874ef17586 解出來就是 2010-11-16 13:42:09.173031.0 UTC。而 7c0fdbe4-1b09-4278-9fc9-5f0c6a1f2ae2 就是純亂數的 UUID，沒有任何意義。

from:http://kanru.info/blog/archives/2010/11/16/uuid-el/Ref:http://en.wikipedia.org/wiki/Universally_unique_identifier

LCP, Authentication, and NCP Stage

Within some of the PPP phases described previously, PPP also goes into specific stages such as LCP negotiation, authentication, and NCP negotiation. For more information, refer to RFC 1548  and RFC 1661 .

LCP (Mandatory Phase)

LCP is a phase in which parameters to establish, configure, and test the data-link connection are negotiated. An LCP state of open means that LCP was successfully completed, while an LCP state of closed indicates an LCP failure.

This diagram shows a conceptual view of an LCP handshake:

The LCP negotiation also uses a parameter called MagicNumber, which is used to determine if the link is looped back. A random string is sent across the link and, if the same value is returned, then the router determines that the link is looped back.

Authentication (Optional Phase by Default)

In this stage, the authentication is performed with the authentication protocol (CHAP or PAP) agreed upon in LCP negotiation. For PAP related information, refer to Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).

For CHAP related information, refer to Understanding and Configuring PPP CHAP Authentication.

Note: Authentication is optional and PPP only enters this stage if it needs to authenticate.

NCP (Mandatory Phase)

This phase is used to establish and configure different network-layer protocols. The most common L3 protocol negotiated is IP. The routers exchange IP Control Protocol (IPCP) messages to negotiate options specific to the protocol (IP in this example).

RFC 1332  says that IPCP negotiates two options: compression and IP address assignments. However, IPCP is also used to pass network related information such as primary and backup Windows Name Service (WINS) and Domain Name System (DNS) servers.

The negotiation occurs with the use of CONF messages, as described in the PPP Negotiation Packets: A Description section of this document.

From: http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800ae945.shtml