Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] tcprewrite alters MAC addresses when using --seed option #901

Open
rambisco opened this issue Sep 16, 2024 · 1 comment
Open

[Bug] tcprewrite alters MAC addresses when using --seed option #901

rambisco opened this issue Sep 16, 2024 · 1 comment
Assignees
Labels

Comments

@rambisco
Copy link

Describe the bug

tcprewrite is modifying MAC addresses when using the --seed option. It should only be modifying IP addresses.

This was discovered because it will set the RII/multi-cast bit of the SRC mac address, rendering it as an invalid MAC on most networks causing our switch to drop the packet. This does not happen for me without the --seed option.

I built the latest 4.5.1 release and built it on my linux machine and the issue still occurs.

This was also reported in #794 - but I have attached example input and output pcaps (with their extensions changed to txt).

first-100-flows.txt

first-100-flows-rewritten.txt

To Reproduce
Steps to reproduce the behavior:

sudo tcpprep --cidr=0.0.0.0/0 --pcap=/tmp/first-100-flows.pcap --cachefile=/tmp/first-100-flows.cache
sudo tcprewrite --cachefile=/tmp/first-100-flows.cache --infile=/tmp/first-100-flows.pcap --outfile=/tmp/first-100-flows-rewritten.pcap --seed=789

Expected behavior
The MAC addresses should be identical after a tcprewrite with only the --seed option.

Screenshots

Here are the first 21 packets' MAC addresses before and after being re-written:

labuser@linux264b$ tshark -r /tmp/first-100-flows.pcap -T fields -e eth.src -e eth.dst | head -n 21
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55

[14:49] DIR:/test/pcaps/st/dev/
labuser@linux264b$ tshark -r /tmp/first-100-flows-rewritten.pcap -T fields -e eth.src -e eth.dst | head -n 21
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       01:00:5e:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       01:00:5e:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
01:00:5e:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55
14:58:d0:5a:de:10       00:11:22:33:44:55

System (please complete the following information):

  • OS: Ubuntu 20.04
  • Tcpreplay 4.5.1

Additional context:
This was originally a '10k-random-flows' pcap not generated by me. I shortened it to only the first 100 flows, but the MAC addresses get changed in the same way.

@fklassen fklassen self-assigned this Sep 21, 2024
@fklassen fklassen added the bug label Sep 21, 2024
@ChuckCottrill
Copy link
Contributor

can anyone provide insight into where the problem might be located?
I have looked at the obvious suspect locations and have seen nothing wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants