add -w output.pcap command line option to direct the output to a pcap #853
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… file instead of normal NIC
|
Thanks for the PR. I'll merge into a staging branch to test. I'll try to get this into 4.5.0. |
fklassen
changed the base branch from
master
to
Feature_#853_direct_traffic_to_pcap
…e/direct-traffic-to-pcap
fklassen
merged commit 457a0f6
into
appneta:Feature_#853_direct_traffic_to_pcap
1 check passed
fklassen
reviewed
Jun 3, 2024
| @@ -671,6 +686,9 @@ sendpacket_get_hwaddr(sendpacket_t *sp) | |||
|
|
|||
| if (sp->handle_type == SP_TYPE_KHIAL) { | |||
| addr = sendpacket_get_hwaddr_khial(sp); | |||
| } else if( sp->handle_type == SP_TYPE_LIBPCAP_DUMP) { | |||
| sendpacket_seterr(sp, "Error: sendpacket_get_hwaddr() not yet supported for pcap dump"); | |||
There was a problem hiding this comment.
This will need to get implemented.
There was a problem hiding this comment.
I think sendpacket_get_hwaddr() only makes sense for real interfaces. Pcap file as an output doesn't support sendpacket_get_hwaddr. The err msg is misleading.
There was a problem hiding this comment.
OK, I still have this in staging and will investigate. I'll probably just change the error message. I may get 4.5.0-beta1 out before this merges so that the testers can have some time to shake out the bugs.
fklassen
added a commit
that referenced
this pull request
Jun 3, 2024
Fix build and run `clang-format`.
fklassen
added a commit
that referenced
this pull request
Jun 6, 2024
Fix build and run `clang-format`.
fklassen
added a commit
that referenced
this pull request
Jun 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
tcpreplay is a great tool to replay pcap files as a traffic generator. tcpreplay-edit is even better with the feature of --unique-ip to simulate real traffic, being fed only a small amount of seed traffic as input. However, to test a system's stability, performance and load balancing, and for troubleshooting/debugging in such an environment, we need large amount of randomly distributed, but repeated traffic as single pcap file.
Right now there's no easy way for it. The typical way to do it is to use tcpreplay-edit --unique-ip or t-rex on one (virtual) machine to generate random traffic to a specific port, and then use tcpdump -i -w on another to sniff the traffic and store it to a pcap file. This isn't the most convenient way and its time consuming. Also this settings have a side effect where the played traffic causes the overall network system to respond to them, thus recorded traffic isn't pure randomized version of the seed traffic, but it includes quite a few responding traffic.
By giving tcpreplay-edit a -w <output.pcap> option, we can simply run tcpreplay-edit --unique-ip -w http_many.pcap http.pcap to generate such a traffic.
This PR is an effort to cover a use case just like that.