ReazonSpeech のデータセットを Hugging Face から DL すると、高確率でネットワークが落ちてしまう
データ自体は 4TB あり、最初は Hugging Face 側の問題かと思っていた
しかし実際には、ローカルの Linux PC 側のネットワークが切れている問題だった
WiFi 自体は落ちていないので、単純に自分の Linux PC の問題だと判断した
事前に入れるコマンド
1
sudo apt install iw
iw は Linux で WiFi デバイスの状態確認や設定変更を行うためのコマンド
今回の場合は、WiFi の省電力設定を確認したり、無効化したりするために使う
現状チェック
外部ドメインに疎通できるか確認する
1
2
ping google.com
...
ping google.com は、ドメイン名を使って外部に疎通できるかを確認するコマンド
この確認には、以下の2つが含まれる
DNS で google.com を IP アドレスに名前解決できるか
名前解決後、その IP アドレスまで実際に通信できるか
そのため、ここで失敗しただけでは DNS の問題なのか、ネットワーク経路の問題なのかはまだ分からない
DNS を使わず IP アドレスに直接 ping する
1
2
3
4
5
6
7
8
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 192.168.3.8 icmp_seq=1 Destination Host Unreachable
From 192.168.3.8 icmp_seq=2 Destination Host Unreachable
From 192.168.3.8 icmp_seq=3 Destination Host Unreachable
From 192.168.3.8 icmp_seq=4 Destination Host Unreachable
From 192.168.3.8 icmp_seq=5 Destination Host Unreachable
From 192.168.3.8 icmp_seq=6 Destination Host Unreachable
1.1.1.1 は Cloudflare の DNS サーバー
ドメイン名ではなく IP アドレスに直接 ping しているので、この確認では DNS を経由しない
ここで Destination Host Unreachable になっているため、少なくとも DNS の問題ではなさそうだと分かる
また、エラーの送信元が 192.168.3.8、つまり自分の Linux PC になっている。これは、PC 自身が「宛先に到達できない」と判断している状態
IPv4 アドレスが付与されているか確認する
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 altname wlp0s20f3
inet 192.168.3.8/24 metric 600 brd 192.168.3.255 scope global dynamic wlo1
valid_lft 18793sec preferred_lft 18793sec
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: br-xxxxx: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-xxxx
valid_lft forever preferred_lft forever
ip -4 a は、各ネットワークインターフェースに付与されている IPv4 アドレスを確認するコマンド
ip route
default via 192.168.3.1 dev wlo1 proto dhcp src 192.168.3.8 metric 600172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-d3b6513508a9 proto kernel scope link src 172.18.0.1 linkdown
192.168.3.0/24 dev wlo1 proto kernel scope link src 192.168.3.8 metric 600192.168.3.1 dev wlo1 proto dhcp scope link src 192.168.3.8 metric 600
ip route は、通信先ごとにどのネットワークインターフェースを使うかを確認するコマンド。
重要なのは以下の行。
1
default via 192.168.3.1 dev wlo1 proto dhcp src 192.168.3.8 metric 600
ip route | awk '/default/ {print $3; exit}'192.168.3.1
このコマンドは、ip route の出力から default 行を探し、その3列目を表示している
今回の出力では、デフォルトゲートウェイは 192.168.3.1
デフォルトゲートウェイに ping する
bash の場合は、以下のように変数に入れて確認する。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
GW=$(ip route | awk '/default/ {print $3; exit}')echo"$GW"192.168.3.1
ping -c 5"$GW"PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
From 192.168.3.8 icmp_seq=1 Destination Host Unreachable
From 192.168.3.8 icmp_seq=2 Destination Host Unreachable
From 192.168.3.8 icmp_seq=3 Destination Host Unreachable
From 192.168.3.8 icmp_seq=4 Destination Host Unreachable
From 192.168.3.8 icmp_seq=5 Destination Host Unreachable
--- 192.168.3.1 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4078ms
pipe 4
ping -c 5 "$GW" は、デフォルトゲートウェイに5回 ping を送るコマンド
ここで Destination Host Unreachable になっている
つまり、インターネットに出られないだけではなく、同じ LAN 内にいるはずのルーター 192.168.3.1 にも到達できていない
この時点で、問題は DNS や Hugging Face 側ではなく、かなりローカル側に寄っている
ARP の状態を確認する
1
2
3
4
5
ip neigh show dev wlo1
192.168.3.1 INCOMPLETE
fe80::da0f:99ff:fed9:ac8d lladdr d8:0f:99:d9:ac:8d router STALE
2400:2412:3360:4d00:1111:1111:1111:1111 router FAILED
ip neigh show dev wlo1 は、wlo1 から見た近隣ホストの状態を確認するコマンド
ARPとは「IPアドレスからMACアドレスを調べる仕組み」
以下のような流れ
1
2
3
4
5
6
7
8
9
10
11
Linux PC
↓
192.168.3.1 に送りたい
↓
でも 192.168.3.1 のMACアドレスが分からない
↓
ARPで「192.168.3.1 のMACアドレスを教えて」と聞く
↓
ルーターがMACアドレスを返す
↓
そのMACアドレス宛に通信する
IPv4 では主に ARP の状態を見るために使う
今回重要なのは以下。
1
192.168.3.1 INCOMPLETE
INCOMPLETE は、ARP 解決に失敗している状態
つまり、PC は 192.168.3.1 というルーターの IP アドレスは知っているが、その IP アドレスに対応する MAC アドレスを取得できていない
同じ LAN 内で通信するには、IP アドレスだけではなく MAC アドレスも必要になる
そのため、ARP が失敗していると、ルーターにすらパケットを届けられない
NetworkManager から見たデバイス状態を確認する
1
2
3
4
5
6
7
8
nmcli dev status
DEVICE TYPE STATE CONNECTION
br-d3b6513508a9 bridge unmanaged --
docker0 bridge unmanaged --
enp2s0 ethernet unmanaged --
lo loopback unmanaged --
wlo1 wifi unmanaged --
nmcli dev status は、NetworkManager から見たネットワークデバイスの状態を確認するコマンド
