Castle on a Cloud

在 OpenWRT 的預設設定中, /etc/config/network 的設定可以分成兩部分, 第一部分是CPU那一端的設定檔, config 'interface' 'loopback'        option 'ifname'   'lo'        option 'proto'    'static'        option 'ipaddr'   '127.0.0.1'        option 'netmask'  '255.0.0.0' config 'interface' 'lan'         option 'ifname'   'eth0.1'         option 'type'     'bridge'         option 'proto'    'static'         option 'ipaddr'   '192.168.1.1'         option 'netmask'  '255.255.255.0' config 'interface' 'wan'         option 'ifname' 'eth0.2'         option 'proto' 'dhcp' 在此部分, 我們可以看到, 對於 CPU 那一端的網路設定而言, 除了 Linux 常見的 loopback 網路設定外, 還有兩張網卡, 分別對應於上一篇文章中圖片內的 eth0 和 eth1, 事實上, eth0.1 和 eth 0.2 對應於同一張物理網卡, 只是虛擬成兩張網卡使用.

對於 OpenWRT 系統來說, 最重要的功能就是提供網路通訊, 而對於 WiFi AP 而言, 網路一共分成兩個角色: 作為有線網路的路由器, 以及作為 WiFi 無線網路主控節點, 而對應於 OpenWRT 的設定檔而言, 則是對應於 network 和 wireless 兩個設定檔中. 為了理解這兩個檔案的設定, 我們要先理解硬體上的設定, 我們以 TP-Link 1043 為例, 其 CPU, 有線網路和無線網路的關聯性如下圖: 來自:  https://openwrt.org/fr/toh/tp-link/tl-wr1043nd

在 Linux 系統中, cron 是一種將工作排程的方式, 關於 cron 的敘述, 可以參考鳥哥的介紹: http://linux.vbird.org/linux_basic/0430cron.php 而在 OpenWRT 中也支援 cron 的功能, 要啟用 cron 的功能, 我們要先編輯 cron 的排程列表, 輸入 crontab -e, 就可以開始編輯 cron 的工作排程, 其格式如下: 來自:  http://einverne.github.io/post/2017/03/auto-reboot-openwrt.html 簡單來說, 就是定義 分; 時; 日; 月; 周期 以及要執行的工作, 舉例而言, 我們可以定義: */1 * * * * echo "hello" 這樣就會每一分鐘都顯示一次 "hello" 訊息, 我們可以在 logread 中看到: root@OpenWrt:~# logread Jun 21 07:17:01 OpenWrt cron.err crond[1211]: USER root pid 1495 cmd echo "hello"

在完成 OpenWRT 的移植之後, 接下來就要開始設定 OpenWRT 的設置, 畢竟, 都建立了一個以 Linux 為基底的 WiFi AP, 當然會希望它可以完成比既有 WiFi AP 更多的功能. 在 OpenWRT (以backfire為例) 中, 關於功能的設定, 都放在 /etc/config 資料夾之下 root@OpenWrt:/etc/config# ls dhcp      dropbear  firewall  fstab     mountd    network   openflow  system    wireless 其中, dropbear 是 OpenWRT 的 SSH server, fstab, mountd 負責檔案系統部分, dhcp, firewall 如其名稱所示, 負責 IP 位置請求以及防火牆, openflow 為 openflow 的相關設定, network 為有線網路的設定, wireless 為無線網路的設定, 這兩部分應該會找時間再記錄細節. system 為一些系統上的設定, 例如所在時區.

在之前的一系列討論中, 說明了 802.11ad 中 beam training 的流程, 然而, 考慮到其技術和傳統 WiFi 的差異, 還是有必要特別討論以下兩點: 在進行 beam training 時, 傳送端和接收端的天線場型 由於 beam training 同時佔有了 beacon 的區間, 因此我們要討論 beam training 如何取代原有的 association 流程 針對第一個問題, 我們可以參考這篇實作的論文: O. Jo et al., "Holistic design considerations for environmentally adaptive 60 GHz beamforming technology," in IEEE Communications Magazine, vol. 52, no. 11, pp. 30-38, Nov. 2014. 在圖中 (figure 2), 明確說明不同階段下, 傳送端和接收端使用的天線場型, 其中, SLS 也就是在一開始的 beacon 階段, 此時, 只學習傳送端的天現場型, 接收端都使用 quasi-omni 的天線場型, 而之後的 beam refinement 和 beam training 才會學習接收端的場型, (這兩部分之後會再找時間詳細介紹)