9月 282023
 

いやぁ。まいった。 FreeBSD 14-RELEASE/amd64 になったら if_iwlwifi.ko が正常動作するようになって FreeBSD でいよいよ待ちに待った WiFi6 が利用できるようになるのかと思いきや・・。
ぜーんぜんそんなことはなくて FreeBSD 14.0-BETA3 で bhyve から Intel AX200 を試してみたけど、やっぱり 802.11a 止まりですな。 802.11ac さえも相変わらず利用できない。一体いつまで待てば FreeBSD で高速な WiFi が利用できることになるのやら・・。

ちなみに FreeBSD 13.2-RELEASE/amd64 では一応 if_iwlwifi.ko は 802.11a では利用可能になりました。しかし、これが suspend/resume に対応していない。 resume すると利用不可になるデバイスなのでまるで利用する気にならない・・。orz。
なので、僕はずっと USB な if_rtwn_usb.ko を利用しています。一応 802.11a での通信になってしまうのだけど supend/resume には対応しているので、そこはかとなく使い続けている状態です。

 
今回は、今 FreeBSD をインストールして利用している ThinkPad X13 で Intel Wi-Fi 6 AX200 を 802.11ac or ax で利用するために bhyve を利用して ubuntu をインストールします。
そして ubuntu 側で Wi-Fi 6 AX200 を利用するのですが、一応、前提条件を書いておきます。

  • 今回 ubuntu はルータとして利用しません。IPv4/IPv6 のデアルスタクにすると設定むづかしくてしょーがない・・。
  • 母艦の FreeBSD はネットワーク的にはフツーに通信できる状態として、それとは別にブリッジ経由で bhyve の ubuntu と通信します。
  • データのやり取りは bhyve な ubuntu 側の wlp0s6 を利用し、母艦の ThunPad X13 上の FreeBSD に橋渡しします。
  • 母艦の FreeBSD の /home/takachan を bhyve な ubuntu に NFS マウントするとこでデータ転送の手間を省きます。

 
上記を図にするとこんな感じ。

 
母艦側の FreeBSD の default gateway を bhybe の ubuntu の 172.16.1.11 にすると母艦側の通信は ubuntu の wlp0s6 を抜けて WiFi6 な通信が可能になるのだけど、戻りパケットの設定などを上位のルータに設定して上げる必要があったりとか、IPv4/IPv6 デアルスタクにすると色々ややこしくなるのでやめました。

 
では、母艦の FreeBSD に必用な設定と bhyve 側 ubuntu のインストールと設定を見ていきましょう。

 
1. FreeBSD 母艦側の設定
まず、 FreeBSD の母艦側の設定を行います。

今回、 bhyve を動作させるために、まず packages をインストールします。今回はこれだけインストールしました。

$ pkg info | grep bhyve
bhyve-firmware-1.0_1           Collection of Firmware for bhyve
edk2-bhyve-g202308_3           EDK2 Firmware for bhyve
uefi-edk2-bhyve-csm-0.2_4,1    UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
vm-bhyve-1.5.0                 Management system for bhyve virtual machines

 
続いて起動時の設定を行います。

 
o./boot/loader.conf

# bhyve
vmm_load="YES"
hw.vmm.amdvi.enable=1
pptdevs="2/0/0"

 
bhyve を利用するには vmm.ko を kldload する必要があります。そして hw.vmm.amdvi.enable=1 にします。
しかし、 vmm.ko は仮想環境で排他利用となります。以前のエントリで書いていますが VirtualBox を利用する場合は vmm.ko を kldunload する必要があります。

pptdevs=”2/0/0″ は pciconf -lv で確認した PCI デバイスを bhyve で利用するための設定です。以下は pciconf -lv の例です。

$ pciconf -lv | grep -A 3 iwl
iwlwifi0@pci0:2:0:0:        class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x8086 subdevice=0x0080
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6 AX200'
    class      = network

 
if_iwlwifi.ko を利用したデバイス iwlwifi0 は PCI バスの 2:0:0 に割り当てられているので、/boot/loader.conf で上記のように割り当ててあげます。

次に bhyve の起動設定です。

 
o. /etc/rc.conf

vm_enable="YES"
vm_dir="/opt/bhyve"

 
vm_enable=”YES” と vm_dir=”hoge” を設定しました。他に zfs のオプションとかなんか色々あるみたいですが、ひとまず不要なので省き、一番簡単な設定のみとしました。

これで一旦再起動します。

 
2. bhyve の準備と OS のインストール

o.ネットワーク設定
bhyve では仮想スイッチを利用します。まぁ『仮想スイッチ』と、言ってもただ単にブリッジインターフェースを作成するのみです。

母艦側 FreeBSD のネットワークの状態は lo0 と wlan0 があるのみです。 wlan0 は if_rtwn_usb.ko を利用した 802.11a で 5G の周波数に接続するフツーの NIC です。

ここに bhyve の ubuntu と通信するための『仮想スイッチ』を準備してしてあげます。

# service vm start
# ifconfig tap0 create
# sysctl net.link.tap.up_on_open=1
# vm switch create -a 172.16.1.1/24 public
# vm switch add public tap0
#
# ifconfig -a
lo0: flags=8049 metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
<一部略>
wlan0: flags=8843 metric 0 mtu 1500
        inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::20f:ff:fe8d:2c72%wlan0 prefixlen 64 scopeid 0x2
        inet6 2001:470:fe36:5678::32:1 prefixlen 64
<一部略>
vm-public: flags=8843 metric 0 mtu 1500
        ether 3e:ce:d6:69:ff:84
        inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap0 flags=143
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
        groups: bridge vm-switch viid-4c918@
        nd6 options=9
tap0: flags=8943 metric 0 mtu 1500
        options=80000
        ether 58:9c:fc:10:fc:0e
        groups: tap
        media: Ethernet autoselect
        status: no carrier
        nd6 options=21
        Opened by PID 2627

 
bhyve で利用する tap0 を作成します。次の sysctl はまぁ、おまじない。次に『仮想スイッチ』を public という名で vm switch create します。ついでに IP アドレスを付加します。

ifconfig -a で確認すると vm-public と tap0 が作成されました。
vm-public は bridge インターフェースで vm switch add public tap0 コマンドにより tap0 を内包しています。かつ vm-public には 172.16.1.1/24 の IPv4 アドレスが付きました。 bhyve 側の ubuntu は FreeBSD 側から見ると tap0 ですが ubuntu 側では enp0s2 として認識してそこに 172.16.1.11/24 のアドレスを付加すると母艦と bhyve 側の ubuntu で通信が可能になります。

母艦側の wlan0 は全く触ることはありません。

 
ネットワークの設定ができたので、bhyve の ubuntu をインストールしていきましょう。

まず、原型を作成します。

# service vm start
# vm create -t ubuntu ubuntu
# cd /opt/bhyve
# ls -aCF
.config/    .img/       .iso/       .templates/ ubuntu/
#
# vm install ubuntu .iso/ubuntu-23.04-live-server-amd64.iso
<以下略>

 
/etc/rc.conf に記載した vm_dir の /opt/bhyve の下に色々できています。 /opt/bhyve/.templates/ の下にファイルを一個作成します。

o./opt/bhyve/.templates/ubuntu.conf

loader="uefi"
cpu=2
memory=2G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
graphics="yes"
graphics_port="5900"

 
このファイルを作成して、iso イメージを /opt/bhyve/.iso/ に設置してから vm install ubuntu を実行しましょう。そして、インストールします。あ。なんか、 ubuntu23 はメモリが 512MB ではインストーラが起動しないようです。1GB とか 2GB のメモリ量にしてあげましょう。

インストール中はネットワークは利用できないので利用する iso イメージは最低限インストールできるものをチョイスします。

これでイントールは完了しましたかねぇ。

o. bhyve の ubuntu の起動スクリプト

#!/bin/sh

case $1 in
'start' )
    bhyve -c 2 -m 1G -w -H -S \
          -s 0,hostbridge \
          -s 1,virtio-blk,/opt/bhyve/ubuntu/disk0.img \
          -s 2,virtio-net,tap0 \
          -s 3,fbuf,tcp=0.0.0.0:5900 \
          -s 4,xhci,tablet \
          -s 5,lpc -l com1,stdio \
          -s 6,passthru,2/0/0 \
          -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
          ubuntu
    ;;
'tm' )
    tmux new-session -d -s mugi-ubuntu 'sudo /opt/bhyve/bin/vm_ubuntu.sh start'
    sleep 3
    ifconfig tap0 | grep status
    ;;
'stop' )
    bhyvectl --force-poweroff --vm=ubuntu
    ;;
'ls' )
    bhyvectl --get-stats --vm=ubuntu
    echo;echo
    echo "tmux list-sessions"
    echo "tmux attach -t ubuntu"
    ;;
'*' )
    echo vm_ubuntu.sh { start | stop | ls | tm }
    ;;

esac

exit 1;

 
bhyve でゲスト OS を起動するにはずいぶんと難儀です。上記のスクリプトは /opt/bhyve/bin/vm_ubuntu.sh という名で準備しました。
ちと、説明が必要ですかね。

まず、 start オプションのパラメータですが、-s は PCI BUS を想定してください。ディスク・ネットワーク・コンソール・USB、そして pptdevs で渡された Intel Wi-Fi 6 AX200 になります。このパラメータでまず、ubuntu が起動できるかと思います。

しかし、ここまでたどり着くまでにはずいぶんと色々苦労したので bhyve の起動オプションは本当に難儀したぞぉ。簡単に bhyve の ubuntu とか FreeBSD が起動するとは思わないほうが良い。色々検索して情報を探してくだされ。 BIOS でのブートとか UEFI でのブートとか、google に聞くと古い情報とかごまんとあって、最新の情報を拾ってくるのは中々悩ましい・・。

 
次の tm オプションですが、これは tmux を介してバックグラウンドで動作させます。 tmux については個別に勉強してください。コマンドのサワリだけ書いておきます。

# tmux list-sessions
ubuntu: 1 windows (created Wed Sep 27 12:31:41 2023)
# tmux attach -t -ubuntu
<以下略>

 
tmux list-sessions で tmux のセッションを確認して、そのセッションに tmux attach -t -ubuntu でアタッチするとコンソールが表示されます。コンソールから抜けるには tmux のコマンド C-b d を打ちます。

もしかしら ubuntu では tmux 使えないかも・・。
もうひとつのコンソールへのアクセス方法があります。 ports から net/tigervnc-viewer をインストールします。そして、以下のコマンドを打ちます。

$ vncviewer localhost:5900
<以下略>

 
上のほうで /opt/bhyve/.templates/ubuntu.conf というファイルを作成しましたが、そのとき graphics_port=”5900″ を指定していると思います。また bhyve 起動時にも -s 3,fbuf,tcp=0.0.0.0:5900 というオプションを指定しています。これが vncviewer でアクセスするポートになります。

コンソールに接続できたので ubuntu の設定を色々していくことにします。まぁ、僕は ubuntu はあまり得意ではありませんので、このあとはサワリだけ説明することにします。

そして、次に行きます。

 
3. 母艦と bhyve の ubuntu との通信
bhyve の ubuntu 側で ip addr をたたくと以下のインターフェースが確認できると思います。

$ ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp0s2:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
3: wlp0s6:  mtu 1500 qdisc noqueue state UP group default qlen 1000

 
enp0s2 が 母艦側との通信インターフェースで wlp0s6 が WiFi6 です。

まず、母艦の 172.16.1.1 と通信する enp0s2 設定からです。

o./etc/netplan/99-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s2:
      dhcp4: false
      addresses: 
        - 172.16.1.11/24
#     gateway4: 172.16.1.1
      nameservers:
        addresses: [192.168.1.34]
        addresses: [192.168.22.251]

 
さーっ!! yaml の設定に悩んでくだされーっ!! なんでまともに設定できんのだ?! とウンザリすることでしょう・・。orz
設定完了後 sudo netplan apply のコマンドを打って、で設定を反映して、そしてうんと怒られてください;-P。

無事に設定が完了すると、FreeBSD 母艦と bhyve との間の 172.16.1.0/.24 のセグメントで通信ができるようになります。

ここまでできたら母艦側から ssh 接続できるようになるので、作業が格段にしやすくなります。

 
続いて wlp0s6 側の設定を見ていきます。 enp0s2 は母艦との接続のためだけのインターフェースですが wlp0s6 は外部との通信を行います。 ubuntu は WiFi6 に対応しているので Intel Wi-Fi 6 AX200 を利用する通信はむちゃくちゃ速いです。

o./etc/netplan/50-cloud-init.yaml

network:
    wifis:
        wlp0s6:
            optional: true
            access-points:
                "AP80211AX":
                    hidden: true
                    password: "PASSWORD"
            dhcp4: false
            addresses:
              - 192.168.1.48/24
              - 2001:470:fe36:abcd::48:1
            gateway4: 192.168.1.1
            nameservers:
              addresses: [192.168.1.34]
              addresses: [2001:470:fe36::ffff:34]

 
WiFi の SSID は AP80211AX で パスフレーズは PASSWORD です。この AP はステルス機能を有効化しているので hidden: true を設定しています。
IP アドレスについては IPv4/IPv6 デアルスタクです。 IPv4 gateway は設定していますが IPv6 gateway は ra で降ってきます。ネームサーバも IPv4/IPv6 両方のアドレスを指定しました。

これまた書き方にうんと悩んだあと sudo netplan apply のコマンドを打って設定を反映して、そしてうんと怒られてください;-P。

これで ubuntu 側の設定は完了です。

 
4. bhyve の ubuntu の設定と実際に利用してみる
ubuntu では設定というか、dep を apt-get install で色々好きなものをインストールしてください。
ここでは特には書かないです。

唯一必要だったのが NFS クライアント側の設定でしょうか。母艦の FreeBSD 側で NFS Server を有効にして /etc/exports を書きます。 /home/takachan を NFS のマウントポイントとして 172.16.1.0/24 から許可します。
ubuntu 側では /etc/fstab に母艦の FreeBSD の /home/takachan を /home/takachan/takachan 辺りにマウントするようにします。

NFS の設定が完了したら、試しに iso イメージをダウンロードしてみましょう。

まずは母艦の FreeBSD で wget を実施し、次に ssh で bhyve の ubuntu にログインしたあとに wget してみました。

$ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 1%[                    ]   7.35M  1.84MB/s   残り3m 49s  
^C
$ ssh 172.16.1.11
ubuntu $ cd takachan
ubuntu $ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 4%[>                   ]  20.66M  10.2MB/s   eta 38s
^C
ubunru $

 
母艦側の FreeBSD のホームディレクトリで wget で iso イメージを取得すると大体 16Mbps の速度が出るか出ないか。これは USB の if_rtwn_usb.ko を利用して 802.11a で通信する FreeBSD で一番速い WiFi の速度です。
次に bhyve の ubuntu に ssh して NFS マウント先で wget すると FreeBSD側 の $HOME で wget するのと同じ状態になります。ただ、ubuntu 側で wget すると速度が全然違い 80Mbps 出ています。これは Linux での iwlwifi ドライバが正常に動作していることを示しています。そして、この速度はうちの外部接続ネットワークの限界です。

 
宅内の他の PC やサーバとデータをやりとりするときは ubuntu 側の 192.168.1.48 側のアドレスでデータをやり取りすることにより高速に転送することが可能です。

 
こんな感じで、いつまで待っても FreeBSD で WiFi の 802.11ac or ax が利用できないのを bhyve の ubuntu で通信速度を稼ぐ。と、いうちょっと荒業を、今回は使ってみました。

おかげで bhyve にずいぶんと詳しくなったぞぉーっ!! みたいな f(^^;;。

一点だけ注意点があるかも。母艦の FreeBSD は suspend/resume に対応していても bhyve で動作する OS が動作しないかな? FreeBSD の resume 後 vm lsit で Running 状態だったゲスト OS は動作がおかしくなる傾向が見受けられました。
が、これは当然でしょうかねぇ・・。考えてみると FreeBSD 側で Intel Wi-Fi 6 AX200 は supend/resume に対応してないので、たとえ pptdevs で ubuntu に渡していても resume 後は利用出来ない状態に陥ります・・。orz。

FreeBSD 14-R で if_iwlwifi.ko が suspend/resume に対応してくれるとともっと幸せになれるのだけれど、それはリリースされてみたいと解らないかなぁ。

 
と、いうことで、皆さんもせっかく持っている内臓の、 FreeBSD では中々利用できない Intel 系の WiFi チップ。 bhyve の ubuntu で有効利用するのもありなのかなぁ。と、いうのが今回のネタだったのでありました。

bhyve のこと、今後、ネタとして書く機会あるかな?

6月 282023
 

自分でも、強引な手法だなぁ。と、思ってしまいます。

まず、 Windows11 Pro 上で動作している Hyper-V サーバがあります。その下で FreeBSD/amd64 13.2-RELEASE が動作しております。

Hyper-V の母艦である Windows11 Pro は NotePC なので WiFi 使ったり RJ45 使ったり VPN 使ったりするので Hyper-V のサーバとクライアントの間の「仮想スイッチ」はブリッジ、それはつまりは仮想スイッチマネージャの「接続の種類」で[外部ネットワーク]を選択することはほぼ不可能(利用する物理ネットワークによって毎回変更する必要がある)なのであります。

母艦側で複数のネットワークアダプタを利用する場合は、どうしても NAT、それはつまりは[内部ネットワーク]をチョイスするしかないのであります。

Hyper-V の仮想スイッチが NAT になると、色々と制約を受けます。まず、 DHCP を克服する必要があります。これについてはウェブ上に、設定方法について、色々書かれたドキュメントがあるのでそちらを参考にしてください。

いろいろ設定すると Hyper-V のクライアント (俗に『仮想マシン』と、言いますな) は NAT 配下で、固定 IPv4 アドレスで動作させることが可能になりました。

Hyper-V の母艦からは仮想マシンに対して ssh などのアクセスができるようになります。が、当然リモートのマシンからは Hyper-V 管理下の仮想マシンへはアクセスできません。

あと、仮想マシンのネットワークは NAT が入るのでこれまた色々と制約受けます。上に書いた、外部からのアクセスができません。他に NFS マウントできません。 gif トンネル張れません。とか・・。

 
そもそも、 Hyper-V の母艦の外部のネットワークに IPv6 がない場合、仮想マシンは IPv6 を利用することができません。あれ? Hyper-V の NAT 仮想スイッチで IPv6 喋れるのか?

どうして仮想マシン側に IPv6 が欲しいのだ? -> だって、IPv4 は NAT なので上記の制約受けるじゃん。それなら、トンネルでも良いから IPv6 でどっかーんっ!! と抜けていきたいじゃん。

と、いうのが発想の原点にあります。

と、いうことで図を書いてみました。

簡単に説明します。

  • 真ん中に Windows11 Pro の Hyper-V サーバがいます
  • Windows11 Pro の Hyper-V サーバは上位のネットワークとは IPv4 アドレスのみが降ってくるネットワークに接続しています
  • Hyper-V 配下の仮想マシンは FreeBSD/amd64 13.2-RELEASE です
  • Hyper-V サーバと仮想マシンの間には NAT の仮想スイッチが入っています
  • NAT の仮想スイッチは仮想マシンが固定 IPv4 アドレスを利用できるようにしています

 
これが現状、フツーにできる Hyper-V 環境です。この状態で、仮想マシン側に IPv6 グローバルアドレスを付加して、IPv4 の NAT 超えをあきらめ、IPv6 で外部との通信をできるようにして色々楽しめる状態にします。

  • 仮想マシンの FreeBSD は wireguard で外部に接続します
  • wireguard で作成した VPN トンネルの中に gif トンネルを通します
  • 仮想マシンに IPv6 が通ったので様々通信ができるようになります

 
トンネルの多段ですね。
図の左側は VyOS と wireguard のサーバは別々に描かれていますが、最近の VyOS を使うと一個にまとめられると思います。僕の環境では未だに VyOS-1.1.8 を利用していますので wireguard は別サーバに構築しました。

 
wireguard と VyOS の置き場所によって仮想マシンの IPv6 の通信速度は圧倒的に変わります。色々考えてみてください;-)。

と、いうことで、次に設定を見ていきましょうか。

 
1. 仮想マシン側の wireguard の設定
今回、仮想マシンは FreeBSD/amd64 13.2-RELEASE なので wireguard は ports から簡単に入ります。 net/wireguard をインストールしましょう。もしかしたら wireguard-kmod-0.0.20220615_1 がインストールされるかもしれませんが、実際には利用しません。

wireguard-kmod-0.0.20220615_1 をインストールした場合には /boot/modules/if_wg.ko がインストールされますが 13.2-RELEASE からは OS 標準で /boot/kernel/if_wg.ko が用意されています。フツーに wireguard_enable=”YES” すると /boot/kernel/if_wg.ko が利用されます。

僕の環境では wireguard-2,1 、wireguard-kmod-0.0.20220615_1 、 wireguard-tools-1.0.20210914_1 がインストールされました。

次に設定です。

が、その前に、まず最初に wireguard では鍵のペアを作成する必要があります。

# cd /usr/local/etc/wireguard/
# wg genkey > server.key
# wg pubkey < server.key > server.pub
#
# wg genkey > client.key
# wg pubkey < client.key > client.pub
# 
# chmod 600 *.key 
#

 
サーバ側とクライアント側のキーの両方を作成しましたが、これを利用します。

続いて設定を見ていきます。今回は wireguard のトンネルを一個作成するだけですので wg0.conf のみです。複数に接続する場合は wg1.conf wg2.conf などと設定フアイルを複数書きます。

・/usr/local/etc/wireguard/wg0.conf

[Interface]
PrivateKey = 8LJDuAU9Ste2ySHRmgHnOAyk+E4ZMbw+vCBbMHXMbZU=
Address = 192.168.254.11/32

[Peer]
PublicKey = 17CucZLVbS1Jt/8LXREvrDGEnYunIA2RYYjlJhxftlk=
AllowedIPs = 192.168.254.1/32, 10.20.65.201/32
Endpoint = 10.20.65.15:51820

 
[Interface] の 設定は自分側の設定を記載します。

  • PrivateKey は作成した鍵ファイルの client.key の内容を記載します。
  • Address は wg0 インターフェイスに付加する IPv4 アドレスです。 wireguard で接続するためだけに利用するので /32 で指定します。ただ、サーバ側と同じレンジが良いでしょう。

続いて [Peer] の設定で、これは wireguard のサーバ側に関する設定になります。

  • PublicKey は server.pub の内容を記載します。
  • AllowedIPs は wireguard サーバの wg0 インターフェイスの IPv4 アドレスを記載します。
  • AllowedIPs にはもう一個 IPv4 アドレスを記載します。 gif トンネルの接続先 IPv4 アドレスを “,” で区切って記載します。詳細についてはあとで書きます。
  • Endpoint は wireguard が動作しているサーバの IPv4 アドレスと Port 番号を記載します。

 
だいたいこんな感じで良いと思います。非常に簡単な設定ですね。ただ、一点。 [Peer] 側の設定の AllowedIPs の設定がクセモノです。
AllowedIPs に wireguard サーバ側の wg0 インターフェースの IP アドレスを書いただけでは wireguard サーバとしか通信ができません。

『wireguard サーバ側で NAT の設定を入れてないから他のネットワークと通信できんのか?』と思い、wireguard サーバ側の設定を色々いじってしまうのですが、そうではなく、クライアント側がどこと通信したいのか、AllowedIPs に記載することにより通信が可能となります。

今回は wireguard トンネルを抜けいてったあと gif トンネルを張りたいので VyOS の IPv4 アドレスを AllowedIPs に追加しました。 10.20.65.0/24 と通信したい場合は AllowedIPs には wireguard サーバの wg0 インターフェースの IPv4 アドレスと 10.20.65.0/24 を追加で書けば良いです。

で、自動起動するように設定を書きます。 /boot/loader.conf に明示的に if_wg_load=”YES” と書かずともカーネルモジュールがロードされます。

・/etc/rc.conf

wireguard_enable="YES"
wireguard_interfaces="wg0"

 
これでクライアント側の設定は完了です。

次にサーバ側の設定を見ていきましょう。

 
2. wireguard のサーバ側の設定
上のほうでも書きましたが、 wireguard のサーバは自前で用意せずとも VyOS で利用可能です。 VyOS-1.3 以降から wireguard に対応したんだったかな? 詳細なバージョンは覚えていませんが・・。

今回、僕は wireguard サーバも FreeBSD 側で作成しました。インストールは ports からですが、クライアント側のと同様のモノをインストールしました。

鍵は既に作成したので、それを使いまわしましょう。すると、サーバ側で用意するのは設定フアイル一個のみです。

・/usr/local/etc/wireguard/wg0.conf

[Interface]
PrivateKey = aJbypbTUy5LB+EIPd6FHf25D2rbTw9l+x5o7fBLL+Ec=
Address = 192.168.254.1/24
ListenPort = 51820

[Peer]
PublicKey = F8kvub6jdPnl99rISnffYtilNVEswDUo+sqGWzc7FRY=
AllowedIPs = 192.168.254.11/32

 
[Interface] の 設定は自分側の設定を記載します。

  • PrivateKey は server.key の内容を記載します。
  • Address は wg0 インターフェイスに付加する IPv4 アドレスです。

続いて [Peer] の設定で、これは wireguard のサーバ側に関する設定になります。

  • PublicKey は client.pub の内容を記載します。
  • AllowedIPs は wireguard クライアントの wg0 インターフェイスの IPv4 アドレスを記載します。

 
以上で設定は完了です。 /etc/rc.conf にクライアントのと同じ設定を追加して wireguard を起動します。サーバ側とクライアント側の両方で service wireguard start を実行すると wg0 インターフェースが生えてきます。

双方の wg0 の IPv4 アドレスに ping を打ち、到達性を確認します。この時点で ping が当たらない場合は設定情報が間違っています。なおしてください。そもそも wireguard のサーバとクライアントの物理インターフェース間で通信できることを確認します。

 
双方の wg0 に付加された IPv4 アドレスに ping が当たるようになったら OK。クライアント側の [Peer] 設定の AllowedIPs に記載した VyOS の IPv4 アドレスに ping が当たることを確認します。
上にも書いた通り 10.2.65.201 だけでなく、もっと他のマシンにも接続したい場合はクライアント側で設定してみてください。

 
最後に wireguard の wg0 トンネルをぬけて gif トンネルを掘ります。 gif トンネルが掘れると Hyper-V の仮想マシンにはグローバルな IPv6 アドレスが付加されます。 IPv6 を利用することにより IPv4 で受けていた NAT の制約から開放されることになります。パチパチパチっ!!

と、いうことで IPv6 gif トンネルの設定については以前書いているのでそつらを参考にしてください。

IPv6 Over IPv4 トンネルを dtcp から VyOSへ。

 
移動する PC 上で Hyper-V を動かしたとき、その下で動作する仮想マシンはネットワーク的に色々な制約を受けるモノです。今回は多段トンネルでその問題を解決してみました。

  • 仮想マシンは NAT ネットワークで gif トンネルが利用できないので wireguard なトンネルを掘る
  • wg0 を抜けて gif トンネルを掘る
  • IPv4 は NAT ネットワークなので IPv6 の直アクセスで NAT 問題を回避
  • 仮想マシンに IPv6 アドレスが付加されたので仮想マシンのネットワークはもーサイコーっ!!

 
こんな感じの手順で今回の構成を構築しましたが、フツーここまでやる?

ってか、まあ、Hyper-V が動作するのは WindowsOS なので、ネットワーク的に色々な制約が多すぎてやりたいことができない。
ネットワークはトンネルで抜けて色々やりましょう。と、いう雰囲気ですが・・。

一点だけ。まだ検証してないし、計算が必要だと思うのですが・・。 MTU って、一体いくつになるの? f(^^;;。

11月 102022
 

僕が持っている色々な PC は WindowsOS と FreeBSD でマルチブートしています。デスクトップ PC の場合は M2.SSD の他に SATA 2.5 インチ SSD と、更に USB HDD を接続して、全てのストレージは NTFS と UFS (ZFS ではない;-) に分割して、どちらの OS でも高速アクセスと、ビッグデータ蓄積領域を確保している状態です。

普段は FreeBSD を利用しているのだけど、たまに Windows11 を起動してアプリを利用したり、蓄積していたデータをファイルサーバにアップして、再度 FreeBSD を起動してファイルサーバから取ってくる。とかしていましたが、今後はそーいう動作は必要なくなります。

FreeBSD 13.1-RELEASE (正確には 13.0-R 辺りからかな?) では NTFS 領域がマウントできて、かつ FreeBSD から rw アクセスが可能となりました。 sysctl で vfs.usermount=1 などとすると、一般ユーザ権限でマウントして、かつ、設定によっては自動的にマウントできたりします。

そして KDE5 などを使っていると dolphin (KDE5 のファイルマネージャ) から簡単にアクセスできるようになります。

設定方法について、順番に見ていきましょう。

 
1. ports からインストール
まずは ports から sysutils/fusefs-ntfs をインストールします。そして /boot/loader.conf に以下の行を書きます。

fusefs_load=”YES”

 
これで完了です。

 
2. 実際にマウント
僕のデスクトップ PC の場合、 FreeBSD の起動時に以下の SSD と HDD が認識されています。

$ dmesg | grep nvd
nvd0:  NVMe namespace
nvd0: 488386MB (1000215216 512 byte sectors)
Trying to mount root from ufs:/dev/nvd0p5 [rw]...
$
$ dmesg | grep da0
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ACS-4 ATA SATA 3.x device
ada0: Serial Number S5RRNF1R566155H
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 953869MB (1953525168 512 byte sectors)
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-3 SCSI device
da0: Serial Number DCC77FFFFFFF
da0: 40.000MB/s transfers
da0: 3815447MB (7814037168 512 byte sectors)
da0: quirks=0x2
$
$ gpart show /dev/nvd0
=>        34  1000215149  nvd0  GPT  (477G)
          34        2014        - free -  (1.0M)
        2048      532480     1  efi  (260M)
      534528       32768     2  ms-reserved  (16M)
      567296   629467136     3  ms-basic-data  (300G)
   630034432    20971520     5  freebsd-ufs  (10G)
   651005952   167772160     6  freebsd-ufs  (80G)
   818778112   125829120     7  freebsd-ufs  (60G)
   944607232    41943040     8  freebsd-ufs  (20G)
   986550272    12124160     9  freebsd-swap  (5.8G)
   998674432     1529856     4  ms-recovery  (747M)
  1000204288       10895        - free -  (5.3M)
$
$ gpart show /dev/ada0
=>        34  1953525101  ada0  GPT  (932G)
          34       32734     1  ms-reserved  (16M)
       32768   819200000     2  ms-basic-data  (391G)
   819232768  1134292367     3  freebsd-ufs  (541G)
$
$ gpart show /dev/da0
=>        34  7814037101  da0  GPT  (3.6T)
          34       32734    1  ms-reserved  (16M)
       32768  4096000000    2  ms-basic-data  (1.9T)
  4096032768  3718004360    3  freebsd-ufs  (1.7T)
  7814037128           7       - free -  (3.5K)

 
nvd0 が M2.SSD で / パーティション他がある、メインの SSD です。
ada0 は SATA SSD で da0 は USB HDD です。全て WindowsOS と FreeBSD で半分ずつ (NTFS と UFS で半分ずつ) 利用しています。

 

実際に NTFS をマウントしてみるには以下のコマンドを利用します。

# ntfs-3g -o rw /dev/ada0p2 /mnt/
#  ls -l /mnt/
total 0
drwxrwxrwx  1 root  wheel  0 Nov 18  2021 $RECYCLE.BIN/
drwxrwxrwx  1 root  wheel  0 Nov 24  2021 Hyper-V/
drwxrwxrwx  1 root  wheel  0 Apr  3  2022 Data/
drwxrwxrwx  1 root  wheel  0 Nov 23  2021 Recovery/
drwxrwxrwx  1 root  wheel  0 Nov 18  2021 System Volume Information/
#
# umount /mnt

 
ports から sysutils/fusefs-ntfs をインストールすると ntfs-3g というコマンドがインストールされ、そのオプションに -o rw を指定しているので FreeBSD から書き込みもできるようになります。

これで NTFS の中のデータを取り出すために WindowsOS を起動することがなくなりました;-)。

 
3. automount しちゃうよ
KDE5 を利用している場合、 sddm からログインすると、ログインした段階で色々なファイルシステムを一般ユーザ権限でマウントしてくれる機能があります。

一般ユーザのアカウント takachan でログインすると、自動マウントさせたい場合には上にも書いた通り /etc/sysctl.conf に以下の設定をします。

vfs.usermount=1

 
この他に「KDE システム設定」でちょっと設定します。

「KDE システム設定」を起動して「起動と終了」→「Background Services」をチョイスすると、その中に [Removable Device Automounter] という項目があるのでこれにチェックを入れて更に再生ボタンを押してステータスを『実行中』にします。

次に同じく「KDE システム設定」の「リムーバブルストレージ」→「Removable Devices」をチョイスして、一番下にある [Automatically mount removable media that have never been mounted before] にチェックを入れて [適用]ボタンを押します。

これで、一旦ログアウトして再度ログインするか、service sddm restart してからログインしてみます。

と、いうか、sddm を再起動したあと、リモートから ssh でログインして df -k とかたたいて確認して、そのあとで sddm から一般ユーザでログインするとログイン後に様々なファイルシステムがマウントできることが確認できます。

僕のデスクトップ PC の場合はこんな感じになります。

$ df -k
Filesystem    1024-blocks      Used      Avail Capacity  Mounted on
*** 一部略 ***
/dev/ada0p3     549341012 187462520  317931212    37%    /opt
*** 一部略 ***
/dev/fuse       409599996  44718652  364881344    11%    /media/Samsung_SSD_870_QVO_1TB_S5RRNF1R566155H_p2
/dev/fuse      2047999996 534627440 1513372556    26%    /media/WDC_WD40_EZRZ-00GXCB0_DCC77FFFFFFF_p2
/dev/da0p3     1800630836 892226780  764353592    54%    /media/WDC_WD40_EZRZ-00GXCB0_DCC77FFFFFFF_p3
/dev/fuse       314733564  69794920  244938644    22%    /media/WDC_PC_SN730_SDBPNTY-512G-1006_213240808600_p3
/dev/fuse          764924    604264     160660    79%    /media/WDC_PC_SN730_SDBPNTY-512G-1006_213240808600_p4

 
/media/ ディレクトリのは以下にデバイス名付きで自動的に、一般ユーザ権限でマウントされます。デバイス名の後ろは p2,p3 とありますがパーティション名ですね。
Windows11 の C:\ や リカバリ領域なども自動マウントします。あと、UFS なファイルシステムも自動マウントしてしまいます。

Filesystem が /dev/fuse の場合は NTFS か FAT で /dev/da0p3 と表示されている場合は UFS ですね。 /media/Samsung_SSD_870_QVO_1TB_S5RRNF1R566155H_p3 は UFS ですが、これは /dev/ada0p3 で既に /opt にマウントしているので自動マウントされません。

 
KDE5 を利用した場合は opendesktop.org 由来の UDisks2 が利用されます。 FreeBSD 的かつ ports 的には sysutils/bsdisks が動作して plasmashell から dbus を経由して自動マウントしてくれるようです。
NTFS ファイルシステムを自動マウントしたくない場合は kldload fusefs.ko をやめれば良いです(あとで別件で説明します)。 UFS はもう完全に自動マウントしてしまうので止められない。自動マウント自体を停止したい場合は「KDE システム設定」の [Removable Device Automounter] を停止するしか手はないです。

 
KDE5 を利用している場合には KDE5 側で自動マウントしてくれますが、KDE5 を利用していな場合、 sysutils/dsbmd をイントールして /etc/rc.conf に dsbmd_enable=YES を書く必要があるかもしれません。

詳細については以下の URL を参照してください。

https://github.com/mrclksr/DSBMD

上記の dsbmd は ports のコンパイル時の make onfig で様々なファイルシステムを検知、自動マウントしてくれるようです。裏を返すとそれだけ色々な fusefs をインストールする。と、いうことになると思いますが。 ext4 とか HFS+ とかすげーな。みたいな・・。

一般ユーザ権限で色々なファイルシステムを自動マウント。遊んでみてください;-)。

 
4. 注意制限事項
注意点は二つ。

  • Bitlocker で保護されている NTFS はマウントできない
  • USB HDD の場合、スピンドルが止まっている場合がある

 
順番に見ていきましょうか。

Lenovo の ThunkPad X13 は Windows11 と FreeBSD のマルチブートですが、 Windows11 の NTFS は Bitlocker で保護されているので ntfs-3g ではマウントできません。以下のようになります。

# ntfs-3g -o rw /dev/nvd0p3 /mnt/
NTFS signature is missing.
Failed to mount '/dev/nvd0p3': 無効な引数です
The device '/dev/nvd0p3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

 
上記のようなエラーが出た場合は WindowsOS 側で「コンピュータの管理」→「ディスクの管理」を開いて当該パーティションが『Bitlocker で保護されてます。』と、いう表示があるか確認してみましょう。
この場合 kldload fusefs.ko していても意味ないです。リカバリ領域が見えても意味ないし・・。

 
次の USB HDD の場合ですが、SSD と違い外付け USB HDD の場合、ケースの機能によっては HDD の回転を停止するものがあります。自動マウントしている状態で HDD のスピンドルが停止していた場合、 cd /media/USB-HDD/ とか ls /media/USB-HDD/ すると、そこから HDD のスピンドルが回り始めます。この場合、ほぼほぼ CAM status: SCSI Status Error が出ます。そして、マウントしている状態だけど ls しても表示してくれない・・。 orz

外付け HDD の場合は cd とか ls でアクセスする前に以下のコマンドを打つ必要があります。

$ sudo camcontrol start /dev/da0

 
上記コマンドを打った段階で停止していた HDD (/dev/da0) のスピンドルが回り始めます。そのあとで cd とか ls でアクセスするようにしましょう。

 
以上、FreeBSD で NTFS に対するアクセスと、ファイルシステムの一般ユーザ権限での自動マウントについて書いてみました。

マルチブートしている PC の場合、もう一方の OS の中へアクセスしたい。と、いうことは多々あるのですが、今回は FreeBSD 側から WindowsOS の NTFS に対して簡単にアクセスする方法を書いてみました。

皆さんの環境でも是非、導入してみてください;-)。自動マウントはらくちんですよ。

8月 282022
 

去年の 11 月にデスクトップ PC を新調しました。 CPU は AMD Ryzen7 PRO 4750G です。この環境において FreeBSD を起動 (当時は 13.0-RELEASE でしたが、今は 13.1-RELEASE が動作しています) しています。

素晴らしい CPUをチョイスしたので 8 Core/16 スレッドです。ports を make するとメモリが足りなくなって大変。みたいな・・。
この強力な CPU パワーを使い切るのは ports のコンパイル時しかないんかい?! になるのも悲しいので VirtualBox でもインストールして利用するべ。などと思っても、ちぃとも動作しない・・。

エラーとしてはこんな感じ。

文字列的には・・。

仮想マシン"WindowsServer2012_01"のセッションを開けませんでした。

VirtualBox can't enable the AMD-V extension. Please close all other virtualization programs. (VERR_SVM_IN_USE).

終了コード : NS_ERROR_FAILURE (0x80004005)
コンポーネント: ConsoleWrap
インターフェース: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

 
まぁ、OS は Windows Server でなくとも良いんですが、 Windows11 だったり FreeBSD なども上記エラーメッセージが出力されて起動しない・・。 orz
せっかくの 8 Core/16 スレッドな CPU なのに・・。

たまに VirtualBox を起動して『あ。やっぱり動かないね。』になるのよねぇ・・。
BIOS (UEFI) で AMD-V (AMD SVM) が有効になっていることは何回も確認している。

上記メッセージは日本語的には

「VirtualBox は AMD-V 拡張機能を有効にできません。 他のすべての仮想化プログラムを閉じてください。 (VERR_SVM_IN_USE)。」

らしいんですな。 Linux 方面では kvm と VirtualBox がケンカしていて仮想化資源を取り合っているんだそうで、VirtualBox を起動する際は kvm のカーネルモジュールを rmmod すれば良いらしい。

 
では、 FreeBSD は何が仮想化資源を掴んでいるのだぁ!? と、なるのですが、原因が全くわかりません・・。

cat /var/log/messages してみると・・。

vboxdrv: XXXXXXXXXXXXXXXX VMMR0.r0
vboxdrv: XXXXXXXXXXXXXXXX VBoxDDR0.r0
VMMR0InitVM: eflags=40246 fKernelFeatures=0x2 (SUPKERNELFEATURES_SMAP=1)

 
んー。見覚えのある文字列がありますが、これはなんなんざんしょ(?_?) と、いう状態です・・。

でもって、閃いた。試しに vmm.ko を kldunload してみた。

$ sudo kldunload vmm.ko
ivhd0: detached
amdiommu0: detached
pci0:  at device 0.2 (no driver attached)

 
man vmm してみると以下のように表示されますな。

NAME
vmm.ko – bhyve virtual machine monitor

DESCRIPTION
vmm.ko provides the kernel portion of the bhyve(4) hypervisor.

An Intel CPU with VT-x/EPT or AMD CPU with SVM support is required.

PCI device passthrough to a virtual machine requires hardware with VT-d support.

なるほどねぇ・・。こいつと競合していたのねぇ・・。と、いうことで、以降はすんなりと VirtualBox の仮想マシンが無事に起動したのでありました。

 
と、いうことで、VirtualBox が仮想化資源をつかめない。上記のようなメッセージが出力されている場合は、競合が発生しているので、とりあえず vmm.ko がロードされていないか確認すると良いと思います。

僕は AMD の CPU しか使ったことないけど、 Intel 系の CPU も vmm.ko は kldload できるのかな?

11月 202021
 

新しくデスクトップ PC を購入しました。『AMD FX おじさん』ではないですが、今まで利用していた PRIMERGY MX130 S2 は 2012 年に購入したのですなぁ。約 10 年使っていた。と、いうことか・・。速度的に『遅いっ!!』とは思ってなかったのでずっと使い続けていましたが・・。

今は半導体不足なときで、PC も決して安くはない。 AMD Ryzen7 PRO 4750G / Memory 16GB / 512GB SSD で 85,000yen 程度。納期は約一週間でした。

写真的には外側よりも内部のほうが嬉しいですよね。多分;-)。

HP ProDesk 405 G6 SFF/CT を買う前に一旦 Lenovo の ThinkCentre M75t Tower Gen2 を注文したんだけど、納期が約半年先、来年の 3 月になる。とのことだったので、待ってられないのでキャンセルした。ということがあるのであります。
HP は昔の日本 DEC の工場を持っているので納期が早いのねぇ。と、いう感じがします。

default の OS は Windows10 home でした。まだ Windows11 にはしていません。それよりも先に、すかさず FreeBSD のインストールを開始するのであります。

 
がっ!!驚きーっ!!よく調べずに今回の PC を買ったのですが、なんとっ!! FreeBSD/amd64 13.0-RELEASE がインストールできないのです。インストール用 USB メモリを Rufus で書き込みブートさせるのですが —<<BOOT>>— が出る前でフリーズしてしまうのでありました。『あらら? もしかしてハズレな PC 買ってしまったか?』 などと調べ始めると・・。

ほおほお。 HP の デスクトップ PC や NotePC では 13.0-RELEASE 以前のバージョンではブートできないパターンがあるのねぇ。

https://forums.freebsd.org/threads/freebsd-on-hp-prodesk-g6.79252/

こちらのスレッドがまさしくビンゴ。 HP の PC は本当に悩みモノらしい。下まで読み進むと 14-CURRENT ではブートするようになったみたいなので、試してみたら確かにブートしてインストールできた。ホっ。
で、更に追加で 13.0-STABLE でも試してみたらこちらも無事にブートしたのでありました。ふぅ。

上記 URL のネタは 6 月には CURRENT 用の修正版が出たみたいだし STABLE に降りてくるのにはそんなに時間がかからないと思うので、今の 11 月辺りでは 13.0-STABLE でも OK 。と、いう感じなのでしょうねぇ。
と、いうことで今回インストールしたのは FreeBSD-13.0-STABLE-amd64-20211111-7647baa1e8f-248036-bootonly.iso になります。 2021/11/11 分の STABLE ですね。

一個前のエントリで書いていますが 13.0-RELEASE と同様に Windows の EFI パーティションをつぶすこともなく、インストールが完了しました。
Lenovo の PC と違い BitLocker を気にする必要がなく、素直にセキュアブートをオフにするだけでインストールすることができたのであります。

 
デバイス的なことを書きましょう。手元に Intel AX200 の代わりに購入した Intel Wireless-AC 9260 があったので、それを設置しました。 NotePC 用に買ったのでアンテナが無かったのですが Amazon で 760yen で追加購入。ただのケーブルが二本だけど、Wi-Fi モジュールに接続できる必要があるので、しっかりと選択する必要があります。長さはだいたい 30cm ほどかなぁ。ケース内にケーブルを這わせたあと、 FreeBSD で利用すると 20Mbps 程度、Windows で利用すると 200Mbps 程度出ます(自宅で可動しているスピード計測サイトでの計測;-)。

他に S-ATA 接続の Samsung SSD 870 QVO 1TB SVQ01B6Q も設置。 M2.2280 な SSD と合わせて 1.5GByte の容量を確保できました。

 
FreeBSD の pciconf -lv で特筆すべきデバイスをちょっと並べてみます。

none0@pci0:4:0:0:       class=0xff0000 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816e subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'Realtek RealManage BMC'
re0@pci0:4:0:1: class=0x020000 rev=0x29 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x103c subdevice=0x872d
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
none1@pci0:4:0:2:       class=0x070002 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816a subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111xP UART'
    class      = simple comms
    subclass   = UART
none2@pci0:4:0:7:       class=0x0c0701 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816c subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111xP IPMI interface'
    class      = serial bus
    subclass   = IPMI
iwm0@pci0:5:0:0:        class=0x028000 rev=0x29 hdr=0x00 vendor=0x8086 device=0x2526 subvendor=0x8086 subdevice=0x0014
    vendor     = 'Intel Corporation'
    device     = 'Wireless-AC 9260'
    class      = network

 
HP の法人向け PC なので Intel でいうことろの vPro みたいなのを積んでいるようですが、 AMD の CPU 搭載なので Intel チップはちと無理か。そのかわりに Realtek のリモート管理系チップが搭載されているようです。俗に『AMD DASH』と呼ばれているヤツかな? BIOS (UEFI) の設定メニューにオン/オフのオプションがありました。

が、当然 FreeBSD では認識されません。

iwm0 はあとから自分が取り付けたモノになります。 BIOS (UEFI) 的にもフツーに認識されているし Bluetooth も BIOS で認識しているので問題ないですね。
下の写真では、一番上の真ん中にあるある出っ張ったパーツです。アンテナが伸びているのは一枚目の写真でも解るでしょうか?

せっかく 13.0-STABLE にしたし Intel Wireless-AC 9260 もついたので、Iwlwifi を試してみるかねぇ。みたいな状態で https://wiki.freebsd.org/WiFi/Iwlwifi を試してみましたが・・。
https://people.freebsd.org/~bz/wireless/apply-wireless-latest.sh これはもうコードが古くてコンパイルも通らないですね・・。orz 20210904 のカーネルソースコードだと linuxkpi のコードにもずいぶんと改修が進んでいるだろうに・・。
と、いうことで FreeBSD での 802.11ac はまだ待ちの状態です。

 
Realtek の NIC は re0 で認識されてはいますが /boot/kernel/if_re.ko では認識できないチップです。最新のチップかな? 最初『え゛。Realtek のチップ認識しないの?』と、驚いたのですが、今の世の中 ports からインストールするとか。 ports の net/realtek-re-kmod/ をインストールすると /boot/modules/if_re.ko が入ります。これを利用すると re0 で認識できます。
/boot/loader.conf はこんな感じで。

if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"
hw.re.max_rx_mbuf_sz="2048"

 
あと、今回の PC は CPU が AMD Ryzen7 PRO 4750G なので GPU は Renoir です。これは ThinkPad X13 と一緒。 ports の graphics/drm-devel-kmod/ では X が起動しませんでした。
せっかく 13.0-STABLE を利用しているので linuxkpi 系は最新のソースコードがはいっているはず。と、いうことで GitHub から drm-kmod-master の最新版を取ってきました。今だと drm-kmod-5.7 になります。これをインストールしたらあーたっ!!

X はバリバリ動作する。

$ xrandr 
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   2560x1440     59.95*+  60.00  
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    60.00    59.94    30.00    24.00    29.97    23.98  
   1600x1200     59.95  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.95  
   1280x800      59.95  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    59.94  
   640x480       60.00    59.94  

 
スゲースゲー。 ThinkPad X13 では 13.0-RELEASE と drm-kmod-5.5-wip でやっとこさ X を動かしたんだけど、 AC アダプタ抜くとカーネルパニックとかしていてまだまだだなぁ。と思っていたんだけどそんなこともなく。

あと、デスクトップ PC で 13.0-STABLE + drm-kmod-master (5.7) を利用すると suspend/resume できますっ!! デスクトップ PC で suspend/resume っ!! resume 後に X が死ぬ。と、いうこともなく本当に無事に、 WindowsOS のようにフツーに動作します。かなり感動的っ!!

 
今回、HP ProDesk 405 G6 SFF/CT にイントールしたあと、すかさず ThinkPad X13 も同じ構成にしてみたんだけど、上にも書いた通り AC アダプタ抜いてもカーネルパニックせず、 X は無事に動作するし suspend/resume も完璧に動作する。嬉しいっ!!

 
PC の技術はどんどん進化しているんだけど UEFI+CSM 時代は 10.1-RELEASE が一番良いと思っていた (suspend/resume していた)。そして、 UEFI 時代の FreeBSD は今度でる 13.1-RELEASE が最適なバージョンになるでしょうなぁ。今回利用した 13.0-STABLE の出来の良さに驚いたのでありました。

もし、手元に UEFI のみで動作するバリバリ最新の PC があるのであれば、是非とも FreeBSD をインストールしてみて頂きたいものであります。

いやぁ。今回は「イバラの道」というのは 13.0-RELEASE インストールでフリーズする以外、13.0-STABLE をチョイスして drm-kmod-master をインストールしたらスルっと、なんの苦労もなく動作したので、幸せな日々が送れて嬉しいのであります;-)。

このネタ、もう完結してしまって、続きませんf(^^;。

7月 292021
 

前回のエントリでは Let’s Note CF-SZ5 の中古を購入して FreeBSD/amd64 13.0-RELEASE をインストールしました。そして、無事に動作して、なんちゃってな suspend/resume が動作しているところまで書いています。

 
さて、suspend/resume ですが、ports-CURRENT を追いかけていると、以下をインストールした辺りで正常に suspend/resume が動作するようになります。

  • drm-fbsd13-kmod-5.4.92.g20210720_1
  • mesa-dri-21.1.5
  • mesa-libs-21.1.5

もう、 /etc/rc.resume の中に色々書く必要ないです。

/etc/sysctl.conf に、以下の設定を記載すると、フタの開け閉めで suspend/resume ができるようになります。

# suspend/resume
#hw.acpi.lid_switch_state=NONE
hw.acpi.lid_switch_state=S3
hw.pci.do_power_suspend=0
hw.acpi.lid_switch_state=S3
hw.acpi.power_button_state=S5

 
すごいことですねぇ。 NotePC でバリバリ利用可能な FreeBSD の完成です;-)。

 
と、いうことで、ここからが本題。

以前のエントリでは Let’s Note のクルクル回すタッチパットでスクロールできない。と、書いていましたが、こちらも問題解決できたので、追加でエントリ書いてみたいと思います。

 
インターネット上で色々探してみると古い FreeBSD のバージョンでは特に気にすることなく動作していたみたいですが、12 系リリースの辺りからクルクルホイールさせるためには色々とワザが必要なって来たようです。

まず、カーネルがブートしたときの psm の状況を見てみましょう。
あ、このとき、/boot/loader.conf には以下のように設定してあります。

# psm/sysmouse
hw.psm.synaptics_support=1
hw.psm.trackpoint_support=1
#hw.psm.elantech_support=1

 
hw.psm.synaptics_support=1 が記載してあります。

それでもブート時には以下のように表示されます。

$ dmesg | grep psm
psm0:  flags 0x1000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0.
psm0: model Generic PS/2 mouse, device ID 0

 
このようになっていた場合、どう xorg の synaptics 設定を書いてもクルクルホイールできません。ただのタッチパッドの動作になります。この状態では、とあるおまじないをする必要があります。

おまじないが有効化されるとこのようになります。

$ dmesg | grep psm
psm0:  flags 0x6000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0.
psm0: model Synaptics Touchpad, device ID 0

 
一番最後が model Generic PS/2 mouse か model Synaptics Touchpad の違いです。

ではどのようにすると model Synaptics Touchpad になるのか?

ソースコードをいじる必要があるんですねぇ・・。
いやぁ、ようやっと、ネタを見つけた。と、いうか・・。

https://github.com/wulf7/iichid/issues/53

pciconf -lv したときに ichsmb0 があると良いのですが・・。 kldstat で ichsmb.ko がロードされているか確認してみてください。

さて、上記 URL を確認してみると、タッチパッドが SMBus 経由で動作するかもしれん。と、いうことで /usr/src/sys/dev/atkbdc/psm.c を書き換えてみてください。と記載されています。

--- psm.c.orig  2021-04-13 10:02:53.550143000 +0900
+++ psm.c       2021-07-28 10:23:34.503022000 +0900
@@ -6315,7 +6315,7 @@
                    active_ports_count);
 
        /* psm has a special support for GenMouse + SynTouchpad combination */
-       if (active_ports_count >= 2) {
+       if (active_ports_count >= 1) {
                for (port = 0; port < KBDC_AUX_MUX_NUM_PORTS; port++) {
                        if ((active_ports_mask & 1 << port) == 0)
                                continue;

 
(active_ports_count >= 2) の部分を 1 に書き換えたあと、カーネルを作り直して再起動してると・・。
おやまぁっ!! psm0 が model Generic PS/2 mouse から model Synaptics Touchpad になったではありませんかっ!!

最近の Let’s Note のタッチパットでクルクルを有効化させるためにはコードを修正する必要がある。と、いう感じでしょうか。

 
あとは xorg の設定をしていきます。僕の場合、/usr/local/etc/X11/xorg.conf.d/70-synaptics.conf を用意しました。

Section "InputClass"
    Identifier          "touchpad catchall"
    Driver              "synaptics"
    MatchIsTouchpad     "on"
    MatchDevicePath     "/dev/input/event*"
    Option              "CircularScrolling"     "1"
    Option              "CircularScrollTrigger" "0"
EndSection

 
/dev/input/event は何番になっているか? とかは libinput list-devices コマンドが良い感じかも。

あと、他の設定はどこに書いたら良いのか・・。僕の設定は /etc/sysctl.conf に書いていました。色々やったけど、動かなかったので /etc/sysctl.conf に書いていた。と、いう状態でしょうか・・。

# synaptics mouse 
hw.psm.synaptics.vscroll_hor_area=1300
hw.psm.synaptics.min_pressure: 16
hw.psm.synaptics.max_pressure: 220
hw.psm.synaptics.max_width: 10

 
こんな設定が入っていましたf(^^;;。これが効いているのかは sysctl で確認。と、いう感じです。
あと、KDE5 を利用している場合「KDE システム設定」の「入力デバイス」→「タッチパッド」で GUI 的に色々設定できるのでそっちで細かい設定をしたほうが直感的かも。

それにしてもようやっと、ホイールが動作してタッチパッドが動作するようになりました。嬉しいかぎかぎカギリですです。

ホイールクルクル回す他に、二本指で上から下に、もしくはその逆になぞるとスクロールもしてくれます。動作的には ThuinkPad X13 AMD みたいな感じかな。

 
さてと。これで Let’s Note CF-SZ5 はほぼぼカンペキな FreeBSD マシンになりました。 ThinkPad X13 AMD の Renoir が今でもまともに動作しないので、どうしてもこの NotePC が FreeBSD のメイン機として活躍していきそうな気配です。

 
あと、この NotePC は vPro が動くみたい(さすがはビジネス向けっ!!)みたいですが、 FreeBSD はそもそも vPro が動作しないようです。

4月 142021
 

以前のエントリで「ThinkPad X13 AMD で利用する FreeBSD。」と、いうのを書きました。このときに利用した FreeBSD のバージョンは FreeBSD/amd64 12.1-RELEASE でした。その後 FreeBSD/amd64 12.2-RELEASE が出たときに試しましたが、やはり Renoir は認識せず、 xf86-video-scfb を使い続けていた状態なのでありました。

 
途中 13-CURRENT も試したりしましたが、カーネルと drm-kmod 辺りの相性が悪く、カーネルパニックになったりしてそこはかとなく悲惨な状態だったので利用を断念して RELEASE バージョンに戻した。と、いう雰囲気だったのであります。

さて、「ThinkPad X13 AMD のタッチパッド。」のエントリに書いていますが、drm-v5.0-fbsd12.1.zip を github から拾ってきて、自分でコンパイルして試したりしていますが、2021/04/14 にリリースされた FreeBSD/amd64 13.0-RELEASE は drm-kmod がバージョン 5 になっているのできっと動くだろうと思い早速トライしたのであります。

 
結果としては、見事に玉砕。最新の ports CURRENT でもカーネルパニックが発生しました・・。orz
ThinkPad X13 AMD はコツコツと BIOS (と、いうか UEFI) のバージョンアップがあるのでその影響が出たのかな? と、いう感じがします。

あ。FreeBSD の ports CURRENT を持ってこようとして svn update しようとしても、2021/04/02 で SVN サーバ上の更新が止まっていますね。しょうがないので git 経由 /usr/ports を更新することにしましょう。と、言いつつ、ウェブで色々探したのですが、一発目のコマンドイメージがどこにも書いてないですね・・。 /usr/src を持ってくる方法はあるのですが・・。と、いうことで、一発目に実行するコマンドイメージを探すのにずいぶんと苦労しました。
以下のコマンドを一回だけたたきます。

# cd /usr
# mv ports ports.svn
# git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports
<以下略>

 
二回目以降は

# cd /usr/ports
# git pull
<以下略>

 
これで良いです。
問題なのは、一回目に実行する git clone がどこにも書かれていない。と、いうことですかねぇ・・。

 
と、いうことで最新の ports CURRENT が手に入りました。これで Renoir に必要な ports を各種インストールすることにします。
だいたいこの辺りをインストールすると良いのではないかと思われます。僕の場合は kde5 を利用しているので、関連する ports もドドドと、当然インストールされますが。

  • drm-fbsd13-kmod-5.4.92.g20210202
  • gpu-firmware-kmod-g20210224
  • xf86-video-amdgpu-19.1.0_1
  • mesa-dri-20.2.3_1
  • mesa-libs-20.2.3

 
続いて、各種設定です。

 
1. /etc/rc.conf

kld_list="amdgpu.ko"

 
amdgpu.ko をロードする設定を記載します。

 
2. /boot/loader.conf

hw.amdgpu.exp_hw_support="1"

hw.psm.elantech_support="1"
hw.psm.trackpoint_support="1"

hw.vmm.amdvi.enable=1

vmm_load="YES"
cpp_load="YES"

ntb_hw_amd_load="YES"
amdpm_load="YES"
amdsmb_load="YES"
amdtemp_load="YES"
amdsbwd_load="YES"

smbus_load="YES"
smb_load="YES"
intpm_load="YES"
ichsmb_load="YES"
imcsmb_load="YES"

iichid_load="YES"
iicsmb_load="YES"
iic_load="YES"
ig4_load="YES"

 
hw.amdgpu.exp_hw_support=1 を記載すると amdgpu が使えるようになります。他、デバイスドライバを認識させるカーネルモジュールも書いておきました;-)。

 
3. /usr/local/etc/X11/xorg.conf.d/06-driver.conf

Section "Device"
    Option      "DRI" "3"
    Option      "AccelMethod" "exa"
    Option      "MigrationHeuristic" "greedy
    Option      "TearFree" "On"
    Driver      "amdgpu"
    BusID       "PCI:5:0:0"
EndSection

 
Driver に amdgpu を指定します。 BusID は pciconf -lv | grep vga を叩いたときに表示される番号を指定します。
準備ができたので、再起動して動作を確認して root で startx だぁーーっ!!

が、カーネルパニック・・。 orz
シューリョー・・。 orz

 
そんなばかなぁ・・。とか、思いつつ色々悪あがきで設定を見直してみましたが、ダメでした・・。引き続き /usr/local/etc/X11/xorg.conf.d/06-driver.conf の Driver は scfb の利用を継続・・。

 
と、いうことで、問題は ports の graphics/drm-fbsd13-kmod であることは多分明白です。これは 13-CURRENT をインストールしていたときに確認しています。 drm-fbsd13-kmod が 5.4 なので、もっと新しいバージョンはないのか?

 
https://github.com/freebsd/drm-kmod/tree/5.5-wip

 
こちらです。 5.5 です。他に drm-kmod-5.5-wip-amd と drm-kmod-5.5-wip-amd-pr がありましたが、これらは make が通りませんでした。
drm-kmod-5.5-wip.zip をダウンロードしてきて make && make install します。そのとき、ports からインストールした graphics/drm-fbsd13-kmod がインストールされていても問題ありません。 drm-kmod-5.5-wip を make install して上書きします。

 
これで、準備ができました。上の設定を全て有効にして再起動します。起動したらすかさず startx を叩きます。

ちょっと長いですが、dmesg を貼り付けます。

amdgpu: [powerplay] smu driver if version = 0x0000000a, smu fw if version = 0x0000000e, smu fw version = 0x00374700 (55.71.0)
amdgpu: [powerplay] SMU driver if version not matched
amdgpu: [powerplay] dpm has been disabled
amdgpu: [powerplay] SMU is initialized successfully!
[drm] Display Core initialized with v3.2.56!
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm ERROR :dm_helpers_parse_edid_caps] Couldn't read SADs: -2
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-2
[drm]   - kern.vt.fb.default_mode
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] VCN decode and encode initialized successfully(under DPG Mode).
[drm] fb mappable at 0x460BC7000
[drm] vram apper at 0x460000000
[drm] size 8294400
[drm] fb depth is 24
[drm]    pitch is 7680
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1080 width=1920 depth=32
cmsize=16 size=8294400
pbase=0x460bc7000 vbase=0xfffffe010c9c7000
name=drmn0 flags=0x0 stride=7680 bpp=32
cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: amdgpudrmfb frame buffer device
drmn0: ring gfx uses VM inv eng 0 on hub 0
drmn0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
drmn0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
drmn0: ring comp_1.2.0 uses VM inv eng 5 on hub 0
drmn0: ring comp_1.3.0 uses VM inv eng 6 on hub 0
drmn0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
drmn0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
drmn0: ring comp_1.2.1 uses VM inv eng 9 on hub 0
drmn0: ring comp_1.3.1 uses VM inv eng 10 on hub 0
drmn0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
drmn0: ring sdma0 uses VM inv eng 0 on hub 1
drmn0: ring vcn_dec uses VM inv eng 1 on hub 1
drmn0: ring vcn_enc0 uses VM inv eng 4 on hub 1
drmn0: ring vcn_enc1 uses VM inv eng 5 on hub 1
drmn0: ring vcn_jpeg uses VM inv eng 6 on hub 1
[drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0
WARNING !(mask != 0) failed at /usr/local/src/drm-kmod-5.5-wip/drivers/gpu/drm/amd/display/dc/dc_helper.c:53
#0 0xffffffff80e3f803 at linux_dump_stack+0x23
#1 0xffffffff83604b0b at set_reg_field_values+0x4b
#2 0xffffffff83604a83 at generic_reg_update_ex+0x53
#3 0xffffffff8353932c at dp_disable_link_phy+0x5c
#4 0xffffffff8353d176 at core_link_disable_stream+0x416
#5 0xffffffff835a2aac at dcn20_reset_hw_ctx_wrap+0x15c
#6 0xffffffff8355f46b at dce110_apply_ctx_to_hw+0x2b
#7 0xffffffff835469de at dc_commit_state+0x51e
#8 0xffffffff8351a23f at amdgpu_dm_atomic_commit_tail+0x4bf
#9 0xffffffff83302f86 at commit_tail+0x46
#10 0xffffffff83302366 at drm_atomic_helper_commit+0x1e6
#11 0xffffffff833059e9 at drm_atomic_connector_commit_dpms+0xd9
#12 0xffffffff83333e3e at drm_mode_obj_set_property_ioctl+0x15e
#13 0xffffffff8330de6b at drm_connector_property_set_ioctl+0x2b
#14 0xffffffff8332cab2 at drm_ioctl_kernel+0x72
#15 0xffffffff8332ce18 at drm_ioctl+0x2c8
#16 0xffffffff80e3d053 at linux_file_ioctl+0x2e3
#17 0xffffffff80c76ced at kern_ioctl+0x26d

 
一応、認識しました。やったーっ!!
ただし、下のほうの # で始まる行は定期的にログが出力されます。まぁ、しょうがないか・・。

 $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 293mm x 165mm
   1024x768      60.03 +
   1920x1080     60.03*+
   1680x1050     60.03  
   1280x1024     60.03  
   1440x900      60.03  
   1280x800      60.03  
   1280x720      60.03  
   800x600       60.03  
   640x480       60.03  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)

 
ディスプレイが eDP として認識されました。と、いうことは xrandr –output eDP –brightness 0.5 も使えて、画面の明るさも変えられるようになりました。

FreeBSD 13.0-RELEASE になって /boot/kernel/backlight.ko というのができて、こいつが画面の明るさを管理しているみたいですが、kldload backlight.ko すると「dmesg 見てみろ。」とか言われいまいち動作していないようです。が、コマンド的に /usr/bin/backlight 30 とかすると画面の明るさが変わります;-)。

 
と、いうことで、Renoir (それはつまりは Vega10 のことですね;-) が無事に動作するようになり、ホッと一安心。そして、画面設定やコンポジタの設定は KDE5 の 「KDE システム設定」から色々できます。嬉しいことです。

 
最後にですが、FreeBSD/amd64 13.0-RELEASE になって、 ThinkPad X13 AMD で Renoir の他に動くようになったモノ、まだ動かないモノなどについて記載しておきます。

  • Realtek のカードリーダ (RTS522A) が rtsx0 で認識して動くようになりました。
  • 音はスピーカーからもヘッドホン端子からも出ます。
  • CPU の温度が拾えるようになりました。
  • Intel Wi-Fi 6 AX200 はまだ動きません。
  • Suspend して Resume で起きても動きません。電源ボタン押すと shutdown はしてくれるようですが、ネットワークは利用できません。

 
こんな感じでしょうかねぇ。それにしても、再度書きますが、 Renoir (それはつまりは Vega10 のことですね;-) が動作するようになったのは嬉しいことです。
AMD Ryzen 7 PRO 4750U で Xorg を動かしたいけど、カーネルがパニックしてしまう。と、いう人は github から drm-kmod-5.5-wip.zip を取ってきてインストールして見るのも一つの手だと思います。

次は suspend/resume にトライだぁ;-)。

1月 062021
 

以前のエントリで、「Nginx + quiche パッチで HTTP/3 にチャレンジ。」と、いうのを書いています。このエントリの『続編』を書いてみたいと思います。

と、いうのも色々あったからです。

簡単に書くと、あっという間にこのエントリは終わってしまいますf(^^;;。
ネタ的なモノを箇条書きにしてみると

  • nginx + quiche パッチでは SSI は動作しません
  • nginx + quiche パッチを利用した場合 RTMP モジュールが利用できないです

の二つになります。これが解れば詳細はどうでもいー。と、いう人はここでおしまいです。
『なんで?』と思った方は読み進んでくださいf(^^;;。

 
まず、上の部分の SSI についてですが、perl による index.cgi で SSI で吐き出すことと同じ動作をするモノを作成すると、無事に動作します。

以下はサンプルです。これは index.cgi 。

#!/usr/local/bin/perl
use strict;
print "Content-type: text/html\n\n";
print "<html>\n<head>\n";
print "<META HTTP-EQUIV=\"Content-type\" CONTENT=\"text/html;charset=utf-8\">\n";
print "<TITLE>IPv6 HTTP/3 Access Web page.</TITLE>¥n";
print "</head>\n<body>\n";

print "<br><h2>Hello HTTP/3 World.</h2><hr>\n";

my $word = "";
if ($ENV{'REMOTE_ADDR'} =~ /:/) {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv6 パケットを受け取りました。";
} else {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv4 パケットを受け取りました。";
}
print "$word<br><hr>\n";;

print "===> Protocol: $ENV{'SERVER_PROTOCOL'}<br>\n<hr>";
print "===> Access Port: $ENV{'SERVER_PORT'}<br>\n<hr>";

exit;

 
似たようなのを index.shtml と access.cgi でやるとこんな感じ。

こちらは index.shtml。

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-type" CONTENT="text/html;charset=utf-8">
<TITLE>IPv6 HTTP/3 Access Web page.</TITLE>
</HEAD>
<BODY>
<ht>
Hello HTTP/3 World.<br>
<hr>
<!--# include file="./access.cgi"-->
<hr>
</BODY>
</HTML>

 
こちらは access.cgi。

#!/usr/local/bin/perl
use strict;
print "Content-type: text/html\n\n";
my $word = "";
if ($ENV{'REMOTE_ADDR'} =~ /:/) {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv6 パケットを受け取りました。";
} else {
    $word  = "---> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv4 パケットを受け取りました。";
}
print "$word<br><hr>\n";;
print "===> プロトコル: $ENV{'SERVER_PROTOCOL'}<br>\n<hr>\n";
print "===> アクセスポート: $ENV{'SERVER_PORT'}<br>\n";
exit;

 
index.html (index.shtml) に include があると、 Nginx + quiche パッチではまともに動作しないようです。 quiche パッチを詳しく追ってはいないのですが、どうやら include 部分がそげ落ちているようです・・。 orz

まぁ、今の段階では SSI を利用しないコンテンツを用意する必要がありそうです。

 
二個目。

テレワークなどで、PC にカメラを接続する機会が多いのですが、せっかく購入したカメラ。もっと色々な用途で使ってみたい。などと思うわけです。 USB Video Class 、俗に USB な UVC カメラを FreeBSD に接続し、 webcamd や obs-studio をインストールして『ストリーミングなどしてみんべ。』などと思うわけです。
このブログでも以前に「NotePCに付いているカメラを FreeBSD で使う。」と、いうのを書いていたりしますが;-)。

更に一歩進んで obs-studio をイントールした場合、配信先に RTMP サーバが必要になります。
Nginx はモジュールとして RTMP モジュールや Stream・Stream SSL モジュールなどを利用可能ですが、HTTP/3 を有効にする quiche パッチを適用した Nginx ではこれらのもジュールは利用できません。

以下は nginx.conf の設定の抜粋です。

load_module /usr/local/libexec/nginx/ngx_stream_module.so;
load_module /usr/local/libexec/nginx/ngx_rtmp_module.so;

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        access_log /var/log/nginx/access_rtmp.log;

        application webcam {
            live on;
            record off;
            wait_video on;
        }
    }
}

 
load_module のところで早くもエラーが出ます。

# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] dlopen() "/usr/local/libexec/nginx/ngx_stream_module.so" failed (/usr/local/libexec/nginx/ngx_stream_module.so: Undefined symbol "SSL_set_tlsext_host_name") in /usr/local/etc/nginx/nginx.conf:7
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

 
もしくは

# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] dlopen() "/usr/local/libexec/nginx/ngx_rtmp_module.so" failed (/usr/local/libexec/nginx/ngx_rtmp_module.so: Undefined symbol "HMAC_CTX_new") in /usr/local/etc/nginx/nginx.conf:7
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

 
みたいな感じ。

最初、どうして、SSL 系でエラーが出るのか解らなかったのですが、ports の www/nginx/Makefile とかソースを眺めていたら解りました。以前のエントリで、Nginx + quiche パッチを適用する場合 configure オプションに –with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl を指定しているんですね。
RTMP や Stream モジュールを利用する場合、ベタな openssl のソースのパスを指定する必用があるのですが、 quiche パッチを適用した場合、quiche 独自の SSL のコードを参照する必用があるので、 RTMP や Steram モジュールのコンパイルが通ったとしても、いざ動作させようとすると色々とシンボル名がなかったりするのですな。

 
と、いうことで、 Nginx に quiche パッチを適用した場合は、 HTTP/3 でのアクセス可状態なサーバで、SSI を利用しないウェブサーバとして利用するみとになります。

あ。Nginx + quiche パッチを適用したウェブサーバでも HTTP/2 や HTTP/1.1 、そして HTTP/1.0 (今では w3m くらいか?) でアクセスがあった場合 (それは、つまりは TCP でアクセスがあった場合かぁ?) には SSI は動作します。あくまで HTTP/3 でアクセスがあった場合のみ SSI の記述がある index.html がまともに表示されない状態になります。

SSI 使ったり RTMP・Strerm モジュールを利用したい場合は別にコンパイルしたサラの Nginx を用意する必用があります。 quiche パッチを適用しない Nginx では SSI や RTMP のサーバとして利用できるので、仮想マシンやコンテナで別立てするのがよろしいかと思われます。

 
ちなみに、Firefox は 72 から、 macOS や iPhone は Safari 14 から HTTP/3 がサポートされるようになりました(詳細については gugu ってください;-)。 macOS や iOS から HTTP/3 でアクセスできるようになると、ウェブサーバ担当者としてもいよいよ HTTP/3 の設定をしてサーバを起動してみたくなりますなぁ;-)。 ファイアーウォールの UDP Port:443 を開けるときが、今っ!! 来ましたっ!! ;-)。

1月 092020
 

2020 年の 正月に ports を csv update したら Firefox72 が降って来ていたので、そのまま FreeBSD/amd64 12.1-RELEASE にインストール。
しかし、ハタと考えてみた。『Firefox って 72 から HTTP/3 をサポートしたんじゃなかったけっ?』
果たして about:config で確認してみると

network.http.http3.enabled

と、いうのがあるではないかっ!! これをすかさず true にして google などを確認してみる。

HTTP/3 というのは、チョー簡単に言うと UDP で SSL 通信を行うものであります。詳細についてはウェブで情報を探してください;-P。
ファイアーウォールなどで UDP の 443 ポートなんてのは中々開いているものではないので、自宅なり、オフィスなりのファイアーウォールをまず先に確認してみましょう。

 
しかし、自分でも UDP:443 で通信するサーバを構築してみたい。色々探してみると apache24 はまだ、未対応ですが、 nginx は対応パッチが出ているようです。

まずは以下の URL にアクセス。

https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/

 
ここに記載されている git からパッチを取ってきて nginx のソースにパッチを当てて make しても良いんだけど、configure のオプションがややこすぃー。せっかく FreeBSD が手元にあるので ports の nginx に quiche パッチを適用してサーバ環境を構築してみましょう。

と、いうのが今回の趣旨です。ひと足お先に HTTP/3 を体験してみましょう。

このブログでは以前に apache24 で HTTP/2+TLSv1.3 対応にするエントリを書いていますが、今回は nginx のエントリになります。

 
1). ports の準備
以下に手順を書いてみます。

# cd /usr/ports/www/
# cp -pr nginx nginx-http3
# cd nginx-http3/
# git clone --recursive https://github.com/cloudflare/quiche
# make patch

 
原本となる /usr/ports/www/nginx/ は一応残しておいて nginx-http3/ というディレクトリで作業を始めます。
git から quiche を一式持ってきて、ports 的には make patch まで走らせます。make patch 時に make config が走ると思いますがお好みの設定で、絶対に忘れてはいけないオプションが HTTP_SSL と HTTPV2 です。 default で [X] になっていると思うんですけどね。

 
2). パッチ適用

# cd work/nginx-1.16.1/
# patch -p01 < ../../quiche/extras/nginx/nginx-1.16.patch
# cd ../..

 
nginx-1.16 用の quiche パッチなので、最新の ports ツリーであれば容易に適用できます。

 
3). ports の Makefile の編集
www/nginx-http3/Makefile を編集します。上記 URL では configure オプションが記載されていますが、それを FreeBSD の ports に書いて上げます。

diff -ur Makefile.orig Makefile
--- Makefile.orig       2020-01-03 12:00:17.947717000 +0900
+++ Makefile    2020-01-03 12:01:29.885305000 +0900
@@ -53,6 +53,9 @@
 
 HAS_CONFIGURE= yes
 CONFIGURE_ARGS+=--prefix=${ETCDIR} \
+               --with-http_v3_module \
+               --with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl \
+               --with-quiche=/usr/ports/www/nginx-http3/quiche \
                --with-cc-opt="-I ${LOCALBASE}/include" \
                --with-ld-opt="-L ${LOCALBASE}/lib" \
                --conf-path=${ETCDIR}/nginx.conf \

 
さーっ!! 準備ができたのでいよいよ make だぁっ!! などと思っては行けません。 quiche 側のソースコードのコンパイルには rust の cargo build を実行するので、なんとっ!! ここへ来て、 rust をインストール必要があります。
Firefox を自前でコンパイルする人は既に rust はインストール済みだと思われるため簡単ですが、持っていない人は /usr/ports/lang/rust/ を make install しましょう。速いマシンでも 30 分くらいかかると思いますけど。

 
rust のインストールが終わったらいよいよ nginx を make install します。

 
以上で HTTP/3 対応 nginx のインストールが完了しました。めでたしめでたし。

 
4). nginx.conf の設定
nginx.conf の設定は抜粋のみです。

user  www;
worker_processes  4;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  16;
}

http {

    autoindex off;

    server {
        listen [::]:443 quic reuseport;
        listen [::]:443 ssl  http2;
        listen      443 quic reuseport;
        listen      443 ssl  http2;

        server_name         nx.icmpv6.org;

        access_log  /var/log/nginx/access_nx_icmpv6_org.log;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.shtml index.php;
            allow  all;
        }

        ssl_certificate     /usr/local/etc/letsencrypt/live/nx.icmpv6.org/cert_chain.pem;
        ssl_certificate_key /usr/local/etc/letsencrypt/live/nx.icmpv6.org/privkey.pem;

        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
        ssl_session_cache   shared:SSL:1m;
        ssl_session_timeout 5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        add_header alt-svc 'h3-23=":443"; ma=86400';

        http3_max_concurrent_streams 128;
        http3_max_requests           1000;
        http3_max_header_size        16k;
    }
}

 
listen は計 4 行ありますが、HTTP/3 で接続する場合には 443 quic reuseport の行が利用されます。 HTTP/3 に対応していないブラウザでは HTTP/2 で待ち受けるので、その設定は 443 ssl http2 になります。

そして、IPv6/IPv4 のデアルスタクです。

HTTP/2 も HTTP/3 も SSL が必須なので証明書を準備しましょう。 SSL 関連の設定もお忘れなく。

 
5). 実際に起動してみる
まず、何はなくとも以下のコマンドを叩いて確認。

$ netstat -an | grep 443
tcp4       0      0 *.443                  *.*                    LISTEN     
tcp6       0      0 *.443                  *.*                    LISTEN     
udp4       0      0 *.443                  *.*                    
udp4       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*
$
# tcpdump -i em0 udp port 443

 
うぉー。udp4,6 で port:443が開いているっ!!
tcpdump を起動して、UDP の port:443 でパケットが流れているか、確認ができます。
また、nginx のアクセスログで "GET / HTTP/2.0" は TCP Port:443 の接続になります。 "GET / HTTP/3" が UDP の Port:443 の接続になります。
上記の nginx の設定ではもう HTTP/2 か HTTP/3 の接続になりますな。高級なブラウザの場合は HTTP/2 か HTTP/3で、 w3m でアクセスするとようやっと "GET / HTTP/1.0" でのアクセスになります。

 
あとは nginx の root パスにドカドカコンテンツを置いていけば良いと思われます。

しかし、 netstat -an で UDP port:443 を確認して待受状態になっているにも関わらず接続できない場合があります。
サーバ側で tcpdump で確認してみると、クライアント側からアクセスがあるだけで、サーバ側からの応答がない場合が・・。しかし、とあるタイミングでは接続できるので・・。今の所 nginx を再起動してみたりと、いう運用ですかねぇ。

あと、Firefox72 は HTTP/3 で接続できなかった場合 HTTP/2 や HTTP/1.1 にフェイルオーバーしません。 HTTP/3 の応答が無くともずっと待っている状態になります。 about:config の HTTP/3 のタイムアウト設定も見当たらないし・・。

 
と、いうことで、今から遊ぶには十分に楽しい HTTP/3 です。FreeBSD では ports を利用すると Firefox72 は使えるわ、 nginx は ports にパッチを当てるだけで configure オプションに悩まなくて済むわ。比較的容易に、そして十分に楽しめること間違いなしです。

ここいらで UDP の世界にどっぷりとハマってみるのも良いのではないでしょうか;-)。

4月 082019
 

FreeBSD の ports-current を追いかけていると www/firefox と mail/thunderbird は i18n な ports/packages が削除されたことが解ります。
なので、firefox や thunderbird をインストールした人は各個人で Japanese Language Pack をアドオンからインストールしてね。と、いうことになるのでありますが・・。

それにしても thunderbird のアドオンから言語パック (Japanese Language Pack のこと)をダウンロードしようにも 52 のままで新しい thunderbird-60.6.1 に対応したものが見つかりません。

困ったのぉ・・。と、いうことで、どーすんべ・・。などと悩んだのですが Linux 方面から持ってくることを思いつきました;-)。

ちょいと調べてみると ubuntu 方面のモノが使えそうです。と、いうことで以下のサイトにアクセスして ubuntu の deb パッケージをダウンロードします。

https://packages.ubuntu.com/ja/xenial/amd64/thunderbird-locale-ja/download

僕は thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb というのをダウンロードしました。

これを適当なディレクトリで展開します。 FreeBSD の tar はなんでもかんでも xvzfp で展開できるのが嬉しいですねぇ;-)。

$ mkdir deb
$ cd deb
$ wget http://security.ubuntu.com/ubuntu/pool/main/t/thunderbird/thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb
$ tar xvzfp thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb
$ tar xvzfp data.tar.xz
$ cd usr/lib/thunderbird-addons/extensions/
$ cp -pr langpack-ja@thunderbird.mozilla.org.xpi ~/.thunderbird/乱数.default/extensions/
$ thunderbird
$

 
以上です。

1. ubuntu の deb パッケージから Japanese Language Pack を引っこ抜きます。
2. それを自分の thunderbird の環境の extensions/ の中に入れます。
3. thunderbird を起動し Japanese Language Pack を enable して再起動します。

以上で FreeBSD の thunderbird-60.6.1 でも日本語対応することができるのであります;-)。

当分の間は、thunderbird のバージョンアップを繰り返すごとに上記を実行する必要があるかなぁ・・。

japanese/thunderbird-langpack-ja/ なんて ports 作っても、きっと却下されるんだろうなぁ。ノラ ports でも作るかなぁ;-)。