Wireshark를 이용한 SMPP 프로토콜 분석

이 문서에서는 Adobe Campaign Classic용 Wireshark를 사용하여 SMPP 프로토콜 분석을 수행하는 방법을 보여줍니다.

설명 description

환경

Adobe Campaign Classic (ACC)

문제/증상

Wireshark를 사용하여 SMPP 트래픽을 분석하는 방법에 대해 알아봅니다.

처리량이 많은 대부분의 SMS-C(Short Message Service Center)는 SMPP 프로토콜 버전 3.4와 호환됩니다. 이 프로토콜을 통해 SMS를 전송하고 해당 SMS 전달에 대한 정보를 수신할 수 있습니다. SMPP 프로토콜이 PDF 문서로 인터넷에서 제공되는 SMPP 프로토콜 사양 v3.4에 설명되어 있습니다.

이 문서는 이 사양을 대체하지 않습니다. Adobe Campaign과 SMS-C 파트너 간의 문제를 해결할 수 있도록 프로토콜 사양을 해석하고 Wireshark 디스플레이와 연결하는 방법에 대해 실용적인 팁을 제공합니다.

SMPP 프로토콜은 구현 팀의 해석에 맡겨진 많은 부분을 포함하기 때문에 다른 SMS-C 간에 차이가 있습니다.

문제를 해결할 때 반드시 SMS-C 파트너에게 문의하여 정보를 얻거나 해당 정보를 다시 확인하십시오. SMS-C가 오류에 응답하면 SMS-C 파트너가 오류에 응답한 이유를 가장 잘 알려 줄 수 있습니다. 실제 SMS-C에 연결하는 대신 SMPP 시뮬레이터를 사용하는 경우 소스 코드(또는 디버거)를 사용하여 현재 상황을 파악할 수 있습니다.

해상도 resolution

Wireshark를 사용하지 않고 네트워크 트래픽 캡처

컴퓨터에 직접 액세스할 수 없는 경우 tcpdump와 같은 명령줄 도구를 사용하여 캡처해야 합니다. 연결부의 TCP 포트를 이미 알고 있는 경우 모든 트래픽을 캡처하지 않도록 올바른 필터를 입력합니다. 다음은 12345 포트를 캡처하는 샘플 tcpdump 명령줄입니다.  outfile.pcap:

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

파일  outfile.pcap  추가 분석을 위해 Wireshark에서 를 열 수 있습니다.

Wireshark 처리

이 항목에서는 사용자가 Wireshark의 기본 사항(패킷 캡처, 간단한 필터 정의, 패킷 세부 사항 읽기)을 잘 알고 있다고 가정합니다. 에 대한 간단한 소개가 제공됩니다. howtogeek - Wireshark를 사용하여 패킷을 캡처, 필터링 및 Inspect하는 방법.

Wireshark에서 SMPP 트래픽을 필터링하려면 다음 세 가지 중요 기능이 필요합니다.

  • SMS-C 포트에서 디스플레이 필터를 사용합니다.

    예를 들어 SMS-C가 포트 10000을 사용하는 경우 다음 필터를 사용합니다.
    tcp.port == 10000

  • 전화번호나 텍스트 콘텐츠별로 패킷을 분리하려면 다음 설정으로 검색 기능을 사용합니다.

    smpp1

  • 사용 TCP 스트림 팔로우 작업 중인 스트림을 분리하는 도구입니다.

    SMPP와 관련이 없는 텍스트 프로토콜에만 유용하므로 표시되는 빨간색/파란색 텍스트 창을 닫습니다.

    smpp2

SMPP 프로토콜

프로토콜은 TCP를 통해 작동하고 완전히 바이너리입니다. 즉, Wireshark(또는 16진수 편집기)와 같은 특수 도구가 스트림 콘텐츠를 해독하는 데 필요합니다.

스트림은 독립 PDU로 구성됩니다. 각 PDU는 명령, 상태, 시퀀스 번호와 명령 기반의 기타 정보 등이 포함된 메시지입니다.

스트림 프로토콜로서 TCP 특성으로 인해 TCP 패킷에는 한 개 이상의 PDU가 포함될 수 있고, PDU는 2개 이상의 TCP 패킷을 포괄할 수 있습니다. Wireshark는 PDU를 올바르게 다시 조립하므로 Wireshark 사용자에게는 대부분 투명합니다.

다음은 MT를 전송하고 SR를 수신하는 경우 네트워크를 통과하는 PDU의 예입니다.
smpp3
참고: 표준 명령 목록은 SMPP 사양(SMPP 명령 집합)의 섹션 5.1.2.1에서 찾을 수 있습니다.

SMPP 응답

SMPP 프로토콜을 사용하려면 응답 PDU에서 모든 명령을 확인해야 합니다.

BIND_TRANSMITTER는 다음을 통해 확인됩니다.  BIND_TRANSMITTER_RESPSUBMIT_SM  은(는) 승인자:  SUBMIT_SM_RESP ​등

응답에는 시간 제한이 있습니다. 일반적으로 10초, 30초 또는 60초입니다. 응답에는 양의 확인(command_status = 0) 또는 오류(5.1.3 참조)가 포함될 수 있습니다.  command_status표 5-2  표준 오류 목록의 SMPP 사양 참조). 대부분의 경우 이러한 응답은 즉각적이고, 응답 시간 제한에 도달하지 않습니다.

반드시 SMPP 응답 오류와 SR 오류 코드를 구별해야 합니다. 동일한 오류 코드는 응답 오류나 SR 오류 필드에서는 다른 코드를 의미할 수 있습니다. 오류 코드를 보고할 때 값의 의미가 컨텍스트에 따라 달라지므로 오류 코드가 발견된 위치에 주의해야 합니다.

SMPP 연결 초기화

SMPP 연결은 TCP를 사용한 연결을 통해 시작됩니다. 그런 다음 BIND 작업이 캠페인에 의해 전송되고 BIND RESP에 의해 확인됩니다. 이러한 작업은 SMPP 사양의 섹션 4.1(BIND 작업)에 설명되어 있습니다.

smpp4 바인드 작업은 로그인/암호 확인을 수행하고 플랫폼 이름, 버전 및 사양에 설명된 기타 필드에 대한 정보를 교환합니다.

참고: 로그인은 system_id 필드에 찾을 수 있습니다.

Campaign에  BIND_TRANSMITTER  MT 전송을 시작하는 경우 패킷 및  BIND_RECEIVER  패킷 시간  nlsm s  mo/SR 연결을 트리거합니다.

송신기, 수신기 및 송수신기: Campaign Classic용 SMPP 커넥터는 개별 송신기/수신기 모드에서 작동합니다. MT 전송 연결부와 MO 및 SR 수신 연결부 등 2개의 TCP 연결부가 있습니다. TCP 연결은 수신기 모드의 경우에도 Campaign에 의해 시작됩니다.

SMPP도 송수신기 모드를 제공하지만 이 모드는 Campaign Classic용 SMPP 커넥터에서는 구현되지 않습니다.

SMPP 커넥터는 여러 연결을 동시에 사용하여 MT를 전송합니다. 이는 커넥터의 설계 방식으로 인해 제어될 수 없습니다.

MO 수신 중
수신기가 바인딩되면 SMS-C는 언제든지 MO를 전송할 수 있습니다. MO는 를 사용하여 전송됩니다  DELIVER_SM  비트 2~5가 포함된 PDU  esm_clas s  지우기(종종,  esm_class  는 간단히 0)입니다.

smpp5 다음 *DELIVER_SM* PDU에 대한 빠른 응답 필요: *DELIVER_SM_RESP* 동일한 PDU *sequence_number*.

MT 전송 중
MT를 전송하려면 송신기는 제대로 바인딩되어야 합니다. 무엇보다도 바인드 프로세스가 제대로 수행되었는지 확인합니다.

MT는  SUBMIT_SM  PDU. SMS-C는 다음으로 빠르게 응답해야 함:  SUBMIT_SM_RESP  PDU: 이 응답 패킷은 SMS-C 데이터베이스의 메시지 ID가 포함되어 있어 특별한 패킷입니다(SMS-C 파트너와 교류 시 이 ID가 포함되면 보다 빠르게 메시지를 찾을 수 있음). 이 ID는 SR에 있으며 MT와 해당 SR을 연결하는 유일한 방법입니다.

필드  registered_delivery  (사양의 섹션 5.2.17에 설명됨)는 SR이 이 특정 MT에 요청되었는지 여부를 SMS-C에 알립니다. 특정 메시지에 대해 SR을 수신하지 않은 경우 필드에 올바르게 설정되어 있는지 확인합니다.  SUBMIT_SM  PDU.

smpp5

MT의 인코딩

주의: SMS 인코딩은 트랩과 구현이 많은 복잡한 주제입니다.

인코딩 문제가 발생하면 항상 SMS-C 파트너에게 문의하는 것이 좋습니다. SMS 파트너는 기술 플랫폼의 제약으로 인해 발생할 수 있는 지원 인코딩 및 특수 규칙에 대해 정확히 알고 있습니다. 그들에게 보내는 내용과 보내는 내용을 확인하도록 합니다. 성공적이고 안정적인 상호연결을 위한 유일한 경로입니다.

SMS 메시지는 GSM7 인코딩이라고도 하는 특수 7비트 인코딩을 사용합니다. Wikipedia GSM 03.38(영어)을 참조하십시오.

SMPP 프로토콜에서 GSM7 텍스트를 문자당 8비트로 확장하면 보다 간편하게 문제를 해결할 수 있습니다. SMS-C는 모바일로 전송하기 전에 문자당 7비트로 압축합니다. 즉, SMPP 프레임에서 SMS의 짧은 메시지 필드 길이는 최대 160바이트일 수 있지만, 모바일 네트워크에서 전송하는 경우에는 140바이트로 제한됩니다(가장 중요한 비트는 간단히 삭제됨).

인코딩 문제가 발생하면 몇 가지 중요 사항을 확인해야 합니다.

  • 먼저 인코딩에 속한 문자가 무엇인지 알아야 합니다. GSM7은 발음 구별 기호(액센트)를 일부 지원하고 있습니다. 특히 프랑스어에서 é와 è는 GSM7의 일부이지만 ê, â 또는 ï은 일부가 아닙니다. 스페인어의 경우 상황은 더 열악합니다.
  • cedilla(ç)가 있는 C는 GSM7 알파벳에서 대문자로만 표시되지만 통화 시 소문자 또는 “스마트” 문자로 렌더링됩니다. 일반적으로 이를 피하고 cedilla(프랑스어로 읽기가 매우 쉬움)를 없애거나 UCS-2로 전환하는 것이 좋습니다.
  • SMS-C 파트너가 명시적으로 요청하지 않는 한 SMS에서 ASCII 문자는 사용하지 마십시오. 8비트 문자가 포함되고 GSM7보다 적용 범위가 적으므로 이 인코딩으로 공간이 낭비됩니다.
  • Latin-1은 항상 지원되지 않습니다. Latin-1을 사용하기 전에 SMS-C 파트너와 함께 호환성을 확인합니다.
  • Adobe Campaign Classic 커넥터에서는 자국어 시프트 테이블을 지원하지 않습니다. 대신 UCS-2를 사용해야 합니다.
  • 통화 시 종종 UCS-2와 UTF-16이 혼합되기도 합니다. 사람들이 이모지와 UCS-2에서 거의 사용되지 않는 문자를 전송하는 경우 문제가 발생합니다.
  • GSM7 인코딩은 Wireshark에서 지원하지 않습니다. 특수 문자가 잘못 표시됩니다. GSM7 문자열이 제대로 인코딩되고 있는지 확인해야 하는 경우 16진수 코드와 GSM7 테이블을 비교해야 합니다.

다음  data_coding  필드는 사용되고 있는 인코딩을 알려 줍니다. 값 0이 사양에서는 기본 SMS-C 인코딩을 의미하지만 보통 GSM7을 의미한다는 것이 유일한 문제입니다. SMS-C에 확인  partner data_coding = 0과 연계된 인코딩(Adobe Campaign은 data_coding의 경우 GSM7만 지원)  = 0).

메시지의 최대 크기는 인코딩에 따라 다릅니다. 이 표에는 관련 모든 정보가 요약되어 있습니다.

인코딩
데이터 코딩
메시지 크기 (문자)
다중 부분 SMS의 부분 크기
사용 가능한 문자
GSM7
0
160
152
GSM7 기본 문자 세트 + 확장 문자 (확장 문자에는 문자 2개가 필요)
Latin-1
3
140
134
ISO-8859-1
UCS-2 UTF-16
8
70
67
유니코드 (통화 시 다름)

사용자 데이터 헤더(UDH)
UDH(User Data Header)는 SMS의 텍스트에 추가되는 소형 바이너리 헤더입니다. SMS 연결, 자국어 시프트 테이블, 로고/이미지(거의 사용하지 않음) 또는 WAP 푸시와 같은 특수 기능을 트리거할 수 있습니다.

UDH는 텍스트 필드(짧은 메시지 SMPP 필드)의 일부이므로 SMS의 유효 크기를 줄입니다. 예를 들어 SMS UDH를 연결하는 데 SMS 파트당 6바이트(7비트 문자가 아닌 실제 8비트 바이트 6개)가 사용되므로 메시지 파트당 7비트 문자 152개에만 충분한 공간이 제공됩니다.

Wikipedia에는 User Data Header 및 Concatenated SMS에 대한 유용한 문서(영어판)가 있습니다.

짧은 메시지에 UDH가 포함되어 있는지 확인하려면 esm_class의 비트 6과 7을 점검해야 합니다(사양의 섹션 5.2.12 참조). Wireshark는 인터페이스의 UDH를 구문 분석하고 정확한 정보를 제공합니다.

smpp7 위의 스크린샷에는 메시지 필드의 사용자 데이터 헤더(1), UDH에 포함된 정보(2), 패킷에 속하지 않지만 Wireshark가 계산한 추가 정보(3)가 표시됩니다. 짧은 메시지 본문 필드는 Wireshark에서 다시 조립한 전체 메시지가 포함되어 있어 매우 흥미롭습니다.

SR 수신 중
수신기가 바인딩되면 SMS-C는 언제든지 SR을 전송할 수 있습니다. SR은 의 2~5비트가 있는 DELIVER_SM PDU를 통해 전송됩니다  esm_class ​설정.

smpp8

다음  DELIVER_SM  PDU에 대한 빠른 응답 필요:  DELIVER_SM_RESP  동일한 PDU  sequence_number. 이 SR과 일치하는 MT를 찾으려면 다음을 검색합니다.  SUBMIT_SM_RESP  ID가 같은. 예를 들어 SR 과 일치하는 MT 는 다음과 같습니다.

smpp9

SR은  registered_delivery  필드는 MT에서 설정됩니다.

참고: Adobe Campaign Classic SMPP 커넥터는 이전에 도착하는 SR을 처리하지 않습니다.  SUBMIT_SM_RESP  패킷. 사양은 이 비헤이비어를 명시적으로 금지하지 않지만 잘못된 비헤이비어로 간주됩니다(메시지는 전송되기 전에 이미 수신됨). 이 사례가 너무 자주 발생하는 경우 SMS-C 파트너에게 플랫폼 수정을 요청하십시오.

SR의 short_message 필드 해독
SR PDU의 텍스트 필드에는 SMPP 프로토콜 사양의 부록 B에 설명된 특수 인코딩이 있습니다. 안타깝게도 대부분의 SMS-C가 이 형식을 어는 정도 준수하지만 이 형식은 프로토콜의 일부가 아닌 권장 사항일 뿐입니다.

SMS-C 파트너에게 자체 구현 설명서를 직접 요청하고 Wireshark에 표시되는 내용과 일치하는지 다시 확인해야 합니다. SMS-C 구현자는 구현 조차도 알지 못하는 경우가 있으며 이로 인해 문제와 오해가 발생합니다. 이 필드(특히 오류 코드)가 의심스러운 경우 주저하지 말고 SMS-C 파트너에게 도움을 요청하십시오.

기본 형식은 다음과 같습니다.

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

다음은 상기 줄을 읽기 위한 일반 지침입니다.

  • ID는에서 전송된 ID와 동일합니다  SUBMIT_SM_RESP ​일치하는 MT의
  • 텍스트 필드의 문제는 무시할 수 있습니다. 이 필드는 유용하지 않고 신뢰할 수 없기 때문에 Campaign에서 무시되며, SMS가 영숫자 ASCII가 아닌 다른 인코딩으로 전송된 경우에는 완전히 읽을 수도 없습니다. 이는 정상적인 비헤이비어가 아닙니다.
  • 필드 이름은 대소문자를 구분하지 않습니다(예: id: sub: Text: 는 ID: SUB: text: 로도 명시될 수 있습니다).
  • 다음  dlvrd ​필드는 일반적으로 SMS-C 파트너가 문서화하지 않으면 신뢰할 수 없습니다.
  • 원격 서버의 시계가 꺼져 있으므로 날짜에 특정 시간대가 발생하여 날짜를 실제로 사용할 수 없거나 날짜가 틀릴 수도 있습니다.
  • 다음  통계 ​필드는 부록 B에 정의된 값과 다른 값을 가질 수 있습니다. 상식과 SMSC 파트너의 설명서를 사용하여 의미를 파악합니다.
  • 다음  err ​필드는 SMS-C에 따라 완전히 달라지고 대부분의 경우 SMS-C 파트너가 문서화합니다. 코드 000은 성공을 나타내고 다른 코드는 오류를 나타내는 경우가 종종 있습니다. 필드는 종종 숫자이지만 16진수일 수도 있습니다.

동일한 MT에 여러 SR 사용
일부 SMS-C는 동일한 MT에 여러 SR을 전송하여 네트워크에서 MT의 진행률을 추적합니다. 대부분의 경우 클라이언트는 메시지를 수신한 시기(보통 마지막 SR임)만 알려고 하기 때문에 거의 사용할 수 없습니다.

확실하지 않은 경우 SMS-C에서 수신한 최신 SR에 대해서만 작업하여 메시지 상태를 검색합니다.

SMPP 창
작업과 응답은 비동기적이므로 응답을 기다리기 전에 여러 작업 PDU를 전송하여 전송률을 최적화할 수 있습니다. 응답이 없는 메시지의 수는 창이라고 합니다.

최대 4개의 창을 사용하는 전송의 예:
smpp10
현재 구현은 창을 제어하지 않으며 원격 SMS-C가 MT를 처리할 수 있을 만큼 빠를 것으로 예상합니다.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f