Analisi del protocollo SMPP con Wireshark

Descrizione

Ambiente

Adobe Campaign Classic

Problema/Sintomi

Scopri come analizzare il traffico SMPP utilizzando Wireshark.

La maggior parte dei centri SMS (Short Message Service Centers) ad alta velocità sono compatibili con il protocollo SMPP versione 3.4. Questo protocollo consente l’invio di SMS e la ricezione di informazioni sulla consegna di questi SMS. Il protocollo SMPP è documentato nelle specifiche del protocollo SMPP v3.4, disponibili su Internet come documento PDF.

Questo articolo non sostituisce questa specifica: fornisce suggerimenti pratici su come interpretare la specifica del protocollo e come abbinarla al display Wireshark per aiutare a risolvere i problemi tra Adobe Campaign e il partner SMS-C.

Poiché il protocollo SMPP contiene molte parti rimaste all'interpretazione del team di implementazione, ci sono differenze tra diversi SMS-C.

Durante la risoluzione dei problemi, contatta sempre il partner SMS-C per ottenere informazioni o ricevere assistenza nella verifica dei risultati ottenuti. Se l’SMS-C restituisce un errore, il partner SMS-C sarà la persona più adatta per indicarti il motivo di tale errore. Se utilizzi un simulatore SMPP invece di connetterti a un SMS-C reale, usa il codice sorgente (o un debugger) per ottenere maggiori informazioni.

Risoluzione

Catturare il traffico di rete senza Wireshark

Se non si dispone dell'accesso diretto alla macchina, potrebbe essere necessario acquisire utilizzando strumenti della riga di comando come tcpdump. Se conosci già la porta TCP della connessione, inserisci il filtro corretto per evitare di acquisire tutto il traffico. Ecco un esempio di riga di comando tcpdump per acquisire la porta 12345 a outfile.pcap:

tcpdump -i any -w outfile.pcap tcp port 12345

Il file outfile.pcap può quindi essere aperto a Wireshark per ulteriori analisi.

Gestione degli squali

Questo argomento presuppone che tu abbia familiarità con le nozioni di base di Wireshark: acquisizione di pacchetti, definizione di filtri semplici, lettura dei dettagli dei pacchetti. Una breve introduzione è disponibile su howtogeek - Come utilizzare Wireshark per acquisire, filtrare e utilizzare pacchetti Inspect.

Per filtrare il traffico SMPP in Wireshark, ci sono tre caratteristiche importanti:

• Utilizza un filtro di visualizzazione sulla porta dell’SMS-C.
  
  Ad esempio, se l’SMS-C utilizza la porta 10000, utilizza il filtro seguente:
  tcp.port == 10000

• Per isolare i pacchetti in base al numero di telefono o al contenuto del testo, utilizza la funzionalità di ricerca con le impostazioni seguenti:
  
  

• Utilizza la Segui flusso TCP strumento per isolare il flusso su cui stai lavorando.
  
  La finestra di testo di colore rosso/blu che viene visualizzata è utile solo per i protocolli di testo che non sono rilevanti per SMPP, quindi puoi chiuderla.

  

Protocollo SMPP
Il protocollo funziona su TCP ed è completamente binario, il che significa che sono necessari strumenti speciali come Wireshark (o un editor esadecimale) per decrittografare il contenuto del flusso.

Il flusso è costituito da PDU indipendenti: ogni PDU è un messaggio contenente un comando, uno stato, un numero di sequenza e altre informazioni basate sul comando.

A causa della natura del TCP come protocollo di flusso, un pacchetto TCP può contenere più di una PDU e le PDU possono estendersi su due o più pacchetti TCP. Wireshark riassemblerà correttamente le PDU, quindi è per lo più trasparente per l'utente Wireshark.

Ecco un esempio di PDU che passano attraverso la rete quando si invia un MT e poi si riceve un SR:

Nota: L’elenco dei comandi standard si trova nella sezione 5.1.2.1 della specifica SMPP (SMPP Command set).

Risposte SMPP
Il protocollo SMPP richiede che tutti i comandi siano riconosciuti da una PDU di risposta:

BIND_TRANSMITTER è riconosciuto da BIND_TRANSMITTER_RESP, SUBMIT_SM è riconosciuto da SUBMIT_SM_RESP, ecc.

Esiste un timeout per le risposte, in genere è di 10, 30 o 60 secondi. La risposta può contenere una convalida positiva (command _status = 0) o un errore (vedere 5.1.3 command_status, tabella 5-2 nella specifica SMPP per l'elenco degli errori standard). Nella maggior parte dei casi, queste risposte sono immediate e non viene raggiunto un timeout di risposta.

Assicurati di saper distinguere tra gli errori di risposta SMPP e i codici di errore SR: lo stesso codice di errore può avere un significato diverso nell’errore di risposta o nel campo di errore SR. Quando segnali un codice di errore, presta attenzione alla sua posizione perché il significato del valore dipende dal relativo contesto.

Inizializzazione della connessione SMPP
La connessione SMPP viene avviata tramite la connessione TCP. Poi un'operazione BIND viene inviata da una campagna, riconosciuta da un RESP BIND. Queste operazioni sono descritte nella sezione 4.1 della specifica SMPP (funzionamento BIND).

L’operazione bind esegue il controllo di login/password e scambia informazioni relative al nome della piattaforma, alla versione e ad altri campi descritti nelle specifiche.

Nota: L'accesso si trova nel campo system_id .

In Campaign, dovresti visualizzare un BIND_TRANSMITTER pacchetto quando si avvia un trasferimento MT e un BIND_RECEIVER packet quando nlsm attiva una connessione MO/SR.

Trasmettitore, ricevitore e ricetrasmettitore. Il connettore SMPP per Campaign Classic funziona in una modalità trasmettitore/ricevitore separata con due connessioni TCP, una per la trasmissione di messaggi MT e un’altra per la ricezione di messaggi MO (Mobile Originated) e SR. La connessione TCP viene sempre avviata da Campaign, anche per la modalità di ricezione.

SMPP offre anche una modalità ricetrasmettitore, ma questa non è implementata nel connettore SMPP per Campaign Classic.

Il connettore SMPP utilizza più connessioni in parallelo per trasmettere messaggi MT. Questo non può essere controllato a causa del modo in cui è stato progettato il connettore.

Ricezione di messaggi MO
Quando il ricevitore è associato, l’SMS-C può inviare messaggi MO in qualsiasi momento. Il MO viene inviato utilizzando un DELIVER_SM PDU con bit 2-5 di esm_clas s chiaro (spesso, esm_class sarà semplicemente 0).

La *DELIVER_SM* La PDU deve ricevere una risposta rapida da un *DELIVER_SM_RESP* PDU con lo stesso *numero_sequenza*.

Invio di messaggi MT
Per inviare un messaggio MT, il trasmettitore deve essere associato correttamente. Prima di tutto verifica che il processo di binding sia stato eseguito correttamente.

Il MT viene inviato in un SUBMIT_SM PDU L'SMS-C dovrebbe rispondere rapidamente con un SUBMIT_SM_RESP PDU: questo pacchetto di risposta è speciale perché contiene l'ID del messaggio nel database dell'SMS-C (includi sempre questo ID quando parli con il partner SMS-C per aiutarlo a trovare il messaggio più rapidamente). Questo ID sarà presente nel messaggio SR ed è l’unico modo per abbinare il messaggio MT al messaggio SR corrispondente.

Il campo registrato_delivery (descritto al punto 5.2.17 del disciplinare) indica all’SMS-C se è richiesta una SR per questo particolare MT. Se non ricevi SR per un messaggio specifico, controlla che il campo sia impostato correttamente nel SUBMIT_SM PDU

Codifica di MT
Attenzione: La codifica SMS è un argomento complesso con molte trappole e diverse implementazioni.

È buona prassi contattare sempre il partner SMS-C in caso di problemi di codifica. Il tuo partner SMS dispone di una conoscenza precisa della codifica supportata e delle regole speciali che possono essere applicate a causa di limitazioni nella sua piattaforma tecnica. Fateli controllare ciò che invii a loro e ciò che vi inviano. E 'l'unica via per un'interconnessione stabile e di successo.

I messaggi SMS utilizzano una speciale codifica a 7 bit, spesso denominata codifica GSM7. Consulta Wikipedia GSM 03.38 (in inglese).

Nel protocollo SMPP, il testo GSM7 verrà espanso a 8 bit per carattere per facilitare la risoluzione dei problemi. L’SMS-C creerà un pacchetto a 7 bit per carattere prima di inviarlo al dispositivo mobile. Ciò significa che il campo short_message dell’SMS può avere una lunghezza massima di 160 byte nel frame SMPP, mentre è limitato a 140 byte quando viene inviato sulla rete mobile (il bit più significativo viene semplicemente scartato).

In caso di problemi di codifica, ecco alcuni aspetti importanti da verificare:

• Innanzitutto, assicurati di sapere quali caratteri appartengono a quale codifica. GSM7 è tristemente noto per il suo parziale supporto dei segni diacritici (accenti). Questo vale soprattutto per la lingua francese, dove “é” ed “è” fanno parte del GSM7, ma non “ê”, “â” o “ï”. La situazione non è migliore per quanto riguarda lo spagnolo.
• La C con cediglia (ç) è presente solo in maiuscolo nell’alfabeto GSM7, ma alcuni telefoni la rendono in minuscolo o con una distinzione di caratteri “smart”. Il consiglio generale è di evitarla completamente e di rimuovere la cediglia (in ogni caso è leggibile in francese) o di passare a UCS-2.
• Non utilizzare ASCII negli SMS, a meno che non sia esplicitamente richiesto dal partner SMS-C. Questa codifica occupa spazio perché presenta caratteri a 8 bit e una copertura inferiore rispetto a GSM7.
• Latin-1 non è sempre supportato: controlla la compatibilità con il partner SMS-C prima di utilizzarlo.
• Le tabelle di cambio della lingua nazionale non sono supportate dal connettore di Adobe Campaign Classic. Utilizza quindi UCS-2.
• Spesso i telefoni fanno confusione tra le codifiche UCS-2 e UTF-16. Ciò rappresenta un problema per le persone che inviano emoji e altri caratteri poco usati e non presenti in UCS-2.
• La codifica GSM7 non è supportata da Wireshark: i caratteri speciali non verranno visualizzati correttamente. Per verificare se una stringa GSM7 è codificata correttamente, confronta i codici esadecimali con la tabella GSM7.

La data_coding indica la codifica utilizzata. L’unico problema è che il valore 0 indica la codifica SMS-C predefinita nelle specifiche, ma in generale significa GSM7. Controlla con l’SMS-C partner quale codifica è associata a data_coding = 0 (Adobe Campaign supporta solo GSM7 per data_coding = 0).

La dimensione massima di un messaggio dipende dalla relativa codifica. Questa tabella riassume tutte le informazioni pertinenti:

Codifica	data_coding	Dimensioni del messaggio (caratteri)	Dimensione di una parte per SMS in più parti	Caratteri disponibili
GSM7	0	160	152	Set di caratteri di base GSM7 + estensione (i caratteri estesi contengono 2 caratteri)
Latin-1	3	140	134	ISO-8859-1
UCS-2 UTF-16	8	70	67	Unicode (varia da telefono a telefono)

UDH (User Data Header, Intestazione dati utente)
Gli UDH sono piccole intestazioni binarie aggiunte al testo di un SMS. Possono attivare funzioni speciali come concatenazione di SMS, tabelle di cambio della lingua nazionale, loghi/immagini (raramente utilizzati) o push WAP.

Poiché l’UDH fa parte del campo di testo (campo SMPP short_message), riduce le dimensioni effettive di un SMS. Un UDH di un SMS concatenato consumerà ad esempio 6 byte per ogni parte dell’SMS, ossia 6 byte reali a 8 bit, non caratteri a 7 bit, lasciando spazio sufficiente per soli 152 caratteri a 7 bit per ogni parte del messaggio.

Wikipedia ha bei articoli su User Data Header e Concatenated SMS (in inglese).

Per sapere se uno short_message contiene un UDH, controlla i bit 6 e 7 di esm_class (vedi la sezione 5.2.12 delle specifiche). Wireshark analizza l'UDH nell'interfaccia e fornisce informazioni precise.

Nella schermata precedente, puoi vedere l'intestazione dei dati utente nel campo messaggio (1), le informazioni contenute nell'UDH (2) e alcune informazioni aggiuntive non appartenenti al pacchetto ma calcolate da Wireshark (3): il campo Corpo messaggio è particolarmente interessante in quanto contiene il messaggio completo riassemblato da Wireshark.

Ricezione di messaggi SR
Quando il ricevitore è associato, l’SMS-C può inviare messaggi SR in qualsiasi momento. L'SR viene inviato utilizzando una PDU DELIVER_SM con bit 2-5 di esm_class impostato.

La DELIVER_SM La PDU deve ricevere una risposta rapida da un DELIVER_SM_RESP PDU con lo stesso numero_sequenza. Per trovare il MT corrispondente a questo SR, cerca un SUBMIT_SM_RESP con lo stesso ID. Ad esempio, questo è il MT che corrisponde all'SR:

L'SR viene inviato solo se registrato_delivery campo impostato nel MT.

Nota: Il connettore Adobe Campaign Classic SMPP non gestisce SR che arriva prima del SUBMIT_SM_RESP pacchetto. Le specifiche non vietano esplicitamente questo comportamento, ma è considerato scorretto in quanto significherebbe che il messaggio è stato ricevuto prima di essere stato inviato. Se questa situazione si verifica spesso, chiedi al tuo partner SMS-C di correggere la piattaforma.

Decifrare il campo short_message del messaggio SR
Il campo di testo della PDU del messaggio SR ha una codifica speciale descritta nell’appendice B delle specifiche del protocollo SMPP. Questo formato è consigliato ma purtroppo non fa parte del protocollo. La maggior parte degli SMS-C tuttavia lo rispettano, anche se in misure diverse.

Dovresti chiedere direttamente al partner SMS-C una documentazione della sua implementazione e verificare che corrisponda a ciò che vedi in Wireshark. Il più delle volte, i responsabili dell’implementazione di SMS-C non conoscono la propria implementazione e questo porta a problemi e incomprensioni. Non esitare a chiedere aiuto al partner SMS-C in caso di dubbi su questo campo (in particolare sui codici di errore).

Il formato di base è il seguente:

id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........

Di seguito sono riportate le linee guida generali per la lettura della riga precedente:

• L'ID è lo stesso inviato nel SUBMIT_SM_RESP del MT corrispondente.
• È possibile ignorare i problemi nel campo di testo: questo campo viene ignorato da Campaign perché è inutile, inaffidabile e potrebbe persino essere del tutto illeggibile se l’SMS è stato inviato utilizzando un’altra codifica rispetto al codice ASCII alfanumerico. Si tratta di un comportamento normale.
• I nomi dei campi non fanno distinzione tra maiuscole e minuscole (ad esempio, id: sub: Testo: può anche essere indicato come ID: SUB: testo:).
• La dlvrd Il campo non è generalmente affidabile, a meno che non sia documentato dal partner SMS-C.
• Le date possono avere qualsiasi fuso orario, rendendole praticamente inutili o semplicemente sbagliate perché l’orologio del server remoto è spento.
• La stat può avere valori diversi da quelli definiti nell'appendice B. Utilizza il buon senso e la documentazione del partner SMSC per comprenderne il significato.
• La errore Il campo dipende completamente dall’SMS-C e per la maggior parte del tempo è documentato dal partner SMS-C. Il codice 000 indica in genere un successo, mentre qualsiasi altro codice indica un errore. Il campo è spesso numerico, ma può anche essere esadecimale.

Messaggi SR multipli per lo stesso messaggio MT
Alcuni SMS-C inviano più messaggi SR per lo stesso messaggio MT al fine di monitorare la progressione del messaggio MT nella rete. Questo è per lo più inutile, perché nella maggior parte dei casi il client vuole solo sapere quando il messaggio è stato ricevuto (in genere l’ultimo messaggio SR).

In caso di dubbi, utilizza solo l’ultimo messaggio SR ricevuto dall’SMS-C per trovare lo stato di un messaggio.

Finestra SMPP
Dal momento che le operazioni e le risposte sono asincrone, puoi ottimizzare la velocità di trasferimento inviando più PDU operative prima di attendere le risposte. Il numero di messaggi senza risposta è chiamato finestra.

Esempio di trasmissione con una finestra massima di 4:

L’implementazione corrente non controlla la finestra e prevede che l’SMS-C remoto sia abbastanza veloce da gestire il messaggio MT.