You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello everyone.I encountered the same issue as this one when using tcpliveplay.
I used a complete TCP packet from the diagram below for replay.
But it seems that Linux automatically sends an RST packet I suspect that it's because the network interruption has a higher priority than tcprelay, causing the Linux system to send an RST.
I try use iptables command (iptables -I OUTPUT -p tcp -m tcp --dport 5000 --tcp-flags RST RST -j DROP) drop this package , But tcpreply
But It does't work.So, I am suspecting if this method of sending TCP payload is feasible? Or is it a better choice to establish a TCP connection using sockets AF_INIT to send and receive payloads?
Looking forward to your reply.
The text was updated successfully, but these errors were encountered:
Sorry guys, the person who wrote tcpliveplay has left the project, and I cannot find anyone to clean it up. I may need to drop it. I will leave it in for another release cycle and if I cannot find anyone to support it, I'll drop it from the product suite.
Hello everyone.I encountered the same issue as this one when using tcpliveplay.
I used a complete TCP packet from the diagram below for replay.
But it seems that Linux automatically sends an RST packet I suspect that it's because the network interruption has a higher priority than tcprelay, causing the Linux system to send an RST.
I try use iptables command (iptables -I OUTPUT -p tcp -m tcp --dport 5000 --tcp-flags RST RST -j DROP) drop this package , But tcpreply
But It does't work.So, I am suspecting if this method of sending TCP payload is feasible? Or is it a better choice to establish a TCP connection using sockets AF_INIT to send and receive payloads?
Looking forward to your reply.
The text was updated successfully, but these errors were encountered: