Issue using CLONE Pattern?

[wem541]

I am attempting to use MGEN to clone a few different traffic captures that I have. I have used the feature in the past without trouble; however, I have encountered an issue with the recent captures.

I created a copy of the .pcap using editcap: editcap filename.pcap filename.dat
I then used the following line to copy the data with GMEN: 0.0 ON 1 UDP DST / CLONE [tcpdump filename.dat [0]]

This has worked in the past but I have four files that return a segmentation fault. Two of the files present a fault immediately (files sizes close to 3 GB), while one faults after about 12 minutes of traffic generation (file size is approximately 450 MB). The mgen.pdf mentions segmentation on Linux machines and presents a few commands to manipulate the settings; however using these did not change my result.

I have looked at the captures in the proximity of the timestamps where the fault occurs and cannot find any packets that are different from those present in successful attempts.

My questions boil down to:

1. Is there some literature on what would cause the segmentation fault (literally the only feed back I get, then the command prompt returns and traffic stops being sent)?

2. Is there a maximum file size for the CLONE pattern, or is the amount of free system memory required for operation related to the size of the file being cloned?

[bebopagogo]

I have had some issues with pcap files that have some sort of content that causes a problem to the libpcap parser.  I think it has sometimes been the case when the file has a partial packet at its end or some other invalid packet issue. One way I have worked around this is to prefilter the file with tcpdump using -r to read the pcap file and -w to write a file with some filter applied to extract specific packets of interest.  It’s been a while, but I think that allowed me to “clean up” a pcap file that could then be uses as a “clone” reference without issue. If the file is something you can share (or even use the tcpdump -w / -r to extract a subset of the file that is problematic) I could take a look at it.  The file size is large but not aware of a specific size limit and I think the mgen code reads the data from file and doesn’t load it into memory (although I would need to double check that). You could also use the “”tcpsplice” command  to do some detective work and identify the portion of the file that is the problem by extracting portions of the file. Best regards, Brian From: wem541 ***@***.***> Reply-To: USNavalResearchLaboratory/mgen ***@***.***> Date: Thursday, May 2, 2024 at 6:52 PM To: USNavalResearchLaboratory/mgen ***@***.***> Cc: Subscribed ***@***.***> Subject: [USNavalResearchLaboratory/mgen] Issue using CLONE Pattern? (Discussion #55) I am attempting to use MGEN to clone a few different traffic captures that I have. I have used the feature in the past without trouble; however, I have encountered an issue with the recent captures. I created a copy of the .pcap using editcap: editcap .pcap .dat I then used the following line to copy the data with GMEN: 0.0 ON 1 UDP DST / CLONE [tcpdump .dat[0]] This has worked in the past but I have four files that return a segmentation fault. Two of the files present a fault immediately (files sizes close to 3 GB), while one faults after about 12 minutes of traffic generation (file size is approximately 450 MB). The mgen.pdf mentions segmentation on Linux machines and presents a few commands to manipulate the settings; however using these did not change my result. I have looked at the captures in the proximity of the timestamps where the fault occurs and cannot find any packets that are different from those present in successful attempts. My questions boil down to: Is there some literature on what would cause the segmentation fault (literally the only feed back I get, then the command prompt returns and traffic stops being sent)? Is there a maximum file size for the CLONE pattern, or is the amount of free system memory required for operation related to the size of the file being cloned? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wem541]

Thank you. I will try to splice the file and see if I can isolate the problem. I am a student and fairly new at using these tools. As far as sharing the files, I will have to consult some coworkers. They are snippets from IoT databases that were supplied to us from other entities and I am not sure we have rights for distribution.