Seite wählen

NETWAYS Blog

Troubleshooting: SMSEagle bekommt keine IP

von | Jan 10, 2022 |

Uns erreichte heute die Frage, warum das SMSEagle, in diesem Fall ein MHD-8100, keine IP Adresse bekommt, obwohl im Netzwerk DHCP aktiviert ist. Wir können hier versuchen, die Einstellungen über die Konsole des Gerätes zu prüfen. Es kann gut sein, dass DHCP evtl. nicht aktiv ist. Die nachfolgenden Infos sind auch für Nutzer interessant, die kein DHCP für das SMSEagle nutzen möchten und auf manuelle IP-Vergabe umstellen möchten.

ACHTUNG: Die Handbücher zu den SMSEagle Geräten findet Ihr hier in Englisch. Dort sind auch die Vorgehensweisen für die anderen Geräte, SMSEagle NXS-9700 und NXS-9750, beschrieben.

Zum Prüfen muss man sich auf die Konsole des Gerätes verbinden, das mit einem Ubuntu Linux läuft. Im folgenden die Schritte:

  • einen Bildschirm über den HDMI-Anschluss und eine Tastatur an den USB-Anschluss anschließen
  • meldet Euch an der Konsole mit Root-Zugangsdaten an (diese wurden mit dem Gerät geliefert)
  • nun müsst Ihr die Konfigurationsdatei öffnen und bearbeiten mit folgendem Befehl:
nano /opt/smseagle/syscfg
  • folgende Zeile muss mit einem Y für Yes versehen sein:
ETH1_START_DHCP=Y
  • Speichern und Beenden der Datei
  • das Gerät herunterfahren
  • nun den SMSEagle mit Eurem LAN über ein Ethernet-Kabel verbinden

Sollte dies nicht das gewünschte Ergebnis bringen, könnt Ihr die IP-Adresse auch händisch vergeben. Hierzu müssen in der oben genannten syscfg-Datei die folgenden Zeilen geändert/ausgefüllt werden:

ETH1_HOST_IP= (IP-Adresse für Ihr Gerät festlegen)
ETH1_GW_IP= (Standard-Gateway-IP-Adresse)
ETH1_NET_MASK= (Subnetzmaske festlegen)
ETH1_START_DHCP=N (auf ETH1_START_DHCP=Y auf N setzen, um den DHCP-Client zu deaktivieren!)

Danach wieder wie in der obigen Anleitung fortfahren.

Probiert das bei Bedarf einfach aus! Evtl. löst es das Problem, ansonsten können wir und der Support bei SMSEagle das zumindest als Problem ausschließen. Wenn das Problem weiterbesteht, dann stehen wir Euch nämlich gerne persönlich zu Verfügung – einfach über unser Kontaktformular Eure Anfrage senden.

Fehler, die es nicht gibt….

von | Mrz 28, 2012 | , , ,

Vergangene Woche ereignete sich ein ganz besonderes Fehlverhalten eines MySQL-Master-Master-Clusters. Das Setup besteht aus zwei MySQL-Servern, die über eine sogenannte Master-Master Konfiguration replizieren. Allerdings werden nicht beide Nodes aktiv verwendet, sondern jeweils nur der zur Zeit aktive. Das ganze ist relativ trivial realisiert und zwar über eine IP-Adresse, die mittels Heartbeat auf einem der beiden Server als Ressource genutzt wird und bei einem Ausfall auf den anderen Node schwenkt. Die Gründe für ein solches Setup sind die eingesetzten nicht replikationssicheren Anwendungen, welche für Inkonsistenzen sorgen würden, sobald sie auf beide Server zugreifen würden und zum zweiten natürlich die Hochverfügbarkeit im Fehlerfall.
Soviel zum Setup, passiert ist nun folgendes: Die Heartbeat IP-Adresse wurde von Server1 auf Server2 und wieder zurück geschwenkt. Anschließend kam es in der Datenbankreplikation zu Fehlern(„1062 Duplicate Key Entry“ und „1032 Key not found“). Nach dem wir die fehlgeschlagenen Statements überprüft und auch in den Bin- und Relay-Logs nachgesehen haben, stellte sich heraus, dass auf beiden Servern Datensätze eingetragen bzw. manipuliert wurden. Wie kann das sein?
Die IP-Adresse war, nach einer Kontrolle mit „ip a“, wieder auf Server Server1 gebunden und aktiv. Mit „netstat“ waren allerdings auf Server2 mehrere MySQL Verbindungen zu sehen. Ist die IP doppelt vergeben? Nein. Mit „ip a“ auf dem zweiten Server gab es keine Spur der Heartbeat-IP. Was jetzt? Was passiert hier?
Es war Zeit für „tcpdump“. Mit „tcpdump port 1234“ auf Server2 und einem „telnet server2 1234“ von einem der Webserver wurde klar, Server2 nimmt Verbindungen für diese IP entgegen. Was kommt jetzt? Klar, vermutlich sind die lokalen ARP-Einträge krumm. In der Tat, die ARP-Tabelle auf einem der Webserver enthält die MAC-Adresse von Server2 für die entsprechende Heartbeat-IP, die ja eigentlich auf Server1 laufen sollte. Ok, das macht soweit Sinn. Der Ressource-Agent für die Heartbeat-IP Adresse gibt zwar mittels Gratuitous ARP seine neue MAC-Adresse via Broadcast bekannt, aber vielleicht hat es ja diese Webserver nicht erreicht. Die Frage jetzt lautet eigentlich: Warum nimmt Server2 diese IP-Verbindungen überhaupt für die offensichtlich nicht konfigurierte IP-Adresse Verbindungen entgegen. Nochmal „ip a“ kontrolliert, ob die IP nicht doch konfiguriert ist. Nein. Mit „tcpdump -i any -n arp“ auf Server2 kontrolliert, ob Server2 auf ARP Requests für diese IP-Adresse antwortet. Ja, da ist der Reply!
Mit einem gekonnten Blick in den Kernel-Source-Code ../net/ipv4/arp.c wird man fündig. Auf ARP-Requests wird geantwortet wenn es einen Lokalen Routing Table Eintrag gibt. („inet_addr_type(net, tip) == RTN_LOCAL &&“). Die Ausgabe der lokalen Routing-Table „ip route show table local“ beantwortet dann letztendlich auch die Frage, warum Server2 auf Pakete mit der vermeintlich nicht konfigurierten IP antwortet bzw. deren Verbindung akzeptiert.
Nach einem erneuten Schwenk auf Server2 und wieder zurück, verschwand auch dieser Eintrag und alles funktionierte wieder wie erwartet.

Sebastian Saemann
Sebastian Saemann
CEO Managed Services
Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.
Lies mehr von Sebastian und triff unser Team

Trainings

Web Services

Events