FreeTDS Development Group

["Brian Johnson" <serversage AT gmail.com>]

Alrighty guys, I'm on the network bandwagon.  I'll start putting feelers out
into the pfSense community to see if any of them have ideas (pfSense is the
firewall/router we are currently using).  It's possible Racoon has an issue
with this particular VPN endpoint the client has or something.

Unfortunately, the Windows end isn't a system/network we have any kind of
access to, other than the database.  It's in a doctor's office, and our
chances of finding an IT guy that is willing to either let us look at it, or
to do it himself, are pretty much 0.

I will try the SACK setting when I get home tonight and see if any magic
happens.  I'll also see if we can get one of their IT guys to be "cool".  :)


Thanks guys, your help has been greatly appreciated.  And I mean GREATLY.
Helping with a problem that exists outside the scope of the software was
above and beyond the "call of duty".

-Brian


On Tue, Apr 8, 2008 at 7:03 AM, James K. Lowden <jklowden AT freetds.org>
wrote:

> Brian Johnson wrote:
> > The Windoze system works great (returns
> > all the rows).  But both linux systems choke.
>
> Consistent with a network issue, pointing to the firewall.  :-/
>
> > The log
> > created when setting TDSDUMP did indeed seem to indicate that there was
> > no problem, data just stopped flowing.  ...
> >
> > Any ideas?  Any where I can point a finger and say, "Aha!  I have
> > something to update!"?
>
> You may find that something simple, say, ftp, fails if the file is large
> enough.  That would eliminate the whole application layer and focus
> attention on the network.
>
> In case Hildo's selective ACK suggestion doesn't do the trick, the
> technical path would be to use tdsdump(8) to log the connection, and watch
> the server stop sending when it shouldn't.  For extra credit, scope the
> server's side, too.  It's work, and some shops don't have the chops.  With
> luck you'll find either the "stuck" packet, the one the server sent that
> the client never received, or you'll see the server mysteriously stop
> sending even though the client is waiting and has abided by the TCP/IP
> RFCs.
>
> (Windump works pretty well if you have the tcpdump man page handy, but I
> have  never used it with a VPN.)
>
> Lament: Observe the negative network effect of Windows.  Your firewall
> "works great" with the Windows machines, but not with Linux.  Your choice
> is to fight or switch, and fighting requires knowledge and patience ...
> and possibly new VPN software.  Who can blame the person who looks at that
> scenario before it even begins, and decides not to go there?
>
> Anyway, good luck.  Please post the outcome if you would.  Someone else
> might benefit.
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>