[Bug] tcprewrite endpoints setting to 1.1.1.1:2.2.2.2 show inconsistent results when traffic is split between non-standard (8080) and standard port (80)

[amit-raut]

Describe the bug

My goal is to use tcprewrite to slit the traffic in PCAP to 1.1.1.1:2.2.2.2.

When port 80 is involved in PCAP I get right results (the endspoints are split based on the different ports) but when I have traffic on port 8080 or non-standard port I get wrong result (endpoints are not split based on the different ports)

To Reproduce Please run the following commnads on the attached PCAP (J.pcap) to see wrong result J.pcap.zip

tcpprep --port --pcap=J.pcap --cachefile=in.cache
tcprewrite --cachefile=in.cache --endpoints=1.1.1.1:2.2.2.2 --infile=J.pcap --outfile=K.pcap

Expected behavior Correct result for endpoints splitting when tcp port 80 is involved

But when port 8080 is involved the endpoints are not split correctly as shown below

System (please complete the following information):

• OS: Xubuntu 16.04
• OS version: 16.04
• Tcpreplay Version: tcprewrite version: 3.4.4 (build 2450) (debug)

Additional context

Thank you for looking in to it :)

-Amit

[fklassen]

AFAIK port 80 isn't magical in tcprewrite. I'll investigate in next bug fix cycle.

[amit-raut]

Thank you for your quick response @fklassen. I forgot to mention earlier that the PCAP file J.pcap contains the traffic with same src/dst IP (172.17.0.2). My guess is that somewhere tcpprep/ tcprewrite takes (IP,port) combination in consideration while changing the endpoints.

Thank you, Amit

[fklassen]

Switching to enhancement. Currently the tcpprep --port command assumes server ports are in the range of 0 - 1023. Requires additional options to expand this range.

[fklassen]

Moving to review in 4.5 for further consideration.

I am inclined to not change anything. Port 8080 is not a standard server port, although it is often used as an alternate HTTP port. Only valid range is 0 - 1023. If this is altered, we will probably introduce bugs.