TRAFFIC_REPLAY(7)

📦
version 4.24.7 · 13 versions
, in fedora 44

💖 TRAFFIC_REPLAY 💖

traffic_replay — the Samba traffic generation tool, aka section 7 of the User Commands manual, aka the thing you pull up when you need your DC to sweat a little 💅

✨ NAME ✨

traffic_replay — Samba traffic generation tool. That's it, that's the vibe. 🎀

🌸 SYNOPSIS 🌸

Okay bestie, there are four ways to call this thing and you gotta pick your lane. Here's the first one, the big main-character traffic-replay mode:

traffic_replay [-F, --fixed-password <test-password>]
 [-T, --packets-per-second <number>]
 [-S, --scale-traffic <scale by factor>]
 [-r, --replay-rate <scale by factor>] [-D, --duration <seconds>]
 [--traffic-summary <output file>] [-I, --instance-id <id>]
 [-K, --prefer-kerberos] [-B, --badpassword-frequency <frequency>]
 [--dns-rate <rate>] [-t, --timing-data <file>] [--random-seed <seed>]
 [-U, --username user] [--password <password>]
 [-W --workgroup <workgroup>] [--realm <realm>]
 [-s, --config-file <file>] [-k, --kerberos <kerberos>]
 [--ipaddress <address>] [-P, --machine-pass] [--option <option>]
 [-d, --debuglevel <debug level>] [--conversation-persistence <0-1>]
 [--latency-timeout <seconds>] [--stop-on-any-error] {summary-file}
 {dns-hostname}

Then the second one — the generate-users-only era, when you just want people, not traffic:

traffic_replay [-G, --generate-users-only]
 [-F, --fixed-password <test-password>]
 [-n, --number-of-users <total users>]
 [--number-of-groups <total groups>]
 [--average-groups-per-user <average number>]
 [--group-memberships <total memberships>] [--max-members <group size>]
 {dns-hostname}

Third one, the glow-down, the cleanup arc:

traffic_replay {-c|--clean-up} {dns-hostname}

And fourth, the little baby invocation that just wants attention:

traffic_replay [-h, --help] [-V, --version]

🦋 DESCRIPTION 🦋

So this tool is part of the samba(7) suite, periodt. 💜

What does it do? It generates traffic, obviously — specifically so you can measure how a Samba DC performs, and test how well Samba will scale as a network grows and grows and grows. It can simulate multiple different hosts all making multiple different types of requests at a DC. Like a whole group chat of machines spamming your domain controller at once. 🫶

Real talk though: this tool is meant to run against a dedicated test DC, not a live DC that's out there handling actual real network traffic. Do not aim this at production, bestie, I am begging you 😭

And now the part you need to know before you go feral with it: a side-effect of running this tool is that user accounts will be created on the DC, because that's how it tests various Samba operations. And since creating accounts can be very time-consuming, those users will remain on the DC by default. They just… stay. Living there. Rent-free. 🏠

To remove these accounts, use the --clean-up option. That's your exit strategy. 👑

(to be continued, bestie — there's more of this page coming)

✨ OPTIONS ✨

okay bestie, buckle up, this is where it gets juicy 💖

  • -h, --help — prints a lil summary of all the command line options, so you can vibe-check what you're working with.
  • summary-file — the file holding the network traffic you wanna replay. this should be a traffic-model (the kind that traffic_learner generates, iykyk). based on this file, the tool is gonna generate conversations, which are basically little representations of Samba activity between a network host and the DC.
  • dns-hostname — the full DNS hostname of the DC you're testing. the Samba activity in the summary-file gets replicated and pointed at this DC. highly recommend you use a dedicated DC for testing — do NOT run this tool against a DC that's out there processing live network traffic, that's giving chaos 😭
  • -F, --fixed-password test-password — test users get created when this tool runs, so that real Samba activity (like authorizing users) can be mimicked. this option sets the password used for any test users that get created.
heads up: any users this tool creates will stay on the DC until you run the --clean-up option. so the test-password needs to be the same every single time you run the tool, otherwise the test users won't authenticate correctly. periodt.
  • random-seed — a number to seed the random number generator with. when traffic is generated from a model-file, use this to keep the traffic consistent across multiple test runs. this is the move for comparing Samba's performance between different releases 💅

🦋 Traffic Model Options 🦋

when the summary-file is a traffic-model (produced by traffic_learner), use these options to alter the traffic that gets generated.

  • -D, --duration seconds — the approximate duration, in seconds, to generate traffic for. default is 60 seconds.
  • -T, --packets-per-second number — generate this many packets per second, no matter what the traffic rate of the sample the model was based on was. this cannot be used with -S.
  • -S, --scale-traffic factor — bumps up the number of conversations by this factor, relative to the original traffic sample the model was based on. this option won't change the rate at which packets get sent (that's still based on the traffic model), but it means more conversations get replayed. it can't be combined with -T, since that sets the traffic rate a whole different way.
  • -r, --replay-rate factor — replays the traffic faster by this factor. this won't change the number of packets sent, but it squeezes them into fewer conversations, which may reduce resource usage. slay 🎀
  • --traffic-summary output-file — instead of replaying a traffic-model, this generates a traffic-summary file based on what traffic would be sent. using a traffic-model lets you scale the packet rate and number of packets sent. BUT using a traffic-model adds some randomness into the traffic generation. so running the same traffic_replay command multiple times with a model file may give you some differences in the actual traffic sent. meanwhile, running the same traffic_replay command multiple times with a traffic-summary file will always result in the same traffic being sent.

for taking performance measurements over several test runs, it's recommended to use this option and replay the traffic from a traffic-summary file, or to use the --random-seed option.

  • --stop-on-any-error — any client error makes the whole run stop. no survivors 💀
  • --conversation-persistence 0-1 — conversation termination (as decided by the model) gets re-interpreted as a long pause with this probability.
  • --latency-timeout seconds — wait this long at the end of the run for outstanding reply packets. the number of conversations that haven't finished by the end of the timeout is a failure metric.
  • --generate-users-only — adds extra users/groups on the DC to increase the DB size. by default, this tool automatically creates test users that map to the traffic conversations being generated. this option lets extra users be created on top of that. note that these extra users may not actually be used for traffic generation — traffic generation is still based on the number of conversations from the model/summary file.

generating a big number of users can take a long time, so this option lets you do it just once.

note that the users created will stay on the DC until the tool is run with the --clean-up option. this means it's best to only assign group memberships once, i.e. run --clean-up before assigning a different allocation of group memberships. 💖
  • -n, --number-of-users total-users — the total number of test users to create (not counting any machine accounts needed for the traffic). note that these extra users just populate the DC's DB — the actual user traffic generated is still based on the summary-file.
  • --number-of-groups total-groups — creates this many groups, for assigning the test users to. note that users are not automatically assigned to groups — use either --average-groups-per-user or --group-memberships to do that.
  • --average-groups-per-user average-groups — randomly assigns the test users to the test groups created. the group memberships get distributed so that the overall average groups a user is a member of matches this number. some users will belong to more groups and some to fewer. this option is incompatible with the --group-membership option.
  • --group-memberships total-memberships — randomly assigns the test users to the test groups created. the group memberships get distributed so that the total groups a user is a member of, across all users, matches this number. for example, with 100 users and 10 groups, --group-memberships=300 would assign a user to 3 groups on average. some users will belong to more groups and some to fewer, but the total of all member linked attributes would be 300. this option is incompatible with the --average-groups-per-user option.
  • --max-members group size — limit the largest group to this size, even if the other group options would've had it otherwise.
  • --clean-up — cleans up any users and groups that were created by previously running this tool. it's recommended you always clean up after running the tool.
  • -I, --instance-id id — use this to run multiple instances of the tool on the same DC at the same time. this adds a prefix to the test users generated to keep them separate on the DC.
  • -K, --prefer-kerberos — use Kerberos to authenticate the test users. ✨
  • -B, --badpassword-frequency frequency — use this to simulate users trying to authenticate with an incorrect password. (chaos behavior, honestly)
  • --dns-rate rate — increase the rate at which DNS packets get sent.
  • -t, --timing-data file — writes extra timing data to the file specified. this is mostly used for reporting options, like generating graphs. 📊

💜 Samba Common Options 💜

  • -d, --debuglevel=level — level is an integer from 0 to 10. the default value if this parameter isn't specified is 1 for client applications.

the higher this value, the more detail gets logged to the log files about what the server's doing. at level 0, only critical errors and serious warnings get logged. level 1 is a reasonable level for day-to-day running — it generates a small amount of info about operations carried out.

levels above 1 generate considerable amounts of log data, and should only be used when investigating a problem. levels above 3 are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic 😭

note that specifying this parameter here will override the log level parameter in the /etc/samba/smb.conf file.
  • --debug-stdout — this redirects debug output to STDOUT. by default all clients log to STDERR.
  • --configfile= <configuration file> — the file specified contains the configuration details required by the client. the info in this file can be general for client and server, or only provide client-specific stuff like options such as client smb encrypt. see /etc/samba/smb.conf for more info. the default configuration file name is determined at compile time.
  • --option= <name>=<value> — set the smb.conf(5) option "<name>" to value "<value>" from the command line. this overrides compiled-in defaults and options read from the configuration file. if a name or a value includes a space, wrap the whole --option=name=value into quotes.
  • --realm= REALM — set the realm name
  • -V, --version — prints the program version number.

🎀 Credential Options 🎀

  • --simple-bind-dn= DN — DN to use for a simple bind
  • --password= PASSWORD — Password
  • -U USERNAME|--username= USERNAME — Username
  • -W WORKGROUP|--workgroup= WORKGROUP — Workgroup
  • --use-kerberos= desired|required|off — this parameter decides whether Samba client tools will try to authenticate using Kerberos. for Kerberos authentication you should use DNS names instead of IP addresses when connecting to a service. by default, Samba client tools try to use the default Kerberos credential cache (ccache). in case the ccache doesn't exist, or the -U|--user option was specified, clients will ask you to enter a password and will obtain a Kerberos ticket (kinit) for you. if you wanna use an alternative Kerberos credential cache, use the --use-krb5-ccache option.
note that specifying this parameter here will override the client use kerberos parameter in the /etc/samba/smb.conf file.
  • --ipaddress= IPADDRESS — IP address of the server
  • -P, --machine-pass — use stored machine account password.

🌈 OPERATIONS 🌈

✨ Generating a traffic-summary file ✨

Okay bestie, listen. To use this tool you need either a traffic-summary file or a traffic-model file. And to get either of those files, you're gonna need a packet capture of actual Samba activity on your network. No capture, no vibes. 🫶

So: use Wireshark to take a packet capture on your network of the traffic you wanna generate. Like, if you wanna simulate a whole crowd of users logging on, take that capture at 8:30am when everyone's logging in. Peak chaos hours. 💅

Next up, you gotta convert that packet capture into a traffic summary file using traffic_summary.pl. What this basically does is strip out any sensitive info from the capture and summarize what type of packet was sent and when. Iconic of it, honestly.

Go check traffic_summary.pl --help for the full details, but the basic command looks something like this:

tshark -r capture.pcapng -T pdml | traffic_summary.pl > traffic-summary.txt

🦋 Replaying a traffic-summary file 🦋

Once you've got a traffic-summary file, you can use it to generate traffic, periodt. The traffic_replay tool gets passed the traffic-summary file, along with the full DNS hostname of the DC being tested. You also need to hand over some user credentials, and possibly the Samba realm and workgroup — though the realm and workgroup may be determined automatically, for example from the /etc/smb.conf file, if one is present. She's smart like that. ✨

E.g.

traffic_replay traffic-summary.txt my-dc.samdom.example.com
-UAdmin%password -W samdom --realm=samdom.example.com
--fixed-password=blahblah123!

This simply regenerates Samba activity seen in the traffic summary. The traffic is grouped into 'conversations' between a host and the DC. A user and machine account is created on the DC for each conversation, so that logon and other operations can actually succeed. The script generates the same types of packets as those seen in the summary. No cap.

Ngl, creating users can be a quite time-consuming process, especially if a lot of conversations are being generated. To save time, the test users remain on the DC by default. Which means you will need to run the --clean-up option to remove them, once you've finished generating traffic. Because the same test users get used across multiple runs of the tool, a consistent password for these users needs to be used — this is specified by the --fixed-password option. Don't skip it, bestie, or it's gonna be a whole mess. 😭

The benefit of this tool over simply using tcprelay is that the traffic generated is independent of any specific network. No setup is needed beforehand on the test DC. And the traffic no longer contains sensitive details, so the traffic summary could potentially be shared with other Samba developers. Sharing is caring, slay. 💖

However — and this is the plot twist — replaying a traffic-summary directly is somewhat limited in what you can actually do. A more flexible approach is to generate the traffic using a model file. Main character move, honestly. 👑

🎀 Generating a traffic-model file 🎀

To create a traffic-model file, simply pass the traffic-summary file to the traffic_learner script. E.g.

traffic_learner traffic-summary.txt -o traffic-model.txt

This generates a model of the Samba activity in your network. And now this model-file can be used to generate traffic. Ate. 🔥

⭐ Replaying the traffic-model file ⭐

Packet generation using a traffic-model file uses the same command as a traffic-summary file, e.g.

traffic_replay traffic-model.txt my-dc.samdom.example.com
-UAdmin%password

By default, this will generate 60 seconds worth of traffic based on the model. You can specify longer using the --duration parameter. Go off.

The traffic generated is an approximation of what was seen in the network capture. The traffic generation involves some randomness, so running the same command multiple times may result in slightly different traffic being generated — although you can avoid this, by specifying the --random-seed option. Consistent queen. 💅

As well as changing how long the model runs for, you can also change how many conversations get generated and how fast the traffic gets replayed. To roughly double the number of conversations that get replayed, use --scale-traffic=2, or to approximately halve the number use --scale-traffic=0.5. To approximately double how quickly the conversations get replayed, use --replay-rate=2, or to halve this use --replay-rate=0.5.

For example, to generate approximately 10 times the amount of traffic seen over a two-minute period (based on the network capture), use:

traffic_replay traffic-model.txt my-dc.samdom.example.com
-UAdmin%password --fixed-password=blahblah123! --scale-traffic=10
--duration=120

💜 Scaling the number of users 💜

Okay so here's the thing: the performance of a Samba DC running a small subset of test users will be different to a fully-populated Samba DC running in a network. As the number of users increases, the size of the DB increases, and a very large DB will perform worse than a smaller DB. It's giving "more users, more problems". 😭

To increase the size of the Samba DB, this tool can also create extra users and groups. These extra users are basically 'filler' for the DB. They won't actually be used to generate traffic, but they may slow down authentication of the test users. Filler arc energy, honestly. 🙈

For example, to populate the DB with an extra 5000 users (note this will take a while), use the command:

traffic_replay my-dc.samdom.example.com -UAdmin%password
--generate-users-only --fixed-password=blahblah123!
--number-of-users=5000

You can also create groups and assign users to groups. The users can be randomly assigned to groups — and this includes any extra users created as well as the users that map to conversations. Use either --average-groups-per-user or --group-memberships to specify how many group memberships should be assigned to the test users. Pick your fighter. ✨

For example, to assign the users in the replayed conversations into 10 groups on average, use a command like:

traffic_replay traffic-model.txt my-dc.samdom.example.com
-UAdmin%password --fixed-password=blahblah123! --generate-users-only
--number-of-groups=25 --average-groups-per-user=10

The users created by the test will have names like STGU-0-xyz. The groups generated have names like STGG-0-xyz. Cute little naming scheme, obsessed. 🎀

🌸 VERSION 🌸

This man page is complete for version 4.24.7 of the Samba suite. She's fully up to date, bestie. 💅

💖 SEE ALSO 💖

👑 AUTHOR 👑

The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed. Legends only. 🫶

The traffic_replay tool was developed by the Samba team at Catalyst IT Ltd.

The traffic_replay manpage was written by Tim Beale. Thank you for your service, king. 🎀

And that's a wrap on the whole page, bestie! This was written against Samba 4.24.7, dated 09/09/2026 — go forth and replay that traffic responsibly. Mwah. 💖✨💅

📦 where this page comes from