にたまご。

よく寝てよく食べる

Google Technical Writing One

GoogleのテクニカルドキュメントのWriting courseを受講しているので内容のサマリーを自分のメモ用に書き留めておく(適宜updateする)。 オープンソースや標準化系ドキュメントを書く人向けに見えるが、技術に関わる文章を書く機会のある人は見てみる価値ありかなと。

  • Terms：専門用語。一度省略型の専門用語を使うことにしたら、最初に省略形の断りを入れた上でそれを使い続ける。 Captive Portal Working Group(capport WG) is formed in 2015..... . The co-chair of capport WG is...

  • Acronyms：頭文字を使った省略単語；文書中で2,3回程度しか使わない単語はわざわざ頭文字省略しない。何回も出てくる場合は使うべし。また、明らかに省略前の単語が非常に長い場合は使うべし。

明確な文章を書くためには

  • あいまいな指示語表現は使わない：名詞に置きかえる、またはThis +名詞で使う。

  • 能動態と受動態：能動態の方が明確な表現になるため、基本的には能動態を使う。ただし、科学研究のレポートや論文等ではIt has been suggested~, XX were evaluated...のように受動態を使い控えめな表現にすることがある。

  • 強い動詞を使う: 文章の内容を明確にするために曖昧な動詞は使わないようにする(例えばoccurやhappenは弱い動詞、traggersやgenerateは強い動詞。他にもbe動詞は弱い動詞に分類される)

  • There is/areの使用頻度は減らす：主題+動詞を明確にした文で書く。

  • (optional)特定の形容詞と副詞はなるべく少なく：明確な文がゆるく定義されてしまうため。特に、テクニカルドキュメントにおいては、筆者による主観が強いように読み手にとられる(マーケティングっぽい印象になってしまう等)可能性があるため。(例：XX run amazingly fast ...)

コードと同じように文書も簡潔に書こう

短いドキュメントの読みやすさ・保守>長いドキュメントの読みやすさ・保守

  • 1センテンスに1アイデア(トピック、コンセプト、意見)：長い文章をやめる。主張したい内容ごとに一文に切って整理する。ついつい接続詞を使って内容を詰め込みがちなので気をつけたい。

  • 長い文章はリスト化する形で書いてしまっても良い(特に操作する手順とか)

  • 無関係の単語は減らすor削除：我々は不必要な動詞を入れてしまうことがある。provide XX...と書いたけどXXを動詞にすればそれで十分だったパターンよくある。

  • 従属節は減らす：which/that/since/unless/untilなどで主節をサポートする場合がある。その場合は、従属節が主節のアイデアをあくまで補足・拡張しているという点で必要か、または別のアイデアについて語っているため別のセンテンスに分けるべきか精査してほしい。1センテンスに1アイデアを守ろう。

  • ThatとWhichはきちんと使い分ける：我々はどっちを使っても良いと思いがちであるが、一般的に米国では「which は不必要な従属節に使う(which節がなくても文章構造として成立する)」、「thatは文章構造的に必要な従属節に使う」とされている。

リストと表

良いリストや表は複雑な技術情報を整理してオーディエンスに見せてくれる。さらに技術系の読者は基本的にリストが好き。

  • リストの種類を把握しよう：順序関係ないものには通常の箇条書きを使う。物事の順序について書く際は数字の箇条書きを使う。一文にカンマで区切って物事を並べる埋め込み箇条書きというのもあるが、あまり効果的ではないので、最初に一文書き(だいたい.... as following:とか)+次の行から箇条書きが始まる形に変えよう。

  • リストアイテムは平行に：効果的なリストを作るには、同じ形式・濃度の情報を並べる。二つは能動態で書いたのにもう一つは受動態で書くなんてことは止めよう。

  • 数字の箇条書きのそれぞれの項目を命令動詞(start, launch, run etc.)で始める

段落

  • 段落の冒頭の文は重要である(読者が冒頭しか読まないかもということを含めて)。

  • 各段落に1トピックに集中する。次の段落やいくつか後の段落で起こることを書いてはならない。

  • 段落は長すぎず、短すぎず。長いと脅迫的に見えるし短すぎると1段落に対して3-5文がちょうどよい。

また、１つの段落は下記のような流れで構成すると良い。

  • WHAT: 何を読み手に伝えようとしているのか？
  • WHY: なぜ重要なのか？
  • HOW: どうやってユーザーはそれを使えば良いのか？

聴衆

  • 読み手を定義する：ソフトウェアエンジニア？学生(大学生or院生)？サイエンティスト ？非エンジニアポジション？Tech PM？彼らはすでに基礎知識として何を知っているか、逆に何を知らないか。
  • 読み手が何を学びたいか明らかにする
  • ナスカの地上絵や相撲、クリケット等の複雑な事柄を入れないこと。熟語の扱いも気をつけたい(非ネイティブだと意味がわからない等)

文書

  • Scope: 良い文書は最初にスコープが決められている。This document describes~◯◯
  • Non-scope: さらに良い文書は、スコープでないものについても述べられてる。This document does not describe~
  • オーディエンスを定める: I wrote this document for ◯◯ who support ◯◯ software. 他にも前提として読んでおくべきドキュメントがある場合は明記しておくことも良いだろう
  • エグゼクティブサマリーを冒頭に1ページつけておく
  • アウトラインを整理する
  • ドキュメントのモジュール化: トピックをセクションに分割する

句読点

  • コンマを使うか、ピリオドにするか。
  • 文章の曖昧さをなるべくなくすため、オックスフォードコンマを使うことが望ましい。
  • 異なる内容が一文に並ぶ場合はピリオドで。
  • セミコロン：ピリオドは異なる主張を分けるのに対し、セミコロンは関連性がある考えを一文に統合するためにある。
  • Em-dash：◯◯◯-◯◯と呼ばれているが-は〜
  • 括弧：重要でない文は括弧で。

(マークダウンについては割愛します)

IETF101の注目WG/BoFはデータセンター、セキュリティ、5G関連？

IETF

3/17-3/23にかけてIETF101会合がロンドンで開催されます。その中でもできたばかり or 今回始めてミーティングを開催する注目のトピックが以下になります。

IETF101のみどころ

DC関連
今回はデータセンター(以下DC), ルーティング周りがアツいようです。昨今のDCは、単一のネットワークに対して数万以上のエンドポイントを持つほどに成長し、トポロジーやトラフィックパターン、迅速な復旧の必要性等の特徴故、DCネットワークには独自の要件がある場合が多いです。上記のような大規模データセンターでのトポロジー、トラフィックパターン、管理性のニーズに対応するプロトコルの策定が新たにIETFの仲間入りをします。

  • ILA(Locator Addressing) BoF: 数十億のノードにまで成長したDCネットワークでは、既存のインフラと相互運用可能なデータセンター、仮想化、モビリティのシナリオにおける、ネットワークオーバーレイの必要性が求められている背景がああります。ILAはカプセル化せずに透過的なオーバーレイネットワークを実現するためのプロトコルを策定します。
  • RIFT( Rounting In Fat Trees) BoF: 上記のようなDCネットワークの集中化に伴い、ディスタンスベクター型とリンクステート型の2種類のダイナミックルーティングプロトコルを用いて、Clos and Fat-Treeネットワークトポロジーにおけるルーティング要求に対処します。Juniper, Comcastが提案中。
  • LSVR(Link State Vector Routing) BoF: リンクステート型とパスベクター型の2つのルーティングメカニズムを用いたハイブリッドルーティングプロトコルを開発し、文書化します。Arrcus, Linkedin, Cisco, Nokia等複数企業が提案中。

RIFTやLSVRについては詳しくは、IETF100報告会で発表者の方のスライドをぜひ！

セキュリティ関連

  • MLS(Messaging Layer Security) BoF: グループメッセージアプリケーション(MessengerとかWhatsAppとか？)における暗号鍵確立のためのセキュリティプロトコルを標準化します。
  • SUIT(Software Update for Internet of Things) WG: IoTデバイスの安全な定期的なファームウェアのアップデートに焦点当てます。SUITに関しても、IETF100報告会で発表者の方のこの資料がわかりやすい！
  • TEEP(Trusted Execution Environment Provisioning) BoF: 同じくIoTのソフトウェアアップデートをシナリオとするTEEPでは、初回のインストール(boot後のアプリ)に焦点当てます。TEEPは毎回BoFやっててなかなかWGにならない印象。。。

5G関連

  • COMS(Common Operations and Management on Network Slices) BoF: 5Gでは、低遅延・強いセキュリティ等、異なる要件に対して、ネットワークを仮想的に分けることで、顧客が提供するサービスの要件に合ったネットワーク環境を提供することができる、ネットワークスライシングという技術があります。COMSでは、このネットワークスライスを配送するアーキテクチャや情報モデルの検討を行います。
  • EMU(EAP Method Update) WG: Wi-Fiの802.1xを用いたアクセスコントロールに広く使われているのがEAPプロトコル(Extensible Authentication Protocol)です。EMU WGは、TLS1.3と5G環境へのデプロイを背景に、必要なEAPの拡張を策定していく予定です。また、このWGの特徴の1つとして、TLS WGや3GPP、EAPの開発コミュニティ等、外部組織や他WGと積極的に連携しながら標準化を進めていくことが挙げられます。

リモートで参加したい

IETFは普段はメーリングリスト(+ WGによってはGithub)ベースで議論が行われ、年3回のオンサイトミーティングがありますが、リモート参加に対するサポートも手厚いです。

「歩くI-Dアナウンス」こと@flano_yukiさんによる、IETFリモート参加のTipsが公開されているので参考に！
qiita.com

おまけ: 今までの議論を追いたい人

◯◯の部分を好きなWGの略語(e.g. quic, capport, httpbis)を入れてください

  1. 気になるWGを決める。=>WGページヘGO: https://datatracker.ietf.org/wg/◯◯/about/
  2. その中でも気になるトピックの関連ドキュメント(Internet Draft)を見つけて斜め読み。
  • 最新の会合の議論を見る。
  1. 会合の様子はYouTubeで見れます。「IETF100 ◯◯WG」とか検索すると出てくるかと思います。(動画の字幕をONにすると純ジャパにも嬉しい。)
  2. 手元にはMinitesを置くとわかりやすいかも？「https://datatracker.ietf.org/meeting/100/session/◯◯」のページにMinites(議事録)があります。

302リダイレクトを使わずにCaptive Portalの認証ページへユーザーを誘導できる？RFC7710

capport IETF

CAPPORT WGでは現在RFC7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs)の改変が行われそうな雰囲気なので、RFC7710について一旦このへんでまとめておく。

背景

現在のCaptive Portalはユーザーのセッションを横取りし、302リダイレクトを用いて強制的にユーザーを認証/同意ページに誘導する、いわば中間者攻撃のような挙動をとるものがほとんどです。この挙動がCaptive PortalにおいてUXを損なっているという背景から、認証/同意ポータルページへ誘導する別の手段が必要とされています。

The Captive-Portal Option

ユーザーのデバイスに「Captive Portalの存在」と「ポータルにコンタクトをとる方法」を知らせるために、DHCPオプションやRAの拡張を用いて、Captive PortalのURIをユーザーのデバイスに広告する方法が挙げられています。いずれも基本的にはCode, Length, URIを含む構成となります。(今のところ、URIは実際にユーザーがアクセスすることとなるポータルのURI、またはCAPPORT APIのURIということになっています。)

f:id:ao0780:20180303163613p:plain

f:id:ao0780:20180303163605p:plain

  • IPv6 RA option: Type 37。このType code37は、RFC7710のためにIANAがアサインしてくれたものです。

f:id:ao0780:20180303163609p:plain

まとめ:

RFC7710は、DHCP/RAのオプションを用いて、デバイスにIPアドレスを割り振る際に、同時にCaptive PortalのURIも配ってしまおうというものです。それにより、以下を実現できます。

  • ユーザーとCaptive Portal間の手続きの簡素化
  • ハイジャックに代わる、よりクリーンな方法の提供(=セキュリティ向上にもなる?)

関連の最新の議論:

  • CAPPORT WGでは他にも、ユーザーとCaptive Portal間の認証情報の手続きを自動化する、CAPPORT APIが策定されており、RFC7710で配るURIはそもそもAPIサーバーのURIなのか、またはポータルページのURIと定義すべきか？
  • “there’s no captive portal to talk to”というシグナルを送る機構が必要

等複数議題が上がっており、本RFCのアップデートも含め、IETF101では議論されそうです。

DNS Queries over HTTPSとネット中立性

IETF インターネットガバナンス

インターネットの標準化を推進する任意団体IETF(Internet Engineering Task Force)では、昨年11月のIETF100にてDOH(DNS over HTTPS) WGの初回ミーティングが開催されました。来たるIETF101@ロンドンでは、２回目となるミーティングが開催予定です。WGで現在議論されているのがdraft-ietf-doh-dns-over-https-03 - DNS Queries over HTTPSDNS Queries over HTTPSです。

DNS Queries over HTTPSの技術面での記事やプレスはたくさんあるのですが、ちょっと違う視点から書いてる海外のおもしろい記事があったので、ネット中立性視点から日本語で補足&まとめてみます。

元記事はこちら：IETF protects privacy and helps net neutrality with DNS over HTTPS • The Register

ネット中立性ってなに

主にアメリカで話題になっている問題ですが、簡単に説明すると「インターネット上のコンテンツやアプリケーション、Webサービス、トラフィック等を、ISP(インターネットサービスプロバイダ)が公正に扱う」ことです。ネット中立性の原理に反する例としては、通信事業者やISPが、特定のコンテンツを優先して配信したり、料金や通信速度で優遇するケースです。身近な例だと、LINEモバイルのコミュニケーションフリープラン(特定のSNSが使い放題。データ通信の上限に含まれない)がこれに当たるかもしれません。アメリカでは、オバマ大統領時代にネット中立性に関する規制が設けられましたが、その後大統領・FCCチェアが変わり、昨年の2017年12月に規制が撤廃され、大きな話題になりました。

(ネット中立性に関しては、バーガーキングのこの動画がわかりやすい↓)
gigazine.net

ISPによるDNS操作が一般化しつつある？

IETF99では、RIPE Atlasを用いたDNSハイジャックの検知に関する発表がありました。例えば、Google DNSのハイジャックの割合を調べると、中国やロシア、その他発展途上国にハイジャックの傾向が目立ちます。これは必ずしも政府による検閲や、ISPによるネット中立性侵害が目的とは限らず、各ISPが独自のポリシーを定めている可能性もあります。しかし、ISPによるDNSの操作が一般化しつつあり、プライバシー面での対策が求められていることは間違いありません。

また、過去には、米VerizonがDNS lookupを失敗した顧客を自社の検索サイトに誘導した上で、顧客が検索失敗した単語に紐づいた広告を出していたため、当時のVerizonのDNSポリシーがネット中立性違反なのではないか、と物議を醸しました(*1, *2参考)。

DNS Queries over HTTPSとは

DNSクエリの通信は暗号化されていないため、なりすましや盗聴等セキュリティ・プライバシーの面で課題があります。例えば、公衆無線LAN環境のようなオープンなネットワークにて、DNSの通信が偽装され、想定外のDNSサーバーへ誘導される場合や、経路の途中で機器によりDNSメッセージの書き換えが起こる場合があります。

そこで、HTTPSをDNSクエリの通信に用いることで、DNSクライアント間の完全性と機密性を提供するメカニズムを開発し、安全な通信を確立しようというのがDNS Queries over HTTPSモチベーションです。

例えば、ユーザーのデバイスがGoogleのPublic DNSである8.8.8.8をDNSリゾルバとして使用する際、そのデバイスはDNSクエリをHTTPSを介して投げることができ、これがend-to-endの暗号化に繋がります。

https://i2.wp.com/respectfulinsolence.com/wp-content/uploads/2016/12/homer-computer-doh.jpg?ssl=1

DOHとネット中立性の関連性は？

このDNS Queries over HTTPSを使えば、インターネットのトラフィックに対して、DNSを用いて何らかのポリシーを課すようなネットワーク(または上記を強いるような政府、ISP)を撃退することの助けになるそうです。

単純にDNSの応答の正当性を担保するのであれば、DNSSECがありますが、DNSSEC自体はISP側でダウングレードすることができてしまいます。そこで用いるのが、ISPの操作の影響を受ける心配がないHTTPSによるend-to-endの暗号化です(=DNS Queries over HTTPS)。

まだ仕様は確定していませんが、DOHクライアントは、ユーザーが検索に失敗した原因を知らせるエラーメッセージを表示したり、クライアントが「通常の」リゾルバにフォールバックすると、何が起こったのかエラーメッセージを表示する等、ユーザーに通知する機能を持つそうです。よって、プロバイダ側からDNSの通信に何らかの操作が行われた際、ユーザーはそれを知ることができます。また、ISPがDNSを用いて差別したいソースを識別している場合、この識別行為は暗号化によりできなくなります。(*実際はDNS lookupがユーザーの識別に不正に使われるのを防いでくれる)

まとめ

DNS Queries over HTTPSは、DNSを用いてネットワークに何らかのポリシー操作を行うような行為を防ぐという意味で、ネット中立性を担保するための技術としても期待されているみたいです。

補足:

Coova Chilli 1.4のインストール方法

capport

Coova Chilli公式のインストール手順を書き残しておく。

Coova Chilliって何

IETFのcapport WGやhackathonでアクティブにrunning codeしている、GoogleのDavid Birdを中心として開発されているOSSのCaptive Portal(Wi-Fiのアクセスコントロール)ソフトウェア。capport WGにおけるInteroperabilityテストもこのOSSベースで試されることが多いです。
 
とはいえ、これだけではCaptive Portalシステムは構築できません。isc-dhcp-serverやRadius、haserl等と組み合わせるとLinux上で構築できます。そのあたりは下記の方々がわかりやすく書いてくださっていると思うので参考にしてください。自分の記事はCoova Chilliのインストール部分のみ触れます。

 

Coova Chilli 1.4(最新版)インストール手順

実行環境:

Raspbian Stretch Lite 4.9 on Raspberry Pi3 

手順:

coova-chilli-1.4をwgetで持ってきて解凍。

$ cd /home/pi
$ sudo wget https://github.com/coova/coova-chilli/archive/1.4.tar.gz
$ tar zxfzf coova-chilli-1.4.tar.gz

buildする

$ cd coova-chilli-1.4
$ ./bootstrap #bootstrap scriptを走らせる 
$ ./configure --help #コマンドにつけるオプションが見れます。加えたい項目があれば、./configure以降に加えてコマンドとして実行。
$ ./configure --enable--miniportal --prefix=/tmp/foo #--prefix=/X/Xでcoova-chilliをインストールする場所を指定できます。--prefix=/tmp/fooにするとrebootすると消えてしまうので、私は何も指定せずに./configure --enable-miniportalだけで実行しました。その場合/usr/local/etc以下にchilliができます。
$ make #buildする
$ make install
$ cd www #終わったらwwwディレクトリも
$ make install

参考:

公式のインストールガイド

このあたりとかが動画つきでわかりやすいと思います。


(俺の考えたさいきょうのCaptive Portal構築の一連のログを残したい気持ちはあるのですが、それは大学が春休みになって余裕ができたら書きたいと思います...)

DHCP option43を使ってAPをWLCにJoinさせる

Wi-Fi NWオペレーション

本記事は下記のアドカレ記事として執筆しています。

SFC-RG Advent Calendar 2017 - Qiita

経験上、本話題は英語での記事はヒットするものも、実際に動いた実績のある設定例が、公式以外で日本語で公開されているケースをあまり見ないなーと思ったので書き残しておきます。

----------------------------------

 　たくさんのアクセスポイント(AP)を集中管理できるのがワイヤレスコントローラー(WLC)ですが、初期状態ではAPは自分たちがどのWLCへ帰属(Join)して良いのかわかりません。そこで、まずAPがWLCを検出できるようにしてあげる必要があります。

　Cisco WLCでは、APをWLCにJoinさせるための設定方法がいくつかありますが、そのうち個人的に最も理解がしやすい/手間がかからないと思われるLinux DHCPサーバーにoption43の設定を書く方法を紹介したいと思います。(他にもスイッチでのoption43設定、Cisco ISC DHCPサーバーでの設定等があります)

DHCP option43とは

　DHCP option43はベンター固有オプションです。これを利用することで、APにWLCの管理インターフェースのIPアドレスを教えることができます。この設定はスイッチに入れることもできますが、今回はLinuxのDHCPサーバーで行う場合の設定方法を紹介します。 

前提

  • DHCPサーバの構築が完了している
  • WLCの初期設定、Interfaceの追加、WLANの追加設定が完了している

実際の設定例

　DHPCサーバー内の/etc/dhcpd.confの該当カラム(自分の環境ではAP-WLC間のマネジメントセグメントであるwireless-mgmtのVLAN)のカラム内に書きます。

*ただし１つのDHCP poolを１種類のAPにだけ割り当てることが可能なため、APの種類が増えた際は、異なるDHCP poolを設定する必要がある。

 

#wireless-mamt
#vlan XXXX
option space Cisco_LWAPP_AP;
option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
subnet X.X.X.X netmask X.X.X.X {  #wireless manegement内のWLCのアドレスとネットマスク
   pool { 
         
         省略
         
         vendor-option-space Cisco_LWAPP_AP;
         option Cisco_LWAPP_AP.server-address X.X.X.X; #managementネットワーク内のwlcのアドレス＝ポータルでアクセスするときのアドレスです
  }
}

 

　これで終わりです。WLC側でこのDHCPサーバーのアドレスを明示的に指定しておけば、APをPoEスイッチに接続すると、DHCP経由でAPにWLCのアドレスがアドバタイズされ、APがWLCを検出できるようになります。

 

＊注意点としては、DHCPサーバーがあらかじめ構築されていないと本設定は動かないため、あらかじめサーバーを構築しておきましょう！

 

 

 

 

cisco WLCでのLaunch failure時のRecovery方法

Wi-Fi NWオペレーション

WLC初期セットアップ時にLaunch failureした時の対応

事象

通常WLCは、電源を入れコンソールケーブルを接続するとCLIで対話型の初期セットアッププロセスが開始する。しかし、WLCのプライマリ・セカンダリパーティションに有効なイメージがない場合、またはRTOSが壊れている場合、下記のような「boot loader menuメニュー」が出てきて、1-4番を選択してもその命令が実行されず、永遠にboot loader menuが繰り返し出てきてしまう。結果、いつまでたっても初期設定の対話画面にたどり着けない。

 

上記の状態になってしまうと、boot loader menuの6番を選ぶ以外手段がない。ということで6番を選択した際のプロセスを紹介する。

 

実際のlaunch failure時の画面 

---------------------------------------------------

Verifying boot loader integrity... OK.

[ ... ]

Press ESC now to access the Boot Menu...

 

Hit the Escape key now

 

============================================================
 Boot Loader Menu
============================================================
 1. Run primary image (Image not found) - Active
 2. Run backup image (Image not found)

  1. Change active boot image
     4. Clear configuration
     5. Format FLASH Drive
     6. Manually update images
    ------------------------------------------------------------
    Enter selection: 4       
    Launching...

  Unable to read "linux.pri.img" from ide 0:2

  Launch Failure

  Loading backup image(Image not found)

  Unable to read "linux.pri.img" from ide 0:2

  Launch Failure

Verifying boot loader integrity... OK.

[ ... ]

Press ESC now to access the Boot Menu...

 

Hit the Escape key now

 

============================================================
 Boot Loader Menu
============================================================
 1. Run primary image (Image not found) - Active
 2. Run backup image (Image not found)

  1. Change active boot image
     4. Clear configuration
     5. Format FLASH Drive
     6. Manually update images
    ------------------------------------------------------------
    Enter selection: 

 

(以下上記プロセスがループ)
  

上記のような事象にあった場合は、

  • ciscoサポートに問い合わせRTOS(+上げたいバージョンのファームウェア)をいただく
  • boot loader menuで6番を選び、手順に従いTFTP経由でWLCにRTOSを転送する

 の2つの手順が必要である。

 

事前準備

  • ciscoサポートに問い合わせRTOS(+上げたいバージョンのファームウェア)をダウンロードする。
  • 今回はMacをTFTPサーバーとし、tftp用ディレクトリにRTOSのイメージファイルを設置。Mac bookとWLCをUTPケーブル1本で繋げる。

 

tftpサーバーの起動

sudo launchtl load -w /System/Library/LaunchDaemons/thtp.plist

以下のように/private/tftpboot/以下にRTOSのイメージ(AS~~がRTOSイメージ名)を置く。 

/private/tftpboot/AS_5500_RTOS-7.0.250.0

 

WLCでのコンソール(CLI)操作

今回自分が組んだ構成。

f:id:ao0780:20171105021148p:plain

 

WLCにコンソールで接続する。以下が入力例。(太字部分)

 

Verifying boot loader integrity... OK.

[ ... ]

Press ESC now to access the Boot Menu...

Hit the Escape key now

============================================================
 Boot Loader Menu
============================================================
 1. Run primary image (Image not found) - Active
 2. Run backup image (Image not found)

  1. Change active boot image
     4. Clear configuration
     5. Format FLASH Drive
     6. Manually update images
    ------------------------------------------------------------
    Enter selection: 6       
    Launching...
    Launching images...
    init started: BusyBox v1.6.0 (2009-02-03 04:56:32 EST) multi-call binary
    Mount failed for selinuxfs on /selinux:  No such file or directory
    starting pid 655, tty '': '/etc/init.d/rcS'
    Use DHCP for ip configuration (Y/n)? n
    Enter switch IP address: 192.168.1.100

  By "switch", the boot loader means WLC
Enter switch netmask: 255.255.255.0
Enter switch gateway: 192.168.1.1
Enter TFTP server IP address: 192.168.1.157
You have entered:
     IP Address     : 192.168.1.100  #WLCのアドレスを設定。なんでもいい。
     Netmask        : 255.255.255.0  #↑のサブネットマスク
     Gateway        : 192.168.1.1      #↑のデフォルトゲートウェイ
     Server Ip Addr : 192.168.1.157  #TFTPサーバー(Mac)のアドレス(WLCのアドレスと同じセグメントであるべき)


Is this correct(y/N)? y
!!! WARNING updating using .aes or unapproved files will disable this unit !!!
Do you want to update RTOS (y/N)? y
Do you want to update Primary Or Secondary Image (P/s)? P
Enter filename for RTOS update: AS_5500_RTOS-7.0.250.0
RTOS update Done ←これが出れば成功。失敗するとCould not Transferingみたいなエラーが出てLaunchできない。
Enter filename for FP update: AS_5500_cavium_main-7.0.250.0

  Depending on your WLC model / boot loader version, you may not be prompted for FP update
FP update Done
Do you want to update an AP image (y/N)? N
AP Images Not Updated
Done.  Restarting...
Restarting system.

 

ここまでくると、あとは再起動しプロセスが終わり次第、コンソールから初期設定ができるようになる。

 

後処理

tftpサーバーは使い終わったらkillする。設置した当該ファイルも削除する。

sudo lsof -i:69
rm /private/tftpboot/AS_5500_RTOS-7.0.250.0 

 

参考: 

- Cisco WLC 2504 fails to boot - Cisco Support Community

- mac osx には tftp サーバーが内蔵されてるので起動してみた - それマグで！