たかちゃん。

FreeBSD で if_urtwm を使ってみる。

9月 102017
 

Amazon で USB Wi-Fi の子機が安く売っているのを発見し、購入しました。 AUKEY の AC1200 というヤツです。似たようなのを出しているメーカ名は色々あって Wavlink だとか、型番が WF-R6 というものだったりします。きっと OEM なんでしょうね。フツーの価格が 2,980yen で、クーポン利用で 999yen だったのでラッキーです。もう一個買おうかなぁ。

届いたのはこんな感じ。壁掛けパッケージです。そして、実物はこんな感じ。ずいぶんと大きいです。

USB の子機は 802.11 b/g/n/a/ac に対応しています。僕が購入した USB Wi-Fi 子機では初めての a (5GHz 帯) 対応です(僕は ac な AP は持ってない)。親機にもなれるようですが WindowsOS の場合はユーティリティをインストールしないとダメなようです。なので、自分的には子機専用で使う予定です。

利用しているチップは REALTEK の RTL8812AU というモノらしいです。 Windows10 Creators Update ではドライバなしでサクっと認識され 5GHz 帯のアクセスポイントにすんなり接続できました。
Cisco の EAP などに接続するためにはメーカサイトからドライバをダウンロードする必要があります。
ドライバはこの辺りのが使えるかな。 WN688A2–CD_WLAN_V6.85 のドライバをダウンロードすると良い感じです。

WindowsOS で 801.11a で接続して速度の検証してみたところ 802.11n の FreeBSD で言うところの if_run (Ralink のチップ) の機器の倍以上の 100Mbps 程度で通信することを確認しました。

 
さてと。これが FreeBSD で動作するのか、早速試してみました。

REALTEK の RTL8812AU は FreeBSD では対応していないようでドライバがありません。 REALTEK チップのカーネルモジュールとしては if_urtwn.ko がありますが、これでは動作しません。
で、ウェブで調べていると GitHub にカーネルモジュールがあったので、今回はそれを試してみました。

GitHub から urtwm-master.zip をダウンロードして適当なディレクトリに展開します。そしてその中にあるパッチを適用します。 usbdevs に適用するパッチになります。あとは、同梱の README.md を読んでその通りにやるとコンパイルが通り、インストールも無事に完了です。

インストール後は /boot/modules/ に urtwm-rtl8812aufw.ko urtwm-rtl8821aufw.ko if_urtwm.ko が配置されます。そして、それらを kldload すると利用可能な状態となります。
僕は普段から if_urtwn.ko を利用しているので、以下の設定が /boot/loader.conf に書いてあります。今回も必要かもしれません。

legal.realtek.license_ack="1"

 
さてと。カーネルモジュールのコンパイル時のとこをはしょりすぎているのでちょっと書きますが GitHub からダウンロードしたソースコードは 11.0-RELEASE 以降のカーネルソースが必要になります。

僕は FreeBSD/amd64 では環境が整わず FreeBSD/i386 と FreeBSD/arm で検証しました。

それにしても FreeBSD の 10 系 RELEASE と 11 系 RELEASE では USB 周りのソースの配置がガラっと変わりましたね。 10 系までは /usr/src/sys/dev/usb/wlan/ などにモジュールのソースがあったのに 11 系では /usr/src/sys/dev/ 配置されるようになりました。他にもカーネルのコードが変わっているので 10 系 RELEASE では if_urtwm はコンパイルできません。是非とも 11 系 RELEASE を用意しましょう。

 
と、いうことで if_urtwm* のコンパイルが通ったので使ってみることにします。一番最初に試したのはなんと Raspberry Pi 2 Model B の FreeBSD 11.0-RELEASE-p1 です。 USB Wi-Fi の子機は USB3 に対応しているのですが Ras Pi2 は USB2 にしか対応していないので性能が出ないんですが・・f(^^;;。

ザクっと USB ポートにさしてみると ugen に落ちて認識しません。あらら。僕が購入した AUKEY の AC1200 の情報を usbdevs に書いてあげる必要があります。

と、いうことで以下の行を /usr/src/sys/dev/usb/usbdevs に記述してあげます。 VendorID は既に登録済みだったので ProductID のみ記載します。

product REALTEK RTL8812AU      0x8812  RTL8812AU

 
あと、ソースコード中にも記載してあげる必要があります。 urtwm-master/sys/dev/urtwm/if_urtwm.c に対して以下のパッチを適用します。

--- sys/dev/urtwm/if_urtwm.c.orig       2017-09-07 18:59:06.031051000 +0900
+++ sys/dev/urtwm/if_urtwm.c    2017-09-06 20:51:41.749003000 +0900
@@ -128,6 +128,7 @@
        URTWM_RTL8812A_DEV(SENAO,               EUB1200AC),
        URTWM_RTL8812A_DEV(SITECOMEU,           WLA7100),
        URTWM_RTL8812A_DEV(TRENDNET,            TEW805UB),
+       URTWM_RTL8812A_DEV(REALTEK,             RTL8812AU),
        URTWM_RTL8812A_DEV(ZYXEL,               NWD6605),
        URTWM_DEV(DLINK,        DWA171A1),
        URTWM_DEV(DLINK,        DWA172A1),

 
これで、再度コンパイルしてインストールします。今回購入した USB Wi-Fi 子機は REALTEK の RTL8812AU というデバイスとして認識されるようになります。

kernel: urtwm0 on uhub0
kernel: urtwm0:  on usbus4
kernel: urtwm0: MAC/BB RTL8812AU, RF 6052 2T2R

 
で、 FreeBSD/arm 11.0-RELEASE-p1 と FreeBSD/i386 11.1-RELEASE-p1 で試してみましたが、残念ながら 802.11a では接続できませんでした・・。orz

ただし、 802.11n では動作しました。こちらのほうはかなりの速さで、一応 30Mbps くらい出ました。 USB 子機が大きくてアンテナがちゃんとしているからでしょうかね。
WindowsOS では 802.11a で利用できるのですが、残念ながら FreeBSD では 802.11n だったですが、速度が出るのでヨシとしておくかぁ。と、いう感じでしょうか。 NotePC には大きくて常用は厳しいですが Ras Pi2 には良いかもしれんです。

USB3 へ接続すると 802.11a で通信できるのかなぁ？ 今回はその環境がありませんでした。

あ。 /etc/wpa_supplicant.conf とか /etc/rc.conf の記述方法は今回ここでは書きませんが、大丈夫ですよね？

 
自宅の ThinkPade145 は USB3 が動作するのですが、この NotePC はカーネルのみが 10.1-RELEASE のままなので今回のカーネルモジュールはコンパイルできません。 syspend/resume を取るか、最新の FreeBSD を取るか悩ましいところではありますが、僕の場合は suspend/resume のほうが重要。なのでバージョンアップはしていません。

 
と、いうことで GitHub から拾ってきた if_urtwm のカーネルモジュールですが、一応は動いている。ということになります。if_run も if_rum も if_urtwn も、今までは 802.11n 対応だったので今回 FreeBSD で初めての 802.11a のドライバ。と、いうことになるかと思われます (僕の試した環境では接続できなかったけど・・)。

if_urtwm はどんなデバイスがあるのか？ というのは上のパッチを適用したソースコードである sys/dev/urtwm/if_urtwm.c の中に書いてあるので、試してみたい方は一回覗いてみると良いかも知れません;-)。

Cisco892J 購入。

9月 092017
 

手頃な値段の Cisco ルータが欲しいなぁ。と、思っていて Cisco C841M-4X-JSEC/K9/START でも良いかなぁ。とか、色々考えたのですが Amazon で CISCO892J-K9 が 2,900yen (当然中古) で売っていたので飛びついてしまいました・・f(^^;;。

まぁ、仕事柄 Cisco のスイッチやルータは触っていて IOS については多少の知識があるので特に問題は無いです。

が、しかし、 CISCO892J-K9 は GigabitEthernet ポートが一個しかなくて、しかもルーテッドポート。スイッチポートが 8 個の FastEthernet ポートなので、自宅が既に Giga 化している環境においては役不足です。『やっぱり 841 のほうが良かったかなぁ・・。』などと悩むのですが、考えてみると 841 はポートが 4 個しかないのでどのみちスイッチを購入する必要があります。

と、いうことで、今回は CISCO892J-K9 と NETGEAR の GS108E-300JPS を購入しました。前者が 2,900yen に対して後者が 4,830yen でした。うむむ。

二つ並べるとこんな感じ。

NETGEAR GS108E-300JPS はアンマネージプラスなスイッチです。シリアルコンソールではアクセスできないし telnet もできないけど、ウェブブラウザでアクセスすることにより VLAN の設定が行えます。
今回は CISCO892J-K9 で VLAN を設定し、タグを GS108E-300JPS に通して、GS108E-300JPS から L3 ルータに伸ばす(こういうふうに書くとかっちょ良いのですが “L3 ルータ” とは VyOS のことです;-)。と、いう構成にしました。

物理構成図はこんな感じ。

GigabitEthernet0 はルーテッドポートなので VLAN が指定できないのですが bridge で VLAN1 に入れました。アップリンクの Fa0 (ルーテッドポート) は PPPoE なので 100Mbps でも大丈夫ですが、下に行くポートは 1Gbps で落としたい。と、いう雰囲気ですね。

CISCO892J-K9 の Gi0 をスイッチポートとして利用する config は以下のようにしました。
bridge 設定の抜粋です。

bridge irb
!
interface GigabitEthernet0
 description # VLAN 1 LAN-Zone #
 no ip address
 duplex auto
 speed auto
 ipv6 enable
 bridge-group 1
!
interface Vlan1
 no ip address
 ip virtual-reassembly in
 ipv6 enable
 bridge-group 1
!
interface BVI1
 description # VLAN1 bridge Interface #
 ip address 192.168.1.254 255.255.255.0
 ipv6 address 3ffe:6580:AA40::254:1/64
 ipv6 address 3ffe:6580:AA40::/64 eui-64
 ipv6 enable
!
bridge 1 protocol ieee
bridge 1 route ip

 
今回利用している IOS は 15.6(3)M2 です。 bridge には interface BVI1 を利用します。BVI1 に IPv4・IPv6 アドレスを付加しています。あ。 IPv6 の設定についてはここでは書きません;-)。

上記設定 GigabitEthernet0 がスイッチポートの仲間入りです。しかし、 GigabitEthernet0 で VLAN を Trunk で利用できないので Fa4 と GS108E-300JPS を物理接続している。と、いうような感じです・・。

CISCO892J-K9 の スイッチポートに接続した機器は GigabitEthernet0 を通って 1Gbps で自宅のサーバ群にアクセスする。と、いうような感じになっています。
あと、 CISCO892J-K9 には Wi-Fi AP も接続しているので 100Mbps の帯域でも十分な場合もあります。なので、これで良いかなぁ。と、いう気がしないでもないです。

 
そーそー。最後に一点。 CISCO892J-K9 には USB ポートがあるのですが『わーい。USB で電源供給できるぞぉ。』などと思い喜んで Raspberry Pi2 と Pi3 の二台の給電をしていたら、あれま・・。 CISCO892J-K9 が夜中に再起動を繰り返すようになってしまいました。

二台の RasPi を USB から引っこ抜き、 CISCO892J-K9 は一日電通しないでほったらかしにして再度起動したらその後は安定稼働しているので、多分電源不足で CISCO892J-K9 が安定しなかったんだろう。と考えています。
今回は中古で購入し、動作不安定でハラハラドキドキしました。一応一ヶ月の保証がある機器だったので購入先に連絡を入れました。が、基本的には USB ポートに RasPi (しかも二台っ!!)を接続しないほうが良さそうですf(^^;;。

 
この CISCO892J-K9 のネタは今後続いていくかな？ 変わった設定とか、へんなことが起きた時に書いていきたいと思います;-)。

FreeBSD から LLDP を流してみる。

8月 202017
 

自宅のネットワーク内で mDNS を流していたら LLDP 流す必要ないやんかー。などと思うんですけども。
mDNS は網内というかルータを超えないセグメント内でマルチキャストを流し、 LLDP も同様に L2 レベルでマルチキャストを流します。

LLDP (Link Layer Discovery Protocol) は接続しているマルチベンダーの機器に対して自分の情報をお知らせするためのプロトコルです。
CDP (Cisco Discovery Protocol) は CIsco 機器だけでしか機器の情報を交換することができませんが、 LLDP は様々なネットワーク機器・サーバが流すことができます。

例えば Cisco ルータ(スイッチでも良いけど;-) で CDP を利用しているとき、VMware ESXi などのハイパーバイザーの NIC は CDP を吸収します。そして、仮想マシンでは LLDP を流すことにより、どのスイッチに、どんな物理サーバ (ESXi が動作している物理サーバ) が接続していて、その物理サーバ上でなんという仮想マシンが乗っているか、 CDP+LLDP で一目瞭然把握できるのであります。

なので、サーバ上で LLDP を流すのはネットワーク機器にとっては良い感じなのですね。

サーバ運用者主体で機器情報を収集するのであれば mDNS を起動しておくだけでも全然問題はないのですが、スイッチのどのポートに何が接続しているか？ と、いう情報まで収集したいのであれば ESXi で CDP を、仮想マシンでは LLDP を動作させるのがグーです。

 
FreeBSD には ports として net-mgmt/cdpd/ もあるし net-mgmt/lldpd/ もあるのでどっちも動作することができます;-)。

が、今回は LLDP について書いてみます。

まぁ、 ports から net-mgmt/lldpd/ を make install しておしまい。って感じですが、 make config のオプションが悩ましい。 BASH も ZSH もインストールしたくないので [ ] として、 SNMP を [X] にすると net-mgmt/net-snmp/ をインストールしてしまい大げさになるし・・。まぁ、お好みで;-)。
JOSN や READLINE 、 XML などは lldpctl -f で出力フォーマットを指定できるのですが、そのときに利用します。

そして、インストール後ですが、設定フアイルは sample さえもインストールされないので自力で用意する必要があります。設定ファイルは /usr/local/etc/lldpd.conf になります。 man lldpcli すると書式が解ります。
僕の場合は以下の書式を作りました。

#configure system hostname "wanchan"
#configure system description "FreeBSD-10.3-RELEASE"
configure system interface pattern em*,bge*,re*,wlan*,ue*,vmx*
configure system ip management pattern 192.168.*,*:*
#configure med fast-start enable
#configure med location address floor "32F"

 
最後の “configure med location address” な設定はどえりゃー複雑で、ちゃんと形式に沿って記述されてないとエラーになります。イヤになって、書く必要ねぇやぁ。みたいな感じですf(^^;;。
設定は上から順に

  • ホスト名
  • OS とバージョン
  • LLDP で流す NIC の情報 “,” で区切って複数指定できます
    IP アドレスの情報は勝手に取ってきて流してくれます
    実は wlan* は not an ethernet device なので動作してくれません
  • IP アドレスのレンジの情報
    IPv4・IPv6共に指定できます
  • Enable LLDP-MED extension の指定
    FreeBSDの ports の場合 configure 時に –enable-lldpmed が付いてないので不要っぽい
  • 上にも書いた通り設置場所情報
    snmpd が動作していれば不要だよねぇ。ふつーは・・

準備ができたら service lldpd onestart して、起動を確認します。

 
続いて確認方法ですが、僕の家には Cisco ルータもしくはスイッチが無いので VyOS で確認してみました。

まず VyOS で LLDP を有効にします。

set service lldp interface eth0

 
FreeBSD 側から LLDP が届いているか確認するには以下のコマンドを打ちます。

takachan@vyos:~$ show lldp neighbors 
Capability Codes: R - Router, B - Bridge, W - Wlan r - Repeater, S - Station
                  D - Docsis, T - Telephone, O - Other

Device ID                 Local  Proto  Cap   Platform             Port ID 
---------                 -----  -----  ---   --------             ------- 
wanchan.running-dog.net   eth0   LLDP   RS     FreeBSD 10.3-RELEAS em0

 
VyOS には LLDP の確認コマンドに対しては show lldp neighbors しかないので貧弱です。Cisco スイッチのように show lldp entry HOGE みたいなのがあっても良いのですけどねぇ。そーいうのはないようです。

 
lldpd を起動した FreeBSD 側での確認するには lldpcli コマンドを利用します。
ウダウダ出るので詳細は書きませんが以下のコマンドを打つと『なるほどね。』となると思います。
あ。 root でコマンドを実行する必要があります。

  • lldpcli show chassis
  • lldpcli show neighbors
  • lldpcli show neighbors summary
  • lldpcli show neighbors ports vmx0
  • lldpcli show statistics

lldpcli コマンドは UI が貧弱なのでとんなオプションがるのかちぃーとも分かりません。しょーがないのでソースコードで確認です。 src/client/show.c を眺めてオプションを把握しますX-|。

なお、 lldpcli が面倒な場合は素直に lldpctl コマンドでオプション無しが良いでしょう。 -h でパラメータも表示してくれます。

 
ただ、 FreeBSD で動作する lldpd は多少問題があるようです。

1). ports の Makefile があやすぃ・・。
net-mgmt/lldpd/Mkaefile の中の CONFIGURE_ARGS で –with-privsep-chroot=/var/empty という行があるのですが、 /var/empty って Read Only やんけ。 lldpd は起動時に /var/empty/etc/timezone を生成しますがそれができないので WARNING なメッセージが出力されます。
僕は Makefile をいじって –with-privsep-chroot=/var/run/lldpd にしてしまいました。

2). bsnmpd と相性が悪い？
lldpd を起動すると以下のメッセージが出力されます。

snmpd[810]: RTM_NEWMADDR for unknown interface 0

 
/usr/lib/snmp_mibII.so の handle_rtmsg() で出ているんだけど、原因がイマイチ分からん。bsnmpd と lldpd を同時に起動すると上記のメッセージが出力される場合があります。

気付いたのはこの二点かな。

 
これで一応、FreeBSD も LLDP を投げるようになり lldpcli で確認することもできます。 lldpcli は mDNS でいうところの avahi-browse と似たようなモンんでしょうかね。

上にも書いた通り mDNS を利用するか LLDP を利用するかについてはネットワーク運用部門の人と綿密に計画を立てて行うのが良いかと思われます。 Cisco 機器の場合 LLDP をサポートしている機器や ISO のバージョンがあまり多くはないような気がしないでもないですし。

まぁ、それにしても、自宅のネットワークの場合は全て僕一人で行うんですけどもね;-)。

Active Directory はあるけど DNS は FreeBSD で管理したいときの設定。

8月 122017
 

自宅の環境に Windows Server 2012 R2 で動作する Active Directory を導入しました。たくさんの FreeBSD (サーバ・デスクトップ含む) と二台の Linux と、ほどほどの Windows10 があるのですが、アカウントを利用している人は二人のみ。どうして Active Directory が必要なんじゃい？ と、なるのですが、実はほとんど利用していない。

と、いうか、諸々な件で検証しなければならず、本当は必要ないんだけど、ショウガなく Active Directory の設定を行い、ユーザ情報を登録してみた。と、いう感じで、現在は色々動作確認している最中です。

 
そもそも、既存の Windows 環境はワークグループで管理していたのにドメインに入るとデスクトップ環境が一から作られるので、ドメインには参加したくはないわなぁ・・。

 
と、いうことで Windows Server 2012 R2 で Active Directory が動作するようになったんだけど、 Active Directory のインストール段階では、自宅のネットワークには既に FreeBSD 上で 二つの DNS サーバが動作しているのであえて Windows Server 上で DNS を起動する必要は全くない。

Windows Server 2012 R2 では Active Directory のみを動作させ、 DNS は継続して FreeBSD で動作させるように構成したのでありました。

さてと。 Windows Server 2012 R2 を再起動して Active Directory で設定したドメインに組み込むと DOMAIN\takachan でログインできるようになりました。

他の Windows マシンもドメインに参加させようと思ったのですが、例えば Windows10 でコントロールパネルの「システム」から「所属するグループ」でドメインをチェックしてドメイン名を指定しても「それは見つからない。」とエラーになりました。

以下のようなエラーコードとなり、Windows10 がドメインに参加できません。このエラーコードは [詳細 >>] を開くと表示されています。

エラー コード 0x0000232B RCODE_NAME_ERROR

 
この事象は Windows Server 2012 R2 で Active Directory を構成して、DNS は他の OS で持たせた場合に発生するようです。
Windows Server 2012 R2 で Active Directory と DNS を同時に構成すると問題ないらしいです。

 
僕は DNS は FreeBSD で bind9 の named で設定していますが、ドメインで利用した ドメイン名のゾーンファイルに SRV レコードを追加してあげる必要があるようです。

 
以下は SRV レコードについてまとめた情報です。条件は以下のときに効果的です。

  • Windows Server 2012 R2 で Active Directory は構成したが DNS は構成していない
  • DNS は FreeBSD や Linux など UNIX 系 OS で named などを利用し既に動作している
  • 上記のような環境で Windows OS がドメインに参加しようとすると参加できない
  • ちなみに Active Directory に設定したドメインは running-dog.net
  • DNS のゾーンファイル名は running-dog.net.zone

ここでは bind9 の named.conf や zone ファイルの基本的な記述方法・内容については書かないです。知っているモノとして話を進めます。

と、いうことで上記のような環境の場合、 UNIX 系 OS で動作している named のゾーンファイルに以下の設定を加筆してあげる必要があります。

今回は bind-9.10.6 のゾーンファイルの記載例です。

今回、Active Directory のドメインは runniong-dog.net なので、 bind9 の running-dog.net.zone のゾーンファイルに以下の行を追加してあげます。

_kerberos._tcp           IN      SRV 0 0   88 ad-server
_kerberos._tcp.dc._msdcs IN      SRV 0 0   88 ad-server
_ldap._tcp               IN      SRV 0 0  389 ad-server
_ldap._tcp.dc._msdcs     IN      SRV 0 0  389 ad-server
gc._msdcs                IN      SRV 0 0 3268 ad-server

 
雰囲気的には mDNS のようですね。 TCP ポート 88・389 と 3268 に対して SRV レコードを追加してあげる。と、いうことですね。
ゾーンファイルの SRV レコードとはなんぞや？ となるのですが、 RFC2782 で定義されていて、DNS でホスト名や IP アドレスの他にサービスについても広報してしまう。と、いうノリのようです。

TCP ポート 88・389・3268 は ad-server.running-dog.net でサービスを提供しているよ。と、いう記述です。

 
通常 Active Directory を構成した場合は Windows Server 2012 R2 で合わせて DNS も構成するので上記の SRV レコードが記載されるのでしょうな(僕はやったことが無いので解らない;-)。しかし、これを bind9 などで構築した場合にはゾーンファイルに SRV レコードを記載してあげないと他の Windows OS が Active Directory を見つけられない。と、いうことなのでしょうなぁ。

 
では、SRV レコードの他にもっと簡単に見つける方法あるんでないの？ と思うと、パッとひらめくのは『 mDNS で流したらえーやん。』と、なるのですが、考えてみると mDNS ってのはルータを超えられないのでデータセンタなどにある AD の場合はまるで役に立たないんですね。
なので、きっと DNS で SRV レコードを記載してそれを利用するのが一番手っ取り早い。と、なったのでしょうなぁ。

ubuntu で VRF 使ってみました。

7月 272017
 

ちょっと前のエントリで FreeBSD のポリシールーティングについて書きました。そのときは FreeBSD においては pf で設定しました。そして、他のやり方がないのか検討し、その記事の下のほうには setfib コマンドでルーティングテーブルを操作して正しいルーティングができるのか試しているのですが、結局はダメだったのであります。

Linux 方面では ip route+ip rule でのポリシールーティングの運用となりますが、カーネルのバージョン 4.4 から VRF が利用できる。というので setfib と比較してどれくらい効果的に機能するのか試してみました。
Linux カーネルが 4.4 以上なディストリビューションには何があるのか調べてみると ubuntu-17.04 が対応しているようなので ISO イメージをダウンロードしてインストールし、実際に設定までしてみます。

 
僕自身 ubuntu はあまり使ったことが無いディストリビューションで Raspberry Pi の Volumio に続き二個目のインストール環境です。仕事でもデスクトップでも使ったことがありません;-)。

それにしても ubuntu のネットワーク設定である /etc/network/interfaces の記述方法が相変わらず解らないので、いつものように /etc/rc.local でやってしまえ。などと思っても ubuntu にはこのファイルが無いし、起動時に利用できないのですねぇ。

以下の URL を参照させて頂き /etc/rc.local を動くようにしました;-)。

http://qiita.com/msrks/items/5201ae15d0e1f8de5946

簡単に書いておくと

o. /etc/systemd/system/rc-local.service を作成

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
# disable timeout logic
TimeoutSec=0
#StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

 
o. enable する

systemctl enable rc-local.service

 
これで /etc/network/interfaces と /etc/rc.local にコマンドを書いて、起動時に実行されるようになりました。

と、いうことで、以降は VRF を利用するネットワークの設定を行います。

 
まず、ネットワーク構成ですが、この前のエントリ「FreeBSD でポリシールーティング。」で書いた CentOS 6.9 を ubuntu-17.04 にリプレイスして ip route+ip rule をやめて VRF を利用してみます。

Server1 が Linux (CentOS 6.9) だったので、これを設定します。以下はネットワークの情報です。

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

これを VRF を利用するように設定します。が、その前に注意点を。

NIC が二個あるのでそれぞれの NIC を VRF にしてルーティングテーブルを二つ別々に持たせよう。などと思ってはいけません。
NIC が二個の場合、一個は default のルーティングテーブル(ip [-6] route list で表示されるルーティングテーブル)を参照するようにして、もう一個の NIC は別のルーティングテーブルを持ち、かつ参照する構成が良いです。ここ、ハマリ道というか思い違いの点ですね。
この点については下のほうに詳しく書きます。

 
では、設定を上から順に見ていきます。

0). /etc/network/interfaces にネットワークの設定のみ書く
lo の他にインターフェース二つ分を書き gateway の設定は書かない

auto ens160
iface ens160 inet static
address 192.168.22.10
netmask 255.255.255.0
iface ens160 inet6 static
address 2001:470:fe36:beef::2:1
netmask 64

auto ens32
iface ens32 inet static
address 192.168.1.10
netmask 255.255.255.0
iface ens32 inet6 static
address 3ffe:6580:aa40::2:1
netmask 64

 
多分、/etc/resolv.conf が作られないので、以下のコマンドを /etc/rc.local に書いておくと良いかもしれんです。

cp -pr /etc/resolv.conf.SV /etc/resolv.conf

 
/etc/resolv.conf.SV は好きに書いてください;-)。
しかし、ディストリビューションの正しい設定方法を無視しているなぁ;-P。

 
1). IP アドレスの付加
僕の場合、/etc/network/interfaces に書いた IPv6 アドレスが自動的に付加されなかったので /etc/rc.local に書きました。
以降の設定は全て /etc/rc.local に書くと楽ちんです;-)。

ip addr add dev ens160 2001:470:fe36:beef::2:1/64
ip addr add dev ens32 3ffe:6580:aa40::2:1/64

 

2).ルーティング情報の付加
今回は Server-Zone 側を default のルーティングテーブルとして利用します。

route add default gw 192.168.22.1
route add -A inet6 default gw 2001:470:fe36:beef::1

 

3). VRF の設定
いよいよ、VRF の設定です。VRF は LAN-Zone 側に設定します。
ip [-6] route list コマンドで表示される default gateway は上でコマンドを打っています。 グローバル側の設定ですね。
VRF はマネージメントポート側で利用する。と、いう意味合いを込めて Cisco 風に mgmt という名にします;-)。

ip link add dev mgmt type vrf table 10
ip link set dev mgmt up

 
type は vrf で table 番号は 10 を利用しました。複数個の VRF を生成する場合はこの番号を増やしていけば良いです。

 
4). VRF と NIC の結びつけ
作成した VRF インターフェースと NIC を結びつけます。つまりは、マネージメントポート用の VRF は mgmt として LAN-Zone の NIC と結びつける。と、いうことですね。

ip link set dev ens32  master mgmt up

 
リモートから ssh で作業していて dev で指定する NIC からアクセスしていた場合、このコマンドを投入した段階でネットワークが切れます。なので反対側の NIC からアクセスして作業するか、コンソールからコマンドを叩く必要があります。
起動時の /etc/rc.local 読み込み時には問題はないんですけどね。

 
5). VRF に default gateway を設定
Server-Zone は default のルーティングテーブルを参照しますが、 LAN-Zone は個別の VRF のルーティングテーブルを参照します。なので別途 default gateway を設定します。 VRF の table 10 に対して route add します。

ip route add default via 192.168.1.1 table 10
ip route add default via 3ffe:6580:aa40::ffff:1 table 10

 

6). 外部からのアクセスを可能にする
最後に sysctl で以下の MIB 値を変更し、外部から VRF 側のネットワークアクセスを可能にします。これをしないと ssh などで接続することができません。

sysctl -w net.ipv4.tcp_l3mdev_accept=1

 
以上で VRF の設定は完了です。

 
確認方法は以下になります。

  • ip route list もしくは ip -6 route list
    default のルーティングテーブルを確認すときに利用
  • ip route list vrf mgmt もしくは ip -6 route list vrf mgmt
    設定した VRF の mgmt のルーティングテーブルを確認

その他、インターフェースの確認として ip link や ip addr を利用します。

 
さて。最初のほうで『二個の NIC に VRF を二個用意してはいけません。』と書いていますが、例えば二個の NIC それぞれで VRF を利用した場合 /etc/resolv.conf を参照しないなど、問題点も多いです。
そりゃそうでしょうなぁ。どっちの NIC から出ていくかわからないですし、リゾルバは正しく動作してくれないんでしょうな。

例えば NIC が ens160 と ens32 の二つがあった場合以下のコマンドを打ったとします。

ip link set dev ens160 master vrf0
ip link set dev ens32  master vrf1

 
この場合、二つの NIC でそれぞれ個別のルーティングテーブルを持つことになるんですが、

  • ping -I vrf0 IP アドレス もしくは ping -I vrf1 IP アドレス

では到達性があります。しかし、以下のように pingすると到達性がありません。

  • ping -I vrf1 FQDN

ルーティングテーブルが VRF のみになると DNS を引きに行ってくれないんですね。なので、 NIC が二個の場合は一個の VRF を設定するのみで、もう一個の NIC は default な ip [-6] route list で表示してくれる経路が必要になります。

二個の NIC で二個の VRF を設定すると netstat -nr や ip route list では何も表示してくれなくなります。

ループバックに IP アドレスとか記載できるのかな？ lo:1 とか書けるのかな？そこまで試していませんが。

 
さてと。ここまで来て VPF の環境設定が終わりましたが、実際に利用してみるとやはり中々楽しいですね。
Cisco ルータの場合、 VRF は interface mgmt で動作することが多々あるんですが、今回は L3 ルータを作る。と、いう目的ではなく、サーバのポリシールーティングのかわりに VRF を利用してみた。と、いう感じですね。

ip [-6] route list で表示されるルーティングテーブルは、サービス側で利用し、マネジメントポート (今回はそれを LAN-Zone と呼んでます) で VRF を利用し、サービスセグメントのルーティング情報とは混在させないで通信を行う。こんな時に必要な機能だと思われます。

 
僕はこのあと VRF を利用しつつ、ウェブサーバを起動して CentOS 6.9 を引退させようと考えています;-)。

FreeBSD の setfib もここまで動いてくれると嬉しいのですが、そこまで到達していないのと、そもそも setfib は IPv6 が動かないので、今の所、僕の環境ではまるで使い道が無い・・。orz

どうしても IPv6 が欲しい状況で NAT66 を使う。

7月 222017
 

一台の PC で IPv6 が使えている状況で、他の PC にも IPv6 がほしいなぁ。と、いうことが、最近、多々あります。
NIC やスイッチのポートが限られていて他の PC を同一セグメントに接続できないじゃーん。みたいな・・。

と、いうことで構成図を一枚。

・緑色のルータは FreeBSD のルータで PC1 と gif トンネルで接続しています。

今までは PC1 で IPv6 を使えれば良かったんだけど、PC2 や PC3 でも IPv6 を利用したい。ぱっと思い浮かぶのが PC2 や PC3 でも個別に gif トンネル掘って緑色のルータと接続すれば良いしゃん。と、いう案です。

他にないの？というと、例えば

PC1 の gif0 と em1 を bridge にして PC2 と PC3 を接続して 2001:470:fe36:11::/64 のセグメントを利用できるようにしてあげる。

って案ですね。が、しかし、 FreeBSD では (if_gif を利用すると？) bridge がまともに動かないですなぁ・・。
と、いうか、最近まで知らなかったのですが、bridge するインターフェースは MTU を揃えないとエラーになるんですね。

# ifconfig em0 mtu 1500 up
# ifconfig gif0 mtu 1280 up
# ifconfig bridge0 create
# ifconfig bridge0 addm gif0 addm em0  up
ifconfig: BRDGADD em0: Invalid argument
# ifconfig bridge0 destroy
# ifconfig em0 mtu 1280 up
# ifconfig bridge0 addm gif0 addm em0  up

 
上記のエラーが出たときにどうして Invalid argument なのか /var/log/messages にメッセージが出力されますね。知らんかった・・。

 
とまぁ、仮に無事に bridge0 が生成されたとしても IPv6 の通信ができないので諦めました。 bridge0 に addm gif0 した段階で通信が途絶えます。 ifconfig bridge0 destroy すると復活します。原因はどこにあるのだろう？

 
以前、 VyOS を二台用意して IPv4 の別セグメントに IPv6 を L2 抜けする設定を一回掲載していますが、そんな大げさなネットワークを構築するのはイヤです;-)。

まぁ、今回は PC1 から PC3 までが同一セグメントに入っている必要はなく、とりあえず三台の PC が IPv6 で外部にアクセスできると嬉しいなぁ。と、いう感じなので、何かワザはないのか？と思い、考えたら『あぁ。NAT すりしゃ良いじゃん。』となったのであります。

 
と、いうことで IPv6 で NAT を有効にするにはどうしたら良いのだぁ？ 調べてみると NAT66 という技術を利用するようですね。 IPv6 で IPv6 の NAT をするので NAT66。

と、いうことで前回同様、今回も pf を利用します。

今回は上の構成図に合わせると PC1 で pf を利用して NAT66 が動作するようにします。 PC1 の pf で設定は以下のような感じ。

nat on gif0 inet6 from 2001:470:fe36:100::/64 to any -> 2001:470:fe36:11::2

 
一行でできました;-)。これを /etc/pf.conf に書けば完了。

PC2 と PC3 は NAT のアドレスなので fd00::/8 のユニークローカル IPv6 ユニキャストアドレスを /64 で任意のセグメントを定義して利用しても問題は無いです。
僕の場合は 2001:470:fe36::/48 を持っているのでその中から NAT 用に 2001:470:fe36:100::/64 を切り出て利用しました。

NAT で利用する 2001:470:fe36:100::/64 は gif0 に付加されている 2001:470:fe36:11::2/64 を抜けて通信するので pf でその設定をしてあげると上のようになります。

簡単ですね。あとは service pf onestart して sudo pfctl -sa で確認すれば良いと思われます。

PC2 と PC3 はスタティックに IPv6 を ifconfig で設定してあげてください。PC1 で rtadvd の設定するの面倒なのでf(^^;;。

PC2 と PC3 では default gateway を指定する必要があるので、そのために PC1 の em1 に IPv6 アドレスを付加してあげる必要があります。

# ifconfig em1 inet6 2001:470:fe36:100::1 alias

 
PC2 と PC3 はこの IPv6 アドレスを default gateway に指定してあげます。

 
ちなみに 緑色のルータと PC1 の gif トンネルの説明はないですが、大丈夫ですよね？ 以前のエントリで「IPv6 Over IPv4 トンネルを dtcp から VyOSへ。」と、いうのを書いているのですが、「2. dtcpclient 側の設定」の設定をサーバ側・クライアント側として逆に打つとトンネルを掘ってくれます。

 
と、いうことで、今回は NAT66 の設定を pf で行い、簡単に IPv6 を利用する方法を書きましたが、IPv6 が欲しい場合には比較的容易に gif トンネル + NAT66 っていうのが良いかもしれないです。

グローバルアドレスが付いている FreeBSD があれば、網内のどこにでもある FreeBSD から gif トンネル掘って、その下で NAT66 すれば良いだけですねぇ。

簡単だぁ;-)。

FreeBSD でポリシールーティング。

7月 182017
 

最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。

と、いうことで自宅のネットワーク環境を見直してみました。

IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。

構成図はこんな感じ。 (多少、端折っているf(^^;;)

Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。

例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。

パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。

管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2

ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。

あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz

FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。

 
上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。

ip route add 192.168.22.0/24         dev eth0 tab 100
ip route add 2001:470:fe36:beef::/64 dev eth0 tab 110
ip route add 192.168.1.0/24          dev eth1 tab 120
ip route add 3ffe:6580:aa40::/64     dev eth1 tab 130

ip route add default via 192.168.22.1           dev eth0 tab 100
ip route add default via 2001:470:fe36:beef::1  dev eth0 tab 110
ip route add default via 192.168.1.1            dev eth1 tab 120
ip route add default via 3ffe:6580:aa40::ffff:1 dev eth1 tab 130

ip    rule add from 192.168.22.10/32           tab 100 priority 1000
ip -6 rule add from 2001:470:fe36:beef::2:1/64 tab 110 priority 1100
ip    rule add from 192.168.1.10/32            tab 120 priority 1200
ip -6 rule add from 3ffe:6580:aa40::2:1/64     tab 130 priority 1300
ip route flush cache

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。

最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。

 
FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。

pass quick on lo0  all
pass quick on vmx0 all
pass quick on em0  all
#
# NIC vmx0 -> vmx0 (IPv4)
pass out quick on vmx0 from 192.168.22.20 to 192.168.22.1/24
pass in quick on vmx0 reply-to (vmx0 192.168.22.1) from any to 192.168.22.20
pass out on vmx0 route-to vmx0 from 192.168.22.20 to any
#pass  out on vmx0 route-to (vmx0 192.168.22.1) from 192.168.22.20 to any
# NIC vmx0 -> vmx0 (IPv6)
pass out quick on vmx0 from 2001:470:fe36:beef::3:1 to 2001:470:fe36:beef::1/64
pass in quick on vmx0 reply-to (vmx0 2001:470:fe36:beef::1) from any to 2001:470:fe36:beef::3:1
#pass out on vmx0 route-to vmx0 from 2001:470:fe36:beef::3:1 to any
pass out on vmx0 route-to (vmx0 2001:470:fe36:beef::1) from 2001:470:fe36:beef::3:1 to any
#
# NIC em0 -> em0 (IPv4)
pass out quick on em0 from 192.168.1.20 to 192.168.1.1/24
pass in quick on em0 reply-to (em0 192.168.1.1) from any to 192.168.1.20
pass out on em0 route-to em0 from 192.168.1.20 to any
#pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.20 to any
# NIC em0 -> em0 (IPv6)
pass out quick on em0 from 3ffe:6580:aa40::3:1 to 3ffe:6580:aa40::ffff:1/64
pass in quick on em0 reply-to (em0 3ffe:6580:aa40::/64) from any to 3ffe:6580:aa40::3:1
pass out on em0 route-to em0 from 3ffe:6580:aa40::3:1 to any
#pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::3:1 to any

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1

これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。

僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの？ って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。

1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定

pass out on em0 route-to em0 from 192.168.1.10 to any
pass out on em0 route-to em0 from 2405:6580:aa40::2:1 to any

 

2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定

pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.10 to any
pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::2:1 to any

 
IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。

こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら？ その点 Linux は良い感じに動作していると思うんですけども。

ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな？

 
設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。

 
あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。

そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう？ fib はインターフェースとリンクしなくて良いのかな？ 不思議だ・・。

$ setfib 0 netstat -nr -f inet
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.33       link#3             UHS         lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#2             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.22.0/24    link#2             U           ue0

 
(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら？

 
ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U         wlan0
192.168.1.33       link#3             UHS         lo0

 

tcsh で systemctl や service をタブキーで補完。

7月 132017
 

systemctl ってのは Linux の新しいシステムの systemd 由来のコマンドですね(この辺りの言い回し、正しくないかも;-)。
つい最近になって CentOS7 を利用し始めたので /etc/init.d/hoge restart とかできなくなって驚いていたんですけども。

じゃぁ、/etc/init.d/ の下にあったのはどこに行ったのだ？ と思い調べてみると /usr/lib/systemd/system/*.service というのがそのようですね。このファイルを利用して systemctl が start/stop をやってくれる。と、いうことのようです。

Linux のシェルは基本的に bash なので以下のファイルをダウンロードしてきて /etc/bash_completion.d/ の中に入れてあげると TAB キーで補完してくれるので幸せになれるようです。 bash 用の systemctl 補完用スクリプトですね。

https://raw.githubusercontent.com/terralinux/systemd/master/src/systemctl-bash-completion.sh

では、普段から tcsh を利用している人 (それはつまりは Linux が流行る前から UNIX をいじっていた人。と、いうことになるのかや？;-) や Linux でも tcsh をメインで利用している人はどうしたらえーねん？ て、ことになるのですが、せっかくなので ~/.tcshrc に以下の設定を書いてみましょう。 (ウェブ上では多分切れているね・・orz。フル HD の全画面で表示してぇ・・。)

complete systemctl 'p/1/(start stop restart status reload enable disable kill ..etc..)/' 'n@*@`/bin/ls /usr/lib/systemd/system | grep service | sed -e "/:/d"`@'

 
tcsh には complete というコマンド(？)があるので、それで TAB の補完の設定ができます。

上記を ~/.tcshrc に書いて systemctl と打ったあと TAB を打つとまず start/stop などの文字列が表示され、その後 *.service をドドドと表示してくれることでしょう。途中の sshd.s で TAB キーを押しても補完してくれます。

これで tcsh をメインのシェルとして利用している人は幸せになれるのではないかと思われます;-)。

 
ところで、 FreeBSD の service も似たように TAB で表示したい。と、いう場合はどうするのか？ 以下の設定をやはり ~/.tcshrc もしくは /root/.cshrc に書くと幸せになれます。

complete service 'n@*@`/bin/ls /etc/rc.d /usr/local/etc/rc.d | sed -e "/:/d"`@' 'p/2/(start stop restart onestart onestop onerestart)/'

 
FreeBSD の起動スクリプトは /etc/rc.d/ や /usr/local/etc/rc.d/ の中に入っているのでその中をごっそりと ls している。と、いうことになります。

bash の場合は専用のスクリプトを用意したりしますが tcsh の場合は強引に /bin/ls で実装している。と、いうことですなぁ。

 
tcsh が好きで好きで手放せない。もしくは bash なんて使ってらんねーぜ。けっ。はたまた zsh なんて遅くて使い物にならん。と、いう方は今後も多分ずっと tcsh を使い続けるかと思いますが、その場合 systemctl や service で TAB キーを使いたい方は是非お試しください;-)。
また、他のコマンドでも TAB を利用して補完したい場合には complete コマンド(？)で定義することができます。

 
2017/07/27 加筆
もう 20 年くらい tcsh 使っているけど、 tcsh を利用するときに complete な一覧が書かれているファイルがあるのね。知らなんだぁ。

o. FreeBSD の場合
/usr/share/examples/tcsh/complete.tcsh
/usr/src/contrib/tcsh/complete.tcsh

o. ubuntu の場合
/etc/complete.tcsh

これを ~/.tcshrc の中で source /usr/share/examples/tcsh/complete.tcsh とかすると色々なコマンドで TAB で補完してくれるので幸せになれます。
僕のは場合は mv cp ln など、二個目のパラメータを TAB キーで抽出できなかったので、一部変更して $HOME に置きました。

ubuntu の人が作ってくれたファイルのようです。感謝。 m(_ _)m。
加筆ここまで

R-SIM10+ を試してみました。

7月 112017
 

僕は現在 SoftBank の回線で iPhone6 を使い続けていますが、 R-SIM10+ という SIM ロックのかかった iPhone を SIM フリーにしてくれる。と、いう、以前から評判になっていた SIM ゲタを購入してみました。
バルク品ですが、980yen だったので試してみた。と、いう感じですが;-)。

届いたのはこんな感じです。本当にバルクだぁ。パチモンではないのかな？ とは思いつつ、購入したのは APM ショップ というところだったので、多分問題ないだろう。と、言う気持ちはありました;-)。

iPhone6 はまだ Softbank の SIM で動作しているので iPhone5 で試してみました。利用したのは DTI SIM。ちなみに現在 iPhone5 は奥さんが利用しております。

奥さんのネットワーク環境は、以前に僕が購入した(その後、詐取された) ZTE Blade Vec 4G に DTI SIM を入れて Wi-Fi ルータ化し iPhone5 でテザリングしている。と、いう状態です。ちなみに、彼女は Softbank のフィーチャーフォンも持っているので、都合三台持ち。と、いうことですね;-)。まぁ、僕がそのように仕向けている。とも言うんですがf(^^;;。

と、いうこと、でわざわざ iPhone5 に R-SIM10+ を使う必要は全くないんだけど、僕が試したくなってしまった。と、いうのが実情ですf(^^;;。

 
さてと。まずは iPhone5 に DTI SIM のプロファイルをダウンロードしてインストールするところから始めます。そして、早速 R-SIM10+ を試してみました。
上記 APN ショップの URL の手順に従い LTE の電波をオフにしたところで電源を入れつつ SIM カード共々接続します。
[JP SoftBank] -> [TMSI1.2G3G4G] -> [M2（IOS8-IOS9)] と、メニューに沿って進んでいきます。

3G の電波は比較的容易に拾いました。そして、通信も無事にできましたが、遅いですねぇ・・。

でもっていよいよ LTE をオンにするのですが、あたたた。いきなり圏外病の発生です。これが俗に言う圏外病というモノなのね。ということで docomo 謹製の MEDIAS LTE N-04D で復活させようとしたのだけど、ダメ。やり方が間違っていたのかな？
しょーがないので iPhone5 の LTE をオフにして SIM カードのみを抜き差ししていたら、あぁら。無事に復活。単なる偶然か？ しかし、調べてみると iPhone 単体でも復活した。と、いう話はウェブ上で見受けられるし。

その後、再度 iPhone5 に DTI SIM && R-SIM10+ を指したら LTE を拾って通信ができるようになったのでヨシとしました。

購入した R-SIM10+ はバルクだったのですが、実際に LTE 接続して動作したので『一応問題なく動作した。』と、いうことになるのでホッとしております;-)。

 
次の日、奥さんに一日持ち歩いてもらいフィールドテストを実施してもらいました。ろくに詳しいことも説明せずに;-)。しかし、 16:00 頃メールが来て『使えないんだけど。圏外になっているんだけど。』と、いうことでシューリョー・・。

家に帰って色々情報を聞くも『使えないと意味がないので、今のまま二台持ちでも全然問題は無い。』と、いう、そっけない意見が出たので、結局 R-SIM10+ を利用したのは一日だけだったのであります・・。 orz
まぁ、確かにそのとおりではある。

 
なお、二回目の圏外病になった DTI SIM ですが iPhone5 単体で試したけど、やっぱりダメで SIM フリースマホである ZTE Blade Vec 4G の LTE をオフにして試してみたらいとも簡単に復活しました。圏外病を復活させるためには docomo のガラケーが必要だ。と、言われているようですが、 docomo の電波を拾う SIM フリーなスマートフォンでも LTE をオフにしていると大丈夫みたいですね。

ZTE Blade Vec 4G が特別なだけかもしれないですが。

 
と、いうことで、まぁ、ほぼ検証のためだけに購入した。と、言っても過言ではない R-SIM10+ ですが、わずか一日の短命に終わったのでありました・・。

圏外病の復活方法がわかっただけでもヨシとすべきか・・。

Xperia Z5 Compact に Android7.1 が降ってきた。

7月 082017
 

ハイレゾ楽曲を聴くために SONY Xperia Z5 Compact E5823 購入したのですが、こいつは SIM アンロック済みのワールドワイド版です。 SONY は早々と Android7 にバージョンアップする。と、アナウンスがあったのですが、キャリア向けのバージョンアップは確か、随分前にありました。僕の持っているヤツはようやっと Android7 が降ってきました。

ここまでは前回書いた Android7 が降ってきた。のエントリと一緒です。

僕が持っている香港版の Xperia Z5 Compact E5823 に Android7 が降ってきたのは 2017/05/25 頃。 UK 版より三ヶ月ほど遅かったのですが、スルスルっと Android7.1.1 が振ってきました。今回は早かった;-)。

早速バージョンアップしました。特に問題も無く 30 分くらいで完了しました。

前回の Android6 から 7 にバージョンアップしたときよりも見た目の変化が少ないように感じるので、ほぼバグフィックスとかセキュリティーホールすぶしのバージョンアップなのでしょうなぁ。

無事に終わったあとのバージョンはこんな感じ。購入してからそろそろ一年が経つのですが、ズイズイとバージョンアップしてくれる SONY には感謝感謝です。やはりちゃんとしたメーカの Android 端末を買わないとダメだよなぁ。と痛感します;-)。

 
さてと。話はこれで終わったら面白くないし、前回のエントリではわざわざ Bluetooth イヤホンのお話を書いたので、それに関連するお話をちょっと書いてみます。

前のエントリにも書いた通り、僕の Xperia Z5 Compact E5823 には 64GB の MicroSD カードに 55GB 分、曲数にすると 280 曲程度入っています。なのにハイレゾ対応イヤホンではなく Bluetooth イヤホンで楽曲を聞いていたので、その恩恵が全く受けられていませんでした。

そんなこんなで久しぶりに『ケーブルが邪魔だけどね。』などと思いつつ SoftBank SELECTION SE-5000HR でハイレゾ楽曲を聞いたのですが。あれ?! 音がずいぶん良くなってない？

まぁ、今まで三ヶ月くらいほぼ毎日 Bluetooth イヤホンで通勤時に楽曲を聞いていたのを突然ハイレゾ対応イヤホンに変えたら、そりゃー音の違いが解って当然だよなぁ。などと思うのですが、ふつー、10 分程度聞いていると耳が慣れてしまうのに、今回はそんなことはなく、いつまで経っても良い音のまま耳に入って来るのであります。

ドンドン来ていないのに重低音がしっかり響き、高音は『あれ？こんな音してた？』って思えるほど聞こえるし、音の広がりがすごいし。人が聞こえない周波数まで音の広がりがある。と、いうより量子化ビット数分ちゃんと厚みのある(情報量のある)音になっている。ような気がするのであります。

 
何を言いたいのか？というと、 Android のバージョンアップでハイレゾ関連の音質良くなったりしてない？ などと思った次第です。

Andoid6 -> 7 にバージョンアップしたときに音が良くなったかな？とも思えるのですが 7 -> 7.11 にバージョンアップしたときには特に変更がないように感じます。

しかし、ウェブで探してみても Xperia が Android7 になってハイレゾの音が良くなった。と、いう改版履歴は特に見当たらない。

もしかしたら、ただ単に気のせいなのか？ f(^^;;

 以前のエントリー  新しいエントリー