9月 092018
 

僕が利用している ThinkPad E145 はカーネルがずっと 10.1-RELEASE のままで、ユーザランドが 10.4-RELEASE だったりしていました。これは以前にも書いていますが suspend/resume が動作しなくなる。resume 後にバックライトの調整ができなくなるため、しかた無く。の対応だったんですね。

あと、ThinkPad E145 はグラフィックスカードに Radeon HD 8330 を利用していて、このチップは radeonkms.ko では未対応で Xorg のドライバでは VESA を利用していたんですね。

そして、 KDE5 は 10.4-RELEASE でコンパイルしたものは、コンパイルしたバージョンとは違う 10.1-RELEASE 上では動作しない。と、いうことになり、そろそろ新しい NotePC を買うことを考えていたところに drm-next-kmod がバリバリと動作する。 Radeon HD 8330 も radeonkms.ko で動作するようだ。と、いうので 10.1-RELEASE から 11.2-RELEASE にいっきに上げてみることにしました。

と、ここまでが前振りです(^^;;。
freebsd-update でいっきに 11.2-RELEASE にして pkg delete -a で古い packages を削除したあとに 11.2-RELEASE でコンパイルした KDE5 一式をドドドとインストール。その他 NotePC に必要なモノをインストールします。

そして、今回はそこに graphics/drm-next-kmod をインストールします。 /usr/ports/graphics/ の下を見ると、全部で以下があるようです。

・drm-devel-kmod/
・drm-legacy-kmod/
・drm-next-kmod/
・drm-stable-kmod/

まぁ、見て、雰囲気が大体解ると思われますが;-)。

graphics/drm-next-kmod をインストールすると /boot/modules/ の中がずいぶんとにぎやかになります。

この中から radeonkms.ko を見つけ出してブート時に kldload するように、/etc/rc.conf に設定します。

# --- kernel module load --- #
kld_list="/boot/modules/radeonkms.ko"

 
radeonkms.ko は今回 graphics/drm-next-kmod でインストールしたモノと別にシステム標準の /boot/kernel/radeonkms.ko があります。 /boot/loader.conf に radeonkms_load=”YES” と書くとシステム標準のカーネルモジュールがロードされてしまうため、上記のように記載します。

インストールが完了したあとは /etc/X11/Xorg.conf を編集してあげます。最近は /usr/local/etc/X11/xorg.conf.d/ 内にドライバ・キーボード・マウスなど、個別のファイルを用意して /etc/X11/Xorg.conf は書かない。ってのが流行みたいですねぇ。まぁ、どっちにしろ Section “Device” の項を書き換えます。

Section "Device"
        Option      "TwinView" "true"
        Option      "TwinViewOrientation" "LeftOf"
#       Option      "RegistryDwords" "EnableBrightnessControl=1"
        Identifier  "Card0"
#       Driver      "radeon"
#       Driver      "vesa"
        Driver      "modesetting"
        BusID       "PCI:0:1:0"
EndSection

 
Driver radeon は動作しないので、しょーがない。今までは Driver vesa で使っていたのですが、今回 graphics/drm-next-kmod にしたので Driver modesetting にしました。最近の Xorg は賢くなって色々なモノを自動認識するようになり、デバイスにあったカーネルモジュールをロードしてくれるようです。

と、いうことで上記の設定ができたらリブートしましょう。
リブート後、僕の ThinkPad E145 では以下のカーネルモジュールがロードされるようになりました。 linuxkpi.ko が今回のカナメでしょうかねぇ。

--- <上略> ---
23    1 0xffffffff82421000 15d6d9   radeonkms.ko
24    1 0xffffffff8257f000 74b70    drm.ko
25    4 0xffffffff825f4000 edc8     linuxkpi.ko
26    3 0xffffffff82603000 114b8    linuxkpi_gplv2.ko
27    2 0xffffffff82615000 6b8      debugfs.ko
28    1 0xffffffff82616000 23f8     radeon_kabini_pfp_bin.ko
29    1 0xffffffff82619000 23f8     radeon_kabini_me_bin.ko
30    1 0xffffffff8261c000 23f8     radeon_kabini_ce_bin.ko
31    1 0xffffffff8261f000 43f8     radeon_kabini_mec_bin.ko
32    1 0xffffffff82624000 2a78     radeon_kabini_rlc_bin.ko
33    1 0xffffffff82627000 12e8     radeon_kabini_sdma_bin.ko
34    1 0xffffffff82629000 38eb0    radeon_bonaire_uvd_bin.ko
35    1 0xffffffff82662000 13328    radeon_BONAIRE_vce_bin.ko
36    1 0xffffffff82676000 37528    linux.ko
37    2 0xffffffff826ae000 2d28     linux_common.ko
38    1 0xffffffff826b1000 31e50    linux64.ko
--- <以下略> ---

 
Xorg を起動し、ログインマネージャの x11/sddm を起動し KDE5 にログインします。そして、 「KDE システム設定」から[ディスプレイとモニタ]->[Compositor]ときて、[レンダリングバックエンド]を確認します。VESA ドライバを利用していたときは選択できるのは xdandr のみだったのですが、今は OpenGL2.0 や 3.1 が指定できます。おぉっ!! これで 「ゆれるウインド」とか「魔法のランプ」などが利用できるようになるっ!!

ってんで、 graphics/drm-next-kmod の恩恵が受けられるのでありました。

 
で、次のステップですが、 まだ、以下の二点が残っております。

・suspend/resume はちゃんと動くの?
・バックライトの明るさ調整はできるの?

まず、suspend/resume についてですが、最初の 1,2 回はフタを閉じた段階でシステムごとフリーズしていたので『むむむ。 graphics/drm-next-kmod は suspend/resume に対応してないのか?』などと思ったのですが、ロードするカーネルモジュールとかその他設定を見直すことで無事に suspend/redume が動作するようになりました。

ThinkPad E145 では acpi_video.ko はまともに動作してないので利用していません。 acpi_ibm.ko はバックライト調整はできないけどボリューム調整はできるのでロードしています。

 
次にバックライト問題ですが、これは、本家でも wiki の掲載があるほどなので、ことは一大事なのでしょうなぁ。

https://wiki.freebsd.org/Graphics/Brightness

ここに書いているのは一通り試しました。上にも書いた通り ThinkPad E145 は Radeon HD 8330 なので intel_backlight (ports 的には graphics/intel-backlight) を使うと Device not found. です。あら。つべたい。

accessibility/sct はオプションの数値を変えると色が変わるので、 LCD brightness とはちょっと違う。

で、結局、僕は xrandr を使うことにしました。xrandr は VESA ドライバを利用している頃はまともに動作しなかった (Can’t open display と表示される) のですが、 graphics/drm-next-kmod を使うと無事に動作するようになりました。

まず、以下のコマンドを打ってディスプレー名を取得します。

$ xrandr --listmonitors
Monitors: 1
 0: +*LVDS-1 1366/256x768/144+0+0  LVDS-1

 
最後の LVDS-1 が重要で VESA ドライバを利用していた頃はこの値が表示されず xrandr で明るさの調整ができなかったんですね。今回 graphics/drm-next-kmod を利用することによりちゃんと動作するようになりました。ここまで来ればラクショーです。あとは以下のようにコマンドを打って画面の明るさ調整をすれば良いだけ。

$ xrandr --output LVDS-1 --brightness 0.8

 
今動作している明るさが 1 で、それよりも暗くしたい場合は 1 以下の数値を小数点で指定し、更に明るくしたい場合は 1.2 とか指定すれば良いです。

雰囲気的には機械的にバックライトを調整するのではなく、画面の色をグレーにすることで暗くなったように見える。と、いう機能ですね。ハードウェア的にバックライトを暗くしてないのでバッテリー運用のときは要注意って感じでしょうか。

 
と、いうことで CPU/GPU 共に AMD な NotePC である ThinkPad E145 ですが、

・11.2-RELEASE にした
・graphics/drm-next-kmod で Radeon HD 8330 を認識してくれる
・KDE5 が使えるぞぉ (これは当たり前;-)
・suspend/resume ができる
・バックライト調整も一応できる

と、いう状態になり、ほぼほぼ満足な結果です。細かく言うと

・キーボードが 101 のままだぁ
・マウスの動作があやすぃー
・音の出るところ調整(スピーカーかイヤホンか)

など、ありますが、それらは Xorg の設定で調整するもヨシ。KDE5 側で設定するもヨシ。と、いう状態なので、道は色々あります。それらを一応全て解決できたので、僕の ThinkPad E145 は壊れなければあと 4,5 年は持つような気がしてきました;-)。

5月 202018
 

最近の ports-current を追いかけていると、統合デスクトップ環境 (懐かしい響きだ;-) に KDE4 を利用している人にとっては、関連性からインストールする packages が xxx-kde4 へと、名前が順次変わっていたので『むむむ。そろそろ KDE5 が降ってくるのか?』などと思っていたら、果たしてその通りで x11/kde5 と、いうのができました。

デスクトップが更新されたのはずいぶんと久しぶりだなぁ。以前のこのブログのエントリに「FreeBSD に KDE4.1 がやってきた。」と、いうのを書いているのですが、それが 2008 年 08 月ですね。約 10 年ほど KDE4 を使い続けた。と、いうことですが、このたび KDE5 に移行しました。今回のネタは FreeBSD で利用する KDE5 について、少々書いてみたいと思います。

 
それにしても 10 年も経つと色々なことが変わりつつあります。そもそも、今でもデスクトップ環境として FreeBSD+xorg を利用している人は何人くらいいるのでしょうか? このエントリを書いて、ちゃんと読んでくれて、設定を方法を見てくれる人がどれくらいいるのでしょうか? 不安です・・f(^^;;。

が、まぁ、しかし、初めてみましょう。

 
1). インストール
まぁ、簡単で ports の x11/kde5 を make install すれば良いだけです。make config で好きなモノを設定していけば良いでしょう。
ただし、KDE4 からのアップグレードの場合、KDE4 に関連する packages は全て削除しましょう。 KDE4 と KDE5 の ports/packages では confrict が発生し、 make install が途中で止まったりします。

インストールは qt5- ・ kf5- ・ plasma5- で始まるモノがドドドとインストールされます。 akonadi はまだ動かないようですね。なので korganizer やkmail などは動きませんし、インストールされません。 okular は QT4 ライブラリがくっ付いているのでインストールする気にもなれません。これらは 18.04.1 のバージョンで多分解決するのではないかな。と思われます。
オフィスアプリは calligra-3.1.0 よりも libreoffice のほうが良いでしょう。

あと、KDE5 や Qt5 では日本語言語パックがなくなりました。フツーにインストールすると i18n 対応です。一応、 devel/kf5-ki18n がインストールされているかだけ、確認しておきましょう。

ports から make すると PC の性能にもよりますが 40 時間程度でインストールされると思います;-)。

 
あと、ウィンドマネージャとしての kdm がなくなりました。変わりに sddm というのを利用します。 kde5 インストール時に関連性でインストールされないので、後から x11/sddm と deskutils/plasma5-sddm-kcm をインストールしましょう。

起動については kdm4 と一緒です。 /etc/rc.conf に以下のように記載すれば OK です。

sddm_enable="YES"
sddm_lang="ja_JP"

 
sddm は一回起動すると /usr/local/share/sddm/scripts/Xsession というログイン時のスクリプトを生成します。自分好みの起動にしたい場合はこのファイルを直接直しちゃいましょう;-)。

インストールについてはだいたいこんな感じでしょうかねぇ。

 
2). 環境構築。
sddm から左上の「セッション」から “plasma” を選択すると上記 sddm の Xsession から startkde が実行され、デスクトップが表示されます。
“User Session” を選択すると ${HOME}/.xsession が動き出します。

起動後についでてすが、 KDE4 を利用していた場合は ${HOME}/.kde4/ に設定ファイルが置かれていましたが、 KDE5 では ${HOME}/.config/ にバラけて入るようになりました。
僕の場合は、ややこすぃーのがイヤなので KDE4 の設定は引き継がず、新たに KDE5 の設定ファイルが新規に生成されるようにしました。しかし、KDE5 になっても ${HOME}/.kde/ に設定ファイルを置くプログラムが何個があるようですね。

KDE5 のデスクトップ環境は「KDE システム設定」 (systemsettings5) で様々な設定をします。

僕は「KDE システム設定」->「起動と終了」->「自動起動」から「スクリプトファイル」で以下を実行するようにしました。環境変数と X のキーボード周り、あと、言語設定などですね。

#!/bin/sh
# XmodMap Sesource Setup
Xkeybord=$HOME/.xmodmaprc
if [ -f $Xkeybord ]; then
        /usr/local/bin/xmodmap $Xkeybord > /dev/null
fi
UsrResource=$HOME/.Xresources
if [ -f $UsrResource ]; then
        /usr/local/bin/xrdb -load $UsrResource
fi

# Start some clients
xset s 300 300 &
xset s noblank &

export LC_TIME=C
export LANG=ja_JP.UTF-8
export LC_CTYPE=ja_JP.UTF-8

export TZ=JST-9

export TERM=xterm
export UNICODEMAP_JP=cp932

# Session Type Select
export KDE_UTF8_FILENAMES=true
export KDE_LANG=ja_JP.UTF-8
export QT_XFT=true
export GDK_USE_XFT=true

## IME Start
#export QT_IM_MODULE=xim        # Qt4 用設定
export QT_IM_MODULE=fcitx       # Qt5 用設定
export GTK_IM_MODULE=xim
export XMODIFIERS=@im=fcitx

exec /usr/local/bin/mozc start
exec /usr/local/bin/fcitx

# Other Wakeup Programs
# gkrellm
Gkrellm="/usr/local/bin/gkrellm"
if [ -f $Gkrellm ]; then
    exec $Gkrellm &
fi
# Emulate3Button
Xkb2mb2="/usr/local/bin/kb2mb2"
if [ -f $Xkb2mb2 ]; then
    exec $Xkb2mb2 -c 117 &
fi

 
日本語入力は fxitx+mozc を利用しています。 fcitx は Qt5 用に textproc/fcitx-qt5 をインストールする必要があります。そして、環境変数の設定方法も変わっています。

fcitx 自体は今でも GUI 部分に Qt4 ライブラリを利用しています。うーむ。早いところ Qt5 に移行してほしいなぁ。 fcitx5 というのがリリースされているので、早いところ FreeBSD の ports になってほしいモノです。
ちなみに japanese/mozc-tool は Qt5 に移行しています。

文字をベコベコ打っていると、キーボードが 101 形式であることがわかります。 106 キーボードに変更する人は「KDEシステム設定」->「入力デバイス」->「キーボード」から設定します。一番最初に表示される [ハードウェア] タブにのキーボードモデルには 106 キーボードが無いんですね。その横にある [レイアウト] タブの「レイアウトを設定」にチェックを入れて JP 日本語キーボードを新規に登録する必要があります。

以下、キャプチャです。

こんな感じでキーボードを登録すると KDE5 側でも 106 キーボードが利用可能です。 X の twm などでは 106 キーボードが使えるのに KDE5 を起動すると 101 キーボードになってしまうので困ってしまうですねぇ。

 
もっと困ったのがマウスでした。僕の場合 Apple が推奨する Natural Scroll 、それは俗にいうホイールの逆回転ですね。これが動かない。
「KDEシステム設定」->「入力デバイス」->「マウス」に『スクロール方向を逆にする』という項目があり、チェックを入れても逆になりません。あららぁ・・。

色々調べてみると KDE5 からは libinput というのがマウスを管理しているようです。ports 的には x11-drivers/xf86-input-libinput です。 xorg.conf の設定で以下のような感じで用意してあげれば動くようなのですが、 Linux のドキュメントはたくさんある。しかし、 FreeBSD のドキュメントは全く無いっ!!

FreeBSD のフツーの X の使い方では xf86-input-libinput は利用されません。

Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
#        MatchDevicePath "/dev/sysmouse"
        Driver "libinput"
        Option "NaturalScrolling" "true"
EndSection

 
詳細についてはインターネット上にある libinput のドキュメントを読んでください。Linux の場合は /dev/input/event* なるデバイスができるようですが、 FreeBSD の場合はそれができない。デバイスではなく MatchHoge でも装置を認識するようです。装置名などにマッチさせることもできるパラメータで何種類かのマッチ要素があるようです。装置を確認するには xinput list で特定するらしいです。

が、そもそも、現在の FreeBSD (少なくとも僕の環境) では libinput は Xorg で利用されないため必要ないようです。なので、この設定自体は無視してかまいません。

では、どうやってマウスのホイールを逆回転するか? いやはや。古典的な設定で実現しました。

 
o.回避策そのいち (xorg.conf)

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/sysmouse"
#   Option         "ZAxisMapping" "4 5 6 7"
    Option         "ZAxisMapping" "5 4 6 7"
EndSection

 
o.回避策そのに (${HOME}/.xmodmaprc)

pointer = 1 2 3 5 4 6 7 8 9 10 11 12

 
マウスのスクロールボタンは 4,5 なので、その値をひっくり返すことにより対応しました。 KDE5 の設定でなんとかしようとせずに X の設定で対応した。と、いう感じでしょうか。これで、マウスの設定も完了です。ふぅ。

 
僕的にはこれで KDE5 を楽しむことができるようになりました。

 
3). 使ってみる。
KDE4 から KDE Plasma5 になり、画面の雰囲気がガラっと変わり、全体的に明るくなりました。ベースのワークスペースのテーマは Breeze というのになりました。そのおかげでちょっと明るめの気配かな。使用感は KDE4 と遜色ないです。

 
気がついた問題点を少々。

 
o.ディスク IO 負荷が高い
ログインしてしばらくすると /usr/local/bin/baloo_file_extractor が動き出します。これはデスクトップのフル検索のための情報収集プログラムだと思われます。 macOS で言うところの mdworker のようなモノですね。こいつが動いていると KDE5 がやたらと重いのでプロセスを kill してかつ、「KDEシステム設定」->「検索」から「Enable File Search」のチェックをはずすとフツーの速さに戻ります。

 
o.今まであったアプリがない
上にも書いた通り、FreeBSD だけかもしれませんが、まだ akonadi が無いためにオフィス系アプリはほとんどありません。別途インストールする必要があります。もしくは 05/19 以降の ports-current を利用するのが良いかと思われます。

あと、このエントリ書くためにスクリーンキャプチャ (スクリーンショット) を撮ろうとしたんだけど、グラフィックスのメニューの中もずいぶん静かで、ありませんでした。
で、調べてみると、なんとっ!! PrtScr ボタンを押すと起動するんですね。 Windows みたいだ。で、実態はというと /usr/local/bin/spectacle が起動するので、メニューに登録してあげると良いでしょう。 (よくよくメニューを眺めてみると「ユーティリティ」の中にありました)

 
o.konqueror は相変わらずか?
レンダリングエンジンが KHTML から Webengine に変わっていますが、firefox に比べて軽いブラウザなので嬉しいです。が、SSL なサイトは相変わらず閲覧できないのは KDE の証明書ライブラリが相変わらずぶっ壊れているからか?

 
とまぁ、ダラダラと書いてみましたが、一番最初にも書いた通り、約 10 年ぶりのデスクトップ環境のアップデートです。嬉しいですねぇ。途中 KDE4 が重くて xfce4 をインストールしたこともありましたが、やはり KDE は良いですねぇ。

Gtk2/3 の角ばった雰囲気よりも Qt4/5 の丸っこいアウトラインが好きだし、そー考えると GNOME はもう 8 年くらい触ってないし。

などと、書いていますが、皆さんも是非 KDE Plasma5 をお試しください;-)。

4月 302018
 

ゴールデンウィークの前半に秋葉原に NVIDIA GeForce GT 720 と 1TB の 3.5 インチの HDD を買いに行きました。古い PC (Athlon64 X2) で FreeBSD を動作させるためですね。
FreeBSD の場合 AMD (ATI) のビデオカードより ports の x11/nvidia-driver-340/ で動作する NVIDIA の NIC のほうが安心して 3D グリグリできるんですね。

で、お買い物終了後、アキバ散策していたら、新しくジャンク屋さんがオープンしていたのでちょっと覗いてみました。そしたらなんとっ!! PCI のグラフィックスカードの新品が 200yen で売っていたので購入してしまいました。当然ジャンク扱いですが。

購入したのはこんな感じ。もう一度繰り返しますが 200yen で、新品です;-)。

グラフィックスチップは往年の ATI の Rage XL です。メモリ 8Mbyte だそうです。うひひ。

今回再利用しようとしている古い PC には PCI スロットがあるので、この 200yen のグラフィックカードで X が表示できると嬉しいなぁ。などと思い、早速試してみました。

# X -configure
...

 
あらら・・。残念ながら、Xorg の -configure では自動的に xorg.conf を生成してくれないようです。挙句のはてには vesa ドライバが選択されました。
古いビデオカードは X -configure で xorg.conf が生成されないのかななぁ・・。

あと、サイズ的にはフル HD の 1920×1080 サイズで表示して欲しいんですけど・・。

やっぱりメモリ 8MB のグラフィックカードでは無理かなぁ?

あまり、格闘せずにさっさと NVIDIA GeForce GT 720 にしてしまったけど、あきらめがちと早いかな。まぁ 200yen だしなぁ・・。

 
話は突然変わりますが、今回購入した NVIDIA GeForce GT 720 を PRIMERGY MX130 S2 の PCI-e BUS にさして電源投入してみましたが、一回 BIOS 画面が出ただけで、まともに表示してくれませんでした。
今まで NVIDIA GeForce GT 210 を利用していたときは無事に起動してくれていたのですけどねぇ。多分電力量の不足が原因なのでしょうなぁ。 AMD FX-6100 な 6Core の CPU 載っているしなぁ。

と、いうことで古い PC の再利用は NVIDIA GeForce GT 720 で決定です。

3月 292018
 

以前のエントリで「FreeBSD で if_urtwm を使ってみる。」と、いうエントリを書いているのですが、今回はそれの続編です。と、いうか、僕は USB の Wi-Fi ドングルが好きなようで、今までにもこのブログでは何回か書きました。

最近は REALTEK の USB Wi-Fi ドングルは 802.11a の 5GHz 帯に対応しているものが多いので FreeBSD でもその恩恵にさずかりたいものだ。などと思っているのですけども。

 
前回の USB 接続機器はずいぶんと大きかったのですが、今回は手頃なサイズの USB 機器です。まずは写真を。

でもってこっちがパッケージ。僕の場合 Windows10 で動作確認する前にまずは FreeBSD に接続して確認するのですが、ご多分にもれず、今回も素直に ugen に落ちました(^^;;。

パッケージやドライバ DC の印刷を見てみると REALTEK の RTL8811AU というチップが使われているようです。

で、以前掲載した GitHub を見に行くと・・。おやまぁ。カーネルモジュールのは FreeBSD 12-CURRENT に対応した patch になっているようです。で、ちょっと違ったところを見に行くと、おぉ。 FreeBSD 本体に commit されたのかしら? 新しく rtwn_usb というカーネルモジュールになるようですねぇ。
もう少し待てば、自分でコンパイルせずとも、 OS 標準で利用できるようになるのかもしれません。

 
さてと。今回購入した USB Wi-Fi ドングルですが、仕様としては REALTEK RTL8811AU ですが、 if_urtwm.ko は RTL8821AU 対応です。大丈夫か? などと思い試しましたが、すんなりと動きました。

まぁ、当然の作業として if_urtwm.c にはエントリを記述して、 usbdevs にも product ID を登録する必要があるんですが。

o. if_urtwm.c に記述する行

        URTWM_DEV(REALTEK,      RTL8811AU),

 
o. usbdevs に記述する行

product REALTEK RTL8811AU       0xa811  RTL8811AU

 
これで利用可能になりました。

 
以前のエントリで試した AUKEY の AC1200 というのは USB3.0 接続でチップセットが RTL8812AU でしたが、今回のは USB2.0 で RTL8811AU なので、もしかしたら一個古いチップで USB2.0 対応なのかもしれません。

 
電波が外にもれない(と思われる)部屋で動作確認をしたところ、200MB のファイルを転送してみると 50Mbps 程度でいたので、ずいぶんと速度が速い USB WiFi で、それが FreeBSD で体験できることにある意味感動を覚えました;-)。

 
あ。FreeBSD で 802.11a を利用する場合 /etc/rc.conf のネットワークの設定のところにおまじないを書かないと動作しないようです。

o. /etc/rc.conf の記述例

wlans_urtwm0="wlan0"
ifconfig_wlan0="WPA DHCP ssid AP802-5 mode 11a country J5"
#ifconfig_wlan0="WPA inet 192.168.1.100 netmask 255.255.255.0 ssid AP802-5 mode 11a country J5"

 
上記の設定は SSID: AP802-5 という 802/11a (もしくは 802.11ac) の AP に接続するときの設定ですが、どこの国で接続するか指定してあげないと正しく動作しないようです。おかげでサクサクと動作しているー;-)。

今後は安定的に動作していることを確認して行きたいとは思うのですが、こってりと利用するのはちょっとはばかれるので、動作確認のみ。と、したいと思います。

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 の中に書いてあるので、試してみたい方は一回覗いてみると良いかも知れません;-)。

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 のバージョンがあまり多くはないような気がしないでもないですし。

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

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 すれば良いだけですねぇ。

簡単だぁ;-)。

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

 

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。
加筆ここまで

5月 182017
 

と、いうことで非常に簡単なエントリーですが、困っている人もたくさんいるのではないかと思うので書いておきます。あ。 ports-CURRENT を追いかけている人向けです。

Vmware ESXi 上で FreeBSD を動作させている人は ports から emulators/open-vm-tools/ もしくは emulators/open-vm-tools-nox11/ をインストールしているかと思われます。

これ、ずいぶん前から FreeBSD/amd64 10.3-RELEASE ではコンパイルが通らなくなっているんですよね・・。
lib/user/utilBacktrace.c の中でエラーが出ています。

FreeBSD な ML でも話題になっていますが、誰も相手にしてくれないようで・・。 orz

https://lists.freebsd.org/pipermail/freebsd-virtualization/2017-January/005186.html

けどもまぁ、一応、パッチを当てて FreebSD/amd64 でコンパイルが通るようにしたので、そのパッチをここに記載しておきます。
以下がパッチです。

--- lib/user/utilBacktrace.c.orig       2017-05-17 22:23:46.088791000 +0900
+++ lib/user/utilBacktrace.c    2017-05-17 22:23:53.932119000 +0900
@@ -54,7 +54,6 @@

 #ifdef VM_X86_64
 #   if defined(__GNUC__) && (!defined(USING_AUTOCONF) || defined(HAVE_UNWIND_H))
-#      define UTIL_BACKTRACE_USE_UNWIND
 #   endif
 #endif

 
これを patch-utilBacktrace.c という名で保存して emulators/open-vm-tools/files/ 辺りにでもほーりこんで make してみてください。

このパッチですが、注目点としてその上の行の ifdef VM_X86_64 の部分です。

実は手元に Vmware ESXi 上で動作する FreeBSD/i386 があるのですが、これでは無事に emulators/open-vm-tools-nox11/ のコンパイルが通りました。

ってことは、つまりはなんだい?

VM_X86_64 のとき(それはつまりはアーキテクチャが x86_64 のとき。と、いうことですね)に UTIL_BACKTRACE_USE_UNWIND が define されて lib/user/utilBacktrace.c をコンパイルすることになって、それがエラーになるのでコンパイルが通らない。と、いうことですね。

ならば UTIL_BACKTRACE_USE_UNWIND を define させなければ良いんじゃーねーのかい? FreeBSD/amd64 だからといってもデバッグ用のロジック(本当か? f(^^;)は FreeBSD/i386 にもないんだからいらねーだろ。って発想です;-)。

果たして、上記パッチを適用することにより FreeBSD/amd64 でも emulators/open-vm-tools-nox11/ のコンパイルが無事に通ったのでありました。

あ。コンパイルが通っただけでなく、利用もしていますが、今の所問題は出ていないです;-)。

 
すげー、お気楽なパッチですが、最新版の emulators/open-vm-tools-nox11/ が FreeBSD/amd64 に今すぐ必要・直ちに必要などという人は参考にしてみてください。

 
ずいぶん前からコンパイルが通ってないのだけど、まだまだ当分、直らないんだろうなぁ。などと思っております・・。