Ask Your Question
0

Dissector Syslog transmitted via relp protocol span multiple TCP packets

asked 2024-09-10 08:56:07 +0000

zhaoxian gravatar image

updated 2024-09-11 02:15:39 +0000

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 ... (more)

edit retag flag offensive close merge delete

Comments

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.

grahamb gravatar imagegrahamb ( 2024-09-10 10:09:28 +0000 )edit

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.

zhaoxian gravatar imagezhaoxian ( 2024-09-11 02:23:38 +0000 )edit

What are the message lengths you are working with that get fragmented?
Can they be generated with logger "some really long text string here ..."?

9114756 syslog 59 <13>2024-09-11T12:08:57.110845-05:00 ubuntu2204 root: hello


Is local tcp_srcport=Field.new("tcp.dstport") a typo? Should it be tcp.srcport?

Chuckc gravatar imageChuckc ( 2024-09-11 17:38:27 +0000 )edit

3 Answers

Sort by » oldest newest most voted
0

answered 2024-09-14 13:47:44 +0000

Chuckc gravatar image

See wiki page Protocols/relp for sample capture and first pass at lua dissector.

edit flag offensive delete link more
0

answered 2024-09-11 08:49:18 +0000

SYN-bit gravatar image

Wireshark is using a two-pass process. On the first pass every packet will be seen in packet order. The second pass happens when packets are displayed in the packet list, but also when a certain packet gets selected.

In your dissector code you need to make a distinction to what needs to be done only on the first pass (pinfo->fd->visited == false) and things that need to be done in subsequential passes.

Also reassembly of the TCP data is a little more complicated than what I can see in your Lua code.

Have a look at the doc/README.* documents in the repository for more detailed information.

edit flag offensive delete link more

Comments

Thank you, the script now works properly with the control of pinfo.visited.

zhaoxian gravatar imagezhaoxian ( 2024-09-12 01:19:28 +0000 )edit

I encountered another issue now. I intentionally created out-of-order TCP segments and tried to parse the reordered information. However, I found that I couldn't retrieve the length information of the reordered data using Field.new("tcp.reassembled.length") in Lua scripts. Similarly, I could not access the reordered data either. How should I retrieve the reordered information in Lua?

zhaoxian gravatar imagezhaoxian ( 2024-09-12 04:54:34 +0000 )edit
0

answered 2024-09-10 12:09:01 +0000

SYN-bit gravatar image

Maybe syslog message re-assembly is confusing you. When syslog messages are spanning multiple TCP segments, all the segmentw will be marked as TCP segment of a reassmbled PDU and only the last segment of the message will match the filter syslog. Re-assembly is enabled by default at the TCP layer, you can disable this with unchecking the TCP protocol preference Allow subdissector to reassemble TCP streams. This might improve your analysis.

If this was not the issue, please follow the suggestions of @grahamb :-)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2024-09-10 08:56:07 +0000

Seen: 148 times

Last updated: Sep 14