alk_white
2025年9月4日 15時00分
==========
製品型番：AG9130-C03Z
Debian/ABOSバージョン：Linux atde9 5.10.0-35-amd64 #1 SMP Debian 5.10.237-1 (2025-05-19) x86_64 GNU/Linux
その他：dpkg -l | grep atmarkの内容
ii atmark-armv7-essential 1.0 all Atmark Techno Development Environment Essential for ARM
ii atmark-firmware 20240221-1 all Firmwares for peripheral devices
ii flutter-elinux 3.27.1-1+atmark1 all Extension to the Flutter SDK for Embedded Linux devices.
ii flutter-elinux-plugins 1.0.5-1+atmark1 all Plugins for flutter-elinux.
ii python3-make-sbom 1.0.1-1+atmark1 all AtmarkTechno make-sbom package
ii syft:amd64 1.31.0-1+atmark1 amd64 A CLI tool and Go library for generating a Software Bill of Materials (SBOM)
==========
お世話になっております。
Armadillo-IoT A9Eについての質問です。
ATDE9の起動時にはPC-Armadillo間のPingが導通するのですが、LANケーブルを抜き差しするとPingが導通しなくなるという事象が発生しています。
ATDE9を再起動するとまたPingが通るようになります。
LANケーブルを抜いてから2秒程度で戻せば復帰できます（Ping導通する）。しかし、ケーブルが抜けた状態が5秒程度だとPingが通らなくなります。
有線LANのIPアドレスは固定IPを用いています。
以下のような接続構成で通信を行っています。
・PC-Armadillo （有線LAN）
・PC-ネットワーク（WiFi）
解決策がございましたらご教示いただけますと幸いです。
コメント
alk_white
> 固定IPを用いているとのことですが、ATDE9の有線とArmadilloの両方について固定IPアドレスを設定しているのでしょうか？
下記、IPアドレスの設定を記載します。
Armadillo
固定IPアドレス
ATDE9
・ブリッジアダプタ（WiFiのドライバ割り当て）：自動割り当てIPアドレス
・ブリッジアダプタ（有線LANのドライバ割り当て）：固定IPアドレス
Windows11
・有線LAN：固定IPアドレス
・WiFi：自動割り当てIPアドレス
・VitualBoxEthernet：固定IPアドレス
> また、ATDE9の有線とArmadilloの固定IPアドレス設定内容として、
> ・アドレスのサブネットマスクは両方同じ
> ・ゲートウェイは空白
> ・DNSは空白
> ・「固定IPアドレス」と「PC-ネットワークで使用しているIPアドレス」は、サブネットマスクを掛けた部分が異なる値になっている
> で間違いないでしょうか？もしそうでない場合はそれが原因になっている可能性があります
間違いないです。
> また、ATDE9を再起動するとPingが通るようになるとのことですが、
> ATDE9右上の[設定]-[ネットワーク]-[（青いトグルスイッチ）]をOFFにしてから3秒ほど待って再度ONにすると、Pingは通るようになるでしょうか？
>
設定内でOFF→ONだとPingは通ります。
よろしくお願いします。
at_shota.shimoyama
alk_white
> 差し支えなければ、ATDEからArmadilloに対してpingのログ（成功時と失敗時）と、ATDEの有線LAN・ArmadilloのIPアドレスとサブネットマスクを教えていただけますでしょうか？
ATDE
有線LAN：192.168.0.3
Armadillo：192.168.0.2/24
サブネットマスクはどちらも255.255.255.0
です。
---成功時---
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=2.95 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=1.74 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=2.50 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=2.00 ms
64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=2.13 ms
64 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=1.86 ms
64 bytes from 192.168.0.2: icmp_seq=7 ttl=64 time=1.98 ms
64 bytes from 192.168.0.2: icmp_seq=8 ttl=64 time=2.25 ms
^C
--- 192.168.0.2 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7037ms
rtt min/avg/max/mdev = 1.739/2.176/2.953/0.366 ms
---失敗時---
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
From 192.168.0.3 icmp_seq=2 Destination Host Unreachable
From 192.168.0.3 icmp_seq=3 Destination Host Unreachable
From 192.168.0.3 icmp_seq=4 Destination Host Unreachable
^C
--- 192.168.0.2 ping statistics ---
7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6153ms
pipe 4
at_shota.shimoyama
失敗時にFrom 192.168.0.3があるということはiptableに問題はなさそうに見えます
ATDEからArmadilloに対してpingを行ったときに、成功時と失敗時のip aの結果も教えていただけますでしょうか？無線LANの方のIPアドレス等は隠していただいても大丈夫です
atmark@atde9:~$ ip a
ちなみに、もしかしたらcarrier検出がうまくいっていないために起こっている可能性があるので、
https://www.networkmanager.dev/docs/api/latest/NetworkManager.conf.html…
を設定するとなおるかもしれません
alk_white
> ATDEからArmadilloに対してpingを行ったときに、成功時と失敗時のip aの結果も教えていただけますでしょうか？無線LANの方のIPアドレス等は隠していただいても大丈夫です
ip -aの結果です。適当にマスクしています。成功時・失敗時に変化はありませんでした。
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback * brd *
inet * scope host lo
valid_lft forever preferred_lft forever
inet6 * scope host
valid_lft forever preferred_lft forever
2: enp0s3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether * brd *
inet * brd * scope global dynamic noprefixroute enp0s3
valid_lft 21531sec preferred_lft 21531sec
inet6 * scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp0s8: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:35:62:2c brd ff:ff:ff:ff:ff:ff
inet 192.168.0.3/24 brd 192.168.0.255 scope global noprefixroute enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::3c98:1323:3c6c:1000/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: br-914b912ad117: mtu 1500 qdisc noqueue state DOWN group default
link/ether * brd *
inet * brd * scope global br-914b912ad117
valid_lft forever preferred_lft forever
5: docker0: mtu 1500 qdisc noqueue state DOWN group default
link/ether * brd *
inet * brd * scope global docker0
valid_lft forever preferred_lft forever
> ちなみに、もしかしたらcarrier検出がうまくいっていないために起こっている可能性があるので、
> https://www.networkmanager.dev/docs/api/latest/NetworkManager.conf.html…
> を設定するとなおるかもしれません
設定の仕方と設定したときの効果がリンク先からいまいち読み取れなかったので設定していません。
すみません。
at_shota.shimoyama
ケーブルを抜いて数秒後にcarrierが見つからない状態になって、ケーブルを再度差した際にcarrierの検出ができずNO-CARRIERのままになっているために発生しているのでは？と予測を立てたのですが、成功時・失敗時ともにip aの結果が変わらずNO-CARRIERでもないということなので、
https://www.networkmanager.dev/docs/api/latest/NetworkManager.conf.html…
こちらの方法は意味が無さそうです、すみません
enp0s8の方に固定IPアドレスを振っているようでしたので、こちらでもやってみましたがやはり再現できませんでした
お手数おかけしますが、以下についてご確認いただけますでしょうか？
１．ケーブルを抜く前から差しなおしてPingが通らなくなる5秒程度後までにかけて、
・ip aの出力が変化するかどうか
・ip routeの出力が変化するかどうか
・sudo dmesgの出力で何かメッセージがあるかどうか(あらかじめsudo dmesg -Cでクリアすると分かりやすいです）
２．Pingが通らなくなってからsudo ip link set enp0s8 down; sudo ip link set enp0s8 upでも復帰するかどうか、そのときにsudo dmesgの出力で何かメッセージが追加されているかどうか
よろしくお願いします
alk_white
> お手数おかけしますが、以下についてご確認いただけますでしょうか？
> １．ケーブルを抜く前から差しなおしてPingが通らなくなる5秒程度後までにかけて、
> ・ip aの出力が変化するかどうか
変化なし
> ・ip routeの出力が変化するかどうか
変化なし
> ・sudo dmesgの出力で何かメッセージがあるかどうか(あらかじめsudo dmesg -Cでクリアすると分かりやすいです）
エラーなし
> ２．Pingが通らなくなってからsudo ip link set enp0s8 down; sudo ip link set enp0s8 upでも復帰するかどうか、そのときにsudo dmesgの出力で何かメッセージが追加されているかどうか
復帰しない
エラーなし
でした。
よろしくお願いします。
alk_white
at_shota.shimoyama
ご確認ありがとうございます。
[drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel
こちらのエラーはおそらくグラフィック関連の問題だと思われますが、抜き差し時の問題を再現できていないこちらの環境でも同様のエラーが確認できているため、おそらく今回の問題にはあまり関係ないと考えています
ただ、共有いただきありがとうございます
sudo ip link set enp0s8 down; sudo ip link set enp0s8 upだと復帰しないということでしたが、
sudo ip link set enp0s8 downを行ってから6秒ほど待ち、sudo ip link set enp0s8 upを行うと復帰するでしょうか？
おそらく6秒ほどの間隔を空けると復帰するのではないかと思います。
また、nmcli c down "有線接続 2"を行ってから数秒待ち、nmcli c up "有線接続 2"を行うと復帰するでしょうか？
こちらは、[設定]-[ネットワーク]のトグルスイッチをON・OFF切り替えるのと同じ効果があるはずなので、これも同様に復帰するのではないかと予想します。
今回はケーブルを抜き差しするとATDE9からArmadilloにPingが到達しないということでしたが、Windows11からArmadilloにPingを送るときにも同じような現象が起こるのでしょうか？
よろしくお願いします
at_shota.shimoyama
追加です。
以前は関係ないかもしれないと言いましたが、試す価値はありますので、念のためignore-carrierの設定も試していただけますでしょうか？
具体的な手順ですが、
atmark@atde9:~$ sudo vi /etc/NetworkManager/NetworkManager.conf
で、以下のように下3行を追加して保存してください
[main] plugins=ifupdown,keyfile [ifupdown] managed=false [device-ethernet] match-device=type:ethernet ignore-carrier=true
その後、以下のコマンドでNetworkManagerを再起動し、上記のignore-carrierの設定を読み込ませます。
atmark@atde9:~$ sudo systemctl restart NetworkManager
その後、ケーブルを抜き差ししてPingが復帰するかどうか確認いただけますでしょうか
よろしくお願いします
alk_white
> sudo ip link set enp0s8 down; sudo ip link set enp0s8 upだと復帰しないということでしたが、
> sudo ip link set enp0s8 downを行ってから6秒ほど待ち、sudo ip link set enp0s8 upを行うと復帰するでしょうか？
> おそらく6秒ほどの間隔を空けると復帰するのではないかと思います。
Pingが通る状態から上記では復帰しますが、ケーブルを抜き差ししてPingが通らなくなってから上記を行っても復帰しません。
> また、nmcli c down "有線接続 2"を行ってから数秒待ち、nmcli c up "有線接続 2"を行うと復帰するでしょうか？
> こちらは、[設定]-[ネットワーク]のトグルスイッチをON・OFF切り替えるのと同じ効果があるはずなので、これも同様に復帰するのではないかと予想します。
こちらも sudo ip link set enp0s8 downと同じでPingが通る状態で行えばdownでPingが通らなくなり、upでPingが通るようになります。
しかし、ケーブルを抜き差ししてPingが通らなくなった後にdown→upを行ってもPingが通るようにはなりません。
> 今回はケーブルを抜き差しするとATDE9からArmadilloにPingが到達しないということでしたが、Windows11からArmadilloにPingを送るときにも同じような現象が起こるのでしょうか？
試してみたところ、Windows11では起きませんでした。（抜き差ししてもPingが通る）
また、ignore-carrierについても試してみましたが効果は得られませんでした。
よろしくお願いします。
at_shota.shimoyama
ご確認ありがとうございます
全て効果が無かったんですね…
そしてWindows11の方では起きていないということはほぼ間違いなくVirtualBoxかATDEに原因がありそうですね
VirtualBoxのバージョンと、VirtualBox Guest Additionsのバージョンを教えてください。
VirtualBoxのバージョンは「Oracle VirtualBox マネージャー」ウィンドウの上の[ヘルプ]-[VirtualBoxについて]に記載があります
VirtualBox Guest AdditionsのバージョンはATDE9内で場所（エクスプローラ）を開いて左側に表示されているVBox_GAs_X.X.Xの数値です
よろしくお願いします
alk_white
> 全て効果が無かったんですね…
はい...残念ながら...
> VirtualBoxのバージョンと、VirtualBox Guest Additionsのバージョンを教えてください。
> VirtualBoxのバージョンは「Oracle VirtualBox マネージャー」ウィンドウの上の[ヘルプ]-[VirtualBoxについて]に記載があります
> VirtualBox Guest AdditionsのバージョンはATDE9内で場所（エクスプローラ）を開いて左側に表示されているVBox_GAs_X.X.Xの数値です
VirtualBox バージョン 7.2.0 r170228 (Qt6.8.0 on windows)
VirtualBox Guest Additions VBox_GAs_7.2.0
よろしくお願いします。
at_shota.shimoyama
こちらも 7.2.0のバージョンを使って確認していたので、やはり再現は難しいようです
前に「（効果なしの）nmcli c up "有線接続 2" と（効果ありの）[設定]-[ネットワーク]のトグルスイッチON・OFF切り替えは同じ効果がある」と言いましたが、ソースコード↓を調べてみると実際には少し差異がありました。
・nmcli c up部分のソースコード
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/mai…
・トグルスイッチ部分のソースコード（gnome-control-center）
https://salsa.debian.org/gnome-team/gnome-control-center/-/blob/debian/…
まず、nmcli c up (connection)（またはnmcli connection up (connection)）と「[設定]-[ネットワーク]のトグルスイッチON」は、どちらも NetworkManager の D-Bus API の ActivateConnection()というメソッドを経由して、NetworkManagerにコネクションの有効化をさせるように指示しています。
https://people.freedesktop.org/~lkundrak/nm-dbus-api/gdbus-org.freedesk…
ですので、どちらも同じインターフェースを使用していることに変わりないのですが、設定するメソッドの引数（connection・device）に違いがあります。
〇nmcli c up "有線接続 2" （復帰しない）
・connection = "有線接続 2"に相当するパス
・device = 未指定
〇トグルスイッチON （復帰する）
・connection = "有線接続 2"に相当するパス
・device = enp0s8に相当するパス
Pingの疎通が復帰する・しないの差が現れたのは、もしかしたらdeviceを指定する・しないの差異によるものかもしれません。
それを判別するための方法として、上記のようにnmcli c up "有線接続 2"だけだとdeviceは未指定になるのですが、ifname (device)を指定するとdeviceも指定されます↓
〇nmcli c up "有線接続 2" ifname enp0s8 （復帰する？）
・connection = "有線接続 2"に相当するパス
・device = enp0s8に相当するパス
また、nmcli d connect (device)（またはnmcli device connect (device)）というコマンドもあって、こちらはdeviceのみ指定します↓
〇nmcli d connect enp0s8 （復帰する？）
・connection = 未指定
・device = enp0s8に相当するパス
そこで、またお手数をおかけしますが
・nmcli c down "有線接続 2" ⇒ 数秒待機 ⇒ nmcli c up "有線接続 2" ifname enp0s8
・nmcli d disconnect enp0s8 ⇒ 数秒待機 ⇒ nmcli d connect enp0s8
のそれぞれで、復帰に効果があるかどうかご確認いただけますでしょうか？
よろしくお願いします
alk_white
すみません。過去の回答で勘違いがありました。
設定内でOFF→ONだとPingが通ると言ったのは
Pingが通る状態（起動後LANケーブルを抜き差ししていない状態）のことで
Pingが通らない状態で設定内でOFF→ONだとPingは通るようにはなりません。
なので、一度抜き差ししてしまうと復帰する手段は今のところありません。
分かりにくい回答をしてしまい申し訳ありません。
> ・nmcli c down "有線接続 2" ⇒ 数秒待機 ⇒ nmcli c up "有線接続 2" ifname enp0s8
> ・nmcli d disconnect enp0s8 ⇒ 数秒待機 ⇒ nmcli d connect enp0s8
上記も復帰はできませんでした。
素人見解ですが、これまでの結果から
ATDEの起動時に行っている処理を行わないと接続できないように思います。
また、LANを抜き差ししたときにWindows11とATDEの接続がどうなっているのかが気になっています。
（このフォーラムで質問する内容の範囲外かもしれませんが、、、）
よろしくお願いします。
alk_white
at_shota.shimoyama
> Pingが通らない状態で設定内でOFF→ONだとPingは通るようにはなりません。
すみません、誤解していました
だとするとご指摘のとおり、ATDE9起動時の処理にヒントがありそうですね
まずは、以前変更していただいたNetworkManagerの設定を元に戻していただけますでしょうか
atmark@atde9:~$ sudo vi /etc/NetworkManager/NetworkManager.conf
追加した以下の3行を削除して保存してください
[device-ethernet] match-device=type:ethernet ignore-carrier=true
その後、以下のコマンドでNetworkManagerを再起動し、設定を読み込ませます。
atmark@atde9:~$ sudo systemctl restart NetworkManager
また繰り返しになりますが、いくつか確認していただきたいことがあります
・VirtualBoxの[設定]-[ネットワーク]-[アダプター2（有線LANの方）]で表示される情報（名前・アダプタータイプ・Promiscuous Modeなど）を教えてください
・Windows11の有線LANの固定IPアドレスは他（ArmadilloとATDE9のenp0s8）の固定IPアドレスと違うことを確認してください。
ATDE9のenp0s8は仮想的なネットワークアダプタとしてふるまうので、同一LAN内にArmadillo・ATDE9のenp0s8・Windows11の有線LAN の３つのネットワークアダプタが存在することになります。
そのため、それぞれにMACアドレスがあり、それらのIPアドレスは異なっている必要があります。
ArmadilloとATDE9のenp0s8の固定IPアドレスが異なっていることは以前確認させていただきましたが、Windows11の有線LANの固定IPアドレスも他とは異なることを確かめてください
・IPアドレスの設定として「Windows11のVitualBoxEthernet：固定IPアドレス」とのことですが、このVirtualBoxEthernetというのは「VirtualBox Host-Only Ethernet Adapter」のことでしょうか？「VirtualBox Host-Only Ethernet Adapter」はホストオンリーアダプターとして割り当てる際に関係するもので、今回のようにブリッジ接続を割り当てる場合は関係ありません。ですので、もしそうであれば原因の切り分けのためにこのアダプターのIPアドレス割り当てを自動（DHCP）にしていただけると助かります。
> また、LANを抜き差ししたときにWindows11とATDEの接続がどうなっているのかが気になっています。
VirtualBoxのブリッジ接続は、Windows11上に新しくネットワークアダプタを作るわけではなく、設定の[名前]で指定した物理ネットワークアダプターにVirtualBoxが提供するフィルタードライバ（VBoxNetFlt）をバインドすることで実現しています
https://github.com/VirtualBox/virtualbox/tree/main/src/VBox/HostDrivers…
このフィルタードライバが物理ネットワークアダプター（今回の場合は有線）と仮想マシン（ATDE9）間を橋渡しして通信をさせることで、同一ネットワーク上に接続しているかのような振る舞い（ブリッジ）にさせています。
フィルタードライバ本体自体はホストOS（Windows11）起動時に自動的に初期化されるのですが、実際のフィルタ機能（インスタンス）は仮想マシン（ATDE9）が起動した際に初期化されるようです。
そのインスタンスの元となる構造体の定義は以下の部分です
https://github.com/VirtualBox/virtualbox/blob/7871fba29c47aa2d52edcf78d…
おそらく、「ATDE9内でrebootさせる場合は復帰しないが、ATDE9をpoweroffしてVirtualBox側から起動させると復帰する」というのは、このインスタンスが作り直されるために治っている可能性があります
実際、このインスタンスが行っている処理の中にvboxNetFltMaybeRediscoveredという関数があって、これはホストのネットワークインターフェースが切断されている場合に再接続できるかどうかを5秒間判定するという処理のようです。（今回の抜き差しの閾値5秒と関係がありそうです）
https://github.com/VirtualBox/virtualbox/blob/7871fba29c47aa2d52edcf78d…
もう少しこのフィルタードライバが行っている処理について調べてみるつもりですが、このフィルタードライバが原因であることが確定しているわけではないため、念のため以下についても試していただけますでしょうか？
・ATDE9起動中にVirtualBoxの[設定]-[ネットワーク]-[アダプター2（有線LANの方）]-[Virtual Cable Connected]のチェックをOFFに切り替えて[OK] ⇒ 5秒ほど待ってからONにして[OK]で復帰するかどうか
・https://www.fxc.jp/support/faq_eee/ に記載されている手順で、Windows11から有線LANのEEE機能を切ってみて、復帰するようになるかどうか
よろしくお願いします
alk_white
> ・VirtualBoxの[設定]-[ネットワーク]-[アダプター2（有線LANの方）]で表示される情報（名前・アダプタータイプ・Promiscuous Modeなど）を教えてください
名前：Intel(R) Ethernet Connection (13) I219-V
アダプタータイプ：準仮想化ネットワーク(virtio-net)
Promiscuous Mode：拒否
> ・Windows11の有線LANの固定IPアドレスは他（ArmadilloとATDE9のenp0s8）の固定IPアドレスと違うことを確認してください。
確認しました。
> 「VirtualBox Host-Only Ethernet Adapter」アダプターのIPアドレス割り当てを自動（DHCP）にしていただけると助かります。
自動にしました。
> > また、LANを抜き差ししたときにWindows11とATDEの接続がどうなっているのかが気になっています。
詳細に回答くださりありがとうございます。
こちらでも確認してみます。
> vboxNetFltMaybeRediscoveredという関数があって、これはホストのネットワークインターフェースが切断されている場合に再接続できるかどうかを5秒間判定するという処理のようです。（今回の抜き差しの閾値5秒と関係がありそうです）
めちゃめちゃ関係ありそうですね。
> ・ATDE9起動中にVirtualBoxの[設定]-[ネットワーク]-[アダプター2（有線LANの方）]-[Virtual Cable Connected]のチェックをOFFに切り替えて[OK] ⇒ 5秒ほど待ってからONにして[OK]で復帰するかどうか
復帰しませんでした。
> ・https://www.fxc.jp/support/faq_eee/ に記載されている手順で、Windows11から有線LANのEEE機能を切ってみて、復帰するようになるかどうか
復帰しませんでした。
at_shota.shimoyama
> アダプタータイプ：準仮想化ネットワーク(virtio-net)
望み薄ですが、両方（Wifiと有線）のアダプタータイプを「Intel PRO/1000 MT デスクトップ」（デフォルト）に変更してみてください
また、VirtualBoxのソースコードはかなり複雑なので、合っているのか確証はないのですが、
[設定]-[ネットワーク]-[アダプター 2]の[割り当て]を「未割り当て」に変更して[OK]をした後、
10秒ほど待ってから再度「ブリッジアダプター」に戻して[OK]をした場合、復帰するかどうか試していただけますでしょうか？
この方法だともしかしたらフィルタドライバのインスタンスを再作成させられるかもしれません
よろしくお願いします
alk_white
> > アダプタータイプ：準仮想化ネットワーク(virtio-net)
> 望み薄ですが、両方（Wifiと有線）のアダプタータイプを「Intel PRO/1000 MT デスクトップ」（デフォルト）に変更してみてください
ダメですね...
> また、VirtualBoxのソースコードはかなり複雑なので、合っているのか確証はないのですが、
> [設定]-[ネットワーク]-[アダプター 2]の[割り当て]を「未割り当て」に変更して[OK]をした後、
> 10秒ほど待ってから再度「ブリッジアダプター」に戻して[OK]をした場合、復帰するかどうか試していただけますでしょうか？
> この方法だともしかしたらフィルタドライバのインスタンスを再作成させられるかもしれません
こちらも効果がないです。
at_shota.shimoyama
> こちらも効果がないです。
本当ですか…
（フィルタドライバのインスタンスまでは再作成しないのかもしれないですね。
VirtualBoxで原因を探ろうにも、デバッグ版としてビルドしないと必要なログは取り出せないようです）
だとするともうVirtualBox側でできる対策は何もなさそうに思えます
効果があるかはわかりませんが、ハブを別途用意してPC-ハブ-Armadilloと接続し、ハブ-Armadillo間のケーブルを抜いた時にPC側にリンクダウンと認識させないようにするという物理的な対策しか思いつきません
力不足で本当に申し訳ありませんが、上記のような対策はいかがでしょうか？
よろしくお願いします
alk_white
> ハブを別途用意してPC-ハブ-Armadilloと接続し、ハブ-Armadillo間のケーブルを抜いた時にPC側にリンクダウンと認識させないようにするという物理的な対策しか思いつきません
この方法でArmadillo側のLANケーブルを抜いたときにPingが通らなくなる現象がなくなることを確認しました！
PC側のLANケーブル抜き差しするとやはりPingは通らなくなります...
なんとなく原因はわかったのでひとまずクローズとしましょう。
もろもろ調査くださり誠にありがとうございました。
もし、新たな情報等ありましたら連絡いただけると幸いです。
よろしくお願いします。
at_shota.shimoyama
2025年9月4日 17時51分
アットマークテクノの下山です。
こちらでは再現できなかったため、何点か確認させてください
固定IPを用いているとのことですが、ATDE9の有線とArmadilloの両方について固定IPアドレスを設定しているのでしょうか？
また、ATDE9の有線とArmadilloの固定IPアドレス設定内容として、
・アドレスのサブネットマスクは両方同じ
・ゲートウェイは空白
・DNSは空白
・「固定IPアドレス」と「PC-ネットワークで使用しているIPアドレス」は、サブネットマスクを掛けた部分が異なる値になっている
で間違いないでしょうか？もしそうでない場合はそれが原因になっている可能性があります
また、ATDE9を再起動するとPingが通るようになるとのことですが、
ATDE9右上の[設定]-[ネットワーク]-[（青いトグルスイッチ）]をOFFにしてから3秒ほど待って再度ONにすると、Pingは通るようになるでしょうか？
よろしくお願いします