外部記憶装置

脳みそ小さすぎるからメモしとく

R86S レビュー(OpenBSD 編)

R86S レビューシリーズ

前回までのあらすじ

小型謎PCである R86S に Ubuntu 22.10 をインストールし、iperf3 を使ってネットワーク性能を計測した。

OpenBSD

OpenBSDNetBSD からフォークされた 4.4 BSD 由来の UNIX ライクなOSである。

The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. As an example of the effect OpenBSD has, the popular OpenSSH software comes from OpenBSD. (OpenBSD より)

私自身、OpenBSD を始めとする FreeBSDNetBSD には触れたことがほとんどなく、適当なことは書けないため OpenBSD の紹介はここまでとする。

OpenBSD on R86S

R86S では、 OpenBSD は標準ではサポートされていない。 しかし、プロセッサ自体は x86_64 であり、基本的な部分は普通の x86_64 サーバーと変わらないため、起動ぐらいは問題なく行うことができると考えられる。 今回は、OpenBSD 7.2 をインストールし、起動から搭載されている 10G NIC(Mellanox Connect-X3) が動作するかまで検証することにする。

インストールメディアの作成

www.openbsd.org

USBメモリからインストールするため、install.imgamd64版をダウンロードする。

USBメモリへの書き込みは、Rufusを利用した。 公式には対応していないように見えるが、正常に書き込むことができた。

インストール

USBメモリとUSBキーボード、HDMIディスプレイを接続した。 ブート順はUbuntu 22.10のインストール時にUSBメモリ→eMMCの順に変更しているため、 特に設定変更なしにUSBメモリからインストーラーを起動することができた。

RJ45ポートにUTPケーブルを指しておくことで、DHCPIPアドレスを自動で割り当ててくれる。 ホスト名やSSHサーバー、インストール先のディスクレイアウト、利用するミラーサーバー等の設定を行うことで、インストールが進む。 インストール完了後に再起動し、USBメモリを抜去した状態で起動すればローカルディスクからOpenBSDが起動する。

初回ログイン

$ ssh root@192.168.13.118
root@192.168.13.118's password:

OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

r86s-openbsd# uname -a
OpenBSD r86s-openbsd 7.2 GENERIC.MP#758 amd64

必要なパッケージ類のインストール

lspci を使うために、pciutilsパッケージをインストールしておく。

r86s-openbsd# pkg_add pciutils
quirks-6.42 signed on 2023-02-27T17:27:27Z
pciutils-3.6.4: ok

Mellanox ConnectX-3 の確認

r86s-openbsd# lspci
00:00.0 Host bridge: Intel Corporation Device 4e24
00:02.0 VGA compatible controller: Intel Corporation Device 4e61 (rev 01)
00:14.0 USB controller: Intel Corporation Device 4ded (rev 01)
00:14.2 RAM memory: Intel Corporation Device 4def (rev 01)
00:16.0 Communication controller: Intel Corporation Device 4de0 (rev 01)
00:1a.0 SD Host controller: Intel Corporation Device 4dc4 (rev 01)
00:1c.0 PCI bridge: Intel Corporation Device 4db8 (rev 01)
00:1c.1 PCI bridge: Intel Corporation Device 4db9 (rev 01)
00:1c.2 PCI bridge: Intel Corporation Device 4dba (rev 01)
00:1c.4 PCI bridge: Intel Corporation Device 4dbc (rev 01)
00:1f.0 ISA bridge: Intel Corporation Device 4d87 (rev 01)
00:1f.3 Audio device: Intel Corporation Device 4dc8 (rev 01)
00:1f.4 SMBus: Intel Corporation Device 4da3 (rev 01)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device 4da4 (rev 01)
01:00.0 Ethernet controller: Intel Corporation Device 15f3 (rev 03)
02:00.0 Ethernet controller: Intel Corporation Device 15f3 (rev 03)
03:00.0 Ethernet controller: Intel Corporation Device 15f3 (rev 03)
04:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]

PCIバス上のデバイスとしては正しく認識されている。

r86s-openbsd# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
        index 5 priority 0 llprio 3
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        inet 127.0.0.1 netmask 0xff000000
igc0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
        lladdr 00:f0:cb:ef:d9:45
        index 1 priority 0 llprio 3
        groups: egress
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet 192.168.13.118 netmask 0xffffff00 broadcast 192.168.13.255
igc1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:f0:cb:ef:d9:46
        index 2 priority 0 llprio 3
        media: Ethernet autoselect (none)
        status: no carrier
igc2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:f0:cb:ef:d9:47
        index 3 priority 0 llprio 3
        media: Ethernet autoselect (none)
        status: no carrier
enc0: flags=0<>
        index 4 priority 0 llprio 3
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
        index 6 priority 0 llprio 3
        groups: pflog

しかし、NICとしては認識できていないようである。

カーネルのログを確認すると、

r86s-openbsd# dmesg
OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8341798912 (7955MB)
avail mem = 8071569408 (7697MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x74c7a000 (116 entries)
bios0: vendor American Megatrends International, LLC. version "JSP18418" date 09/27/2022
bios0: GoWin Solution R86S
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT TPM2 WSMT FPDT
acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc0000000, bus 0-255
acpihpet0 at acpi0: 19200000 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2793.96 MHz, 06-9c-00
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2793.96 MHz, 06-9c-00
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2793.95 MHz, 06-9c-00
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2793.96 MHz, 06-9c-00
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PC00)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 4 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus -1 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PC00: 0x00000000 0x00000011 0x00000001
"ACPI000E" at acpi0 not configured
"INT34C8" at acpi0 not configured
com4 at acpi0 UAH2 addr 0xfe036000/0x8 irq 34: ns16550a, 16 byte fifo
acpibtn0 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT33A1" at acpi0 not configured
acpibtn1 at acpi0: PWRB
tpm0 at acpi0 TPM_ 2.0 (CRB) addr 0xfed40000/0x5000, device 0x00000000 rev 0x0
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpipwrres0 at acpi0: WRST
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpicpu2 at acpi0: C1(@1 halt!), PSS
acpicpu3 at acpi0: C1(@1 halt!), PSS
acpipwrres1 at acpi0: FN00, resource for FAN0
acpipwrres2 at acpi0: FN01, resource for FAN1
acpipwrres3 at acpi0: FN02, resource for FAN2
acpipwrres4 at acpi0: FN03, resource for FAN3
acpipwrres5 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 119 degC
acpipwrres6 at acpi0: PIN_
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
acpivout1 at acpivideo0: DD2F
cpu0: Enhanced SpeedStep 2793 MHz: speeds: 2001, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
pci0 at mainbus0 bus 0
0:31:5: mem address conflict 0xfe010000/0x1000
pchb0 at pci0 dev 0 function 0 "Intel Jasper Lake Host" rev 0x00
inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics" rev 0x01
drm0 at inteldrm0
inteldrm0: msi, JASPERLAKE, gen 11
xhci0 at pci0 dev 20 function 0 "Intel Jasper Lake xHCI" rev 0x01: msi, xHCI 1.10
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel Jasper Lake Shared SRAM" rev 0x01 at pci0 dev 20 function 2 not configured
"Intel Jasper Lake HECI" rev 0x01 at pci0 dev 22 function 0 not configured
sdhc0 at pci0 dev 26 function 0 "Intel Jasper Lake eMMC" rev 0x01: apic 2 int 16
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
ppb0 at pci0 dev 28 function 0 "Intel Jasper Lake PCIE" rev 0x01: msi
pci1 at ppb0 bus 1
igc0 at pci1 dev 0 function 0 "Intel I225-V" rev 0x03, msix, 4 queues, address 00:f0:cb:ef:d9:45
ppb1 at pci0 dev 28 function 1 "Intel Jasper Lake PCIE" rev 0x01: msi
pci2 at ppb1 bus 2
igc1 at pci2 dev 0 function 0 "Intel I225-V" rev 0x03, msix, 4 queues, address 00:f0:cb:ef:d9:46
ppb2 at pci0 dev 28 function 2 "Intel Jasper Lake PCIE" rev 0x01: msi
pci3 at ppb2 bus 3
igc2 at pci3 dev 0 function 0 "Intel I225-V" rev 0x03, msix, 4 queues, address 00:f0:cb:ef:d9:47
ppb3 at pci0 dev 28 function 4 "Intel Jasper Lake PCIE" rev 0x01: msi
pci4 at ppb3 bus 4
vendor "Mellanox", unknown product 0x1003 (class network subclass ethernet, rev 0x00) at pci4 dev 0 function 0 not configured
pcib0 at pci0 dev 31 function 0 "Intel Jasper Lake eSPI" rev 0x01
azalia0 at pci0 dev 31 function 3 "Intel Jasper Lake HD Audio" rev 0x01: msi
azalia0: no supported codecs
ichiic0 at pci0 dev 31 function 4 "Intel Jasper Lake SMBus" rev 0x01: apic 2 int 16
iic0 at ichiic0
"Intel Jasper Lake SPI" rev 0x01 at pci0 dev 31 function 5 not configured
isa0 at pcib0
isadma0 at isa0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
efifb at mainbus0 not configured
scsibus1 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: <SD/MMC, SCA128, 0000> removable
sd0: 119296MB, 512 bytes/sector, 244318208 sectors
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (5fca080fa3ba5689.a) swap on sd0b dump on sd0b
inteldrm0: 1024x768, 32bpp
wsdisplay0 at inteldrm0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
vendor "Mellanox", unknown product 0x1003 (class network subclass ethernet, rev 0x00) at pci4 dev 0 function 0 not configured

とあり、カーネルが対応するデバイスドライバを持っていないのか、残念ながら認識できていないようである。 Mellanox のNICドライバは、mcx(4) として実装されている。

man.openbsd.org

The mcx driver supports Mellanox 5th generation Ethernet devices. Chipsets and cards in this group include:
- ConnectX-4 Lx EN
- ConnectX-4 EN
- ConnectX-5 EN
- ConnectX-6 EN

ConnectX-4, 5, 6 についてはサポートしているが、ConnextX-3 についてはサポートされていない。 実際に、デバイスドライバソースコードを確認すると、

github.com

static const struct pci_matchid mcx_devices[] = {
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT27700 },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT27700VF },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT27710 },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT27710VF },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT27800 },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT27800VF },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT28800 },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT28800VF },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT28908 },
    { PCI_VENDOR_MELLANOX,  PCI_PRODUCT_MELLANOX_MT2892  },
};

とあり、ConnectX-3 MT27500 は含まれない。 そのため、標準の OpenBSD では R86S に搭載されている ConnectX-3 は利用できない。 ドライバにパッチを当てることで利用できるかもしれない。

まとめ

R86S に OpenBSD 7.2 をインストールし、起動までは確認することができた。 しかし、ConnectX-3 に対応するドライバが存在しないことから、R86S に搭載されている 10G NIC は利用できないことが分かった。 どうしても利用したい場合は、別途ドライバにパッチを当てる必要があり、NIC 独自のオフロード機能の利用等は容易ではないと考えられる。

R86S レビュー(Ubuntu 22.10 編 その2 NAPT他)

R86S レビューシリーズ

前回のあらすじと今回の内容

謎の小型PC、R86S を手に入れ、いろいろ遊んでいる。 前回は iperf3 で L2ブリッジとL3フォワーディングの環境において、iperf3 を用いて性能を計測した。

前回の iperf3 の計測では片方向(クライアント→サーバー)でトラフィックを流して計測していた。 今回はより負荷をかけるために、双方向の全二重でトラフィックを流し、その時の性能を計測した。

L3フォワーディング (双方向)

iperf3 に --bidir オプションを追加し、前回と同様の計測を行った。

forward が クライアント→サーバー、reverse がサーバー→クライアントにあたる。 片方向の場合に比べて、両方向共におおむね8割程度のスループットが出ている。

CPUの使用率はソフトウェア割り込みが2割程度増加している。

各コアへの割り当てについては、張られる2つのTCPセッションをうまくコアごとに分散している場合と、 分散されずに一つのコアに割り込みがかかっている場合がある。 このあたりのコアの割り当てやスケジューラについてはよく知らないが、 ソフトウェア割り込みということはコンテキストスイッチ等が関係しているのだろうか?

NAPT

前回と同様のネットワークで、VLAN B → VLAN A の接続について iptables で NAPT を行う場合について計測した。

iptables -t nat -A POSTROUTING -s [VLAN B のサブネット] -o [VLAN A の IF] -j MASQUERADE

スループットについては、L2ブリッジやL3フォワーディングとほぼ同様の傾向であった。

双方向な場合についても計測したが、L3フォワーディングの場合に比べて、forward と reverse で若干不均衡な結果が得られた。 合計したスループットとしてはほぼ同様であった。

双方向で計測している時のCPU使用率は、L3フォワーディングの時と比べて若干高い結果となった。

ソフトウェア割り込みについてもL3フォワーディングに比べて若干高めの結果が得られた。

まとめ

TCPで通信を行う場合、CPUコアへの割り当て次第ではあるが、9Gbps を超える速度でNAPTが出来ることが分かった。 軽い使い方をする環境(一般家庭等)ならば、10Gbps の環境におけるソフトウェアルーターやNAPTサーバーとして十分に活用できそうである。

ショートパケットが大量に流れる環境や、アプリケーションを動かす場合については今回の計測結果からは何とも言えないため、 TRexのような専用のトラフィックジェネレータを用いて計測する必要がある。(TRexを動かせる物理マシン環境がないため、今回は計測していない)

次回以降は pfSense や OpenBSD を動かしてみることにする。

R86S レビュー (Ubuntu 22.10 編 その1)

R86S レビューシリーズ

謎の小型PC、R86S を購入し、簡単な計測を行った時の記録

R86S について

R86S は aliexpress で販売されている謎の小型PCである。 SFP+ が2個と 2.5Gbps Ethernet(RJ-45) が3個搭載されていることが最大の特徴となっている。

docs.r86s.net

購入はここから。

R86S Soft Routing Multi net port, Intel mini host N5105 8GB/16GB 10 Gigabit fiber port 2.5G| | - AliExpress

購入したモデルは GW-R86S-G1 である。 CPU Intel Celeron N5105(4Core/4Thread)、メモリ 8GB、NICIntel I225(2.5Gbps x 3) と Mellanox ConnectX-3 (SFP+ x 2) が搭載されている。

OSは基本的に最新の WindowsUbuntu であれば問題なくサポートされている様子(R86S Document より)

バイスに関する詳細なレビューは yas-nyan 氏のレビューが分かりやすいため、ここでは省略する。

zenn.dev

ネットワーク処理性能の計測

R86S を高速ルーターや高速パケット処理のおもちゃとして利用するにあたり、 バニラな Ubuntu 22.10 をインストールした環境で iperf3 を用いた計測を行った。 なお、計測は SFP+x2 な部分についてのみ行った。

計測環境

計測用のネットワークはこのようになっている。MTU は全体で 9000 とした。

物理マシンと接続された10Gスイッチが10GBASE-Tしか刺さらないため、メディコン代わりに別の10Gスイッチを介して接続している。 当初は 10GBASE-T SFP+モジュールを用いる予定であったが、購入したモジュール が R86S でリンクを上げることが出来なかったため、このような構成となっている。

計測は iperf3 を用いた。

iperf3 -c 192.168.14.2 -i 0 -O 5 -M [MSS] -t 120

R86S

  • モデル: GW-R86S-G1
  • OS: Ubuntu 22.10 (Kernel: 5.19.0-31-generic)

負荷生成用マシン(仮想マシン)

2台の物理マシン上に1台ずつ負荷生成用のマシンとして仮想マシンを用意した。 vCPU の pinning やそのほかのチューニングは行わず、QEMU/libvirt の標準設定で作成した。 専用の物理マシンやパケットジェネレータを利用したわけではないため、パケットサイズが小さい場合は不正確な測定結果となっている可能性がある。

  • CPU: 4コア
  • メモリ: 8GB
  • OS: Ubuntu 22.10 (Kernel: 5.19.0-31-generic)
  • テスト用NIC: virtio

L2 フォワーディング(bridge)

10G NIC 間を bridge で接続した場合について計測した。

  bridges:
    br0:
      mtu: 9000
      interfaces:
      - enp4s0
      - enp4s0d1

計測結果は以下のとおりである。MSS が 1000bytesを超えたあたりから 9Gbps を超えている。

L3 フォワーディング(routing)

10G NIC 間で静的ルーティングを行った場合について計測した。 おおむね、L2 フォワーディングの時とほぼ同様な傾向であることが分かる。

CPU の負荷

L3 フォワーディングの計測を行っている間のCPU使用率を mpstat で計測した。 MSS を 80, 216, 472, 984, 1240, 1478, 3960, 7960, 8960 と2分ずつ計測した時のCPU使用率(全コア合算)のグラフが下図である。

MSS が大きくなるにつれて、soft(ソフトウェア割り込み) の割合が下がっていることが分かる。 しかし、MSS が 3960 以上となるとまたソフトウェア割り込みが増加している。

各コアのソフトウェア割り込みの割合についても計測した。

iperf3 では計測毎に接続を貼りなおすため、計測ごとに割り込みがかかっているコアが違っていることが分かる。 MSS が小さい場合、1つのコアがソフトウェア割り込みによってほぼ使い果たされている。 MSSが1500に近づくにつれてその割合は減るものの、MSSが1500を超えると、ソフトウェア割り込みの割合が 50%前後を遷移している。 詳細な原因は分からないため、今後調べることにする。

まとめ

R86S で iperf3 を用いて簡易的なネットワーク処理性能の計測を行った。 MSS が 1000 bytes を超えるような場合において、約 9Gbps 以上でパケットフォワーディングができた。 簡易的な高速ルーターやパケットキャプチャデバイスとしては十分に利用できそうなデバイスであると思う。

2022年を1月からふりかえる

1月

専攻の中間発表があった。 中間発表後は競技プログラミングにはまっていた。

2月

NTT研究所(ソフトウェアイノベーションセンタ)のインターン「コンテナランタイムの実装と評価」に参加した。 Rootless コンテナの通信速度を大幅に改善するbypass4netnsに取り組み、 2週間の期間中にnerdctlへのマージまでたどり着いた。 とても刺激的な楽しい期間だった。(関係者の皆様、大変お世話になりました。)

国際会議のワークショップの発表に使う動画の提出もした。

3月

セキュリティキャンプ全国大会2021-L3トラックでの成果について、情報処理学会第84回全国大会で「完全準同型暗号における BNN を用いた高速な秘匿推論手法の実装と評価」を受講生の方が発表した。 受講生の方が行った発表のクオリティも高く、学生奨励賞も受賞された。(凄い!)

セキュリティキャンプフォーラムで、未踏事業での取り組み「VSP(Virtual Secure Platform)」やセキュリティキャンプとのかかわりについて発表した。

国際会議(PerCom)のワークショップ(PerFlow)で発表をしたが、英語力がなさ過ぎて質疑が全然できなかった。 [

[

大学の博士課程学生向けのフェローシップ制度に申請書を出した。

4月

実験のTAが忙しかった気がする。 卒論でやってたことを論文としてまとめ、投稿した。

クソコラ画像を作った。

Ubuntu 22.04 がリリースされ、MPTCPで遊んだりしてた。

5月

実験のTAが忙しかった気がする。

Nintendo Switch を買った。10月にNintendo SwitchFactorioが発売されるまで使わなかった。

学振DC1の申請書を提出した。

6月

ShowNetのSTMをやってた。

ShowNetの期間と国内研究会の原稿締切が重なったため、セルフデスマーチをやってた。

大学の博士課程入試の願書を出した。

7月

あまり記憶がない。 色々重なって大変なことになってた気がする。

GPUを買ってたらしい。

時雨堂さんのQUIC/TLS1.3をZigで実装するお仕事に応募したり、ISUCONに参加したりしてた。

SWoPP2022(2022年並列/分散/協調処理に関するサマー・ワークショップ)で2月のインターン成果(bypass4netns)をまとめた発表をした。「優秀若手発表賞」を受賞した。(大変光栄です)

8月

博士課程の入試を受験し、無事合格した。

@ushitora_anqou さんが書いた論文の発表に、付き人として一緒にイスラエルに行った。

tls13-zigの開発をしてた。

論文の査読結果が届き、追加実験をしたり文章を書き換えたりしてた。

9月

tls13-zigの開発とか論文を書いてた。

TAをやったり、計算機をUbuntu 22.04にアップグレードする作業とかも頑張ったらしい。 「情報科学若手の会」に参加した。

DC1の内定通知が届いた。

10月

研究をしてた。 計算機をいっぱい買ったらしい。

11月

研究発表をするために初北陸、初新潟な出張をした。

お土産の日本酒を自宅の最寄り駅で割ってしまい泣いた。

修論の予備審査があった。

12月

研究のサーベイしたり実装をしたりしてた。 国内研究会の原稿を書いて提出した。

zig の標準ライブラリに tls1.3の実装が入るらしい。 自分の開発した tls13-zig が参考にされてて嬉しくなった。 rsa署名回りについて、tls13-zigのコードが一時的に利用されてる。

酔っぱらってスマホを電車で落とした。(次の日に忘れ物センターで無事回収した。) 2021年末にもスマホをなくしてた気がする...

総括

研究

あれこれやっていたため、研究に対して真摯に時間をかけて取り組めていたとは言い切れない1年であった。来年度以降は博士課程に進学するため、その自覚を持って取り組みたい。 国内で発表してそのままになっている成果があるため、国際会議に投稿したい。

技術

2月のbypass4netns、8月のtls13-zigなど、とても刺激的な1年であった。 zigについてはissueを建てたりPRを出してマージされたりした。 bypass4netnsを含むコンテナ周りや、tls13-zigを含むzig周りについて、今後も引き続き取り組んでいきたい。

私生活

わりと無理をして帳尻を合わせることが多く、反動で虚無になっていることが多かった気がする。 規則正しい生活を心掛けていきたい。

MPTCP を触ってみる(Ubuntu 22.04 LTS)

概要

Ubuntu 22.04 LTS (Linux Kernel 5.15) がリリースされ、通常用途のサーバーでも Linux Kernel 5.6 で実装された MPTCP の利用が容易になった。 せっかくなので、3つのシナリオで MPTCP を用いたアプリケーションを動かし、その動作の様子を観察した。 (※通学に利用している電車のWiFiが不安定で何とかしたいという理由もある)

MPTCP について

datatracker.ietf.org www.multipath-tcp.org Multipath TCPは複数パスを用いてコネクションを張ることで、TCPスループットや通信品質を改善することを目的としている。 利用用途としては、モバイル回線と固定回線の併用や複数のモバイル回線の併用といった、通信が不安定になりがちな回線におけるTCPの品質改善に利用されることを想定しているようだ。

MPTCP の使い方

MPTCP を利用するには、 socket(2)IPPROT_MPTCP フラグを指定してソケットを作成する必要がある。

int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);

そのため、既存のアプリケーションでは、socket(2) の引数を適切に書き換える必要がある。 RedHat では、既存のアプリケーションをMPTCPに対応させるために、SystemTapを用いた方法を説明している。

access.redhat.com

SystemTap を用いる方法は少し面倒なので、 今回は、 SystemTap を利用する代わりにTCPプロキシで通常のTCPの接続をMPTCPに中継する方法を取った。

MPTCP-Proxy

TCP の接続を終端し、MPTCPで接続を張り中継するだけなので、Go言語で簡易的に実装した。 (すでに既存実装があるような気がするが、探すのも面倒だったので)

github.com

動作としては、単純なTCPのプロキシである。 mode = "client" では、TCP -> MPTCP の中継を行い、mode = "server" では、 MPTCP -> TCP の中継を行う。

実験環境

Docker と docker-compose を用いて実験環境を用意した。 ホストは Ubuntu 22.04 LTS で、以下の設定となっている。

$ sudo sysctl -a | grep mptcp
net.ipv4.tcp_available_ulp = espintcp mptcp tls
net.mptcp.add_addr_timeout = 120
net.mptcp.allow_join_initial_addr_port = 1
net.mptcp.checksum_enabled = 0
net.mptcp.enabled = 1
net.mptcp.stale_loss_cnt = 4

$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

実験にあたり、以下の資料を参考にした。

access.redhat.com

実験1(単純な2パス)

図のような環境で様子を観察した。本実験はMPTCP-Proxytest/simpleにあるスクリプト一式で行った。

$ cd test/simple
$ docker-compose up -d

で動かすことができる。

MPTCP 関連の設定

クライアント側

クライアント側では、MPTCP-Proxy5555/tcpTCP接続を待ち受け、10.123.200.2:4444 へMPTCPで接続する。

$ mptcp-proxy -m client -p 5555 -r 10.123.200.2:4444

MPTCP関連の設定として、サブフローを1つまで受け入れる設定をしている。

$ ip mptcp limits set subflow 1 add_addr_accepted 1

サーバー側

サーバー側では iperf3 が接続を待ち受け、 MPTCP-Proxy4444/tcp でMPTCP接続を待ち受け、localhost:5201TCPで接続する。

$ iperf3 -s &
$ mptcp-proxy -m server -p 4444 -r localhost:5201

MPTCP関連の設定として、サブフローを1つまで受け入れる設定をしている。 また、10.123.201.2(eth1) をMPTCPのエンドポイントとして利用する設定も行っている。

$ ip mptcp limits set subflow 1
$ ip mptcp endpoint add 10.123.201.2 dev eth1 signal

実験

iproute2 でMPTCPの接続状況を監視することができる。

$ docker-compose exec client ip mptcp monitor

別コンソールで iperf3 を動作させる。

$ docker-compose exec client iperf3 -c localhost -p 5555
Connecting to host localhost, port 5555
[  5] local 127.0.0.1 port 35948 connected to 127.0.0.1 port 5555
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.10 GBytes  9.46 Gbits/sec    0   1.37 MBytes       
[  5]   1.00-2.00   sec  1.10 GBytes  9.43 Gbits/sec    0   1.37 MBytes       

mptcp monitor を用いた動作状況の確認

iproute2 mptcp monitor でも接続状況が反映される。

$ docker-compose exec client ip mptcp monitor
[       CREATED] token=c53b6fd4 remid=0 locid=0 saddr4=10.123.200.3 daddr4=10.123.200.2 sport=53360 dport=4444
[   ESTABLISHED] token=c53b6fd4 remid=0 locid=0 saddr4=10.123.200.3 daddr4=10.123.200.2 sport=53360 dport=4444
[     ANNOUNCED] token=c53b6fd4 remid=1 daddr4=10.123.201.2 dport=0
[SF_ESTABLISHED] token=c53b6fd4 remid=1 locid=0 saddr4=10.123.201.3 daddr4=10.123.201.2 sport=39957 dport=4444 backup=0
[       CREATED] token=c03b1893 remid=0 locid=0 saddr4=10.123.200.3 daddr4=10.123.200.2 sport=53362 dport=4444
[   ESTABLISHED] token=c03b1893 remid=0 locid=0 saddr4=10.123.200.3 daddr4=10.123.200.2 sport=53362 dport=4444
[     ANNOUNCED] token=c03b1893 remid=1 daddr4=10.123.201.2 dport=0
[SF_ESTABLISHED] token=c03b1893 remid=1 locid=0 saddr4=10.123.201.3 daddr4=10.123.201.2 sport=33487 dport=4444 backup=0

主フロー(Master flow) が 10.123.200.3 <-> 10.123.200.2 間で確立されている。 サーバー側から 10.123.201.2 へMPTCPによる接続が可能である通知が行われると、10.123.201.3 <-> 10.123.201.2 間でサブフロー(Sub flow) の接続が確立されていることが分かる。

クライアント(10.123.200.3/24, eth0) でのパケットキャプチャ

3-way handshake が MPTCP Multipath Capable フラグ付きで行われていることが分かる。

3-way handshake 直後に、サーバーから MPTCP Add Address オプションにより、 10.123.201.2 へのMPTCP接続をクライアントに対して通知していることが分かる。

クライアント(10.123.201.3/24, eth1) でのパケットキャプチャ

クライアント側のルーティングテーブルに従い、 10.123.201.2への接続は10.123.201.3/24のアドレスが割り当てられてインタフェース(ここではeth1)が利用される。 クライアント側から、10.123.201.2MPTCP Join Connection オプション付きで 3-way handshake が行われていることが分かる。

実験2(クライアントがシングルホーム)

図のような環境で様子を観察した。本実験はMPTCP-Proxytest/routingにあるスクリプト一式で行った。

$ cd test/routing
$ docker-compose up -d

で動かすことができる。

MPTCP 関連の設定

実験1 と同じである。

ルーティング

スタティックルーティングの設定を行っている。

クライアント側

ip route add 10.123.200.0/24 via 10.123.202.2
ip route add 10.123.201.0/24 via 10.123.202.2

サーバー側

ip route add 10.123.202.0/24 nexthop via 10.123.200.3 weight 1 nexthop via 10.123.201.3 weight 1

サーバー側については、ECMP(Equal Cost Multipath)で設定を行っている。 本来は、ip rule でエンドポイントのアドレスが割り当てられたインタフェースからパケットが送信されるように設定すべきな気がしている。

実験

実験1と同様の手順で実験を行った。

mptcp monitor を用いた動作状況の確認

iproute2 mptcp monitor でも接続状況が反映される。

$ docker-compose exec client ip mptcp monitor
[       CREATED] token=67e9a281 remid=0 locid=0 saddr4=10.123.202.3 daddr4=10.123.200.2 sport=46050 dport=4444
[   ESTABLISHED] token=67e9a281 remid=0 locid=0 saddr4=10.123.202.3 daddr4=10.123.200.2 sport=46050 dport=4444
[     ANNOUNCED] token=67e9a281 remid=1 daddr4=10.123.201.2 dport=0
[SF_ESTABLISHED] token=67e9a281 remid=1 locid=0 saddr4=10.123.202.3 daddr4=10.123.201.2 sport=47341 dport=4444 backup=0
[       CREATED] token=ab7a4b72 remid=0 locid=0 saddr4=10.123.202.3 daddr4=10.123.200.2 sport=46052 dport=4444
[   ESTABLISHED] token=ab7a4b72 remid=0 locid=0 saddr4=10.123.202.3 daddr4=10.123.200.2 sport=46052 dport=4444
[     ANNOUNCED] token=ab7a4b72 remid=1 daddr4=10.123.201.2 dport=0
[SF_ESTABLISHED] token=ab7a4b72 remid=1 locid=0 saddr4=10.123.202.3 daddr4=10.123.201.2 sport=59891 dport=4444 backup=0

主フロー(Master flow) が 10.123.202.3 <-> 10.123.200.2 間で確立されている。 サーバー側から 10.123.201.2 へMPTCPによる接続が可能である通知が行われると、10.123.202.3 <-> 10.123.201.2 間でサブフロー(Sub flow) の接続が確立されていることが分かる。

サーバー(10.123.200.2/24, eth0) でのパケットキャプチャ

3-way handshake 直後に、サーバーから MPTCP Add Address オプションにより、 10.123.201.2 へのMPTCP接続をクライアントに対して通知していることが分かる。 また、クライアント(10.123.202.3) <-> サーバー(10.123.200.2) の通信のみが行われていることが分かる。

サーバー(10.123.201.2/24, eth1) でのパケットキャプチャ

クライアント側から、10.123.201.2MPTCP Join Connection オプション付きで 3-way handshake が行われていることが分かる。 また、クライアント(10.123.202.3) <-> サーバー(10.123.201.2) の通信のみが行われていることが分かる。 LinuxのECMPにおいて送信元アドレスがどのような挙動(必ずアドレスが割り当てられたインタフェースから送信されるか)を示すかはさらなる調査が必要ではあるものの、2つのインタフェースに分配して通信が行われていることが分かる。

実験3(サーバーがシングルホーム)

図のような環境で様子を観察した。本実験はMPTCP-Proxytest/routing2にあるスクリプト一式で行った。

$ cd test/routing2
$ docker-compose up -d

で動かすことができる。

MPTCP 関連の設定

クライアント側

ip mptcp limits set subflow 1 add_addr_accepted 1
ip mptcp endpoint add 10.123.202.3 dev eth1 subflow

クライアント側からMPTCP subflow の接続を行う設定を行っている。

サーバー側

ip mptcp limits set subflow 1

ルーティング

スタティックルーティングの設定を行っている。

クライアント側

ip route add 10.123.200.0/24 via 10.123.201.2 src 10.123.201.3 metric 10
ip route add 10.123.200.0/24 via 10.123.202.2 src 10.123.202.3 metric 11

送信元アドレスが割り当てられたインタフェースから送信されるように経路を設定している。

ip rule で設定していたところ、クライアントのルーティングは利用できない様子?

サーバー側

ip route add 10.123.201.0/24 via 10.123.200.3
ip route add 10.123.202.0/24 via 10.123.200.3

実験

実験1と同様の手順で実験を行った。

mptcp monitor を用いた動作状況の確認

iproute2 mptcp monitor でも接続状況が反映される。

$ docker-compose exec client ip mptcp monitor
[       CREATED] token=e24736a9 remid=0 locid=0 saddr4=10.123.201.3 daddr4=10.123.200.2 sport=45618 dport=4444
[   ESTABLISHED] token=e24736a9 remid=0 locid=0 saddr4=10.123.201.3 daddr4=10.123.200.2 sport=45618 dport=4444
[SF_ESTABLISHED] token=e24736a9 remid=0 locid=1 saddr4=10.123.202.3 daddr4=10.123.200.2 sport=56857 dport=4444 backup=0 ifindex=533
[       CREATED] token=4d43f0e6 remid=0 locid=0 saddr4=10.123.201.3 daddr4=10.123.200.2 sport=45620 dport=4444
[   ESTABLISHED] token=4d43f0e6 remid=0 locid=0 saddr4=10.123.201.3 daddr4=10.123.200.2 sport=45620 dport=4444
[SF_ESTABLISHED] token=4d43f0e6 remid=0 locid=1 saddr4=10.123.202.3 daddr4=10.123.200.2 sport=45035 dport=4444 backup=0 ifindex=533

主フロー(Master flow) が 10.123.201.3 <-> 10.123.200.2 間で確立されている。 その後、10.123.202.3 <-> 10.123.200.2 間でサブフロー(Sub flow) の接続が確立されていることが分かる。

クライアント(10.123.201.3/24, eth0) でのパケットキャプチャ

3-way handshake が行われた後、サーバー、クライアント互いに新しいサブフローを張るために必要な情報を交換している様子は観察できなかった。 RFC8684 を読んだところ、2.2. Associating a New Subflow with an Existing MPTCP Connection に従っていそう。 通信はクライアント(10.123.201.3) <-> サーバー(10.123.200.2) の通信のみが行われていることが分かる。

クライアント(10.123.202.3/24, eth1) でのパケットキャプチャ

クライアントから MPTCP Join Connection オプション付きで 3-way handshake が行われていることが分かる。 また、クライアント(10.123.202.3) <-> サーバー(10.123.200.2) の通信のみが行われていることが分かる。

まとめ

3つのシナリオを取り上げて MPTCP の通信の様子を観察し、 通信がそれぞれのパスを利用して行われていることは確認できた。 実際に、4G(5G) と WiFi といった組み合わせの場合や、サブフローごとの重みの設定といった細かい制御が出来ると利用用途が広がりそうである。

P.S. Linux のルーティングよく分からん。

2021年を400文字で振り返る

2021年もあと数時間で終わるから今年やったことを400文字にまとめる。

卒論

1月に卒論を提出して無事卒業できた。 外部の研究会発表の締め切りと卒論の締め切りが1週間の中に同居してて大変だった。

学会発表

3月にIA研究会、6月にDICOMO 2021 シンポジウムで発表した。 DICOMOのナイトテクニカルセッションですべったのはいい思い出。 期末試験、レポートが重なる期間中に国際会議に出した論文が reject されてへこんだ。

セキュリティキャンプ

セキュリティキャンプ全国大会2021オンラインでL-III「準同型暗号アプリケーション開発ゼミ 」の講師をさせていただいた。 初めての講師で大変なことばかりだったが、とてもいい経験になった。

その他

1年を通して体重が増えた。来年は国際会議に論文通して海外に行きたい。

Android 12 で EAP-TLS の認証ができないときの対処方法

結論: 証明書の再インストール

大学に設置されている無線APではクライアント証明書による EAP-TLS 認証を利用しているが、 Android 12 にアップデートした Pixel 3a では認証できなくなったため問題を調査した。

状況

  • Android 12 にアップグレードした Pixel 3a で Wi-FiEAP-TLS 認証ができない
  • Android 11 の端末や新しく証明書をインストールした場合は認証が通る

Android のバージョン情報

f:id:PiBVT:20211112152418p:plain

問題調査

ADB shell 経由 logcat | grep wpa_supplicant で認証失敗時の wpa_supplicant のログを吸い上げた。

11-12 14:24:25.867   766   766 I wpa_supplicant: wlan0: Associated with (対象APのBSSID)
11-12 14:24:25.867   766   766 I wpa_supplicant: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
11-12 14:24:25.868   766   766 I wpa_supplicant: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
11-12 14:24:25.882   766   766 I wpa_supplicant: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
11-12 14:24:25.883   766   766 I wpa_supplicant: tls_connection_set_params: Clearing pending SSL error: error:0c00009e:ASN.1 encoding routines:OPENSSL_internal:NESTED_ASN1_ERROR
11-12 14:24:25.884   766   766 W wpa_supplicant: EVP_PKEY_from_keystore2:347 Keystore backend used with legacy alias prefix - ignoring.
11-12 14:24:25.886   766   766 E wpa_supplicant: EVP_PKEY_from_keystore2:389 Failed to parse x509 certificate.
11-12 14:24:25.886   766   766 E wpa_supplicant: ENGINE: cannot load private key with id 'USRPKEY_(証明書の名前)' [error:0c0000be:ASN.1 encoding routines:OPENSSL_internal:WRONG_TAG]
11-12 14:24:25.886   766   766 I wpa_supplicant: TLS: Failed to initialize engine
11-12 14:24:25.886   766   766 I wpa_supplicant: TLS: Failed to set TLS connection parameters, error code: -2
11-12 14:24:25.886   766   766 I wpa_supplicant: EAP-TLS: Failed to initialize SSL.
11-12 14:24:25.887   766   766 I wpa_supplicant: wlan0: CTRL-REQ-PIN-0:PIN needed for SSID (対象APのSSID)
11-12 14:24:25.887   766   766 I wpa_supplicant: wlan0: EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS)

まず NESTED_ASN1_ERROR について調査したが情報が見つからなかったのでスルーした。

次に、EVP_PKEY_from_keystore2:389 Failed to parse x509 certificate. について調査したところ、Android 12 で導入された keystore2 のコミットログにそのような文字列が見つかった。

android.googlesource.com

f:id:PiBVT:20211112151802p:plain

コミットログを見たところ、

Keystore 2.0 engine: Handle legacy PEM certificates.

Keystore 2.0 in Android S requires all new certificates to be stored in
DER format, however, when upgrading from R or older, there may be
certificates stored in PEM format. This patch allows keystore2-engine to
extract the public keys from certificates in either format.

とあることから、Android 12 では証明書を管理するフォーマットが変わっており、このコミットで古いフォーマットについてもハンドルするようにしたことがわかる。 しかし、手元の端末では該当コミットで削除された Failed to parse x509 certificate. が出力されていることや、システムアップデートの日時以降のコミットであることから、 現在の Android 12 では この該当コミットが取り込まれていない可能性がある。

対応

古いフォーマットの証明書が読めていない可能性が高いため、再インストールすれば問題は解決するはずである。 結果、証明書を一度削除してから再インストールしたところ、無事接続に成功するようになった。