Re: TCP torture testing

[Etienne-Victor Depasquale via NANOG <nanog () nanog org>]

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
> <https://shopify.engineering/building-and-testing-resilient-ruby-on-rails-applications>
> 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 <dentto () gmail com>


-- 
Etienne-Victor Depasquale