SVX日記

　 あづくて、作業ができん。ブレッドボードを出したところで力尽きる。

　 とりあえず

　 一般に、ガキは電車が好きである。ウチのガキも、例に漏れず大好きである。最近は、バスとデコトラに傾倒していたが、ここにきてかなり電車が盛り返してきた。その原因がコレ。「電車でD」の同人ゲームのプロモーション映像だ。

　 実際、オイラの目にも、超絶的なクオリティに見える。ゲームのデキは触ってみなくてはわからないが、映像で見る限り、テーマソングは入っているわ、セリフは入っているわ、悪ノリのレベルはかなり高い。

　 ガキには、専用にLinuxのノートPCを渡してあるのだが、その中にプロモーション映像を置いてやったところ、毎日のように「いっぽんしょうぶ、みるぅ」などいいながら、幾度となく観ては、テーマソングもセリフもすっかり覚えてしまった。

　 「啓介が負けたぞぉ、拓海が勝ったぁ」だの「あの2000系はオレが倒す」だの、先日などはボタンに手をかけて「カウント始めっぞぉ、5……」などとやりはじめる始末。

　 最近、帰宅すると、プラレールの車両が「なぜかゴム車輪が外れた状態で」床に転がっているのを不思議に思っていたのだが、どうも手ころがしで複線ドリフトをやりまくっているせいらしい。

　 同時期に、中古のPS2のゲーム「鉄1グランプリ」を与えたら、それもかなりガンバっている。そして、めざとく「阪急」を見つけてお気に入り車両にしている。阪急は「電車でD」の主人公の車両だ。

　 うーむ、こういうのも「英才教育」なんだろうか。かなり間違っている気もするが、オイラもそうやって好きなことだけやって生きてきたしな。これでいいのだ。

　 というわけで、Raspbianでなくpidoraで、同じようにブリッジを形成することにした。

　 それはそれとして、そのうち無線LANアクセスポイント自体をラズベリーパイで構築してみようと、先行して注文しておいたWN-AC433UAが届いたので、早速装着してみたところ……あかーん! スケベ心で先を見据えて802.11ac対応を選んだのが裏目った。新しすぎてドライバが入ってないではないか。

　 最近のLinuxのコネクティビティの良さに油断しとったわ。どうやらアウトボックスのドライバは既にあるようだが、今はそこに時間を掛けたくないので。サクッとタイムカプセル処分とする。ちなみに、ひとつ前のWN-G300UAはイケるようだ。最初から、値段も消費電力も優しいコッチにしておけばよかったワイ。

　 ひと通りガックリしたところで、ブリッジの形成に戻る。pidoraはFedora系なので、ネットワーク系の設定ファイルの場所が、/etc/networkの下ではなく、/etc/sysconfig/network-scriptsの下になる。と、そんなことより、基本的にはNetworkManagerを使うべきなので、場所がどうこうよりは、nmcliコマンドを駆使することの方が重要だ。

　 まずは、アクセスポイントのスキャン。

[root@xxxpi ~]# nmcli device wifi list ifname wlan0
*  SSID             MODE   CHAN  RATE       SIGNAL  BARS  SECURITY  
   <ESSID1>         Infra  1     44 Mbit/s  52      ▂▄__  WPA1 WPA2 
   <ESSID2>         Infra  1     16 Mbit/s  43      ▂▄__  WPA1 WPA2 
   <ESSID3>         Infra  7     54 Mbit/s  23      ▂___  WEP       
   <ESSID4>         Infra  1     54 Mbit/s  46      ▂▄__  WEP       

　 必要なら以下で再スキャンできる。

[root@xxxpi ~]# nmcli device wifi rescan ifname wlan0

　 アクセスポイントに接続するにはこう。

[root@xxxpi ~]# nmcli device wifi connect "<ESSID>" password "<KEY>" ifname wlan0

　 無線接続が有効になったことは、以下のように確かめられる。

[root@xxxpi ~]# iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"xxxxxxxxxxxx"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.412 GHz  Access Point: AA:BB:CC:DD:EE:F0   
          Bit Rate:300 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=74/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

　 これをやると、/etc/sysconfig/network-scriptsの下にifcfg-<ESSID>とkeys-<ESSID>が作られる。内容は以下のような感じ。

[root@xxxpi network-scripts]# cat ifcfg-<ESSID>
HWADDR=AA:BB:CC:DD:EE:F0
ESSID="<ESSID>"
MODE=Managed
KEY_MGMT=WPA-PSK
SECURITYMODE=open
TYPE=Wireless
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=<ESSID>
UUID=xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
ONBOOT=yes
 
[root@xxxpi network-scripts]# cat keys-<ESSID>
WPA_PSK='<KEY>'

　 すぐにdhcpが動くので、この状態で、既に通信が可能になっている。

　 ifconfigの形式のが見慣れているので、net-toolsを導入して、確認。

[root@xxxpi ~]# yum install net-tools
[root@xxxpi ~]# ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.xx.xx.xxx  netmask 255.255.255.0  broadcast 172.xx.xx.255
        ether aa:bb:cc:dd:ee:6e  txqueuelen 1000  (Ethernet)

　 次はブリッジインタフェイスを作る。

[root@xxxpi ~]# nmcli connection add type bridge ifname br0 stp no
[root@xxxpi ~]# ifconfig br0
br0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether aa:bb:cc:dd:ee:02  txqueuelen 0  (Ethernet)
[root@xxxpi ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		0080.000000000000	no		
[root@xxx network-scripts]# cat ifcfg-bridge-br0 
DEVICE=br0
STP=no
TYPE=Bridge
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=bridge-br0
UUID=xbridgex-xxxx-xxxx-xxxxxxxxxxxxxxxxx
ONBOOT=yes

　 ……んでもって……

[root@xxxpi ~]# nmcli device show br0
[root@xxxpi ~]# nmcli connection show configured bridge-br0
[root@xxxpi ~]# nmcli connection add type bridge-slave ifname wlan0 master br0 
[root@xxxpi ~]# ifdown wlan0

　 ……この辺りから、何をどうやっても意図した設定にならなくなってしまい丸一日ドハマリ。nmcliコマンドでチマチマと設定しているのが、なんだかくねくねする棒で背中を掻いているようなもどかしい気分になってきた。

　 結局、直接に、有線側と無線側の両方の設定ファイルから要らない部分を削除し、ブリッジへ帰属する設定を追加したら希望の動作となった。膨大な時間を無駄にしたわ。あほくさ。ちなみにdhcpのままでいいならifcfg-bridge-br0はノータッチでいい。

[root@xxxpi network-scripts]# diff -bc ifcfg-eth0.org ifcfg-eth0
  DEVICE=eth0
- BOOTPROTO=dhcp
  ONBOOT=yes
  NM_CONTROLLED=yes
--- 1,4 ----
  DEVICE=eth0
  ONBOOT=yes
  NM_CONTROLLED=yes
+ BRIDGE=xbridgex-xxxx-xxxx-xxxxxxxxxxxxxxxxx
 
[root@xxxpi network-scripts]# diff -bc ifcfg-<ESSID>.org ifcfg-<ESSID>
  KEY_MGMT=WPA-PSK
  SECURITYMODE=open
  TYPE=Wireless
- BOOTPROTO=dhcp
- DEFROUTE=yes
- PEERDNS=yes
- PEERROUTES=yes
- IPV4_FAILURE_FATAL=no
- IPV6INIT=yes
- IPV6_AUTOCONF=yes
- IPV6_DEFROUTE=yes
- IPV6_PEERDNS=yes
- IPV6_PEERROUTES=yes
- IPV6_FAILURE_FATAL=no
  NAME=<ESSID>
  UUID=xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
  ONBOOT=yes
--- 4,10 ----
  KEY_MGMT=WPA-PSK
  SECURITYMODE=open
  TYPE=Wireless
  NAME=<ESSID>
  UUID=xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
  ONBOOT=yes
+ BRIDGE=xbridgex-xxxx-xxxx-xxxxxxxxxxxxxxxxx

　 そして、NetworkManagerを再起動すると……

[root@xxxpi network-scripts]# systemctl daemon-reload 
[root@xxxpi network-scripts]# systemctl restart NetworkManager

　 ……経路にループが発生してブロードキャストストームが発生する！……ので、あわてず有線LANを抜いて、再起動！ ネットワークトラフィック低下！ ブリッジの形成を確認！ 現時刻をもって「ブリッジ形成作戦」を終了とします……といいたいところだが、普段使いのPCから、ラズベリーパイにsshアクセスができないことに気づいた(またかよ)……つづく。

　 長らく愛用していた「EARNiNE EN120」だが、夜に耳に突っ込むと右から音が出なくなっていた。ケーブルをアレコレしてもまったく何の反応もなく、断線かどうかもわからない。残念。

　 思い返せば、衝撃的だった2019年7月の購入から2年と1ヶ月。よく持った方ではないかと思う。なにせ稼働時間がモノスゴイ。それなりに大事に扱っていたとはいえ、通勤、ランニング、寝ホンと、ほぼ毎日のように使い続けていたのだから。

　 しかし、まったく不満のなかったプロダクトであるから、なくなると困るのだ。他にこんな音を出すイヤホンがあるとは思えない。なので、実は困らないように2020年4月に予備を買っておいたのであった。

　 とはいえ、イヤホンの寿命なんて運みたいなもの。言うなれば「フォースフィールドが剥がれた状態」になってしまったわけで、次のヒットで死亡、と考えると不安を感じてしまうのである。もうひとつ予備を……と思ったら、既にディスコンらしく、どこにも売っていない。調べると、後継の製品がないどころか、会社自体を畳んでしまったようにも見える……ううむ。

　 それでも諦めきれずに探し回ったところ、適価で中古が見つかった。別に中古でも問題はない。即座にポチる。

　 一応、音が出なくなった個体も保存しておくことにする。将来ニコイチできるかもしれないし、2年以上も使うと愛着も湧いているので……。

　 という成果を受けて、同じような要領で1階の書斎まで呼び線を引こうと試したのだが引けなかった。紐を割かなかったのが原因かもしれん。

　 DIYが好きな自分は、こういう状況はむしろ楽しみでもあるし「自前でウマいことやったった」感を味わいたいので、業者さんに頼む気にはならないのだが、ウマくいかなければ、それはそれでそれが心労となる面倒な性格である。なんだろうな、関西人の「高ければウマいのは当たり前」「ウマくても安くなきゃ不満」みたいな気持ちだろうか。知らんけど。

　 要するに本当はこうしたいのだが、ケーブルが1本しか敷かれてないので、現状ではこうなっている、ということだ。

　 だが、そこで思いついた。別に2台同時に高速通信する必要はないし、仕事PCを使う時は、必ず主力PCも立ち上げている。その条件なら、ケーブルを追加しなくても、こういうテがあるではないか。

　 主力PCにイーサネットポートを追加し、ブリッジ(≒スイッチ、≠ルータ)の役割をさせ、仕事PCの通信を中継をさせればいい。手元には100MbpsのUSBイーサしかないが、ちょっと調べたらイマドキはUSB3.0の1Gbpsのモノも千円チョイで買えるようだ。普通に思考すればギガビットのスイッチに置き換えるのが普通の思考であることはわかっているが、上記の方法ならば必要のない時には電源が切れるという利点がある。まぁ、普通に置き換えるだけじゃ面白くないってのもあるんだが。

　 で、ここからが本題。USBイーサを挿したら、主力PC内に仮想ブリッジを設定するのであるが、以前からこのブリッジの設定について、納得のいっていない点があるのだ。なんでブリッジデバイスにIPアドレス付いちゃってんの？

　 ブリッジの設定自体は、GUIからチョイチョイとできてしまい、この状態になる。

# brctl show
bridge name     bridge id               STP enabled     interfaces
bridge0         8000.e86a64573438       no              enp3s0f0     ※本体のイーサポート
                                                        enp4s0f3u4u4 ※USBのイーサポート
 
# ip addr show
enp3s0f0:     <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP group default qlen 1000
enp4s0f3u4u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP group default qlen 1000
bridge0:      <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 172.28.0.99/16 brd 172.28.255.255 scope global dynamic noprefixroute bridge0

　 んが、ネットワークの基本ではあるが、ブリッジつうのはレイヤ2であるから、それ自体にIPアドレスは付かないはずなのだ。同じ理屈でスイッチングハブにもIPアドレスは付かない。スマートスイッチだと管理用のIPアドレスが付くかもしれないが、それは意味が違う。なのに、現状を絵に描くとこう。

　 自分のイメージ的にはこう、もしくは、こう、だと思えるのだが。

　 動いてんだから問題ないじゃん、という考え方もあろうが、サポートでメシ食っている人間としては、その指向はあまりよろしくないので、少し突き詰めてみる。んが、現状の物理デバイスをネタに突き詰めてもいいのだが、実はdockerのコンテナ環境もブリッジを使い倒している。なので、そっちの方面から深堀りしてみることにする。

　 ネタはこないだ導入したミニPCの上の、Fedora40のdocker(podman)環境だ。常々、コンテナを起動するとifconfigってやたら賑やかになるよなぁ、と思ってはいたが、あまり中身を意識したことはなかった。

# ip addr show
podman1:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.0.1/24 brd 10.89.0.255 scope global podman1
veth0@if2:  mtu 1500 qdisc noqueue master podman1 state UP group default qlen 1000
podman2:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.1.1/24 brd 10.89.1.255 scope global podman2
veth1@if2:  mtu 1500 qdisc noqueue master podman2 state UP group default qlen 1000

　 コンテナを立ち上げるとpodmanX, vethXが対で増える。vethXってナニよ？ 試しに母艦とコンテナ両方でtcpdumpを採りながら、母艦からコンテナAにpingを打ったら理解できた。基本tcpdumpに-i anyの指定はご法度だが、最近はI/F名も出るようになって便利なんだよな。

# tcpdump -tt -nn -i any icmp
.220946 podman1 Out IP 10.89.0.1 > 10.89.0.2: ICMP echo request, id 174, seq 1, length 64
.220958 veth0   Out IP 10.89.0.1 > 10.89.0.2: ICMP echo request, id 174, seq 1, length 64
.220973 eth0    In  IP 10.89.0.1 > 10.89.0.2: ICMP echo request, id 174, seq 1, length 64
.221012 eth0    Out IP 10.89.0.2 > 10.89.0.1: ICMP echo reply, id 174, seq 1, length 64
.221016 veth0   P   IP 10.89.0.2 > 10.89.0.1: ICMP echo reply, id 174, seq 1, length 64
.221020 podman1 In  IP 10.89.0.2 > 10.89.0.1: ICMP echo reply, id 174, seq 1, length 64

　 わかりやすい。行きはpodman1 veth0, eth0の順、帰りはその逆順。veth0て、内部にある外向け(?)の仮想のイーサポートってことだったんだな。Virtual-ETHer。つまり、図にするとこうだ。

　 コンテナ間通信を行う場合は、コンテナの所属するネットワーク名を合わせる。つまり、図にするとこうだ。

　 コンテナBからコンテナAにpingを打ってみる。

$ sudo ping 10.89.0.2
# tcpdump -tt -nn -i any icmp
.724550 eth0  Out IP 10.89.0.3 > 10.89.0.2: ICMP echo request, id 175, seq 1, length 64
.724553 veth1 P   IP 10.89.0.3 > 10.89.0.2: ICMP echo request, id 175, seq 1, length 64
.724554 veth0 Out IP 10.89.0.3 > 10.89.0.2: ICMP echo request, id 175, seq 1, length 64
.724570 veth0 P   IP 10.89.0.2 > 10.89.0.3: ICMP echo reply, id 175, seq 1, length 64
.724571 veth1 Out IP 10.89.0.2 > 10.89.0.3: ICMP echo reply, id 175, seq 1, length 64
.724571 eth0  In  IP 10.89.0.2 > 10.89.0.3: ICMP echo reply, id 175, seq 1, length 64

　 さっきと異なり、podman1を経由していない。いやいや、ブリッジを経由しないでパケットが届くわけないよね。逆に考えれば「podman1という名前はブリッジそのものを指しているわけではない」ということになってしまう。podman1は「ブリッジにオマケでくっついているNIC」を指している、と理解すればいいのだろうか？

　 podman1のIPアドレスを外してみよう。

# ip addr show podman1
podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.0.1/24 brd 10.89.0.255 scope global podman1
# ip addr del 10.89.0.1/24 dev podman1
# ip addr show podman1
podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

　 こうすると、コンテナAから母艦へのpingは通らなくなるが、コンテナBからコンテナAへのpingは通る。

　 今回「なんでブリッジデバイスにIPアドレス付いちゃってんの？」てのが納得のいっていない点なので、podman1にIPアドレスが付いていない状態で、母艦とコンテナ間で通信ができればなんとなく納得できる。んが、IPアドレスを付ける場所がなければどうしようもないので、仮想NICを作ってみる。

# ip link add veth101 type veth peer name veth100
# ip link show
veth100@veth101: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
veth101@veth100: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

　 仮想NICはペアで互いにリンクした状態で生成されるようだ。veth101の側にIPアドレスを付け、双方をアップする。

# ip addr add 10.89.0.101/24 dev veth101
# ip link set veth100 up
# ip link set veth101 up
# ip addr show
veth100@veth101: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
veth101@veth100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.0.101/24 scope global veth101

　 そして、コンテナBから母艦へpingを打ってみる……が、通らない。そりゃ、veth100/veth101ペアはどこにもつながっていないからだ。veth100の方をブリッジにつなげてやる。

# brctl show
bridge name     bridge id               STP enabled     interfaces
podman1         8000.26d98dba414b       no              veth0
                                                        veth1
# brctl addif podman1 veth100
# brctl show
bridge name     bridge id               STP enabled     interfaces
podman1         8000.26d98dba414b       no              veth0
                                                        veth1
                                                        veth100

　 つまり、図にするとこうだ。

　 で、再度コンテナBから母艦へpingを打ってみると……

$ sudo ping 10.89.0.101
# tcpdump -tt -nn -i any icmp
.923306 eth0    Out IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923310 veth1   P   IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923311 veth100 Out IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923311 veth101 In  IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923378 veth101 Out IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64
.923379 veth100 P   IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64
.923381 veth1   Out IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64
.923381 eth0    In  IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64

　 通ったー!! んが、結局ここまでやってわかったことは「そんな面倒なことしなくて済むように」「ブリッジにはオマケでNICがくっついて」いて、それが「ブリッジデバイスにIPアドレス付いちゃってる」ように見える、ってことっぽい。

　 ちなみに、コンテナBは、podman1のアドレスがデフォルトゲートウェイになっていて、DNSもそこを指しているので、そのIPアドレスを外してしまっている現状では、外と通信することができない。デフォルトゲートウェイをveth101にし、別のDNSを参照するようにすれば、外と通信することができるようになる。つまり、podman1のIPアドレスを外し、veth100/veth101で通信するようにした状態も、特に間違っているわけではないということだ。

$ ip route show
default via 10.89.0.1 dev eth0 proto static metric 100 
10.89.0.0/24 dev eth0 proto kernel scope link src 10.89.0.3 
$ sudo ip route delete default via 10.89.0.1
$ ip route show
10.89.0.0/24 dev eth0 proto kernel scope link src 10.89.0.3 
$ sudo ip route add default via 10.89.0.101 dev eth0
$ ip route show
default via 10.89.0.101 dev eth0 
10.89.0.0/24 dev eth0 proto kernel scope link src 10.89.0.3 
 
$ cat /etc/resolv.conf 
search dns.podman
nameserver 10.89.0.1
$ sudo vi /etc/resolv.conf
$ cat /etc/resolv.conf 
search dns.podman
nameserver 172.28.0.1
 
$ curl www.example.com
<!doctype html>
<html>
<head>
    <title>Example Domain</title>
      :

　 結局、まぁそうだろうな、というトコロに落ちたわけだが、今回の試行を通じて、コンテナネットワークに関する知見も増えたし、様々なipコマンドの使い方も身に付いた。つまるところプログラミングもネットワークも経験の積み重ねなんだよね。で、肝心の仕事PCへの中継についてもできているのだが、それはまたもう少しネタを揃えて後日まとめるとして……別の意味で「自前でウマいことやったった」状態になっちまったいま、楽しみのような苦しみのようなケーブルの増設作業はどうすんだオレ……。