28-Aug-2022
[ip/slattach/ifconfigおぼえがき]

OpenBSDのsl(4)代わりに使うツール、当然通信相手が必要になるのでそれをLinux(Debian-11.4)マシンにお願いすることになります。ということは、ipコマンドとかslattachコマンドが分からないと操作できないということになりますね。という訳でメモ。

・slattachを使う場合(IPv4)

例のツールを使う場合(IPv4)

これをOpenBSD側では

で受けることになります。

折角なので、IPv6をSLIPで通せるか…という実験をしてみます。

Linux側はこんな感じで、

OpenBSD側はこう。

一応動いてはいる感じなのですが、同じ設定をしていても動かないことがあります。設定に順番があるのかもしれません。また、slattachでの動作については未確認です。MTUを1280に増やすことはできるようなので、こちらでも動くのかもしれません。

例のアレはドキュメントをまだまとめていないので、そのうちまとめておかないといけませんね…57.0kg(17:25)

26-Aug-2022
[車輪の再発明してました(TUNデバイスおぼえがき)]

某所でAX.25のKISSプロトコルの話→とりあえずシリアル(RS-232C)上でSLIP(RFC1055)使ってTCP/IP喋らせてみるか→あれ?OpenBSDのsl(4)は5.6までの対応になってる→じゃあ作ってみますかねということをしていたのですが…こんなのは車輪の再発明だと思っていて(そもそもsl(4)があれば何もしなくて済むのだし)、作っている際に見かけた今さらSLIPを復習するでもcontikiのtunslip.cが紹介されていたりします。まあ、自分のやってることは今更なんです実際。

とりあえずOpenBSDやそれ以外のOSでTUNデバイスを使った際に感じた、それぞれの癖みたいなものを忘れる前にメモ。

流石に一番最後のは参りましたが…データリンクによってMTUが違うという話(PDFの50ページ目にあります)、分かっている人にとっては常識なのでしょうね。

KISS protocolがSLIPと大体一緒というのはコードを作って始めて知ったのですが(お前はこの35年間一体何を見ていたのだ、という罵倒は甘受します)、MTUのサイズを考慮するに、AX.25上でIPv6を流すのは現実的ではないと判断する必要がありそうです。56.9kg(07:00)

27-Aug-2022補足:LinuxにおけるPIのprotoの指定、rand()の値で試してみましたがしっかりチェックしているようです。

21-Aug-2022
[なるほど]

pthreadを触る必要が生じてしまいました。Oracleのマルチスレッドのプログラミングを参考に試しているのですが、単にスレッドを作って実行するだけだったらこんな感じのコードで良いんですかね。μITRON系のOSに例えるならcre_tsk(), sta_tsk(), exd_tsk()辺りのアレと書いておきましょうか…結構シンプルに書けるので驚いています。

今回はスレッド同期のオブジェクトは使わない予定なのでこれで本当に十分なはず…?57.6kg(15:55)

15-Aug-2022
[LoRaKissTNC-SX1280おぼえがき]

JARD測定器室でRetevis RT85および5個のeByte E28-2G4M12Sのスプリアス測定を行ってきました。すべて問題無いとの結果が出ていますので、これで免許申請へ進むことができそうです、と31-Jul-2021と書いておきながら一年近く放っている状態です。

再免許申請絡みの問題(再免許申請中に変更申請を出すのは色々面倒)とお金の問題(SX1280以外にも変更申請を出したい無線機はあるけど保証申請料がかさむ)に加え、LoRaKissTNC(SX1280)がRadioLibのバージョンによってはうまく動かない問題があってこの原因を探るのはあまりにも面倒でもう嫌だなーとぶん投げていたというのが理由です。

とはいえハムフェア2022も近いことですし、いつまでも塩漬けにしていてもしょうがないのでこの問題を渋々調べていたのですが…LoRaKissTNC-RadioLib(SX1280版およびSX127x版の両方とも)はRadioLib-4.4.2との組み合わせを推奨する、というのが現時点での結論です。

RadioLib-4.5.0から追加される[PHY] Added direct reception supportによりメモリ消費量が増えるようで、ATmega328P(LGT8F328P)では受信動作が正常に行えなくなります。4.4.2では108文字前後の受信ができるのに対し、4.5.0/4.6.0では16文字程度、5.0.0/5.1.0では4文字程度、5.2.0/5.3.0ではほぼ不可能な状態です。

Arduino/libraries/RadioLib/src/protocols/PhysicalLayer/PhysicalLayer.hのuint8_t _buffer[RADIOLIB_STATIC_ARRAY_SIZE];をuint8_t _buffer[0];とでもすればある程度動くようになりすが、それでも4.5.0では100文字程度、5.3.0では86文字程度と…ライブラリのバージョンアップに伴うメモリ消費量の増大による影響は避けきれません。AVR系以外の、RAM容量が十分にあるマイコンへ移行するしかないのかもしれません。

なお、4.4.2→4.5.0で[SX128x] Added support for changing LoRa sync wordが取り込まれましたが、4.4.2←→4.5.0相互の通信はできているため、このコードによる影響は無いものと考えます。※体重計の電池切れにつき体重は不明(13:00)

17-Aug-2022補足:折角なのでRFM98/SX1278のボードを取り出してLoRaKissTNC-RadioLibのSX127x版を試してみたのですが、こちらはRadioLib-4.0.1推奨に訂正します。なお、RFM98ボードはSX1278クラスではなくRFM98クラスで宣言しないとちゃんと動作しません。set freqがちゃんと動いていない気がするので、これは何かの折に調べてみます。

18-Aug-2022補足:SX1278のボードですが、これをSX1278クラスで使用した場合はRadioLib-4.2.0までは動くものの、set freqの不具合を抱えたままになります。その一方で、RFM98クラスで使用するとRadioLib-4.4.2でも動き(それ以降は未確認)、set freqも動作します。SX1278クラスだとerrata対策か何かのコードが有効になるようで、これが悪さをしている可能性を考えています。

12-Aug-2022
[シリアルコンソール/NFSクライアントおぼえがき(2)]

あらすじ:今回・前回ともに、既にQEMU仮想マシンにインストール済みのOSをどうシリアルコンソール対応にしていくかという話。最初っからヘッドレスなマシンではどうするか、というのは申し訳ないのだけど他当たってください。

Void Linuxの場合はインストーラーの時点からフレームバッファが有効になっているため、Installing Void Linux with a Serial Terminalに従っても良いのですが…QEMUの-display cursesを使わずにインストールして、そこからシリアルコンソール対応作業を行うことにします。インストール時のBootLoaderの項目で問われる、「Use a graphical terminal for the boot loader?」にはNoを答えておいて下さい。

/etc/default/grubに以下の項目を追加し、grub-mkconfig -o /boot/grub/grub.cfg。loglevel=4は元々のgrub.cfgでもこの指定が付いています。


GRUB_CMDLINE_LINUX_DEFAULT="loglevel=4 console=ttyS0,115200n8"
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

/etc/securettyはttyS0の指定が有効になっているのでこのまま、ln -s /etc/sv/agetty-ttyS0 /etc/runit/runsvdir/defaultでシリアルコンソールが有効になります。

NFSの使用はNetwork Filesystemsの手順に従い、xbps-install nfs-utils sv-netmount; ln -s /etc/sv/statd /etc/runit/runsvdir/default; ln -s /etc/sv/rpcbind /etc/runit/runsvdir/default; ln -s /etc/sv/netmount /etc/runit/runsvdir/default; echo "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstab。runitは/etc/runit/runsvdirに起動するサービスのシンボリックリンクを放り込むスタイル。

mountコマンドでマウントするだけならsv-netmountパッケージは不要ですが、/etc/fstabを設定して起動時にマウントさせる場合にsv-netmountが必要になります。

Arch Linuxの場合もVoid Linuxと同様にインストーラーの時点からフレームバッファが有効になっているため、QEMUの-display cursesを使わずにInstallation guideに従ってインストールします。ブートローダはGRUBを使うので、pacman -Syu grub; grub-install --target=i386-pc /dev/vda。ここから一気にやっても良さそうですが、一旦grub-mkconfig -o /boot/grub/grub.cfgを行ってきちんと起動できることを確認してからシリアルコンソール対応作業を行います。

/etc/default/grubの設定は、Void Linuxと同じようになります。/boot/grub/grub.cfgに記されているカーネルオプションはloglevel=3 quietになっていますから、こんな感じのものを追加することになるでしょう。エディタはpacmanでお好みのものを入れるなり、この程度ならecho hoge >> /etc/default/grubでもできますね。


GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet console=ttyS0,115200n8"
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

追加した後はgrub-mkconfig -o /boot/grub/grub.cfgを忘れずに。/etc/securettyはttyS0の設定が済んでおり、systemd周りも設定がされているのか、GRUBの設定を行うだけでシリアルポートからのログインができてしまいます。

ネットワークの設定を忘れてしまった場合はsystemd-networkdを参考に/etc/systemd/network/20-wired.networkを記述して、systemctl enable systemd-networkd.serviceをしておいてください。必要があれば、systemd-resolvedも。SSHのクライアント/サーバも入っていないので、pacman -Syu openssh; systemctl enable sshdもお忘れなく。

NFSについてはいちいち書かずとも、NFS - ArchWikiを見れば十分な気がします。pacman -Syu nfs-utils; echo "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstab。

Slackwareと異なり、Void LinuxとArch Linuxは共にvirtioのストレージ/ネットワークを使ってインストール/運用が可能です。それはともかく、/etc/groupに定義されるGIDはSlackwareもVoidもArchもDebianも全然違うのですが、これってどう扱えば良いんでしょう…?56.3kg(10:45)

08-Sep-2022補足:NFSサーバの/export→/srv/nfs/exportへの変更に伴う修正を行っています。

11-Aug-2022
[シリアルコンソール/NFSクライアントおぼえがき]

qemuで-display none -daemonizeを指定して裏で動かしておくのは便利なのですが、やっぱり何かあった際に介入できる手段は持っておかないと危ないな…ということで、シリアルコンソールを使えるようにしておきます。telnet越しにシリアルポートを叩けるようqemuには-serial telnet:localhost:65000,server,nowait,nodelayオプションを追加し(ポート番号は仮想マシン毎に変えて下さい)、あとはOS毎に必要な設定を行っていきます。これがまあ面倒臭くって…

OpenBSD
19-Feb-2014のメモ通り。/etc/boot.confと/etc/ttysを設定する。
NetBSD
boot.cfg(5)を参照。/boot.cfgの最初に、menu=Boot with serial console:rndseed /var/db/entropy-file;consdev com0;bootを追加するだけ。
FreeBSD
27.6 Setting Up the Serial Console27.6.1. Quick Serial Console Configurationに従い、/boot/loader.confにconsole="comconsole"を記述するだけ。
DragonFlyBSD
DragonFly as a KVM guestを参照。/boot/loader.confにシリアルコンソールの設定を追加するだけ。
Slackware-15.0 (LILO, sysvinit)
5.1. Configure Linux kernel using LILOを参照。/etc/lilo.confは、LILO向けにserial=0,115200n8を追加し、カーネル向けにappend="console=tty0 console=ttyS0,115200n8"を追加。/etc/securettyのttyS0のコメントを外し、/etc/inittabのs1:12345:respawn:/sbin/agetty -L ttyS0のコメントを外す(通信速度も適宜設定する)。これは、インストール完了直後〜再起動までの間に済ませておかないと非常に面倒なことになる。

あとはLILOではなくGRUBと、systemdやrunit, s6を使ったLinux仮想マシンでの設定例が必要そうです。とはいえ、仮想マシンであっても5台分の設定をするのは流石に疲れたので、これくらいで留めておきます。

なお、SlackwareのQEMU/KVM仮想マシンへのインストールは注意が必要で、ストレージはvirtio非対応です。ネットワークはインストール後にvirtioが使えることを確認していますが、インストール時については不明です。ahciとe1000を選んでおけば困らないと思います。

折角なので、NFSを使用したファイル共有の設定もメモしておきます。とりあえずホスト機(Debian-11.4)の/exportを仮想マシンにマウントできれば良いという設定なので、パフォーマンスチューニング等の詳細なオプションは省いています。

OpenBSD
Absolute OpenBSD, 2nd Editionにはデーモンの起動や事前設定は要らず単にマウントするだけで良いと書かれているので、echo "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstabだけ。
NetBSD
NetBSD におけるファイルシステムの設定を参考に。/etc/rc.confにnfs_client="YES"を追加し、echo "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstab。
FreeBSD
NFSクライアントを構築する (nfsd)を参考に。/etc/rc.confにnfs_client_enable="YES"を追加(nfs_client_flagsは使われていないようなので設定しない)。あとはecho "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstab。
DragonFlyBSD
Re: NFS Client setup on DragonFlyを参考に。OpenBSD同様、echo "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstabのみ。
Slackware-15.0
mountコマンドでマウントしようとすると「rpc.lockdが動いていないので-o nolockを指定せよ」と怒られたのと、(出典は省きますが)nolockを指定できるのはNFSv3に限られるらしいので、それを明示してこんな感じ→echo "192.168.0.2:/srv/nfs/export /export nfs rw,vers=3,nolock 0 0" >> /etc/fstab。

同じLinuxだから/etc/groupの内容は同じだろう…と思っていたのですが、DebianとSlackwareで全然違います。供養した例のコードで比較すると、こんな感じ。nogroup=65534となっている方がDebianです。56.2kg(18:10)

08-Sep-2022補足:NFSサーバの/export→/srv/nfs/exportへの変更に伴う修正を行っています。

10-Aug-2022
[Debian-11.4でのNFSおぼえがき]

Debian WikiのNFS Server Setupの情報が古くなってて使えないので、Debian 11 (bullseye) - NFS サーバ構築!を参考に。何しろDebian Wikiではapt install portmapって書いてあるけど実際にそれやると「注意、'portmap' の代わりに 'rpcbind' を選択します」なんて言われてしまうので。どうしろと。

OpenBSDはNFSv3までの対応なので、Kerberosだの/etc/idmapd.confについては触らずに。Debianマシンの/homeを他からも共有できるようにしたいというシナリオで。

NFSサーバのインストール
apt-get install nfs-kernel-server
/etc/exportsの編集
/home 192.168.0.0/24(rw,no_root_squash,subtree_check)
NFSサーバ起動
systemctl restart nfs-kernel-server
NFSサービスの永続化
systemctl enable nfs-kernel-server

これでOpenBSDマシンからmount 192.168.0.2:/home /mntとかすればマウント可能になる訳ですが…UID/GIDの対応が取れていないので、ユーザ名/グループ名はめちゃくちゃになります。かつてのLinuxでは/etc/exportsのオプションにmap_staticがありこれで指定した変換表を使うことで対応できるのではないかと試していたのですが…現在はmap_staticを指定するとエラーとなり、NFS自体が立ち上がりません。

NISを使ってUID/GIDを統一するのも大変なので、Linuxマシン以外からのアクセスではall_squashを指定して匿名ユーザとして共有することにします。anonuid=65534, anongid=65534(nobody:nogroup)だとちょっと厳しすぎるので、anonuid=65534:anongid=100(nobody:users)とでもしておきましょうか。

とはいえ、この設定だとLinux側ではちゃんとしているものの、OpenBSD側ではしっちゃかめっちゃかになるという内容なので、これもこれで考え物です…自分以外のユーザが存在しない環境ならUIDはどれも1000になるだろうし、ということでall_squash/anonuid/anongidは使わずにGIDのみ荒れたままにしておくという手もあるかもしれません(それが気持ち悪かったので足掻いていたのですが)。そもそも、NFSはクライアント〜サーバ間でUID/GIDが同じであることを前提にしているとArch Wikiで言ってますので、同じでない環境で使う場合は諦めが必要なのでしょう。

map_static用の変換表を作るコードを書いてはみたのですが、使い道もないようなのでここで供養しておきます。56.4kg(07:50)

11-Aug-2022補足:結局NFSでの/home共有はしないことにして、mkdir /export; chown nobody:users /export; chmod 775 /exportして、/etc/exportsは/export 192.168.0.0/24(rw,all_squash,subtree_check,anonuid=65534,anongid=100)と記述しました。

08-Sep-2022補足:NFS用ディレクトリをアクセスするための、マシン間で統一したUID/GIDを用意することにしました。これについての詳細は08-Sep-2022を参照。また、自分自身へもNFSマウントするため(後述)、mkdir -p /srv/nfs/export; chown export:export /srv/nfs/export; chmod 775 /srv/nfs/exportして、/etc/exportsは/srv/nfs/export 192.168.0.0/24(rw,all_squash,subtree_check,anonuid=32000,anongid=32000)とします。

Debianシステムはユーザー専用グループ(UPG)方式をデフォルトで使用しますというのはセキュリティの面では有用なのですが、ファイルを共有する場面では少し不便なので、NFS公開用のディレクトリ(/srv/nfs/export)をNFS経由で自分自身の/exportにマウントし、パーミッションと所有者の問題を回避します。他の環境と同じように、echo "192.168.0.2:/srv/nfs/export /export nfs rw 0 0" >> /etc/fstabでok。ハードマウントだとnfsd起動前にマウントしようとした場合にハングアップでも起こすのではないかと心配していたのですが、賢くやってくれているのか問題は無かったです。

07-Aug-2022
[ネットワークブリッジおぼえがき]

QEMU等の仮想マシンをDebian-11.4上で動かし、仮想マシンを実マシンと同様に(NAT越しで繋ぐ形ではなく)ネットワークに参加させる場合はネットワークブリッジを構成する必要があります。Windows上のVMware Playerだとこの辺の設定をGUIでほいほいできてしまいますが、QEMU(というかLinux?)ではARM on QEMU環境でDebianを動かすkvmでTUN/TAPを使いゲストOSをホストOSと同じネットワークに所属させるを参考にして、/etc/network/interfacesをこう書く必要があるようです。


# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto enp4s0
iface enp4s0 inet manual
up ifconfig enp4s0 0.0.0.0 up

auto br0
iface br0 inet dhcp
bridge_ports enp4s0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9
pre-up ip tuntap add dev tap0 mode tap user root
pre-up ip tuntap add dev tap1 mode tap user root
pre-up ip tuntap add dev tap2 mode tap user root
pre-up ip tuntap add dev tap3 mode tap user root
pre-up ip tuntap add dev tap4 mode tap user root
pre-up ip tuntap add dev tap5 mode tap user root
pre-up ip tuntap add dev tap6 mode tap user root
pre-up ip tuntap add dev tap7 mode tap user root
pre-up ip tuntap add dev tap8 mode tap user root
pre-up ip tuntap add dev tap9 mode tap user root
pre-up ip link set tap0 up
pre-up ip link set tap1 up
pre-up ip link set tap2 up
pre-up ip link set tap3 up
pre-up ip link set tap4 up
pre-up ip link set tap5 up
pre-up ip link set tap6 up
pre-up ip link set tap7 up
pre-up ip link set tap8 up
pre-up ip link set tap9 up
post-down ip link set tap9 down
post-down ip link set tap8 down
post-down ip link set tap7 down
post-down ip link set tap6 down
post-down ip link set tap5 down
post-down ip link set tap4 down
post-down ip link set tap3 down
post-down ip link set tap2 down
post-down ip link set tap1 down
post-down ip link set tap0 down
post-down ip tuntap del dev tap9 mode tap
post-down ip tuntap del dev tap8 mode tap
post-down ip tuntap del dev tap7 mode tap
post-down ip tuntap del dev tap6 mode tap
post-down ip tuntap del dev tap5 mode tap
post-down ip tuntap del dev tap4 mode tap
post-down ip tuntap del dev tap3 mode tap
post-down ip tuntap del dev tap2 mode tap
post-down ip tuntap del dev tap1 mode tap
post-down ip tuntap del dev tap0 mode tap

auto enp4s0以降の部分を追加しています(太字にしています)。同時に8つのQEMUを立ち上げることを考えてTAPデバイスを8つ作っていますが、ちょっと作りすぎたかもしれません。

あとはqemu-img create -f qcow2 netbsd.qcow2 120G; sudo qemu-system-x86_64 -enable-kvm -boot d -drive file=netbsd.qcow2,if=virtio -cdrom boot.iso -device virtio-rng-pci -net nic,model=virtio -net tap,ifname=tap0 -m 4096 -rtc base=utc -smp 4 -display cursesとでもしてNetBSD仮想マシンのインストールをしてみました。sudoでroot権限使って動かすのは美しくない気がしますが、動けば良しとします。

インストール後は、sudo qemu-system-x86_64 -enable-kvm -drive file=netbsd.qcow2,if=virtio -device virtio-rng-pci -net nic,model=virtio,macaddr=52:54:00:12:34:00 -net tap,ifname=tap0 -m 4096 -rtc base=utc -smp 4 -display curses(-bootと-cdromの指定を抜いてMACアドレスの指定を入れただけ)で仮想マシンを起動します。長ったらしいので、適当にシェルスクリプトの形にまとめておけば楽できそうです。

複数の仮想マシンを同時に使う場合は、仮想マシン毎にMACアドレスとTAPデバイスを用意しないといけない点に注意が必要です。設定が落ち着いたら、-display none -daemonizeとでもして裏で動かしておけば良いでしょうか。そういえばvirt-manager越しにこの辺りの設定をやる場合、どうやるんですかね…?56.4kg(18:30)

08-Aug-2022補足:NFSを使うことを考慮し、/etc/network/interfacesのiface br0 inet dhcpの行は以下のように書き直し、固定IPアドレスで使うことにします(IPアドレスは適当に記述しています)。/etc/resolv.confの記述も忘れずに。


iface br0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1

11-Aug-2022補足:思っていたよりも仮想マシンの数が増えそうなので、tap8, tap9の定義も追加しました。

12-Aug-2022補足:このように予めTAPデバイスを作っている場合は、QEMUの起動オプションに-net tap,ifname=tapX,script=no,downscript=noを指定して/etc/qemu-if{up,down}の実行を止めておいた方が良さそうです。また、-enable-kvmを指定してQEMUを実行する→QEMUの実行者はgroup kvmに所属していることから、pre-up ip tuntap add dev tapX mode tapのuser rootはgroup kvmに変更することができます。

これらにより、qemu-system-x86_64 -enable-kvm -drive file=netbsd.qcow2,if=virtio -device virtio-rng-pci -net nic,model=virtio,macaddr=52:54:00:12:34:00 -net tap,ifname=tap0,script=no,downscript=no -m 4096 -rtc base=utc -smp 4 -display cursesでroot権限を持たなくても起動可能になり、さらに-display cursesを付けなかった場合におけるCan't open display問題に悩まされることがなくなりました。

25-Dec-2022補足:細かい修正を入れて、こんな感じになりました。tap0〜9だと他の目的で使う名前と当たりそうなので、qtap0〜9としています。