Materiał artykułu pochodzi z mojego .
Używanie TShark do analizy pakietów RTP
W przeszłości Zmontowaliśmy obwód zdalnego sterowania z generatora tonu i detektora tonu, których komunikacja odbywała się za pomocą strumienia RTP.
W tym artykule kontynuujemy badania nad transmisją sygnału audio za pomocą protokołu RTP. Na początek podzielmy naszą aplikację testową na nadajnik i odbiornik oraz nauczmy się badać strumień RTP za pomocą analizatora ruchu sieciowego.
Abyśmy więc mogli wyraźniej zobaczyć, które elementy programu odpowiadają za transmisję RTP, a które za odbiór, dzielimy nasz plik mstest6.c na dwa niezależne programy dla nadajnika i odbiornika; umieścimy wspólne funkcje, z których oba korzystają w trzecim pliku, który nazwiemy mstest_common.c, zostanie połączony przez nadajnik i odbiornik za pomocą dyrektywy include:
/* Файл mstest_common.c Общие функции для передатчика и приемника. */
#include <mediastreamer2/msfilter.h>
#include <mediastreamer2/msticker.h>
#include <mediastreamer2/msrtp.h>
#include <ortp/rtpsession.h>
#include <ortp/payloadtype.h>
define PCMU 0
/*---------------------------------------------------------*/
/* Функция регистрации типов полезных нагрузок. */
void register_payloads(void)
{
/* Регистрируем типы нагрузок в таблице профилей. Позднее, по индексу взятому
из заголовка RTP-пакета из этой таблицы будут извлекаться параметры
нагрузки, необходимые для декодирования данных пакета. */
rtp_profile_set_payload (&av_profile, PCMU, &payload_type_pcm8000);
}
/*---------------------------------------------------------*/
/* Эта функция создана из функции create_duplex_rtpsession() в audiostream.c медиастримера2. */
static RtpSession *create_rtpsession (int loc_rtp_port, int loc_rtcp_port, bool_t ipv6, RtpSessionMode mode)
{
RtpSession *rtpr; rtpr = rtp_session_new ((int) mode);
rtp_session_set_scheduling_mode (rtpr, 0);
rtp_session_set_blocking_mode (rtpr, 0);
rtp_session_enable_adaptive_jitter_compensation (rtpr, TRUE);
rtp_session_set_symmetric_rtp (rtpr, TRUE);
rtp_session_set_local_addr (rtpr, ipv6 ? "::" : "0.0.0.0", loc_rtp_port, loc_rtcp_port);
rtp_session_signal_connect (rtpr, "timestamp_jump", (RtpCallback) rtp_session_resync, 0);
rtp_session_signal_connect (rtpr, "ssrc_changed", (RtpCallback) rtp_session_resync, 0);
rtp_session_set_ssrc_changed_threshold (rtpr, 0);
rtp_session_set_send_payload_type(rtpr, PCMU);
/* По умолчанию выключаем RTCP-сессию, так как наш пульт не будет использовать
её. */
rtp_session_enable_rtcp (rtpr, FALSE);
return rtpr;
}
Teraz oddzielny plik nadajnika:
/* Файл mstest6.c Имитатор пульта управления (передатчика). */
#include <mediastreamer2/dtmfgen.h>
#include <mediastreamer2/msrtp.h>
#include "mstest_common.c"
/*----------------------------------------------------------*/
int main()
{
ms_init();
/* Создаем экземпляры фильтров. */
MSFilter *voidsource = ms_filter_new(MS_VOID_SOURCE_ID);
MSFilter *dtmfgen = ms_filter_new(MS_DTMF_GEN_ID);
/* Создаем фильтр кодера. */
MSFilter *encoder = ms_filter_create_encoder("PCMU");
/* Регистрируем типы нагрузки. */
register_payloads();
/* Создаем RTP-сессию передатчика. */
RtpSession *tx_rtp_session = create_rtpsession (8010, 8011, FALSE, RTP_SESSION_SENDONLY);
rtp_session_set_remote_addr_and_port(tx_rtp_session,"127.0.0.1", 7010, 7011);
rtp_session_set_send_payload_type(tx_rtp_session, PCMU);
MSFilter *rtpsend = ms_filter_new(MS_RTP_SEND_ID);
ms_filter_call_method(rtpsend, MS_RTP_SEND_SET_SESSION, tx_rtp_session);
/* Создаем источник тактов - тикер. */
MSTicker *ticker_tx = ms_ticker_new();
/* Соединяем фильтры передатчика. */
ms_filter_link(voidsource, 0, dtmfgen, 0);
ms_filter_link(dtmfgen, 0, encoder, 0);
ms_filter_link(encoder, 0, rtpsend, 0);
/* Подключаем источник тактов. */
ms_ticker_attach(ticker_tx, voidsource);
/* Настраиваем структуру, управляющую выходным сигналом генератора. */
MSDtmfGenCustomTone dtmf_cfg;
dtmf_cfg.tone_name[0] = 0;
dtmf_cfg.duration = 1000;
dtmf_cfg.frequencies[0] = 440;
/* Будем генерировать один тон, частоту второго тона установим в 0. */
dtmf_cfg.frequencies[1] = 0;
dtmf_cfg.amplitude = 1.0;
dtmf_cfg.interval = 0.;
dtmf_cfg.repeat_count = 0.;
/* Организуем цикл сканирования нажатых клавиш. Ввод нуля завершает
* цикл и работу программы. */
char key='9';
printf("Нажмите клавишу команды, затем ввод.n"
"Для завершения программы введите 0.n");
while(key != '0')
{
key = getchar();
if ((key >= 49) && (key <= 54))
{
printf("Отправлена команда: %cn", key);
/* Устанавливаем частоту генератора в соответствии с
* кодом нажатой клавиши. */
dtmf_cfg.frequencies[0] = 440 + 100*(key-49);
/* Включаем звуковой генератор c обновленной частотой. */
ms_filter_call_method(dtmfgen, MS_DTMF_GEN_PLAY_CUSTOM, (void*)&dtmf_cfg);
}
/* Укладываем тред в спячку на 20мс, чтобы другие треды
* приложения получили время на работу. */
ms_usleep(20000);
}
}I na koniec plik odbiornika:
/* Файл mstest7.c Имитатор приемника. */
include <mediastreamer2/mssndcard.h>
include <mediastreamer2/mstonedetector.h>
include <mediastreamer2/msrtp.h>
/* Подключаем заголовочный файл с функциями управления событиями медиастримера.*/
include <mediastreamer2/mseventqueue.h>
/* Подключаем файл общих функций. */
include "mstest_common.c"
/* Функция обратного вызова, она будет вызвана фильтром, как только он обнаружит совпадение характеристик входного сигнала с заданными. */
static void tone_detected_cb(void *data, MSFilter *f, unsigned int event_id,MSToneDetectorEvent *ev)
{
printf("Принята команда: %sn", ev->tone_name);
}
/*----------------------------------------------------------*/
int main()
{
ms_init();
/* Создаем экземпляры фильтров. */
MSSndCard *card_playback = ms_snd_card_manager_get_default_card(ms_snd_card_manager_get());
MSFilter *snd_card_write = ms_snd_card_create_writer(card_playback);
MSFilter *detector = ms_filter_new(MS_TONE_DETECTOR_ID);
/* Очищаем массив находящийся внутри детектора тонов, он описывает
* особые приметы разыскиваемых сигналов.*/
ms_filter_call_method(detector, MS_TONE_DETECTOR_CLEAR_SCANS, 0);
/* Подключаем к фильтру функцию обратного вызова. */
ms_filter_set_notify_callback(detector, (MSFilterNotifyFunc)tone_detected_cb, NULL);
/* Создаем массив, каждый элемент которого описывает характеристику
* одного из тонов, который требуется обнаруживать:
Текстовое имя
* данного элемента, частота в герцах, длительность в миллисекундах,
* минимальный уровень относительно 0,775В. */
MSToneDetectorDef scan[6]=
{
{"V+",440, 100, 0.1}, /* Команда "Увеличить громкость". */
{"V-",540, 100, 0.1}, /* Команда "Уменьшить громкость". */
{"C+",640, 100, 0.1}, /* Команда "Увеличить номер канала". */
{"C-",740, 100, 0.1}, /* Команда "Уменьшить номер канала". */
{"ON",840, 100, 0.1}, /* Команда "Включить телевизор". */
{"OFF", 940, 100, 0.1}/* Команда "Выключить телевизор". */
};
/* Передаем "приметы" сигналов детектор тонов. */
int i;
for (i = 0; i < 6; i++)
{
ms_filter_call_method(detector, MS_TONE_DETECTOR_ADD_SCAN, &scan[i]);
}
/* Создаем фильтр декодера */
MSFilter *decoder=ms_filter_create_decoder("PCMU");
/* Регистрируем типы нагрузки. */
register_payloads();
/* Создаем RTP-сессию приемника. */
MSFilter *rtprecv = ms_filter_new(MS_RTP_RECV_ID);
RtpSession *rx_rtp_session = create_rtpsession (7010, 7011, FALSE, RTP_SESSION_RECVONLY);
ms_filter_call_method(rtprecv, MS_RTP_RECV_SET_SESSION, rx_rtp_session);
/* Создаем источник тактов - тикер. */
MSTicker *ticker_rx = ms_ticker_new();
/* Соединяем фильтры приёмника. */
ms_filter_link(rtprecv, 0, decoder, 0);
ms_filter_link(decoder, 0, detector, 0);
ms_filter_link(detector, 0, snd_card_write, 0);
/* Подключаем источник тактов. */
ms_ticker_attach(ticker_rx, rtprecv);
char key='9';
printf( "Для завершения программы введите 0.n");
while(key != '0')
{
key = getchar();
/* Укладываем тред в спячку на 20мс, чтобы другие треды * приложения получили время на работу. */
ms_usleep(20000);
}
}
Kompilujemy nadajnik i odbiornik, a następnie uruchamiamy każdy z nich w osobnej konsoli. Wtedy powinno działać jak poprzednio - jedynie w konsoli nadajnika wpisujemy cyfry od 1 do 6, a odpowiedź na nie powinna pojawić się w konsoli odbiornika. Dźwięki powinny być słyszalne w głośniku. Jeżeli wszystko jest tak, to nawiązaliśmy połączenie pomiędzy odbiornikiem a nadajnikiem - następuje ciągła transmisja pakietów RTP od nadajnika do odbiornika.
Teraz czas zainstalować analizator ruchu, w tym celu zainstalujemy konsolową wersję doskonałego programu Wireshark - nazywa się TShark. Do dalszych dyskusji wybrałem TShark, aby ułatwić opis zarządzania programem. Dzięki Wireshark potrzebowałbym morza zrzutów ekranu, które mogłyby szybko stać się nieaktualne, gdy zostanie wydana nowa wersja Wireshark.
Jeśli wiesz, jak korzystać z Wireshark, możesz go użyć do przestudiowania naszych przykładów. Ale nawet w tym przypadku zalecam opanowanie TShark, ponieważ pomoże Ci to zautomatyzować testowanie aplikacji VoIP, a także przeprowadzić zdalne przechwytywanie.
Zainstaluj TShark za pomocą polecenia:
$ sudo apt-get install tsharkTradycyjnie wynik instalacji sprawdzamy pytając o wersję programu:
$ tshark --versionJeśli otrzymamy odpowiednią odpowiedź, kontynuujemy.
Ponieważ nasze pakiety na razie trafiają tylko do komputera, możemy powiedzieć tsharkowi, aby pokazywał tylko takie pakiety. Aby to zrobić, musisz wybrać przechwytywanie pakietów z interfejsu sprzężenia zwrotnego (pętla zwrotna), przekazując TShark opcję -ilo:
$ sudo tshark -i loWiadomości o pakietach wysłanych przez nasz nadajnik od razu zaczną napływać do konsoli (w sposób ciągły, niezależnie od tego, czy wcisnęliśmy przycisk na pilocie, czy nie). Być może na Twoim komputerze znajdują się programy, które również wysyłają pakiety przez pętlę lokalną. W takim przypadku otrzymamy mieszankę pakietów naszych i pakietów innych osób. Aby mieć pewność, że na liście zobaczymy tylko pakiety wysłane przez naszego pilota, dodamy filtr po numerze portu. Naciskając Ctrl-C zatrzymujemy analizator i wprowadzamy filtr dla numeru portu, którego pilot używa jako portu docelowego dla swojej transmisji (8010): -f „port udp 8010”. Teraz nasza linia poleceń będzie wyglądać następująco:
$ sudo tshark -i lo -f "udp port 8010"W konsoli pojawią się następujące dane wyjściowe (pierwsze 10 linii):
1 0.000000000 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
2 0.020059705 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
3 0.040044409 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
4 0.060057104 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
5 0.080082311 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
6 0.100597153 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
7 0.120122668 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
8 0.140204789 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
9 0.160719008 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172
10 0.180673685 127.0.0.1 → 127.0.0.1 UDP 214 8010 → 7010 Len=172Na razie nie są to pakiety, ale numerowana lista zdarzeń, gdzie każda linia to komunikat o kolejnym pakiecie, który został zauważony na interfejsie. Ponieważ zajęliśmy się już filtrowaniem pakietów, na liście widzimy tylko komunikaty o pakietach z naszego nadajnika. Następnie odszyfrujmy tę tabelę według numerów kolumn:
Numer wydarzenia.
Czas jego wystąpienia.
Źródłowy adres IP pakietu i docelowy adres IP pakietu.
Protokół pakietu jest pokazywany jako UDP, ponieważ pakiety RTP są wysyłane jako ładunek wewnątrz pakietów UDP.
Rozmiar pakietu w bajtach.
Numer portu źródłowego pakietu i numer portu docelowego pakietu.
Rozmiar ładunku pakietu, stąd możemy wywnioskować, że nasz nadajnik generuje pakiety RTP o rozmiarze 172 bajtów, które niczym kaczka w klatce piersiowej znajdują się w pakiecie UDP o rozmiarze 214 bajtów.
Teraz czas zajrzeć do pakietów UDP, w tym celu uruchomimy TShark z rozszerzonym zestawem kluczy:
sudo tshark -i lo -f "udp port 8010" -P -V -O rtp -o rtp.heuristic_rtp:TRUE -xW rezultacie wyjście programu zostanie wzbogacone - do każdego zdarzenia dodane zostanie odszyfrowanie wewnętrznej zawartości pakietu, który to spowodował. Aby lepiej przyjrzeć się wynikom, możesz zatrzymać TShark, naciskając Ctrl-C, lub zduplikować jego dane wyjściowe do pliku, dodając potok do programu tee do polecenia run, podając nazwę pliku, tee <nazwa pliku>:
$ sudo tshark -i lo -f "udp port 8010" -P -V -O rtp -o rtp.heuristic_rtp:TRUE -x | tee log.txtPrzyjrzyjmy się teraz co mamy w pliku, oto pierwszy z niego pakiet:
1 0.000000000 127.0.0.1 → 127.0.0.1 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x6B8B4567, Seq=58366, Time=355368720
Frame 1: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1User Datagram Protocol, Src Port: 8010, Dst Port: 7010
Real-Time Transport Protocol [Stream setup by HEUR RT (frame 1)]
[Setup frame: 1]
[Setup Method: HEUR RT]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: ITU-T G.711 PCMU (0)
Sequence number: 58366 [Extended sequence number: 58366]
Timestamp: 355368720
Synchronization Source identifier: 0x6b8b4567 (1804289383)
Payload: ffffffffffffffffffffffffffffffffffffffffffffffff...
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E.
0010 00 c8 3c 69 40 00 40 11 ff b9 7f 00 00 01 7f 00 ..<i@.@.........
0020 00 01 1f 4a 1b 62 00 b4 fe c7 80 00 e3 fe 15 2e ...J.b..........
0030 7f 10 6b 8b 45 67 ff ff ff ff ff ff ff ff ff ff ..k.Eg..........
0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00d0 ff ff ff ff ff ff ......Następny artykuł poświęcimy analizie informacji zawartych w tym zestawieniu i nieuchronnie porozmawiamy o wewnętrznej strukturze pakietu RTP.
Źródło: www.habr.com