ポート4444のデバイス（/dev/linkToDevice）でソケットを開くアプリケーションがあります。 「linkToDevice」はttyUSB0へのリンクです。アプリケーションはデーモンで、起動時に実行されるC ++プログラムです。デーモンはネットワークに関係なく実行されます。したがって、Linuxシステムが起動してネットワークがない場合は、デーモンがすぐに起動し、まだネットワークがなくても正しく通信できます（telnet localhost 4444）。ただし、ネットワークケーブルを接続したり、dhclientがDHCPがないと判断したり、デフォルトのIPアドレスをリースしたり、単にIPインターフェイスを提供したりすると、通信できなくなります。ただし、Telnet接続を開くことはできますが、接続を照会しても応答がありません。
ソケットを開くIP（すべてのIPアドレスを意味します）として0.0.0.0を使用します。私はこれがコードの問題だとは思わない。
私にとって奇妙なことは、通信できなくなった後にデーモンを再起動すると、期待どおりにすべてがうまく機能することです。ただし、ネットワークを切断したり、インターフェイスの設定を解除したり、sudo /etc/init.d/networkingを実行して再起動したり、ネットワークをシャットダウンして再起動したりすると、プロセス全体の間にデバイスとの接続が失われることはありません。したがって、ネットワークなしでコンピュータを起動し、突然ネットワークを取得した場合にのみ問題が発生します。なぜこれがブート時にのみ発生するのかというアイデアはありますか？
ベストアンサー1
「主にネットワークなしで起動した後に初めてeth0インターフェイスを取得することと、以前にネットワークを設定し、ネットワークを再起動した後にeth0インターフェイスを再取得することとの違いを理解する必要があります。コードは後者に対して機能します。」
この方法でアクセスする前に、高度なネットワークサービス（「NetworkManager」）の無駄を排除してください。私はいつもそれを無効にし、起動プロセスの適切なポイント（たとえば）にコマンドを貼り付けてから、他の簡単なifconfig eth0 up && dhclient eth0スクリプトを手動で実行してethからwifiなどに切り替えます。 NetworkManagerは巨大な自動化タコです。 「インターフェース」が何であるかわからない場合、またはWi-Fiネットワークからローミングしようとしてラップトップを運転している場合は、デバイスの電源を入れて使用することを好むと驚くべきことができます。迷惑で神秘的な選択です。私は、高レベルのツールが「管理」する低レベルのツールよりも特定のタスクに使用するのが難しく、そのタスクの文脈で適切なツールではないと仮定すると、構成方法をまったく学ぶことができなかったことを認めます。
明確でない場合：
ネットワークを切断したり、インターフェイスの設定を解除したり、sudo /etc/init.d/networking restartを実行したりするとき
/etc/init.d/networking.deb システム ( .rpm で使用/etc/init.d/network) を意味します。 障害を負うしたがって、このサービス（および/またはupstartを使用するシステム上の対応するupstartサービス）は起動時に実行されず、後で起動プロセスでネットワークにアクセスするために必要な単純なコマンドに置き換えられます。私もloが存在する場合を除いてすべてを/etc/network/interfacesコメントアウトします。
私は通常、この良いアドバイスを他のユーザーに配布することを考慮していませんが、あなたの質問は「それは巨大なタコだと思います」と叫んでいます。この時点で後ろを見る前に、実際にそれを排除する必要があります。