Freigeben über

Lösungen für allgemeine Probleme in Azure IoT Edge

  • Artikel

Gilt für: yes icon IoT Edge 1.1

Wichtig

IoT Edge 1.1: Datum für das Supportende war der 13. Dezember 2022. Informationen zur Unterstützung für dieses Produkt, diesen Dienst, diese Technologie oder diese API finden Sie in der Microsoft Lifecycle-Richtlinie. Weitere Informationen zum Aktualisieren auf die neueste Version von IoT Edge finden Sie unter Update IoT Edge.

Mithilfe dieses Artikels können sie allgemeine Probleme identifizieren und beheben, die bei der Verwendung von IoT Edge-Lösungen auftreten. Wenn Sie erfahren möchten, wie Sie von Ihrem IoT Edge-Gerät stammende Protokolle und Fehler finden, lesen Sie Behandeln von Problemen bei Ihrem IoT Edge-Gerät.

Bereitstellung

IoT Edge-Modul wird erfolgreich bereitgestellt und verschwindet dann vom Gerät

Problembeschreibung

Nach Festlegung von Modulen für ein IoT Edge-Gerät werden die Module erfolgreich bereitgestellt, doch nach einigen Minuten verschwinden sie vom Gerät und aus den Gerätedetails im Azure-Portal. Auch andere als die definierten Module können auf dem Gerät auftauchen.

Ursache

Wenn eine automatische Bereitstellung ein Gerät zum Ziel hat, hat sie Vorrang vor der manuellen Festlegung der Module für ein einzelnes Gerät. Die Funktionalität Module festlegen im Azure-Portal oder Bereitstellung für ein einzelnes Gerät erstellen in Visual Studio Code wird für einen Augenblick wirksam. Sie sehen, dass die von Ihnen definierten Module auf dem Gerät gestartet werden. Dann greift die Priorität der automatischen Bereitstellung und überschreibt die gewünschten Eigenschaften des Geräts.

Lösung

Verwenden Sie nur eine Art von Bereitstellungsmechanismus pro Gerät, entweder eine automatische Bereitstellung oder individuelle Gerätebereitstellungen. Bei mehreren automatischen Bereitstellungen, die ein Gerät zum Ziel haben, können Sie die Priorität oder Zielbeschreibungen ändern, um sicherzustellen, dass die richtige Beschreibung für ein bestimmtes Gerät zutrifft. Sie können auch den Gerätezwilling aktualisieren, sodass er nicht mehr der Zielbeschreibung der automatischen Bereitstellung entspricht.

Weitere Informationen finden Sie unter Grundlegendes zu automatischen IoT Edge-Bereitstellungen für einzelne Geräte oder nach Bedarf.

IoT Edge-Runtimeprotokolle in Windows können nicht abgerufen werden.

Problembeschreibung

Bei Verwenden von Get-WinEvent unter Windows erhalten Sie die Meldung EventLogException.

Ursache

Damit der PowerShell-Befehl Get-WinEvent Protokolle anhand eines bestimmten ProviderName suchen kann, muss ein Registrierungseintrag vorhanden sein.

Lösung

Legen Sie einen Registrierungseintrag für den IoT Edge-Daemon fest. Erstellen Sie eine Datei vom Typ iotedge.reg mit dem folgenden Inhalt, und importieren Sie sie in die Windows-Registrierung, indem Sie auf die Datei doppelklicken oder den Befehl reg import iotedge.reg ausführen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\iotedged]
"CustomSource"=dword:00000001
"EventMessageFile"="C:\\ProgramData\\iotedge\\iotedged.exe"
"TypesSupported"=dword:00000007

DPS-Clientfehler

Problembeschreibung

IoT Edge kann nicht gestartet werden, und die Fehlermeldung lautet: failed to provision with IoT Hub, and no valid device backup was found dps client error.

Ursache

Eine Gruppenregistrierung wird zum Bereitstellen eines IoT Edge-Geräts für eine IoT Hub-Instanz verwendet. Das IoT Edge-Gerät wird zu einem anderen Hub verschoben. Die Registrierung wird in DPS gelöscht. In DPS wird eine neue Registrierung für den neuen Hub erstellt. Das Gerät wird nicht erneut bereitgestellt.

Lösung

  1. Überprüfen Sie, ob Ihre DPS-Anmeldeinformationen korrekt sind.
  2. Wenden Sie Ihre Konfiguration mithilfe von sudo iotedge apply config an.
  3. Wenn das Gerät nicht erneut bereitgestellt wird, starten Sie es neu mit sudo iotedge system restart.
  4. Wenn das Gerät nicht erneut bereitgestellt wird, erzwingen Sie mit sudo iotedge system reprovision die erneute Bereitstellung.

Legen Sie für die automatische erneute Bereitstellung dynamic_reprovisioning: true in der Gerätekonfigurationsdatei fest. Wenn Sie dieses Flag auf „True“ festlegen, wird das Feature für dynamische erneute Bereitstellung aktiviert. IoT Edge erkennt Situationen, in denen das Gerät in der Cloud offenbar erneut bereitgestellt wurde, indem es seine eigene IoT Hub-Verbindung auf bestimmte Fehler überwacht. IoT Edge reagiert, indem es alle Edge-Module und sich selbst herunterfährt. Bei seinem nächsten Start versucht der Daemon, dieses Gerät mit Azure erneut bereitzustellen, um die neuen IoT Hub-Bereitstellungsinformationen zu empfangen.

Wenn Sie externe Bereitstellung verwenden, benachrichtigt der Daemon außerdem den externen Bereitstellungsendpunkt über das Ereignis der erneuten Bereitstellung, bevor er heruntergefahren wird. Weitere Informationen finden Sie unter IoT Hub Device-Konzepte für die erneute Bereitstellung.

IoT Edge-Laufzeit

Der IoT Edge-Agent wird nach einer Minute beendet.

Problembeschreibung

Das edgeAgent-Modul startet und wird ungefähr eine Minute lang erfolgreich ausgeführt, dann wird es beendet. Aus den Protokollen geht hervor, dass der IoT Edge-Agent versucht, zuerst über AMQP eine Verbindung mit IoT Hub und dann mithilfe von AMQP über WebSocket eine Verbindung herzustellen. Wenn hierbei ein Fehler auftritt, wird der IoT Edge-Agent beendet.

Beispielprotokolle von „edgeAgent“:

2017-11-28 18:46:19 [INF] - Starting module management agent.
2017-11-28 18:46:19 [INF] - Version - 1.0.7516610 (03c94f85d0833a861a43c669842f0817924911d5)
2017-11-28 18:46:19 [INF] - Edge agent attempting to connect to IoT Hub via AMQP...
2017-11-28 18:46:49 [INF] - Edge agent attempting to connect to IoT Hub via AMQP over WebSocket...

Ursache

Eine Netzwerkkonfiguration im Hostnetzwerk hindert den IoT Edge-Agent daran, das Netzwerk zu erreichen. Der Agent versucht zuerst, eine Verbindung über AMQP (Port 5671) herzustellen. Wenn ein Verbindungsfehler auftritt, verwendet er WebSockets (Port 443).

Die IoT Edge-Runtime richtet ein Netzwerk für die Kommunikation der einzelnen Module ein. Unter Linux ist dieses Netzwerk ein Bridgenetzwerk. Unter Windows wird NAT verwendet. Dieses Problem tritt häufiger auf Windows-Geräten mit Windows-Containern auf, die das NAT-Netzwerk verwenden.

Lösung

Stellen Sie sicher, dass für die diesem Bridge-/NAT-Netzwerk zugewiesenen IP-Adressen eine Route zum Internet besteht. In einigen Fällen hat eine VPN-Konfiguration auf dem Host Vorrang vor dem IoT Edge-Netzwerk.

Das Edge-Agent-Modul meldet „empty config file“, und auf dem Gerät werden keine Module gestartet

Problembeschreibung

Auf dem Gerät treten Probleme beim Starten von in der Bereitstellung definierten Modulen auf. Nur der Edge-Agent (edgeAgent) wird ausgeführt, dieser meldet jedoch kontinuierlich „empty config file ...“.

Ursache

Standardmäßig werden Module in IoT Edge in ihrem eigenen isolierten Containernetzwerk gestartet. Möglicherweise liegt auf dem Gerät ein Problem mit der DNS-Namensauflösung in diesem privaten Netzwerk vor.

Lösung

Option 1: Festlegen des DNS-Servers in Containermoduleinstellungen

Geben Sie den DNS-Server für Ihre Umgebung in den Einstellungen der Containerengine an, die für alle durch die Engine gestarteten Containermodule gelten sollen. Erstellen Sie die Datei daemon.json, und geben Sie dann den DNS-Server an, der verwendet werden soll. Beispiel:

{
    "dns": ["1.1.1.1"]
}

Dieser DNS-Server wird auf einen öffentlich zugänglichen DNS-Dienst festgelegt. In einigen Netzwerken, z. B. Unternehmensnetzwerken, sind jedoch eigene DNS-Server installiert, und sie lassen den Zugriff auf öffentliche DNS-Server nicht zu. Wenn Ihr Edgegerät auf einen öffentlichen DNS-Server nicht zugreifen kann, ersetzen Sie ihn deshalb durch eine erreichbare DNS-Serveradresse.

Fügen Sie daemon.json im richtigen Pfad für Ihre Plattform ein:

Plattform Location
Linux /etc/docker
Windows-Host mit Windows-Containern C:\ProgramData\iotedge-moby\config

Wenn die Datei daemon.json im Pfad bereits vorhanden ist, fügen Sie ihr den Schlüssel dns hinzu, und speichern Sie die Datei.

Starten Sie die Containerengine neu, damit die Änderungen wirksam werden.

Plattform Get-Help
Linux sudo systemctl restart docker
Windows (Administrator-PowerShell) Restart-Service iotedge-moby -Force

Option 2: Festlegen des DNS-Servers in der IoT Edge-Bereitstellung je Modul

Sie können den DNS-Server für createOptions jedes Moduls in der IoT Edge-Bereitstellung festlegen. Beispiel:

"createOptions": {
  "HostConfig": {
    "Dns": [
      "x.x.x.x"
    ]
  }
}

Warnung

Wenn Sie diese Methode verwenden und die falsche DNS-Adresse angeben, verliert edgeAgent die Verbindung mit IoT Hub und kann keine neuen Bereitstellungen für die Problembehebung empfangen. Zum Lösen dieses Problems können Sie die IoT Edge-Runtime neu installieren. Bevor Sie eine neue Instanz von IoT Edge installieren, müssen Sie alle edgeAgent-Container aus der vorherigen Installation entfernen.

Achten Sie darauf, diese Konfiguration auch für die Module edgeAgent und edgeHub festzulegen.

Der IoT Edge-Agent kann nicht auf das Image eines Moduls (403) zugreifen.

Problembeschreibung

Ein Container kann nicht ausgeführt werden, und die edgeAgent-Protokolle weisen melden Fehler 403.

Ursache

Das IoT Edge-Agent-Modul hat keine Zugriffsberechtigungen für das Image eines Moduls.

Lösung

Stellen Sie sicher, dass Ihre Anmeldeinformationen für die Containerregistrierung im Bereitstellungsmanifest des Geräts richtig sind.

IoT Edge-Hub kann nicht gestartet werden.

Problembeschreibung

Das Modul edgeHub kann nicht gestartet werden. Möglicherweise wird eine Fehlermeldung wie eine der folgenden in den Protokollen angezeigt:

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

Oder

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:  
        The process cannot access the file because it is being used by another process. (0x20)

Ursache

Ein anderer Prozess auf dem Hostcomputer hat einen Port gebunden, den das Modul edgeHub zu binden versucht. IoT Edge-Hub ordnet die Ports 443, 5671 und 8883 für den Einsatz in Gatewayszenarien zu. Das Modul kann nicht gestartet werden, wenn ein anderer Prozess bereits einen dieser Ports gebunden hat.

Lösung

Sie können dieses Problem auf zwei Arten beheben:

Wenn das IoT Edge-Gerät als Gatewaygerät fungiert, müssen Sie den Prozess, der Port 443, 5671 oder 8883 verwendet, finden und beenden. Ein Fehler für Port 443 bedeutet in der Regel, dass der andere Prozess ein Webserver ist.

Wenn Sie das IoT Edge-Gerät nicht als Gatewaygerät verwenden müssen, können Sie die Portbindungen aus den Optionen zur Modulerstellung von edgeHub entfernen. Sie können die Erstellungsoptionen im Azure-Portal oder direkt in der Datei „deployment.json“ ändern.

Führen Sie im Azure-Portal die folgenden Schritte aus:

  1. Navigieren Sie zu Ihrem IoT-Hub, und wählen Sie Geräte im Menü Geräteverwaltung aus.

  2. Wählen Sie das IoT Edge-Gerät aus, das Sie aktualisieren oder entfernen möchten.

  3. Wählen Sie Module festlegen aus.

  4. Wählen Sie Runtimeeinstellungen aus.

  5. Löschen Sie in den Einstellungen des Moduls Edge Hub alles aus dem Textfeld Erstellungsoptionen.

  6. Speichern Sie Ihre Änderungen, und erstellen Sie die Bereitstellung.

Gehen Sie in der Datei „deployment.json“ so vor:

  1. Öffnen Sie zunächst die Datei „deployment.json“, die Sie auf Ihr IoT Edge-Gerät angewendet haben.

  2. Suchen Sie im Abschnitt mit den gewünschten Einstellungen für edgeAgent die Einstellungen für edgeHub:

    "edgeHub": {
    "settings": {
        "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
        "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}]}}}"
    },
    "type": "docker",
    "status": "running",
    "restartPolicy": "always"
}

  3. Entfernen Sie die Zeile createOptions und das abschließende Komma am Ende der Zeile image davor:

    "edgeHub": {
    "settings": {
        "image": "mcr.microsoft.com/azureiotedge-hub:1.1"
    },
    "type": "docker",
    "status": "running",
    "restartPolicy": "always"
}

  4. Speichern Sie die Datei, und wenden Sie sie erneut auf Ihr IoT Edge-Gerät an.

Beim Versuch des IoT Edge-Moduls, eine Nachricht an edgeHub zu senden, tritt ein 404-Fehler auf

Problembeschreibung

Beim Versuch eines benutzerdefinierten IoT Edge-Moduls, eine Nachricht an den IoT Edge-Hub zu senden, tritt ein 404-Fehler (Module not found) auf. Die IoT Edge-Runtime gibt folgende Meldung an die Protokolle aus:

Error: Time:Thu Jun  4 19:44:58 2018 File:/usr/sdk/src/c/provisioning_client/adapters/hsm_client_http_edge.c Func:on_edge_hsm_http_recv Line:364 executing HTTP request fails, status=404, response_buffer={"message":"Module not found"}u, 04 )

Ursache

Die IoT Edge-Runtime erzwingt aus Sicherheitsgründen die Prozessidentifizierung für alle Module, die eine Verbindung mit edgeHub herstellen. Dadurch wird sichergestellt, dass alle von einem Modul gesendeten Nachrichten von der Hauptprozess-ID des Moduls stammen. Sendet ein Modul eine Nachricht, die nicht von der anfangs festgelegten Prozess-ID stammt, wird die Nachricht mit dem Fehlercode 404 abgelehnt.

Lösung

Ab Version 1.0.7 dürfen alle Modulprozesse eine Verbindung herstellen. Weitere Informationen finden Sie im Änderungsprotokoll zum Release 1.0.7.

Wenn ein Upgrade auf Version 1.0.7 nicht möglich ist, führen Sie die folgenden Schritte aus. Stellen Sie sicher, dass das benutzerdefinierte IoT Edge-Modul beim Senden von Nachrichten an den Edge-Hub immer die gleiche Prozess-ID verwendet. Stellen Sie beispielsweise sicher, dass Sie in Ihrer Docker-Datei den Befehl ENTRYPOINT und nicht den Befehl CMD verwenden. Der Befehl CMD führt zu einer Prozess-ID für das Modul und einer weiteren Prozess-ID für den bash-Befehl, der das Hauptprogramm ausführt, aber ENTRYPOINT führt zu einer einzelnen Prozess-ID.

Stabilitätsprobleme auf kleineren Geräten

Problembeschreibung

Auf Geräten mit eingeschränkten Ressourcen wie Raspberry Pi können Stabilitätsprobleme auftreten, insbesondere wenn sie als Gateway verwendet werden. Zu den Symptomen gehören Arbeitsspeicherausnahmen im IoT Edge-Hub-Modul. Nachgeschaltete Geräte können sich nicht verbinden, oder das Gerät sendet nach einigen Stunden keine Telemetrienachrichten mehr.

Ursache

Der zur IoT Edge-Runtime gehörige IoT Edge-Hub ist standardmäßig für die Leistungserbringung optimiert und versucht, große Blöcke des Speichers zuzuordnen. Diese Optimierung ist für eingeschränkte Edge-Geräte nicht ideal und kann zu Stabilitätsproblemen führen.

Lösung

Legen Sie für den IoT Edge-Hub eine Umgebungsvariable OptimizeForPerformance auf false fest. Es gibt zwei Möglichkeiten zur Festlegung von Umgebungsvariablen:

Führen Sie im Azure-Portal die folgenden Schritte aus:

Wählen Sie in Ihrem IoT Hub Ihr IoT Edge-Gerät und dann auf der Seite mit den Gerätedetails Module festlegen>Runtimeeinstellungen aus. Erstellen Sie eine Umgebungsvariable für das IoT Edge-Hub-Modul namens OptimizeForPerformance, die auf FALSE festgelegt ist.

„OptimizeForPerformance“ ist auf FALSE festgelegt.

Im Bereitstellungsmanifest:

"edgeHub": {
  "type": "docker",
  "settings": {
    "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
    "createOptions": <snipped>
  },
  "env": {
    "OptimizeForPerformance": {
      "value": "false"
    }
  },

Sicherheitsdaemon konnte nicht gestartet werden

Problembeschreibung

Der Sicherheitsdaemon kann nicht gestartet werden, und es werden keine Modulcontainer erstellt. edgeAgent, edgeHub und andere benutzerdefinierte Module werden vom IoT Edge-Dienst nicht gestartet. In den Protokollen zu aziot-edged wird dieser Fehler angezeigt:

  • Der Daemon konnte nicht gestartet werden: Der Verwaltungsdienst konnte nicht gestartet werden.
  • Ursache: Fehler im Pfad „/var/run/iotedge/mgmt.sock“
  • Ursache: Berechtigung verweigert (Betriebssystemfehler 13)

Ursache

Für alle Linux-Distributionen mit Ausnahme von CentOS 7 wird bei der Standardkonfiguration von IoT Edge die systemd-Socketaktivierung verwendet. Ein Berechtigungsfehler tritt auf, wenn Sie die Konfigurationsdatei so ändern, dass nicht die Socketaktivierung verwendet wird, aber als URLs /var/run/iotedge/*.sock beibehalten, da iotedge-Benutzer*innen nicht in /var/run/iotedge schreiben können. Das bedeutet, dass die Sockets selbst nicht entsperrt und eingebunden werden können.

Lösung

Sie müssen die Socketaktivierung bei Distributionen, unter denen die Socketaktivierung unterstützt wird, nicht deaktivieren. Wenn Sie die Socketaktivierung jedoch überhaupt nicht verwenden möchten, platzieren Sie die Sockets in /var/lib/iotedge/.

  1. Führen Sie systemctl disable iotedge.socket iotedge.mgmt.socket aus, um die Socketeinheiten zu deaktivieren, damit systemd sie nicht unnötig startet.
  2. Ändern der IoT Edge-Konfiguration zur Verwendung von /var/lib/iotedge/*.sock in den Abschnitten connect und listen
  3. Wenn Sie bereits über Module verfügen, haben sie die alten /var/run/iotedge/*.sock-Bereitstellungen. Sie sollten sie daher mit docker rm -f entfernen.

Das Modul konnte aufgrund von Betriebssystemkonflikten nicht gestartet werden.

Symptom

Das EdgeHub-Modul kann nicht in IoT Edge Version 1.1 gestartet werden.

Ursache

Windows-Modul verwendet eine Version von Windows, die mit der Version von Windows auf dem Host nicht kompatibel ist. IoT Edge Windows Version 1809 Build 17763 wird als Basisebene für das Modulimage benötigt, aber eine andere Version wird verwendet.

Lösung

Überprüfen Sie die Version Ihrer verschiedenen Windows-Betriebssysteme in der Problembehandlung bei Host- und Containerimagekonflikten. Wenn sich die Betriebssysteme unterscheiden, aktualisieren Sie sie auf IoT Edge Windows Version 1809 Build 17763, und erstellen Sie das Docker-Image neu, das für dieses Modul verwendet wird.

Netzwerk

Fehler für den Daemon für die IoT Edge-Sicherheit aufgrund eines ungültigen Hostnamens

Problembeschreibung

Der Versuch, die Protokolle des IoT Edge-Sicherheits-Managers zu prüfen, schlägt mit folgender Meldung fehl:

Error parsing user input data: invalid hostname. Hostname cannot be empty or greater than 64 characters

Ursache

Die IoT-Edge-Runtime unterstützt nur Hostnamen, die kürzer als 64 Zeichen sind. Physische Computer weisen in der Regel keine langen Hostnamen auf, das Problem ist eher bei virtuellen Computern üblich. Die automatisch generierten Hostnamen für in Azure gehostete virtuelle Windows-Computer sind tendenziell lang sein.

Lösung

Wenn dieser Fehler angezeigt wird, können Sie ihn durch Konfigurieren des DNS-Namens des virtuellen Computers und anschließendes Festlegen des DNS-Namens als Hostname im Setupbefehl beheben.

  1. Navigieren Sie im Azure-Portal zur Übersichtsseite Ihrer VM.

  2. Wählen Sie unter „DNS-Name“ Konfigurieren. Wenn für Ihren virtuellen Computer bereits ein DNS-Name konfiguriert wurde, müssen Sie keinen neuen konfigurieren.

    Konfigurieren des DNS-Namens der VM

  3. Geben Sie einen Wert für DNS-Namensbezeichnung ein, und wählen Sie Speichern.

  4. Kopieren Sie den neuen DNS-Namen, der das Format <DNS-Namensbezeichnung>.< VM-Speicherort>. cloudapp.azure.com aufweisen sollte.

  5. Verwenden Sie innerhalb des virtuellen Computers den folgenden Befehl zum Einrichten der IoT Edge-Runtime mit Ihrem DNS-Namen:

    • Unter Linux:

      sudo nano /etc/iotedge/config.yaml

    • Unter Windows:

      notepad C:\ProgramData\iotedge\config.yaml

IoT Edge-Modul meldet Verbindungsfehler

Problembeschreibung

IoT Edge-Module, die eine direkte Verbindung mit Clouddiensten herstellen, einschließlich der Runtimemodule, funktionieren nicht mehr wie erwartet und geben Verbindungs- oder Netzwerkfehler zurück.

Ursache

Container benötigen die IP-Paketweiterleitung, um eine Verbindung mit dem Internet herzustellen, damit sie mit Clouddiensten kommunizieren können. Die IP-Paketweiterleitung ist in Docker standardmäßig aktiviert. Wenn sie jedoch deaktiviert wird, funktionieren Module, die eine Verbindung mit Clouddiensten herstellen, nicht mehr wie erwartet. Weitere Informationen finden Sie in der Docker-Dokumentation unter Understand container communication (Informationen zur Containerkommunikation).

Lösung

Gehen Sie nach folgenden Schritte vor, um die IP-Paketweiterleitung zu aktivieren.

Unter Windows:

  1. Öffnen Sie die Anwendung Ausführen.

  2. Geben Sie regedit in das Textfeld ein, und wählen Sie OK aus.

  3. Navigieren Sie im Fenster Registrierungs-Editor zu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

  4. Suchen Sie nach dem Parameter IPEnableRouter.

    1. Wenn der Parameter vorhanden ist, legen Sie seinen Wert auf 1 fest.

    2. Ist der Parameter nicht vorhanden, fügen Sie ihn als neuen Parameter mit den folgenden Einstellungen hinzu:

      Einstellung Wert
      Name IPEnableRouter
      type REG_DWORD
      Wert 1

  5. Schließen Sie das Fenster „Registrierungs-Editor“.

  6. Starten Sie das System neu, um die Änderungen anzuwenden.

Unter Linux:

  1. Öffnen Sie die Datei sysctl.conf.

    sudo nano /etc/sysctl.conf

  2. Fügen Sie der Datei die folgende Zeile hinzu:

    net.ipv4.ip_forward=1

  3. Speichern und schließen Sie die Datei.

  4. Starten Sie den Netzwerkdienst und den Docker-Dienst neu, um die Änderungen anzuwenden.

Nächste Schritte

Sind Sie der Meinung, dass Sie in der IoT Edge-Plattform einen Fehler gefunden haben? Melden Sie ein Problem, damit wir die Plattform weiter verbessern können.

Wenn Sie weitere Fragen haben, erstellen Sie eine Supportanfrage, um Hilfe zu erhalten.