Malformed TCP packets

I have an application that uses overlapped sockets. I run two instances of
the application on different PCs; one instance connects to another, then
both instances exchange some data. I am having troubles with certain PCs,
which send out malformed TCP packets with wrong TCP checksums or IP headers
partially overwritten by user data.

The problem happens with Win2k SP3 machines, and SP4 seems to help.

Now I have an XP SP1 machine (A) and XP SP2 machine (B).

When A connects to B, all works fine. When B connects to A (i.e. A is
listening), then some TCP packets coming out of A are malformed. When two
instances of the appliction are running on A, all is fine. Other XP SP1 and
2003 machines work fine. So it must be something wrong with the machine A.

Even if I did something wrong in my user-mode program, this woudn't affect
the packet headers, would it?

Is it possible to get the list of all the drivers in the TCP stack? I would
then compare the stacks on A and B to see if there's any difference.

Any other suggestions?

Thanks.

> Is it possible to get the list of all the drivers in the TCP stack? I would

No standard means. This is because lots of people are writing the hackery-based
drivers (like TDI filters or NDIS hookers) which plugs themselves inside the
networking stack bypassing the interfaces provided by Microsoft. With such a
driver, no standard means will be able to detect it as being a part of the
networking stack.

So, provide us with a list of all binaries in SystemRoot\system32\drivers with
their VersionInfo resources, we will possibly help.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

"Maxim S. Shatskih" <> wrote in message
news:...
> > Is it possible to get the list of all the drivers in the TCP stack? I
would
>
> No standard means. This is because lots of people are writing the
hackery-based
> drivers (like TDI filters or NDIS hookers) which plugs themselves inside
the
> networking stack bypassing the interfaces provided by Microsoft. With such
a
> driver, no standard means will be able to detect it as being a part of the
> networking stack.
>

Actually, Max, even if you exclude TDI filters and NDIS-hookers I don't
think there is a user-mode tool that actually shows the NDIS bindings
completely. The DDK "BindView" application shows only the bindings that the
user-mode NDIS installer knows about. There is no visibility into the
internal bindings created by legitimate NDIS IM drivers.

The NDIS debugger extension !ndiskd.protocols and !ndiskd.miniports commands
may offer some visibility.

Regards,

Thomas F. Divine
http://www.rawether.net



> So, provide us with a list of all binaries in SystemRoot\system32\drivers
with
> their VersionInfo resources, we will possibly help.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
>
> http://www.storagecraft.com
>
>

Following up to Thomas' post, actually !opens might be more helpful as it
will pair the miniport/protocol bindings in an easier-to-sort-out view.
But it will miss anything that's hooked in, which I hope is becomming less
common.

Bryan S. Burgin


This posting is provided "AS IS" with no warranties, and confers no rights.

I will try that, thanks. I've compared the lists of .sys files and they seem
to be alike.


""Bryan S. Burgin [MSFT]"" <> wrote in message
news:...
> Following up to Thomas' post, actually !opens might be more helpful as it
> will pair the miniport/protocol bindings in an easier-to-sort-out view.
> But it will miss anything that's hooked in, which I hope is becomming less
> common.
>
> Bryan S. Burgin
>
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.