Многократные сообщения диаметра в одном заголовке TCP

Question

Я хочу использовать tshark для фильтрации и обработки сообщений диаметра. В моем захвате я вижу, что у меня есть три сообщения диаметра в одном заголовке TCP. Мой вариант использования требует от меня поиска Result-Code в сообщении диаметра. В соответствии со спецификацией диаметра можно иметь несколько кодов результата в одном сообщении диаметра. Также возможно не иметь код результата в сообщении диаметра.

По этой причине, если я получу код результата как A,B,C для сообщений трех диаметров, я не смогу распознать, какой код результата принадлежит какому сообщению диаметра.

Можно ли применить некоторые плагины / функции, которые помогут мне разделить сообщения трех диаметров?

Я мог видеть, что есть старая цепочка по аналогичной теме в https://ask.wireshark.org/questions/4291/multiple-occurrences-filter-for-diameter но нет ответа на вопрос, как это можно сделать.

Answer 1

Прежде всего, ваше предположение о коде результата неверно.

Согласно RFC 6733 (3588 говорят то же самое):

7.1. Код результата AVP

Код результата AVP (код AVP 268) имеет тип Unsigned32 и
указывает, был ли конкретный запрос выполнен успешно или
произошла ошибка. Все ответные сообщения Diameter в IETF
Спецификации приложения Diameter ДОЛЖНЫ включать один код результата AVP.

Если вы будете использовать Wireshark, вы сможете увидеть каждый из ответов по отдельности, и вы сможете легко увидеть, какой AVP принадлежит к каждому ответу

Answer 2

Я буду второй Раджив по этому вопросу. При анализе большого количества сообщений диаметра управление сообщениями объединенного диаметра в одной полезной нагрузке TCP становится неразрешимым.

Пример:

tshark -Tfields -e diameter.Session-Id -e diameter.Result-Code -e diameter.CC-Total-Octets -r mydiametercap.pcap -Y "diameter.Result-Code" > session-ids-and-results.txt

Эта команда иногда дает мне (абстрактный) вывод:

<session-id-1>,<session-id-2>,<session-id-3><tab><many result codes (sometimes 3 per message)><tab><one value of total octets>

Я не могу поверить, что все поля следуют одному и тому же соглашению, и поэтому не могу использовать надежный алгоритм синтаксического анализа для просмотра результатов. Еще хуже, когда вы думаете, что AVP (которые интерпретируются очень плоско в этой реализации диаметра) могут принадлежать к части MSCC или к совершенно другой части, и нет ничего, что их разделяло бы.

Не поймите меня неправильно: правила tshark...:-) Просто пытаюсь сделать это еще лучше.