In my lab work, I use Ostinato to craft 
(a) packet streams and 
(b) sequences of packet streams.

Ostinato is stateless, 
so you'll have to co-ordinate the 3-way handshake yourself to open the connection. 
That is: 
you'd have to send the SYN segment (segment 1) from Ostinato,
investigate the SN sent by your OS (segment 2), and then
use AN = SN+1 in the reply in the acknowledgement segment (segment 3)
in the AN field sent by Ostinato to the peer.

Your OS (acting as server) would need to tolerate lengthy delays
between its opening SYN (segment 2) and the corresponding ACK (segment 3).
You can mitigate these delays by preparing all the fields beforehand, 
leaving only the peer's OS's SN to be captured.
AFAIK, these delays run between 30s and 90s, 
giving you some time to copy and paste from your capture program to Ostinato's UI.

Cheers,

Etienne







On Sun, Jan 19, 2025 at 3:19 AM Pete D. <denitto@gmail.com> wrote:
Shopify built a go app called Toxiproxy that would allow for injecting TCP oddballs into an http stream.

https://github.com/Shopify/toxiproxy

> Toxiproxy is a framework for simulating network conditions. It's made specifically to work in testing, CI and development environments, supporting deterministic tampering with connections, but with support for randomized chaos and customization. Toxiproxy is the tool you need to prove with tests that your application doesn't have single points of failure. We've been successfully using it in all development and test environments at Shopify since October, 2014. See our blog post on resiliency for more information.

--Pete





On Fri, Jan 17, 2025 at 2:42 PM Brandon Martin <lists.nanog@monmotha.net> wrote:
On 1/17/25 14:29, William Herrin wrote:
> Well... In theory, TCP closes the segment at the end of the
> application's send() and sets the PSH flag. Likewise, on the receiving
> side the recv() returns before filling the buffer upon receipt of a
> segment with the PSH flag set.

Every segment this thing sends has PSH set which again makes me think
that they've got TCP_NODELAY set but are sending their messages
piecemeal across multiple send/write calls.

The actual high-level messages are fairly small at typically less than
100B.  Most implementations end up sending the entire message in a
single TCP segment.

> In theory. In practice, it doesn't always work out that way and
> applications which depend on a short recv() meaning that was where the
> sender's send() ended tend to flake out in unexpected ways.

I don't think that's the issue in this case, but it's a useful thing to
go looking for.

--
Brandon Martin


--
--
Peter A. DeNitto
denitto@gmail.com


--
Etienne-Victor Depasquale