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 に今すぐ必要・直ちに必要などという人は参考にしてみてください。

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

5月 102017
 

一個前のエントリは RPi ZERO で FreeBSD/arm 11.0-RELEASE が動いた。というお話でした。RPi 2/3/ZERO 上で動作する OS はディスプレーが無いので Zeroconf を動かして ssh hoge.local したいと思いますよね。

そして、以前のエントリで「Zeroconf 考察」というのを書いているのですが、デスクトップには Avahi をインストールして、サーバなどはより軽量な mDNSResponder をインストールすれば良いよ。などと書いているのですが、 mDNSResponder は core dump するなど、どうも動作があやすぃ・・。
なので、いっそのこと Avahi で統一したいモノだ。などと思っていたんですけども net/avahi-app/ は、サーバには不要なモノをインストールしすぎる。

そんなこんなで、もっと簡単にインストールできる軽量版の net/avahi-app/ の ports を作成しました。名前を avahi-app-small としていますが・・。
以下の URL にあるので、もし試してみたい。と、いう方がいましたらダウンロードしてみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-avahi-app-small-20170510.tgz

インストールは以下の通り。

# cd /usr/ports/net/
# tar xvzfp ~/ports-avahi-app-small-20170510.tgz
# cd avahi-app-small/
# make install

 
フツーの ports をインストールするのとなんらかわりはありません。が、注意点が一点だけあります。クライアント側の ports である dns/nss_mdns/ を make install するより先に avahi-app-small をインストールしてください。

ではどの辺りが違うのか? 軽量なのか?

標準の net/avahi-app/ の ports は以下をインストールします。

Shared Libs required:
        libintl.so.8
        libglib-2.0.so.0
        libgobject-2.0.so.0
        libexpat.so.1
        libgdbm.so.4
        libdaemon.so.0
        libdbus-1.so.3

 
devel/glib20/ や devel/gobject-introspection/ は関連性でサーバには要らんモノ (cairo とか freetype2 とか python27 とその関連性の ports など)をドドドとインストールしてとてつもないことになるし sysutils/gnome_subr/ なんてのも要らんし・・。

僕が作成した avahi-app-small の ports をインストールすると以下がインストールされます。

Shared Libs required:
        libdbus-1.so.3
        libintl.so.8
        libdaemon.so.0
        libexpat.so.1

 
これだけです。 非常に軽量にインストールできます。 Avahi 自体は dbus を利用しているので dbus は必須になってしまいますが、これはまぁしょーがないか。
ports からインストールするとコンパイルのために色々インストールされますが、あとで pkg autoremove するか、コンパイルの時間がもったいない場合には packages からインストールしてください。

 
ports の Makefile では LIB_DEPENDS は最小限にして CONFIGURE_ARGS では不要なモノを色々 disable にしています。これだけでずいぶんと小さくなりました。
GNOME 必要ねーし。 Makefile の以下の行は何のためにあるんだぁ?

avahi-post-patch:
    :
        @${REINPLACE_CMD} -e 's|%%RC_SUBR%%|/etc/rc.subr| ; \
                s|%%GNOME_SUBR%%|${GNOME_SUBR}|' \
                ${WRKSRC}/initscript/freebsd/avahi-dnsconfd.sh.in \
                ${WRKSRC}/initscript/freebsd/avahi-daemon.sh.in
    :

 
files/patch-initscript_freebsd_avahi-daemon.sh.in には +. %%GNOME_SUBR%% なんて最初から書いてあるし・・。

と、いうことで要らんモノを削ぎ落としていったらすごい軽量な(それはつまりは、余計なモノをインストールしなくて済む。と、いうことで、動作的に軽くなった。と、いう意味ではない;-) Avahi がインストールできるようになりました。
試したのは avahi-daemon avahi-dnsconfd avahi-browse くらいですが、これだけ動けば、一応問題はないでしょ? f(^^;;。

あ。ports 的にはノラです;-)。gnome@freebsd.org (メンテナ) に連絡して「make config で余計なのインストールするのやめるように、選択できるようにしてくれよー。」って、ツッコミ入れるのはアリだと思うのですけどねぇ・・。

今回の ports はサーバと FreeBSD/arm で動作させるために作成した。と、言っても過言ではないですが、これで自宅のデスクトップとサーバは Linux も含めて全て Avahi になった。あ。macOS は別だぁ;-)。

5月 022017
 

ゴールデンウィークのお楽しみ用に Raspberry Pi を二個購入しました。一個は Raspberry Pi 3 Model B で、もう一個は Raspberry Pi ZERO です。二個合わせて 5,000yenちょっと出た程度。

正規代理店の 株式会社 ケイエスワイで購入しました。
5,000yen 以上だと送料無料だというので二個買ってしまった。と、いう話なんですけども。

これで Raspberry Pi は 2,3,ZERO と三つになりました。

左から RPi2 -> RPi3 (ハイレゾ音源ボード装着) -> RPi ZERO と並んでいます;-)。

Raspberry Pi 3 Model B は volumio2 で利用予定です。 オンボードの Wifi チップは FreeBSD では利用できませんが、Linux では利用できるので。ちなみに volumio2 でも利用可能です。おかげで USB な Wi-Fi が余ったので他の RPi に回せます。

今まで利用していた Raspberry Pi 2 Model B は 自宅で FreeBSD マシンとして動作させるべく FreeBSD/arm 11.0-RELEASE をインストールしました。以前このブログでもエントリを書いているのでサクっと動作します;-)。

ports のコンパイル環境も母艦側を FreeBSD/amd64 10.1-R から 11.1-R にバージョンアップして、 qemu 側も新たに FreeBSD/arm 11.0-R 用のを作成したのでコツコツと最新の ports-CURRENT を更新して行きたいと思います。

最近の FreeBSD/arm 11.0-R は pkg install が利用できるのでずいぶんと楽にはなりましたね。ただ、ちょっと古い。そんな場合は以下の URL を覗いてみてください;-)。

http://distfiles.icmpv6.org/freebsd:11:armv6:32/latest/All/

と、いうことで、今回のネタは Raspberry Pi ZERO についてです。

 
Raspberry Pi ZERO は値段が 600yen で非常に手頃な値段です。外部接続には電源供給用の MicroUSB と、USB 機器接続用の MicroUSB のポートがあります。ディスプレーは MiniHDMI ポート、これはちょっと痛かった・・。 MicroHDMI ポートだと Diginnos DG-D08IWBと互換があるので嬉しかったのですが・・。

今回は HDMI への出力を諦め、シリアルコンソールを利用しました。

そもそも RPi ZERO には GPIO ピンがなくて穴が空いているだけです。なのでシリアルコンソール用のピンをハンダで付けてあげる必要があります。

まず、ピンの手配ですが、昔利用していた PC のサウンドカードから 3 本ほど調達しました。下の写真のような感じ。

うまく固定もしたのでこれを穴の中に通します。ハンダ付けはしません。ちょっとななめにすると接触するのでハンダ付けしなくとも利用できました。

OS は FreeBSD/arm 11.0-RELEASE をチョイス。イメージは以下を利用しました。

FreeBSD-11.0-RELEASE-arm-armv6-RPI-B.img.xz

ちなみに RPi2 では以下のイメージを利用します。

FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img.xz

RPI2 のイメージも RPi ZERO で試しまたがブートしませんでした。

RPI-B なイメージを MicroSD に dd し SD カードを差し込んで電源オンっ!! 無事に起動したのであります。

起動時の情報は以下になります。

dmesg
sysctl -a

僕は MIcroUSB -> USB 変換ケーブルで USB Wi-Fi や USB NIC を付けてネットワークリーチャブルにしたあとリモートからの SSH と NFS で作業を実施。環境構築が完了したのでありました。

そーそー。 RPi ZERO の ports/packages は FreeBSD/arm 11.0-RELEASE RPI2 の環境で作成したものがそのまま動作しました。 RPi2 と ZERO ではブート用イメージファイルが違うので ports/packages も違うのかな?などと思ったのですが、どちらも 32bit なバイナリで、同一のものが動作します。幸せなことです;-)。

と、いうことで特に問題もなく RPi ZERO は FreeBSD/arm が動作しました。

 
値段が 600yen で、約 5cm ほどの最小の FreeBSD 環境が整った。と、いうことですね。ゴールデンウィークの暇つぶしにピッタリなおもちゃです;-)。

4月 052017
 

FreeBSD の ports CURRENT を追いかけていると svn update したあとに portmaster -D -a するクセが付いているのでそれをやってバシバシ最新の ports/pkg を利用しているんだけど・・。

だいたい、時期を同じくして portmaster -D -a してのバージョンアップと Xming の利用が一緒になり、前のエントリの中で『Xming では mozc で日本語入力ができない。』などと書いていたのですが、なんとっ!! よくよく調べてみると GTK-3.0 を利用しているアプリの日本語入力ができなくなっていることがわかった。

KDE 系のアプリは Xming 経由や、素の Xorg 上では日本語入力ができるけど GTK-3.0 なアプリが日本語入力できなくなっていた。

最近は GTK-2.0 から 3.0 への過渡期で、僕の場合は GNOME3 は使ってないんだけど emacs や firefox は GTK-3.0 を明示的に指定して ports のコンパイルをしているし xfce4-terminal も default で GTK-3.0 を利用するようになっている。

と、いうことで今更ながら GTK-2.0 の IM 周りの設定を見直してもショウガない。 xfce4-terminal などは ldd で確認すると libgtk-3.so.0 を利用しているしね。
と、いうことで GTK-3.0 の日本語入力の設定の見直しです。

あ。 GTK-3.0 のアプリで日本語が入力できなくなったのは 03/31 に svn update して portmaster -D -a してからですね。その前まではちゃんと日本語が打てていました。

 
GTK-3.0 の設定はインストールすると、以下のディレクトリに散りばめられます。

・/usr/local/lib/gtk-3.0/3.0.0/
・/usr/local/etc/gtk-3.0/
・$HOME/.config/gtk-3.0/

この中に IM に関する設定ファイルが必要なります。

ちなみに GTK-2.0 の場合には日本語入力するためのファイルは以下になります。

・/usr/local/etc/gtk-2.0/gtk.immodules

このフアイルのおかげで、環境変数に以下を設定した場合に GTK アプリで日本語入力ができるようになります。

export QT_IM_MODULE=xim
export GTK_IM_MODULE=xim
export XMODIFIERS=@im=fcitx

exec mozc start
exec fcitx

 
僕の場合は QT_IM_MODULE を設定して KDE アプリで xim を利用し、 GTK_IM_MODULE も同様で、日本語入力には fcitx を mozc 経由で利用しています。

今回は GTK-3.0 のアプリについてですが、 GTK-2.0 の頃には /usr/local/etc/gtk-2.0/gtk.immodules があったのですが /usr/local/etc/gtk-3.0/ の下にはそんなファイルがありません。

なので作ってあげる必要があります。その場合、以下のコマンドを打ちます。

# cd /usr/local/etc/gtk-3.0/
# gtk-query-immodules-3.0 > gtk.immodules

 
さてと。準備完了。では xfce4-terminal を起動して Shift+SPACE を押してと。あれま。ダメだ・・。
と、いうことで上記の設定ファイルを用意してもダメなようです。

しょーがないので GTK-3.0 のドキュメントを読んでみることにしましょう。

https://developer.gnome.org/gtk3/unstable/gtk-running.html

上記の URL に書かれている説明では immodules の設定ファイルは immodules.cache という名になっているようです。では先程作成したファイルを mv して名前を変更して再度トライ。

しかし、ダメなようです。あれま・・。

上記のドキュメントを読むと直接ほーりむようなことが書いてあるので ports がフアイルをインストールしたディレクトリに直接用意してみることにします。

# cd /usr/local/lib/gtk-3.0/3.0.0/
# gtk-query-immodules-3.0 > immodules.cache

 
これで再度 xfce4-terminal を起動して Shift+SPACE を押してみます。おぉっ!! 今度は無事に fcitx の画面が表示されて日本語が打てるようになりました。メデタシメデタシ。

と、いうことは ports のバグっぽいので、今後バージョンアップされたときには直ることでしようなぁ。 ちなみに 03/31 の ports でインストールされた GTK-3.0 のバージョンは gtk3-3.18.8_4 です。
次にバージョンアップするとしたら gtk3-3.18.8_5 かな? 😉

 
GTK-3.0 のアプリで日本語が今まで打てていたのに急に打てなくなった。と、いう方は上記のように試してみてください。

4月 032017
 

遅ればせながら感が強いのですが、 Xming という Windows アプリを使ってみました。それについて、気付いた点を 2,3 書いてみたいと思います。

普段は会社でも FreeBSD+Xorg 環境なのですが、会社でフル HD なディスプレーが支給されて『わーいっ。X の画面も広くなるぞぉ。』などと思っていたのですが D-SUB 15pin のディスプレーカードと VESA では 1920×1080 の画面が表示できない。と、いうのを知ってアングリ・・。 orz

xrandr しても 1920×1080 が表示されないし、 xorg.conf に Modeline 書いてもダメだし。で、色々悪あがきしましたが、FreeBSD で 1920×1080 な画面を利用するのは諦めました。
新しい PC を買ってもらえれば解決すると思うんですが・・。

 
と、いうことで Windows10 から X のアプリを表示させるために Xming の利用を開始した。と、いうことなんですけども、色々ウェブで探してみると以下のようなものを拾ってくると OK らしい。と、いうことが解りました。

・Xming-6-9-0-31-setup.exe
・Xming-mesa-6-9-0-31-setup.exe
・Xming-fonts-7-7-0-10-setup.exe

以下の URL からダウンロード可能です。

https://ja.osdn.net/projects/sfnet_xming/releases/

mesa 版を利用すると OpenGL が使えるのかな? 好みでどうぞ。

あと、PuTTY が必要なようなんだけど、必要なモノは以下のようです。

・putty.exe
・plink.exe

URL も一応書いておきます。

http://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

が、今回は PuTTY は利用しません。 OpenSSH-Win64 を利用します。

・OpenSSH-Win64.zip

以下の URL からダウンロードします。

https://github.com/PowerShell/Win32-OpenSSH/releases

OpenSSH-Win64 は展開してからフォルダをとりあえずデスクトップに置いておきます。そして Xming と Xming-fonts をインストールします。

インストールが終わったら C:\Program Files (x86)\Xming\ の中にデスクトップの OpenSSH-Win64\ssh.exe を入れてあげると準備が整います。

使い方については様々なサイトで書かれているのでここでは書きませんが、一点だけ。 Xlaunch を起動して次々に画面を遷移していきますが、以下にたどり着きます。

上のキャプチャにもありますが、Using SSH (ssh.exe) にチェックを入れれば良いです。
色々試しましたが plink.exe ってのは機能的には ssh.exe と一緒なのですね。 DOS のコマンドプロンプトから plink.exe を利用すると ssh ログインできるのね。普段 PuTTY 使ってないので知らなかったです。ぼく。

 
さてと。ここから、僕はハマッたのですが、ちょっと書いておきます。

・Hyper-V をインストールしていると Xming は ssh できねくね?

ssh.exe 単体で FreeBSD にログインしようとすると無事にログインできるのですが Xming から ssh.exe を実行すると、ログインできないのであります。最初は plink.exe で試していたのだけど、上記のキャプチャのように ssh.exe でも大丈夫みたいだったので試したのですが、Xming が利用できない状態でした。

僕は Windows10 64bit の環境で FreeBSD を起動するために Hyper-V をインストールしていたんだけど、画面の描写が遅いので、今回サクっと Hyper-V を削除しました。

その後はサクっと Xming が動作し、 X アプリもガンガン飛んでくるようになりました。

Hyper-V をインストールすると、ネットワークインターフェースが bridge になってしまうので『Hyper-V が怪しいなぁ。』などと、メドは付けていたのですが、実際に Hyper-V を削除して試してみると無事に接続できたので、やはり。と、いう感じでしょうか。

たまたま、僕の環境だけなのかも知れませんが、 Xming が ssh 接続できない人は Hyper-V インストールしていたりしませんか?

 
さてと。 X アプリが飛んでくるようになったけど、キーがおかしくね? Ctrl キー使えないじゃーん。などと思ってしばらく難儀していたのですが、あ。僕の環境では Xkeymacs を利用していたわ。

と、いうことで Xkeymacs を OFF にすると無事に動作するようになりました。

・Xkeymacs をオフにすると Ctrl キーが利用できるようになる。

と、いうことで、無事に Windows10 上で X のアプリが利用できるようになったのでありました。一安心です;-)。

あぁ。mozic 使えないですね。例えば Firefox では日本語入力できない。emacs の場合は mozc.el を利用しているので日本語入力できます。

まぁ、この辺りはしょーがないのかなぁ。

と、いうことで Xming のの使い方について、書いてみました。実際に使ってみると中々良い感じです。タスクバーとかも欲しくなってしまう;-)。

 
さてと。話は変わるのですが、同じ Windows 上の環境と、いうことで Windows on bash の話を最後に書いてこのエントリを終了します。

Anniversary Update で Bash on Windows が提供されて bash が利用できるようになりました。しかし、 ssh した先で日本語を表示などすると悲惨な状況だっんですけどね。しかし 2017/04/11 から提供される Creators Update では正しく日本語が表示できるようになりました。これは嬉しい。

僕の場合は Windows Insider Previrew で 04/01 に Creators Update が降ってきたのですが、これで試したらもーバッチリな bash になっていました;-)。

皆さんも是非試してみてください。もしくは Creators Update リリースまで待ってから試してみてください;-)。

3月 112017
 

僕が持っている ThinkPad e145 は FreeBSD がインストールされていて、 suspend/resume するんだけど、resume 時、それはつまり目覚めたとき、パカっとフタを明けたときに default gateway が消えていたりして、ネットワーク的にはちょっと問題があったんですね。
まぁ、目覚めたあとにいつも route add していたんですけども。

そんなこんなで、resume 後に route add が必要なわけ、挙動をいよいよ調査してみることにしたんですね。

僕の FreeBSD の環境は以下です。

・FreeBSD/amd64 10.1-RELEASE
・ネットワーク環境は USB 接続の run0 -> wlan0

OS はまたもっと面白いことになってます。カーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。やってはいけない環境で動かしている。と、いうことですね。どうしてこんな環境で動かしているかについてはあとで少しお話します。

今の話題は resume 後に routing テーブルが消えている点についてですね。話を元に戻しましょう。

 
suspend して、その後 resume したときに起き上がってきた FreeBSD の動作ですが、だいたい以下のようになっているようです。

0. 実は suspend 時に USB デバイスが全部抜去される
1. resume 後に USB を認識してデバイスが接続される
2. resume 後に /etc/rc.resume が動く
3. devd が色々良きに計らってくれる (僕の環境では webcamd の再起動と pccard_ether のすーたと)
4. 自分で記述したスクリプトの動作
5. /etc/rc.resume の終了

まぁ、こんな感じですが、問題は 5. ですかね。

suspend で USB 機器が外されたということはつまりは wlan0 が無くなった。と、いうことなので、これで routing テーブルは全て消えます。
その後 resume して USB 機器が接続され wlan0 が認識され、wpa_supplicant が動き出してネットワークインターフェースには IP アドレスが付加されるようになります。

じゃぁ /etc/rc.resume の中で route add すりゃいんじゃね?

とか思うんですが /etc/rc.resume 内で route add してもそのときはまだ wlan0 に IP アドレスが付く前なので意味無いんですよね。

じゃぁ /etc/rc.resume の中で route add する前に sleep 30 とかすりゃいんじゃね?

とか、次に思いますよね。ところがっ!! /et/rc.resume はちょっとおかしな動作をしていて、 /etc/rc.resume が動作し終わったあとに wlan0 に IP アドレスが付加されるようです。

なので /etc/rc.resume の中で

sleep 30
route add default 192.168.1.1
route add -inet6 default fe80::1

 

などと書いても全く意味ない状態です。では、どうするか?と、いうと、上記の部分をスクリプト、例えば /usr/local/bin/routeadd.sh などとして準備します。
/etc/rc.resume には以下のように書きます。

/usr/bin/logger -t $subsystem route add default.
/usr/local/bin/routeadd.sh &

 

ここで注意しなければならないのは、スクリプトを記載したあと、最後に “&” を付けてバックグラウンドで処理させる必要があります。
動作的には /etc/rc.resume の実行後に wlan0 に IP アドレスが付くので /etc/rc.resume が実行中に sleep 30 してもまるで意味なくて route add されない状態です。なので “&” を書いてバックグラウンドに飛ばして、バックグラウンドのスクリプトが sleep 30 している間に /etc/rc.resume が終了して wlan0 に IP アドレスが付いたあと、 sleep 30 が終わり route add されるようにしないとダメなのであります。

この現象は USB NIC を利用しているからかもしれません。
動作的に resume 後に routing デーブルが消えていて、毎回、自分で route add 打つのが困難な人は上記のようにすれば良いのではないかと思います。

 
で、もう一個のネタを簡単に。

上のほうにも書きましたが、僕の ThinkPad e145 上で動作している FreeBSD はカーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。これ、FreeBSD の動作保証対象外の構成らしいですね。カーネルは新しく、ユーザランドが古い場合には問題ないらしいですが・・。

どうしてこんな環境で動かしているかというと ThinkPad を使っている人は 10.2-RELEASE 以降、suspend して resume したら LCD の明るさが最大になってしまい変更できなくなってしまったんですね。
10.1-RELEASE までだと Fn7,8 などで明るさが変更できた。 acpi_ibm や acpi_video がなくとも変更ができた。しかし、10.2-RELEASE 以降では Fn7,8 ボタンが効かなくなって、acpi_ibm の dev.acpi_ibm.0.lcd_brightness も有効にならなくて acpi_viode の hw.acpi.video.lcd0.brightness も使えなくなった。
resume 後に明るさを変えることができなくなったので、僕はいつまでもカーネルは 10.1-RELEASE を使い続けている。と、いうことです。

あと、別の手段としては ports から sysutils/acpi_call/ をインストールして ACPI のパラメータを表示したり変更したりできるようですが \_SB_.PCI0.VGA.LCD._BCM なパラメータなどをいじったりするなど、ちょっと試してみましたがダメでした。

acpi_call のコマンドイメージをちょっと書いておきます。使うには kldload acpi_call.ko する必要があります。

# acpi_call -vp '\_SB_.PCI0.VGA.LCD._BCM' -o i -i 50
Path: \_SB_.PCI0.VGA.LCD._BCM
Number of arguments: 1
Argument 1 type: Integer
Argument 1 value: 50
Status: 0
Result: 1

 
acpidump -d の結果を確認すると _BCM ってのが “Brightness Control Method” らしいです。他にも _BCL ってのがあって、こいつは “Brightness Control Levels” らしいです。
acpi_call で _BCM の値を 50 に変更してあげる。ってのが上記のコマンドと、その結果です。
しかし、値は反映されない・・。 orz

 
ThinkPad でも Nvidia のグラフィックスカードを利用しているヤツは Nvidia のツールで画面の明るさを変えられたり Intel の場合は graphics/intel-backlight/ などで画面の明るさを変えられるらしいです。
僕の ThinkPad e145 は Radeon のチップなので・・。orz

多分 10.2-RELEASE 以降で ACPI 周りに変更が入ったのでしょうなぁ。

ThinkPad e145 は BIOS モードと UEFI モードの両方で 11.0-RELEASE で試しましたが画面の明るさは変えることができませんでした・・。

と、いうことでももうしばらく、ってか、壊れるまで? 10.1-RELEASE の利用は続きそうです・・。

2月 222017
 

ある意味悲しいのかもしれないですが、僕は今も昔も IPv6 を利用するときに IPv6 Over IPv4 トンネルを利用する機会が多いです。
そもそも FreeBSD をずっと利用しているので dtcp を利用すると簡単に接続できます。 FreeBSD の ports 的に言うと net/dtcp になりますが、サーバ側とクライアント側の両方がインストールされます。通常、サーバ側に net/dtcp をインストールして dtcpd を利用し、クライアント側には net/dtcpclient をインストールしたりしますが、まぁ、とりあえずは net/dtcp をクライアント側にもインストールすることで、グローバルアドレスがあれば簡単に IPv6 Over IPv4 なトンネルが掘れるのであります。

が、そろそろ FreeBSD でのルータ機能は引退させたいものだ。などと思っていて、 NTT-X で超格安の Cisco841J を買いそびれた今、 VyOS で実装するしかなんかべ。と、なり IPv6 Over IPv4 トンネル で利用する dtcp を引退することにしたのでありました。

今回は VyOS と FreeBSD との間で IPv6 Over IPv4 トンネルを掘る設定を書いてみたいと思います。何を今更。感が満載ではありますがf(^^;;。

 
まずは構成図を。

真ん中の黄色いのが IPv6 ゲートウェイなルータでで FreeBSD/amd64 10.3-RELEASE から VyOS-1.1.7 にネットワーク機能を変更しました。
周りのピンクのセグメントは dtcpclient が動いていたのですが、これを VyOS に接続するために設定変更しなおします。

 
1. ゲートウェイスイッチ側の設定
FreeBSD から VyOS にリプレイスしたので設定は VyOS の設定になります。だいたいこんな感じ。

    tunnel tun10 {
        address 2001:470:fe36:1111::1/64
        description "# IPv6 Tunnel No1 #"
        encapsulation sit
        local-ip 192.168.1.210
        multicast disable
        policy {
            route mss
        }
        remote-ip 172.16.1.211
    }

 
VyOS は基本的に Linux なので sit なんてのが見えますが、こんな感じの設定ですね。

・local-ip で自分の IPv4 アドレスを設定
・remote-ip には接続先 IPv4 アドレスを設定
・policy route mss は IPv6 Path MTU Discovery にはまらないためのおまじない

以下の設定で MSS の値を調整しています。

policy {
    route mss {
        rule 5 {
            protocol tcp
            set {
                tcp-mss 1386
            }
            tcp {
                flags SYN
            }
        }
        rule 10 {
            protocol tcp
            set {
                tcp-mss 1386
            }
            tcp {
                flags SYN,RST
            }
        }
    }
}

 
簡単ですねぇ;-)。
ただ、 IPv6 Path MTU Discovery にハマると http とか接続できない問題が発生するのでその対応が必要になります。 tcp-mss 1386 の数値の部分は自分の環境によって変わるので過去に書いた記事を参考にしてみてください。

 
2. dtcpclient 側の設定
ルータ側の設定が終わったので、次にクライアント側の FreeBSD の設定になります。

とりあえず、以下のコマンドを打てばトンネルは掘ってくれます。

ifconfig gif0 create
ifconfig gif0 tunnel 172.16.1.211 192.168.1.210
ifconfig gif0 inet6 2001:470:fe36:2222::1 2001:470:fe36:1111::1 prefixlen 128
route -n add -inet6 default 2001:470:fe36:1111::1
ifconfig gif0 up

 
起動時に IPv6 トンネルを自動的に掘りたい場合はどうしますかねぇ・・。 /etc/rc.conf に色々設定するのが大変なので、僕の場合は /etc/rc.local というファイルを作って、そこに記述して起動時にどうにかしてもらっていますf(^^;;。

 
3. 確認方法
両方で設定が完了するとあとは確認になります。FreeBSD 側から以下のコマンドが有効ですね。

$ ping6 ff02::1%gif0
PING6(56=40+8+8 bytes) fe80::a1f:29ff:fefe:9696%gif0 --> ff02::1%gif0
16 bytes from fe80::a1f:29ff:fefe:9696%gif0, icmp_seq=0 hlim=64 time=0.089 ms
16 bytes from fe80::ccaa:f1d2%gif0, icmp_seq=0 hlim=64 time=8.663 ms(DUP!)
16 bytes from fe80::a1f:29ff:fefe:9696%gif0, icmp_seq=1 hlim=64 time=0.047 ms
16 bytes from fe80::ccaa:f1d2%gif0, icmp_seq=1 hlim=64 time=7.081 ms(DUP!)
^C

 
二つのリンクローカルアドレスから ping6 の応答があれば無事に接続しました。これで IPv6 Over IPv4 トンネルが掘れました。
グローバル IPv6 に ping6 を打って返ってこない場合はルーティングに問題があるので、ゲートウェイ側の設定を見直すなどしましょう。

 
と、いうことでゲートウェイ側を FreeBSD から VyOS に移行し、更に dtcp の利用をやめて接続しても、いとも簡単にトンネルが掘れました。良かったですぅ;-)。

2月 022017
 

IT 系のニュースサイトを会社でお昼休みに見ていたら Amazonセール速報:本日限りの特価! と、いうのを発見。かねてより会社で使うためのマウスを探していたので、すかさず購入しました。

購入後、次の日には届いたので早速使ってみることに。が・・。あたたたたた。使えることは使えるんだけど、ホイールが軽すぎて真ん中ボタンを押したら上下にホイールしてしまう状態である意味全然全く使えない。

例えばブラウザでとあるサイトのアンカータグを真ん中ボタンでクリックすると新規タブで開いてくれるんだけど、真ん中ボタンを押した表示されているコンテンツが上下にズズズと動いてしまう状態。全然使えないじゃん・・。

と、いうことで届いたその日のうちに分解。何とかカスタマイズできないかなぁ?などと思うわけです。分解の手順は至って簡単。

1. 電池を抜きます。
2. すると電池の溝の影のところにネジが一本あるのでそれを抜きます。
3. 裏ブタを下にずらしつつ上のほうのロックが外れる。
4. 上ブタのボタンのコネクタを爪などで抜きます。

以上で分解完了。

ホイールの部分を眺めてみるとどこかでテンションというか抵抗を付けてあげるとホイールの回転が渋くなるのになぁ。と思います。それに相当するのが、あったー。

写真でいう針金のようなものがホイールを回り込んているようです。

これを曲げてホイールに対して抵抗を作ってあげるとクルクル回る現象はある程度回避できそうです。
針金は本体プラスチックの爪で固定さているので横 (右ボタン側) にずらして外します。このときスプリングがびよーーんっ!! とどこかに飛んでいってしまうので注意が必要です。

抜き出した針金はこんな感じ。

これを、ちょうど良い硬さのホイールになるように曲げてあげます。僕はラジオペンチで曲げつつ調整しました。ビタっとしたちょうど良いホイールの硬さにするために三回くらいトライしました。もし、このエントリを読んだ人が同じことをする場合は、自分の感覚を信じて色々曲げてみてください;-)。

と、いうことでホイールは無事にちょうど良い硬さになり、ホイールの真ん中ボタンを押してもコンテンツが上下にブレる。と、いうことから開放されたのでありました;-)。

 
と、いうことで、これだけで終わってしまったらただ単にフツーの、そこいら中にある分解・改造の記事になってしまうので一歩踏み込みます;-P。

まず、僕の PC の環境についてですが、キーボードとマウスは二台の PC で共有しています。 USB 切替器で FreeBSD と Widnows10 を行ったり来たりしている状態です。

で、この Logicool の M5454 というマウスはホイールが前後に回転する他に左右に倒すことによってイベントが発生するようです。しかも右側には更にボタンが二つあります。

パッっと思いつくのは『このボタン達は FreeBSD で使えないのかな?』と、いう点。 Windows10 の場合は専用ドライバをインストールすると、ホイールの左右方向と左側の二個のボタンには色々な動作を割り当てられます。

これを FreeBSD+Xorg で似たようなことできるのかな?とか思い、ちょっと調べてみました。

まずは Xorg のマウスの設定。

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/sysmouse"
        Option      "ZAxisMapping" "4 5 6 7"
        Option      "ButtonMapping" "1 9 3 2 2"
EndSection

 
最後に ButtonMapping と、いうオプションを付けてみました。

オプションの数値はボタンの番号を表しています。ボタンの番号は xeve で取得できます。数値が “1 9 3 2 2” となっていますが、これは “左 左横前 右 ホイール ホイール” の各ボタンを指しています。
動作的には “左ボタン 真ん中ボタン 右ボタン ホイールの前 ホイールの後” ということになります。 FreeBSD のマウスによるペースト動作を左横前ボタンで代用する。と、いう設定ですね。

さてと。X を再起動して /var/log/Xorg.0.log を眺めてみましたが X からは ButtonMapping の設定がまるで無視されていました・・。orz

 
次に FreeBSD の ports で何かないんかい?と思い調べたのですが x11-drivers/xf86-input-evdev という、 X のドライバでマウスの様々なボタンに対応できるらしい。とのことで調査開始。

Linux では動作するらしいですね。 /dev/input/* なデバイスを利用するとマウスで色々なボタンが利用できるようになったり、Logicool M565 などは専用カーネルモジュールがあるようで。

FreeBSD ではまだ evdev.ko なるカーネルモジュールがないので実質的に xf86-input-evdev は利用できないようです。 CURRENT で現在検証中らしいのですが、それ以上は追うのはやめました。

 
と、いうことで FreeBSD においてはフツーの無線の USB マウスとして利用しようとおもった矢先、ブラウザでとあるサイト見ているときにホイールを左右に振ってみると。あれれ?

ホイールを左に振ると戻るボタン
ホイールを右に振ると進むポタン

と、して動作するようですねぇ。あれれ? X で制御しているのかな? KDE 側で対応しているのかな?あれあれ? ソースコード追ってません。すみません。ただの動作確認のみですf(^^;;。
一応 firefox rekonq では上記のように動作しました。 konqueror では動作しませんでした。

xmodmap で進む・戻るボタンが設定できるようですね。詳細は書きませんが。 evdev が動かなくても xinput などでも色々設定が可能らしいです。ここでは詳細は書きませんが。

まぁ、珍しい機能が動くモノだ。と、いうことで Windows10 側でもドライバユーティリティで設定を FreeBSD に合わせた。と、いうことで、二つの OS で動作が一緒になったのでありました;-)。

 
今回はマウスを一個購入して、エントリを書いていますが、タネは二つ。

・ホイールクルクルがイヤな人は分解して針金曲げてみましょう
・FreeBSD ではホイール左右で戻る・進むが動作する

と、いうことですね。中々楽しめた一品だったのでありました;-)。

あ。お約束ですが、『分解』することになるので、自己責任でお願いしますね。