☰

BeagleBone Black 静的 IP 保持

tag-icon • tag-icon beagleboneblack
BeagleBone Black 静的 IP 保持

私は、IoT プロジェクトで BeagleBone Black デバイスをエネルギー監視デバイスとして使用しています。アプリケーションは USB (Modbus RTU) 経由でデータを読み取り、MQTT 経由でリモート クラウドに送信します。このような BeagleBone Black デバイスは 15～20 台ほどあります。インターネットにアクセスするために、工場の IT マネージャーから静的 IP アドレスのインスタンスを 15～20 個もらいました。ファイルに静的 IP アドレスを設定しました/etc/network/interfacesが、インターネット接続が機能しないことがあります。デバッグしてみると、BeagleBone Black が動的 IP アドレスを取得していることがわかりました。

プラントには静的 IP アドレスと動的 IP アドレスの別々の範囲があります。BeagleBone Black を再起動すると、静的 IP アドレスが再び適切に取得され、システムが正常に動作します。

ランダム IP アドレスでこの問題に直面しています。現時点では、動的 IP 範囲で永続的に変更するオプションはありません。これはランダムなデバイスで発生しています。この問題の解決にご協力ください。ファイルで設定された IP/etc/network/interfaceと受信した IP アドレスは次のとおりです。

たとえば、デバイスに設定された静的 IP アドレス。これは/etc/network/interfaceBeableBone Black の設定ファイルです。

#auto eth0
#iface eth0 inet dhcp

auto eth0
iface eth0 inet static
    address 10.12.4.152
    netmask 255.255.254.0
    gateway 10.12.4.1


# Example to keep MAC address between reboots
#hwaddress ether DE:AD:BE:EF:CA:FE

##connman: ethX static config
#connmanctl services
#Using the appropriate ethernet service, tell connman to setup a static IP address for that service:
#sudo connmanctl config <service> --ipv4 manual <ip_addr> <netmask> <gateway> --nameservers <dns_server>

##connman: WiFi
#
#connmanctl
#connmanctl> tether wifi off
#connmanctl> enable wifi
#connmanctl> scan wifi
#connmanctl> services
#connmanctl> agent on
#connmanctl> connect wifi_*_managed_psk
#connmanctl> quit

# Ethernet/RNDIS gadget (g_ether)
# Used by: /opt/sripts/boot/autoconfigure_usb0.sh
iface usb0 inet static
    address 192.168.7.2
    netmask 255.255.255.252
    network 192.168.7.0
    gateway 192.168.7.1

ファイル内の IP アドレス:

address 10.12.4.152
netmask: 255.255.254.0
gateway: 10.12.4.1

受信した IP アドレス (ifconfigコマンドを使用して確認):

inet 10.12.4.207  netmask 255.255.254.0

コマンドの完全な応答ifconfig:

# ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
        inet 10.12.4.207  netmask 255.255.254.0  broadcast 10.12.5.255
        inet6 fe80::f6e1:1eff:fe8c:d785  prefixlen 64  scopeid 0x20<link>
        ether f4:e1:1e:8c:d7:85  txqueuelen 1000  (Ethernet)
        RX packets 146702  bytes 10983334 (10.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6716  bytes 509906 (497.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 174

lo: flags=74<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 164064  bytes 18078349 (17.2 MiB)
        RX errors 0  dropped 0  everruns 0  frame 0
        TX packets 164064  bytes 18078349 (17.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.7.2  netmask 255.255.255.252  broadcast 192.168.7.3
        ether f4:e1:1e:8c:d7:87  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.6.2  netmask 255.255.255.252  braodcast 192.168.6.3
        ether f4:e1:1e:8c:d7:8a  txquequelen 1000 (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

答え1

前回、Beaglebone Black を操作したとき、その標準 Debian イメージは、2 つの完全に異なる DHCP クライアントを同時にアクティブにすることで、奇妙な動作をし、(率直に言って) 壊れてしまいました。/etc/network/interfaces を使用しているようですが、もう 1 つは "connman" です。connman が DHCP クライアントとして動作しないように無効にするよう十分注意してください。そうしないと、connman が制御権を持っていると認識し、ネットワークを再構成します。

あなたの問題の「ランダム」な性質を考えると、それは次のように思えます。ある場合には、ネットワークは/etc/network/interfacesによって静的に設定された後、connmanによって再構成されています。

スクリーンショットには、これを実行しようとするコメントアウトされたコマンドが表示されていますが、これが実際にすべてのデバイスで実行されたかどうかは不明です。

関連情報