Dissector Syslog transmitted via relp protocol span multiple TCP packets
I am currently facing an issue with the parsing results in Wireshark, where the display order of parsed information is dependent on the sequence in which packets are clicked rather than the chronological order in which the packets were captured. This has caused discrepancies in the presentation of parsed data, leading to potential misinterpretation of packet content.
As I parse syslog messages that span multiple TCP packets, it is essential for me to ensure that the parsed information accurately reflects the temporal sequence in which the packets were recorded, rather than being influenced by the order in which the packets are clicked during analysis.
Despite my efforts to explore different strategies, such as utilizing Lua scripts to manage packet parsing, I have been unable to decouple the display order of parsing results from the packet click order within Wireshark's protocol tree. I seek advice and guidance on how to address this issue and align the display of parsed data solely with the temporal sequencing of packet capture, independent of user interaction.
-- 创建一个空的 Tvb 对象
local current_time = os.time()
local formatted_time = os.date("%Y%m%d_%H%M%S", current_time)
local max_file_size=10 * 1024 --10M
local listen_port=514
local buf="" --to record the remaind bytes which are not a complete message.
local tcp_dstport=Field.new("tcp.dstport")
local tcp_srcport=Field.new("tcp.dstport")
local tcp_stream=Field.new("tcp.stream")
local tcp_len=Field.new("tcp.len")
local data_field = Field.new("data.data")
local file_handles = {} -- 用于保存不同 TCP 流的文件句柄
local function get_time()
return os.date("%Y%m%d_%H%M%S",os.time())
end
-- 创建一个函数根据流号生成文件路径
local function get_file_path(stream_number)
return string.format("C:\\Users\\zhaoxian\\Downloads\\Syslog_Stream_%s_%s.log", stream_number,get_time())
end
local relp_proto = Proto("RELP", "RELP Protocol")
_G.MAXSTRINGSZ = 0
-- Define fields for RELP protocol
local relp_fields = {
syslog_records = ProtoField.string("relp.syslog_records", "Syslog Records")
}
relp_proto.fields = relp_fields
function relp_proto.dissector(tvbuf, pinfo, tree)
if (tcp_dstport().value== listen_port) or (tcp_srcport().value== listen_port) then
local tcp_length=tcp_len().value
local buffer=tvbuf(tvbuf():len()-tcp_length,tcp_length)
local stream_number = tcp_stream()
local subtree = tree:add(relp_proto, tvbuf(tvbuf():len()-tcp_length,tcp_length))
local syslog_records = tvbuf(tvbuf():len()-tcp_length,tcp_length):string()
local start_pos = 0
local end_p=0
for record, end_pos in string.gmatch(syslog_records, "([^\n]+)()\n") do
local count = 0
for _ in string.gmatch(record, '\239\191\189') do
count = count + 1
end
local record_tree = subtree:add(relp_fields.syslog_records, buffer(start_pos,record:len()-2*count),buf .. record)
--record_tree:set_text(tostring(pinfo.number).."Syslog Record " .. record_number .. ": " .. buf .. record)
start_pos = end_pos
end_p=end_pos
buf=""
end
if end_p < buffer:len() then
buf=buffer(end_p,buffer():len()-end_p):string()
end
end
end
--tcp_table = DissectorTable.get("tcp.port")
--tcp_table:add(514, relp_proto)
register_postdissector(relp_proto)
Version 4.2.4 (v4.2.4-0-g1fe5bce8d665).
Compiled (64-bit) using Microsoft Visual Studio 2022 (VC++ 14.37, build 32822), with GLib 2.78.0, with Qt 6.5.3, with libpcap, with zlib 1.3.0, with PCRE2, with Lua 5.2.4 (with UfW patches), with GnuTLS 3.8.3 and PKCS #11 support, with Gcrypt ...
Can you provide more information, e.g. Wireshark version, a sample capture file and what packets you click on in that capture to create the effect you're reporting.
Reliable Event Logging Protocol (RELP)
Due to network restrictions, I am unable to attach files. However, I have provided the version of Wireshark and the script I am using. When I drag data into Wireshark, if I first click on a TCP packet with a syslog message (where the last part of the message is incomplete and referred to as a leftover part), and then select another TCP packet with a syslog message, the leftover part from the previous packet will be concatenated into the protocol tree of the current packet. This behavior is different from what I actually expect. I expect the concatenation to be based on the order of data collection, rather than the data being viewed later.
What are the message lengths you are working with that get fragmented?
Can they be generated with
logger "some really long text string here ..."
?Is
local tcp_srcport=Field.new("tcp.dstport")
a typo? Should it betcp.srcport
?