SMPP-Protokollanalyse mithilfe von Wireshark
In diesem Artikel erfahren Sie, wie Sie mit Wireshark für Adobe Campaign Classic eine SMPP-Protokollanalyse durchführen.
Beschreibung description
Umgebung
Adobe Campaign Classic (ACC)
Problem/Symptome
Erfahren Sie, wie Sie den SMPP-Traffic mithilfe von Wireshark analysieren.
Die meisten Short Message Service Center (SMS-C) mit hohem Durchsatz sind mit dem SMPP-Protokoll Version 3.4 kompatibel. Dieses Protokoll ermöglicht den Versand von SMS und den Empfang von Informationen über den Versand dieser SMS. Das SMPP-Protokoll ist in der SMPP Protocol Specification v3.4 dokumentiert, die im Internet als PDF-Dokument verfügbar ist.
Dieser Artikel ersetzt diese Spezifikation nicht: Er gibt praktische Tipps, wie die Protokollspezifikation zu interpretieren und mit dem Wireshark-Display abzugleichen ist, um die Fehlerbehebung zwischen Adobe Campaign und dem SMS-C-Partner zu erleichtern.
Da das SMPP-Protokoll viele Teile enthält, die der Interpretation des Implementierungs-Teams überlassen bleiben, gibt es Unterschiede zwischen verschiedenen SMS-C.
Wenden Sie sich bei der Problembehebung immer an den SMS-C-Partner, um Informationen zu erhalten oder um zu überprüfen, was Sie erhalten. Wenn SMS-C mit einem Fehler antwortet, kann Ihr SMS-C-Partner Ihnen am besten mitteilen, warum es mit dem Fehler geantwortet hat. Wenn Sie einen SMPP-Simulator verwenden, anstatt eine Verbindung zu einem echten SMS-C herzustellen, sollten Sie den Quellcode (oder einen Debugger) verwenden, um zu verstehen, was passiert.
Lösung resolution
Erfassen des Netzwerk-Traffics ohne Wireshark
Wenn Sie keinen direkten Zugriff auf die Maschine haben, kann es notwendig sein, mit Befehlszeilen-Tools wie tcpdump zu erfassen. Wenn Sie bereits den TCP-Port der Verbindung kennen, stellen Sie den richtigen Filter ein, um zu vermeiden, dass der gesamte Traffic erfasst wird. Hier ist eine Beispiel-tcpdump-Befehlszeile zum Erfassen von Port-12345 in outfile.pcap:
tcpdump -i any -w outfile.pcap tcp port 12345
Die Datei outfile.pcap kann dann in Wireshark zur weiteren Analyse geöffnet werden.
In diesem Thema wird davon ausgegangen, dass Sie mit den Grundlagen von Wireshark vertraut sind: Pakete erfassen, einfache Filter definieren, Paketdetails lesen. Eine kurze Einführung finden Sie unter howtogeek - Verwendung von Wireshark zum Erfassen, Filtern und Inspect-Paketen.
Um SMPP-Traffic in Wireshark herauszufiltern, gibt es drei wichtige Funktionen:
-
Verwenden Sie einen Anzeigefilter für den Port des SMS-C. Wenn das SMS-C beispielsweise Port 10000 verwendet, verwenden Sie den folgenden Filter:
tcp.port == 10000 -
Um Pakete nach Telefonnummer oder Textinhalt zu isolieren, verwenden Sie die Suchfunktion mit den folgenden Einstellungen:
-
Verwenden Sie das TCP-Stream-Tool, um den Stream zu isolieren, an dem Sie arbeiten.
Schließen Sie das rote/blaue Textfenster, das angezeigt wird, da es nur für Textprotokolle nützlich ist, die für SMPP nicht relevant sind.
-
SMPPProtocol
Das Protokoll funktioniert über TCP und ist vollständig binär, was bedeutet, dass spezielle Tools wie Wireshark (oder ein Hexadezimaleditor) erforderlich sind, um den Inhalt des Streams zu entschlüsseln.
Der Stream besteht aus unabhängigen PDUs: Jede PDU ist eine Nachricht mit einem Befehl, einem Status, einer Sequenznummer und anderen Informationen, die auf dem Befehl basieren.
Aufgrund der Natur von TCP als Stream-Protokoll kann ein TCP-Paket mehr als eine PDU enthalten, und PDUs können 2 oder mehr TCP-Pakete umfassen. Wireshark stellt PDUs korrekt neu zusammen, sodass es für den Wireshark-Benutzer transparent ist.
Im Folgenden finden Sie ein Beispiel für PDUs, die beim Senden eines MT und anschließendem Empfangen eines SR das Netzwerk durchlaufen:
Hinweis: Die Liste der Standardbefehle finden Sie in Abschnitt 5.1.2.1 der SMPP-Spezifikation (SMPP-Befehlssatz).
SMPP-Antworten
Das SMPP-Protokoll erfordert, dass alle Befehle von einer Antwort-PDU quittiert werden:
BIND_TRANSMITTER wird von BIND_TRANSMITTER_RESP quittiert, SUBMIT_SM wird von SUBMIT_SM_RESP usw. quittiert.
Es gibt eine Zeitüberschreitung für Antworten, normalerweise 10, 30 oder 60 Sekunden. Die Antwort kann eine positive Bestätigung (Befehl _status = 0) oder einen Fehler (siehe 5.1.3 Befehl_Status, Tabelle 5-2 in der SMPP-Spezifikation für die Liste der Standardfehler) enthalten. In den meisten Fällen erfolgen diese Antworten sofort und es wird keine Zeitüberschreitung bei einer Antwort erreicht.
Achten Sie darauf, zwischen SMPP-Antwortfehlern und SR-Fehlercodes zu unterscheiden: derselbe Fehlercode kann im Antwortfehler oder im SR-Fehlerfeld unterschiedliche Bedeutungen haben. Wenn Sie einen Fehler-Code melden, müssen Sie sehr vorsichtig sein, wo Sie ihn gefunden haben, da die Bedeutung des Werts von seinem Kontext abhängt.
SMPP-Verbindungsinitialisierung
Die SMPP-Verbindung beginnt mit der Verbindung über TCP. Dann wird ein BIND-Vorgang von Campaign gesendet und von einem BIND RESP quittiert. Diese Vorgänge werden in Abschnitt 4.1 der SMPP-Spezifikation (BIND-Vorgang) beschrieben.
Der Bindungsvorgang führt die Anmelde-/Kennwortprüfung durch und tauscht Informationen über den Plattformnamen, die Version und andere in der Spezifikation beschriebene Felder aus.
Hinweis: Die Anmeldung finden Sie im Feld system_id .
In Campaign sollten Sie ein BIND_TRANSMITTER-Paket sehen, wenn eine MT-Übertragung eingeleitet wird, und ein BIND_RECEIVER-Paket, wenn nlsm eine MO/SR-Verbindung Trigger.
Sender, Empfänger und Transceiver: Der SMPP-Connector für Campaign Classic funktioniert in einem separaten Sender-/Empfängermodus: Es gibt zwei TCP-Verbindungen, eine zum Senden von MT und eine andere zum Empfangen von MO und SR. Beachten Sie, dass die TCP-Verbindung immer von Campaign initiiert wird, auch für den Empfängermodus.
SMPP bietet auch einen Transceiver-Modus. Dieser Modus wird jedoch für Campaign Classic nicht im SMPP-Connector implementiert.
Der SMPP-Connector verwendet mehrere parallele Verbindungen, um MT zu übertragen. Dies kann aufgrund der Art und Weise, wie der Connector gestaltet ist, nicht gesteuert werden.
Empfangen von MO
Wenn der Empfänger gebunden ist, kann das SMS-C MO jederzeit senden. Das MO wird mit einer DELIVER_SM-PDU gesendet, bei der die Bits 2-5 von esm_clas gelöscht sind (häufig esm_class einfach 0 sein).
Auf die DELIVER_SM PDU muss schnell von einer DELIVER_SM_RESP PDU mit derselben sequence_number geantwortet werden.
MT wird gesendet
Um ein MT zu senden, muss der Transmitter erfolgreich gebunden sein. Prüfen Sie vor allem, ob der Bindungsprozess erfolgreich durchgeführt wurde.
Das MT wird in einer SUBMIT_SM-PDU gesendet. Das SMS-C sollte schnell mit einer SUBMIT_SM_RESP-PDU antworten: Dieses Antwortpaket ist besonders, da es die ID der Nachricht in der Datenbank des SMS-C enthält (geben Sie diese ID immer an, wenn Sie mit dem SMS-C-Partner sprechen, damit er die Nachricht schneller findet). Diese ID ist im SR enthalten und ist die einzige Möglichkeit, das MT dem entsprechenden SR zuzuordnen.
Das Feld registered_delivery (beschrieben im Abschnitt 5.2.17 der Spezifikation) gibt dem SMS-C an, ob für dieses bestimmte MT ein SR angefordert wird. Wenn Sie für eine bestimmte Nachricht kein SR erhalten, überprüfen Sie, ob das Feld in der PDU SUBMIT_SM korrekt eingestellt ist.
Kodierung von MT
Achtung: Die SMS-Kodierung ist ein komplexes Thema mit vielen Fallen und verschiedenen Implementierungen.
Bei Kodierungsproblemen ist es stets empfehlenswert, sich an den SMS-C-Partner zu wenden. Ihr SMS-Partner verfügt über genaue Kenntnisse der unterstützten Kodierung und speziellen Regeln, die aufgrund von Einschränkungen in der technischen Plattform gelten können. Lassen Sie sie überprüfen, was Sie ihnen senden und was sie Ihnen zurücksenden. Dies ist der einzige Weg zu einer erfolgreichen und stabilen Verbindung.
SMS-Nachrichten verwenden eine spezielle 7-Bit-Kodierung, die oft GSM7-Kodierung genannt wird. Siehe Wikipedia GSM 03.38 (auf Englisch).
Im SMPP-Protokoll wird der GSM7-Text auf 8 Bit pro Zeichen erweitert, um die Fehlerbehebung zu erleichtern. Das SMS-C packt ihn in 7 Bit pro Zeichen, bevor es an das Mobilgerät gesendet wird. Das bedeutet, dass das Feld „short_message“ der SMS im SMPP-Rahmen bis zu 160 Byte lang sein kann, während es beim Versand über das Mobilfunknetz auf 140 Byte begrenzt ist (das höchstwertige Bit wird einfach verworfen).
Bei Kodierungsproblemen sollten Sie Folgendes überprüfen:
- Stellen Sie zunächst sicher, dass Sie wissen, welche Zeichen zu welcher Kodierung gehören. GSM7 ist berüchtigt für seine nur teilweise Unterstützung diakritischer Zeichen (Akzente). Besonders im Französischen, wo é und è zu GSM7 gehören, ê, â oder ï aber nicht. Die Situation in Bezug auf Spanisch ist nicht besser.
- Das C mit Zedille (ç) ist im GSM7-Alphabet nur in Großbuchstaben vorhanden, aber einige Telefone geben es in Kleinbuchstaben oder „intelligenter“ Großschreibung wieder: die allgemeine Empfehlung ist, es ganz zu vermeiden und die Zedille zu entfernen (es ist im Französischen immer noch sehr gut lesbar) oder zu UCS-2 zu wechseln.
- Verwenden Sie kein ASCII in SMS, es sei denn, der SMS-C-Partner verlangt dies ausdrücklich: Diese Kodierung verschwendet Platz, da sie 8-Bit-Zeichen und eine geringere Abdeckung als GSM7 hat.
- Latin-1 wird nicht immer unterstützt: Fragen Sie bei Ihrem SMS-C-Partner nach der Kompatibilität, bevor Sie versuchen, Latin-1 zu verwenden.
- Nationale Sprachverschiebungstabellen werden vom Adobe Campaign Classic-Connector nicht unterstützt. Sie müssen stattdessen UCS-2 verwenden.
- UCS-2 und UTF-16 werden oft per Telefon gemischt. Dies ist ein Problem für Personen, die Emojis und andere selten verwendete Zeichen senden, die nicht in UCS-2 vorhanden sind.
- Die GSM7-Kodierung wird von Wireshark nicht unterstützt: Sonderzeichen werden falsch angezeigt. Wenn Sie überprüfen müssen, ob eine GSM7-Zeichenfolge korrekt kodiert ist, müssen Sie Hexadezimalcodes mit der GSM7-Tabelle vergleichen.
Das Feld data_coding gibt an, welche Kodierung verwendet wird. Das einzige Problem ist, dass der Wert 0 in der Spezifikation für die SMS-C-Standardkodierung steht, im Allgemeinen aber für GSM7. Erkundigen Sie sich beim SMS-C Partner, welche Kodierung mit data_coding = 0 verknüpft ist (Adobe Campaign unterstützt für data_coding nur GSM7 = 0).
Die maximale Größe einer Nachricht hängt von ihrer Kodierung ab. In dieser Tabelle sind alle relevanten Informationen zusammengefasst:
User Data Header (UDH)
UDH (User Data Header) sind kleine binäre Kopfzeilen, die zum Text einer SMS hinzugefügt werden. Sie können besondere Funktionen wie SMS-Verkettung, nationale Sprachverschiebungstabellen, Logos/Bilder (selten verwendet) oder WAP-Push auslösen.
Da der UDH Teil des Textfelds ist (SMPP-Feld „short_message“), verkürzt er die effektive Größe einer SMS. Beispielsweise verbraucht ein verketteter SMS-UDH 6 Byte pro SMS-Teil (d. h. 6 echte 8-Bit-Bytes, nicht 7-Bit-Zeichen), sodass nur für 152 7-Bit-Zeichen genügend Platz pro Nachrichtenteil bleibt.
Wikipedia hat nette Artikel über User Data Header und verkettete SMS (in Englisch).
Um herauszufinden, ob „short_message“ einen UDH enthält, überprüfen Sie die Bits 6 und 7 von „esm_class“ (siehe Abschnitt 5.2.12 der Spezifikation). Wireshark analysiert UDH in der Schnittstelle und gibt genaue Informationen.
Im obigen Screenshot sehen Sie den User Data Header im Nachrichtenfeld (1), die im UDH enthaltenen Informationen (2) und einige zusätzliche Informationen, die nicht zum Paket gehören, aber von Wireshark berechnet werden (3): Das Feld „Short Message body“ ist besonders interessant, da es die vollständige, von Wireshark neu zusammengesetzte Nachricht enthält.
Empfangen von SR
Wenn der Empfänger gebunden ist, kann das SMS-C SR jederzeit senden. Das SR wird mit einer DELIVER_SM-PDU gesendet, bei der die Bits 2-5 auf esm_class set festgelegt sind.
Auf die DELIVER_SM PDU muss schnell von einer DELIVER_SM_RESP PDU mit derselben sequence_number geantwortet werden. Um das MT zu finden, das dieser SR entspricht, suchen Sie nach SUBMIT_SM_RESP mit derselben ID. Dies ist beispielsweise das MT, der dem SR entspricht:
SR werden nur gesendet, wenn das Feld registered_delivery im MT festgelegt ist.
Hinweis: Der Adobe Campaign Classic-SMPP-Connector verarbeitet keine SR, die vor dem SUBMIT_SM_RESP). Die Spezifikation verbietet dieses Verhalten nicht ausdrücklich, aber es wird als schlechtes Verhalten angesehen (es würde bedeuten, dass die Nachricht empfangen wurde, bevor sie gesendet wurde). Wenn Sie diesen Fall zu oft feststellen, bitten Sie Ihren SMS-C-Partner, seine Plattform zu reparieren.
Entschlüsseln des Felds „short_message“ des SR
Das Textfeld der SR-PDUs verfügt über eine spezielle Kodierung, die in Anhang B der SMPP-Protokollspezifikation beschrieben ist. Leider ist dieses Format nur eine Empfehlung und nicht Teil des Protokolls, auch wenn die meisten SMS-C mehr oder weniger genau dieses Format einhalten.
Sie sollten den SMS-C-Partner direkt um eine Dokumentation seiner eigenen Implementierung bitten und überprüfen, ob sie mit dem übereinstimmt, was Sie in Wireshark sehen. Oftmals kennen die SMS-C-Implementierer nicht einmal ihre eigene Implementierung, was zu Problemen und Missverständnissen führt. Fragen Sie den SMS-C-Partner um Hilfe, wenn Sie Zweifel bezüglich dieses Felds haben (insbesondere wegen der Fehlercodes).
Das Grundformat lautet wie folgt:
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........
Dies sind allgemeine Leitlinien für das Lesen der obigen Zeile:
- Die ID ist die gleiche, die im SUBMIT_SM_RESP) des MT gesendet wurde.
- Probleme im Textfeld können Sie ignorieren: Dieses Feld wird von Campaign ignoriert, da es nutzlos und unzuverlässig ist und sogar völlig unlesbar sein kann, wenn die SMS in einer anderen Kodierung als reinem alphanumerischen ASCII gesendet wurde. Dies ist ein normales Verhalten.
- Bei Feldnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden (z. B. kann id: sub: text: auch als ID: SUB: text: angegeben werden).
- Das dlvrd field ist im Allgemeinen nicht zuverlässig, es sei denn, es wurde von dem SMS-C-Partner dokumentiert.
- Die Datumsangaben können eine beliebige Zeitzone haben, was sie praktisch unbrauchbar macht, oder sie sind schlichtweg falsch, weil die Uhr des entfernten Servers falsch geht.
- Das stat field kann andere als die in Anlage B definierten Werte aufweisen. Nutzen Sie den gesunden Menschenverstand und die Dokumentation des SMSC-Partners, um die Bedeutung zu verstehen.
- Das Feld err field hängt vollständig vom SMS-C ab. Es wird meistens vom SMS-C-Partner dokumentiert. Oft bedeutet der Code 000 einen Erfolg, während jeder andere Code Fehler anzeigt. Das Feld ist häufig numerisch, kann aber auch hexadezimal sein.
Mehrere SR für dasselbe MT
Einige SMS-C senden mehrere SR für dasselbe MT, um den Fortschritt des MT im Netzwerk zu verfolgen. Dies ist zumeist nutzlos, da der Client in den meisten Fällen nur wissen möchte, wann die Nachricht empfangen wurde (dies ist in der Regel das letzte SR).
Im Zweifelsfall sollten Sie nur das neueste vom SMS-C empfangene SR verwenden, um den Status einer Nachricht zu ermitteln.
SMPP-Fenster
Da Vorgänge und Antworten asynchron sind, können Sie Übertragungsraten optimieren, indem Sie mehrere Vorgangs-PDUs senden, bevor Sie auf die Antworten warten. Die Anzahl der Nachrichten ohne Antwort wird als Fenster bezeichnet.
Beispiel einer Übertragung mit einem maximalen Fenster von 4:
Die aktuelle Implementierung kontrolliert das Fenster nicht und erwartet, dass das Remote-SMS-C für die Handhabung von MT schnell genug ist.