nfstream / nfstream

NFStream: a Flexible Network Data Analysis Framework.
https://www.nfstream.org
GNU Lesser General Public License v3.0
1.06k stars 118 forks source link

Cannot convert pcap file that consists of NGAP protocol #198

Open DLTeamTUC opened 1 month ago

DLTeamTUC commented 1 month ago

Hi, we have collected a pcap file containing signaling messages between our simulated 5G core and mobile user equipment (UE). We have modify the pcap so that it only includes NGAP protocol. See the pcap here.

However, when we process these pcap using NFStream, no flows are generated. We use the following python code to convert pcap to csv: Python code. It appears that the NGAP protocol might not be supported by the tool. Could you please confirm if this is indeed the case? Any suggestion to capture and convert pcap file with NGAP packets to csv?

Thank you.

drnpkr commented 1 month ago

Hi,

using your code and the provided PCAPNG file, I get exactly one IP flow in the CSV. This flow has 30125 packets, which matches the packet count in the PCAPNG file. So NFStream processes all the packets and converts them into a flow, but only on the IP level.

SCTP is not supported, hence you have 0 for src_port and dst_port. No protocols built on top of UDP/TCP are supported, i.e., no NGAP support.

I hope this clarifies your concern.

Unfortunately, I cannot help with suggesting a tool that can convert your PCAPNG to flows with information at the granularity of NGAP.

DLTeamTUC commented 1 month ago

I'm sorry for my mistake, I was looking at a different csv file. Yes, using the code the flow is only 1. Then my next question are, how is it collected into 1 flow only? Is it because of the packets are coming from the same IP address and going to the same IP address? I was wondering maybe those 30125 packets can be split into several flows? Maybe set the duration?

drnpkr commented 1 month ago

The flow key to create IP flows is a 6 tuple (src and dst IPs, src and dst ports, protocol, vlan ID) with tunnel decoding turned off, or 7 tuple if tunnel decoding is turned on (the seventh parameter is the tunnel ID).

Generally, a flow is defined as a set of packets that share some common properties (n-tuple) over a period of time. Since in your trace you have a communication only between 2 IP addresses, the protocol is 132 (SCTP), source and destination ports are both zeros (due to the lack of support for this protocol), no VLAN and no tunnel are present, this will yield a set of packets that will belong to the same IP flow based on the properties that define the flow (7 tuple, because by default, tunnel decoding is turned on).

The duration of your traffic trace is 611 seconds. NFStream default idle timeout is set to 120 seconds (since there is no such a long idle period in packet transfer, this won't be activated), while active timeout is set to 1800 seconds.

One way to create multiple flows is to reduce the active timeout to 30 seconds. This will "break" your trace into multiple flows.