Re: Fault injection via man-in-the-middle proxy?

2016-11-11 17:53 GMT+00:00 David Bakin <[email protected]>:
> (New to the list, new to TDS: I may have serious misconceptions!)
>
> I'm thinking it would be useful - in order to help diagnose certain client-side reliability issues due to network problems we occasionally experience that lead to database connections returning errors (at the client-side) - to have a sort of man-in-the-middle proxy that could do SQL-oriented fault injection - e.g. returning errors at the protocol level, or simulating network faults (e.g., abnormal delays, or timeouts).
>

For network tools you should probably find lot of tools. Even using
VPN software and stopping
them can give good tests.

> (It's hard for me to find the right keywords for a google search as it turns out that "SQL Fault Injection" has a completely different meaning ...)
>
> So ... a couple of questions:
>
>
> a)      Does this even make sense?
>

Maybe

> b)      Is there an existing tool that'll do it?
>

Not as far as I know

> c)       Can I use FreeTDS to create a tool that'll do it?
>
> *         Does this sound like a promising approach (assuming the answer to point a is "yes")?
>
> *         As to point c - an earlier message on this list pointed a requester to tdspool as a starting point.
>
> o   Is tdspool a good starting point?
>

Can be, it's actually a SQL proxy.

> o   This message/response was in 2010 and the response was that tdspool was subject to bit rot - I do see now in git that it was last updated only 4 months ago ... so I assume it is working now?
>

Yes, has some limits like sql users and not encryption but works. On
the other side it reads packet content only at login time.

> *         Assuming a = yes, b = no, c = yes and I go ahead with this, do you think the end result would be of general interest?
>

Don't know.

> Thanks! - David
>
> P.S. The environment is Windows, ODBC, SQL Server, and the client is a C++ application.

All FreeTDS is quite portable.

Frediano