TRAFFIC_LEARNER(7)

πŸ’– TRAFFIC_LEARNER πŸ’–

okay bestie, gather round, because this one is the traffic_learner manual page (that's the TRAFFIC_LEARNER(7) page, section 7, user commands, iykyk) and it's genuinely such a vibe. It's a Samba tool that helps you out with traffic generation. no cap. let's get into it.


✨ NAME ✨

traffic_learner β€” the Samba tool that assists with traffic generation. that's it, that's the whole name. slay. πŸ’…


🌸 SYNOPSIS 🌸

traffic_learner {-o OUTPUT_FILE ...} [-h] [--dns-mode {inline|count}]
 [SUMMARY_FILE] [SUMMARY_FILE ...]

look at her. gorgeous. and yes, that -o is doing a lot of heavy lifting, more on that below. 🫢


πŸ¦‹ DESCRIPTION πŸ¦‹

This tool is part of the samba(7) suite. family reunion, we love to see it. πŸ’–

So here's the tea: this tool assists with generation of Samba traffic. It takes a traffic-summary file as input β€” and that summary file is produced by traffic_summary.pl, so that's your girl for the upstream step β€” and it produces a traffic-model file that can then be used by traffic_replay for traffic generation. it's giving pipeline. it's giving relay race. πŸƒβ€β™€οΈ

The model file summarizes the types of traffic (the 'conversations' between a host and a Samba DC, cute) that occur on a network. And the way it describes the traffic means it can be scaled β€” so either more packets get sent or fewer packets get sent, and the packets can be sent at a faster rate or a slower rate than whatever was actually seen on the network. flexible queen. πŸ‘‘


πŸŽ€ OPTIONS πŸŽ€

  • -h|--help β€” Print a summary of command line options. bestie behaviour honestly, always offer the help.
  • SUMMARY_FILE β€” File containing a network traffic-summary. The traffic-summary file should be generated by traffic_summary.pl from a packet capture of actual network traffic. More than one file can be specified, in which case the traffic will be combined into a single traffic-model. And if no SUMMARY_FILE is specified, this tool will read the traffic-summary from STDIN β€” i.e. you can pipe the output from traffic_summary.pl directly to this tool. iconic, lowkey the best way to do it. 🌈
  • -o|--out OUTPUT_FILE β€” The traffic-model that is produced will be written to this file. The OUTPUT_FILE can then be passed to traffic_replay to generate (and manipulate) Samba network traffic. this is the whole point of the operation, don't skip her. ✨
  • --dns-mode [inline|count] β€” How DNS traffic should be handled by the model. that's the whole description, she's mysterious like that. πŸ™ˆ

πŸ’œ EXAMPLES πŸ’œ

To take a traffic-summary file and produce a traffic-model file, use:

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

To generate a traffic-model from a packet capture, you can pipe the traffic summary to STDIN using:

tshark -r capture.pcapng -T pdml | traffic_summary.pl | traffic_learner
-o traffic-model.txt

the way that second one is literally three commands holding hands across a pipe 🫢🫢🫢 we love a chain.


⭐ OUTPUT FILE FORMAT ⭐

The output model file describes a Markov model estimating the probability of a packet occurring given the last two packets. yes, she went to math class and she thrived. πŸ“š

The count of each continuation after a pair of successive packets is stored, and the ratios of these counts is used to calculate probabilities for the next packet.

The model is stored in JSON format, and also contains information about the packet rate and DNS traffic rate. cute AND informative.

πŸ“ Example ngram listing πŸ“

The following listing shows a contrived example of a single ngram entry.

              "ngrams": {
                 "ldap:0\tdcerpc:11": {
                     "lsarpc:77": 1,
                     "ldap:2": 370,
                     "ldap:3": 62,
                     "wait:3": 2,
                     "-": 1
                 }, [...]
              }

This counts the observed continuations after an ldap packet with opcode 0 (a bind) followed by a dcerpc packet with opcode 11 (also a bind). The most common next packet is "ldap:2" which is an unbind, so this is the most likely packet type to be selected in replay. At the other extreme, lsarpc opcode 77 (lookup names) has been seen only once, and it is unlikely but possible that this will be selected in replay. so it's a probability girlie, not a guarantee girlie. 😭

There are two special packet types here. "wait:3" refers to a temporary pause in the conversation, where the "3" pseudo-opcode indicates the length of the wait on an exponential scale. That is, a "wait:4" pause would be about 2.7 times longer that a "wait:3", which in turn would be similarly longer than a "wait:2". exponential, she's dramatic like that. πŸ’…

The other special packet is "-", which represents the limit of the conversation. In the example, this indicates that one observed conversation ended after this particular ngram. This special opcode is also used at the beginning of conversations, which are indicated by the ngram "-\t-". so "-" is both the start AND the end, main character energy tbh. πŸ‘‘


🌸 VERSION 🌸

This man page is complete for version 4.24.7 of the Samba suite. periodt.


πŸ”₯ SEE ALSO πŸ”₯

traffic_replay(7). go read her next, she's the one who actually uses the model you just made. besties. 🫢


πŸ‘‘ 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_learner tool was developed by the Samba team at Catalyst IT Ltd.

The traffic_learner manpage was written by Tim Beale. thank you tim, we appreciate you. πŸ’–


okay that's the whole page bestie, no skips, no shortcuts, every single flag accounted for. this was Samba 4.24.7, dated 09/09/2026, and honestly? she ate. πŸ’…βœ¨

πŸ“¦ where this page comes from