やりたかったこと

Nextcloudを動かしているラズパイのLANインタフェースでジャンボフレームを有効化したかった。

環境

ハードウェア:　RaspberryPi 4B+
OS: RaspberryPi OS (Debian GNU/Linux 11)(bullseye)
有線LANアダプタ: バッファロー　LUA5-U3-AGTE-NBK

前提条件

RaspberryPi OSの制約なのか、ハードウェアの制約なのかはよく分からなかったのですが、内蔵のLANポートでジャンボフレームを有効化しようとするとカーネルの再コンパイルが必要とのこと。面倒そうだったのでデバイスを買いました。また、このデバイスは挿しただけではジャンボフレームを利用できないようです。バッファローからはLinux対応ドライバは提供されていないので、チップメーカーのドライバを導入することにします。

作業内容

使われているチップを調べる

~ $ lsusb

Bus 002 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub'

ASIX社のAX88179というチップを使っていることが分かったので、ダウンロードします。

tar -jxf ASIX_USB_NIC_Linux_Driver_Source_v3.5.0.tar.bz2

ちゃんとReadmeファイルを読んでおきます（戒め）

less Readme

カーネルヘッダをインストールしておきます

sudo apt update
sudo apt install raspberrypi-kernel-headers

確認しておきます（ちゃんと存在してればヨシ）

ls -l /lib/modules/$(uname -r)/build

ビルド＆インストールします

cd ~/ASIX_USB_NIC_Linux_Driver_Source_v3.5.0
make
sudo make install

Warning: modules_install: missing 'System.map' file. Skipping depmod.

というエラーが出ていますが、気にしなくて大丈夫らしいです。

再起動します

sudo reboot

ジャンボフレームの動作確認

ip a

4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 84:e8:cb:7e:d1:f5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.7/24 brd 192.168.0.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 2405:1200:5283:c100:86e8:cbff:fe7e:d1f5/64 scope global dynamic mngtmpaddr
       valid_lft 86375sec preferred_lft 14375sec
    inet6 fe80::86e8:cbff:fe7e:d1f5/64 scope link
       valid_lft forever preferred_lft forever

でデバイスが認識されていたら、仮設定を行います。

sudo ip link set dev eth1 mtu 9000

ハマりポイント

当初、別のUSB-有線LANデバイス（PLANEX社製:廃番品）がeth1で、このデバイスはeth2の状態でドライバをインストールしたらうまく動作したのですが、このPLANEXのほうを抜去して別のラズパイに移設してeth2がeth1に変わった際、MTUを9kに設定できなくなりました。

このデバイスをeth1にした状態でドライバを再度インストールしたらちゃんと変更できました。実使用の環境でドライバをインストールしてあげないとダメなようです。

どハマりポイント

最初、

eth0 -> 192.168.0.6

eth1 -> 192.168.0.7

としていたのですが、

ping -f -l 8972 192.168.0.7

○応答あり　ヨシ！

ping -f -l 8973 192.168.0.7

○応答あり　え？

おかしい。断片化してるのか？？
ということでいろいろ調べてみていった。

tcpdumpでICMPの着信を調べてみたら

admin@NCLOCAL:~ $ sudo tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:49:20.103894 IP 192.168.0.74 > 192.168.0.6: ICMP echo request, id 1, seq 55, length 1486
18:49:20.104003 IP 192.168.0.6 > 192.168.0.74: ICMP echo reply, id 1, seq 55, length 1480
18:49:20.104069 IP 192.168.0.6 > 192.168.0.74: icmp
18:49:21.106791 IP 192.168.0.74 > 192.168.0.6: ICMP echo request, id 1, seq 56, length 1486
18:49:21.106909 IP 192.168.0.6 > 192.168.0.74: ICMP echo reply, id 1, seq 56, length 1480
18:49:21.106936 IP 192.168.0.6 > 192.168.0.74: icmp
18:49:22.110236 IP 192.168.0.74 > 192.168.0.6: ICMP echo request, id 1, seq 57, length 1486
18:49:22.110350 IP 192.168.0.6 > 192.168.0.74: ICMP echo reply, id 1, seq 57, length 1480
18:49:22.110379 IP 192.168.0.6 > 192.168.0.74: icmp
18:49:23.118102 IP 192.168.0.74 > 192.168.0.6: ICMP echo request, id 1, seq 58, length 1486
18:49:23.118214 IP 192.168.0.6 > 192.168.0.74: ICMP echo reply, id 1, seq 58, length 1480
18:49:23.118242 IP 192.168.0.6 > 192.168.0.74: icmp

なのに、

admin@NCLOCAL:~ $ sudo tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

となる。あれえええ？

原因究明

●標準設定ではIPアドレス単位でなくノード全体でARP解決を行うから　←結論

eth1に対するARP要求にeth0のMACアドレスが応答してしまう可能性があると判明。

いろいろ出てきましたが、面倒なのでeth0(.6)側のLANケーブルをぶち抜きます。

再度pingを打ってみます

PS C:\Users\kenji> ping -f -l 8972 192.168.0.7

192.168.0.7 に ping を送信しています 8972 バイトのデータ:
192.168.0.7 からの応答: バイト数 =8972 時間 =1ms TTL=64
192.168.0.7 からの応答: バイト数 =8972 時間 =1ms TTL=64
192.168.0.7 からの応答: バイト数 =8972 時間 =1ms TTL=64
192.168.0.7 からの応答: バイト数 =8972 時間 =1ms TTL=64

192.168.0.7 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 1ms、最大 = 1ms、平均 = 1ms
PS C:\Users\kenji> ping -f -l 8973 192.168.0.7

192.168.0.7 に ping を送信しています 8973 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。

192.168.0.7 の ping 統計:
    パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、

通りました。
8972バイトで応答が返りますのでヨシ。

注：ICMPヘッダは8バイトなので、IPヘッダ(20バイト）+ICMPヘッダ（8バイト）で28バイトぶん減じています。

正式にはarp_filterとかrp_filterを使うみたいです。
当面、eth0は使用しないのでこのままでいいやということにします。

課題

/etc/dhcpcd.conf で、MTUを設定できない（原因調査中）ので、

 sudo ip link set dev eth0 mtu 9000

と手動で実行しているので、今後はこれを自動化したい。

終わりに

[参考文献]

bobuhiro11's blog 様　「LUA4-U3-AGTE-NBK ドライバのインストール
 Qiita株式会社　様　「Markdown記法チートシート」

[技術協力]

・ChatGPT 4o
・テレワーク中（修羅場）の嫁氏