Analisi del protocollo SMPP tramite Wireshark

Questo articolo illustra come eseguire l’analisi del protocollo SMPP utilizzando Wireshark per Adobe Campaign Classic.

Descrizione

Ambiente

Adobe Campaign Classic (ACC)

Problema/Sintomi

Scopri come analizzare il traffico SMPP con Wireshark.

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

Questo articolo non sostituisce le specifiche, ma offre suggerimenti pratici su come interpretare le specifiche del protocollo e confrontarle con la visualizzazione Wireshark per facilitare la risoluzione dei problemi tra Adobe Campaign e il partner SMS-C.

Poiché il protocollo SMPP contiene molte parti lasciate all’interpretazione del team di implementazione, vi sono differenze tra i 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

Acquisizione del traffico di rete senza Wireshark

Se non disponi di accesso diretto alla macchina, potrebbe essere necessario acquisire i dati 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. Di seguito è riportata una riga di comando tcpdump di esempio 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 in Wireshark per ulteriori analisi.

Manipolazione di wireshark

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

Per filtrare il traffico SMPP in Wireshark, sono disponibili tre funzioni importanti:

• Utilizza un filtro di visualizzazione sulla porta dell’SMS-C.
  
  Ad esempio, se l’SMS-C utilizza la porta 10000, utilizza il seguente filtro:
  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 il Segui flusso TCP per isolare il flusso su cui si sta 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, in modo da essere per lo più trasparente per l'utente di Wireshark.

Ecco un esempio di PDU che passano attraverso la rete quando si invia un messaggio MT (Mobile Terminated) e successivamente si riceve un messaggio SR:

Nota: l’elenco dei comandi standard è disponibile nella sezione 5.1.2.1 delle specifiche SMPP (SMPP Command set).

Risposte SMPP

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

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

Il timeout per le risposte è in genere di 10, 30 o 60 secondi. La risposta può contenere una conferma positiva (comando _status = 0) o un errore (cfr. 5.1.3 command_status, tabella 5-2 nelle specifiche 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. Quindi viene inviata un’operazione BIND per campagna, confermata da un BIND RESP. Queste operazioni sono descritte nella sezione 4.1 delle specifiche SMPP (operazione 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: il login è disponibile nel campo system_id.

In Campaign dovresti visualizzare un’ BIND_TRANSMITTER quando si avvia un trasferimento MT e un BIND_RECEIVER pacchetto quando nlsm s 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 messaggio MO viene inviato utilizzando un DELIVER_SM PDU con bit 2-5 di esm_clas s chiaro (spesso, esm_class sarà semplicemente 0).

Il *DELIVER_SM* Alla PDU si deve rispondere rapidamente con un *DELIVER_SM_RESP* PDU con *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 messaggio MT viene inviato in un SUBMIT_SM PDU L’SMS-C deve 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 più rapidamente il messaggio). Questo ID sarà presente nel messaggio SR ed è l’unico modo per abbinare il messaggio MT al messaggio SR corrispondente.

Il campo registered_delivery (descritto nella sezione 5.2.17 delle specifiche) indica all’SMS-C se è richiesto un messaggio SR per questo particolare MT. Se non ricevi alcun SR per un messaggio specifico, controlla che il campo sia impostato correttamente nella SUBMIT_SM PDU

Codifica di MT

Attenzione: la codifica SMS è un argomento complesso con molte trappole e varie implementazioni.

È consigliabile contattare sempre il partner SMS-C in caso di problemi di codifica. Il partner SMS ha una conoscenza approfondita della codifica supportata e delle regole speciali che possono essere applicate a causa delle limitazioni della piattaforma tecnica. Assicurati che controllino ciò che gli invii e ciò che ti inviano. Essa è l'unica strada per un'interconnessione stabile e di successo.

I messaggi SMS utilizzano una speciale codifica a 7 bit, spesso denominata codifica GSM7. Fai riferimento a 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 vengono visualizzati correttamente. Per verificare se una stringa GSM7 è codificata correttamente, confronta i codici esadecimali con la tabella GSM7.

Il 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. Verifica con l’SMS-C partner alla 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 articoli interessanti su UDH e SMS concatenati (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 accurate.

Nella schermata precedente puoi visualizzare l’intestazione dei dati utente nel campo del messaggio (1), le informazioni contenute nell’UDH (2) e alcune informazioni aggiuntive non appartenenti al pacchetto ma calcolate da Wireshark (3). Il campo del corpo del messaggio breve è 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. Il messaggio SR viene inviato utilizzando una PDU DELIVER_SM con bit 2-5 di esm_class impostata.

Il DELIVER_SM Alla PDU si deve rispondere rapidamente con un DELIVER_SM_RESP PDU con numero_sequenza. Per trovare il messaggio MT corrispondente a questo messaggio SR, cerca un SUBMIT_SM_RESP con lo stesso ID. Ad esempio, questo è il messaggio MT che corrisponde al messaggio SR:

Gli SR vengono inviati solo se registered_delivery è impostato nel messaggio MT.

Nota: il connettore SMPP di Adobe Campaign Classic non gestisce i messaggi SR che arrivano 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.

Chiedi direttamente al partner SMS-C la documentazione relativa all’implementazione e verifica che corrisponda a quanto visualizzato 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 è uguale a quello inviato nel SUBMIT_SM_RESP del messaggio MT corrispondente.
• Puoi ignorare i problemi nel campo di testo: questo campo viene ignorato da Campaign perché è inutile, inaffidabile e può anche essere completamente illeggibile se l’SMS è stato inviato utilizzando una codifica diversa da quella ASCII alfanumerica pura. Si tratta di un comportamento normale.
• I nomi dei campi non fanno distinzione tra maiuscole e minuscole (ad esempio, id: sub: Text: può anche essere annotato come ID: SUB: text:).
• Il dlvrd generalmente non è 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.
• Il 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.
• Il errore Il campo dipende completamente dall’SMS-C e la maggior parte delle volte è documentato dal relativo partner. 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.