TCP/IP comms problems between WinXP and DOS

[Guest]

I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.

 

[r norman]

I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.

Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.

Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.

 

[adebaene]

I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.

<snip>
Use a network sniffer (such as WireShark) to check what happens "on
the wire" on the server side.

Arnaud
MVP - VC

 

[Ben Voigt]

I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked
PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server
versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as
client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It
can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this
works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the
server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this
fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK
with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server'
test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?

At a guess, you've used a C structure for your message, with different
compilers (one 16-bit and one 32-bit) so the layouts are incompatible. Make
sure you are passing the exact same size to send() and recv() in both
environments.

 

[Guest]

Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.

Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.

The effect I see is that in my VC++ program OnReceive() doesn't get called
even though a Send() is executed by the DOS program. As a result my VC++
program doesn't set the flag that causes my program to then do a Recive() to
get the message. In case it was OnReceive() not working properly I tried
using a key press to set the flag when I knew the DOS program had done a
send. In this case Receive() returned no data, effectively confirming that
indeed nothing had apparently been received.
At the DOS end an asynchronous Send is triggered. A second call to Send then
returns an error indicating that the previous send has not yet completed.
This agrees with the message not getting received by my VC++ program. Of
course it doesn't explain why and which end is at fault.
I can send messages successfully the other way (from VC++ to the DOS app),
so the socket must have been established OK.
The logic etc. in both my programs is presumably basically correct as they
work when the 'other end' is on an O/S combination that works OK. e.g.
DOS->NT or XP->NT. I
I'll try to find the sniffer I came across a few years ago, though my
understanding of very low level TCP/IP is limited so I'm not sure what it
will tell me. I expect the OS to do that for me! I suspect I'll need to find
an ethernet hub rather that an ethernet switch too - which could be more of a
challenge - may need to visit a museum.

 

[r norman]

The effect I see is that in my VC++ program OnReceive() doesn't get called
even though a Send() is executed by the DOS program. As a result my VC++
program doesn't set the flag that causes my program to then do a Recive() to
get the message. In case it was OnReceive() not working properly I tried
using a key press to set the flag when I knew the DOS program had done a
send. In this case Receive() returned no data, effectively confirming that
indeed nothing had apparently been received.
At the DOS end an asynchronous Send is triggered. A second call to Send then
returns an error indicating that the previous send has not yet completed.
This agrees with the message not getting received by my VC++ program. Of
course it doesn't explain why and which end is at fault.
I can send messages successfully the other way (from VC++ to the DOS app),
so the socket must have been established OK.
The logic etc. in both my programs is presumably basically correct as they
work when the 'other end' is on an O/S combination that works OK. e.g.
DOS->NT or XP->NT. I
I'll try to find the sniffer I came across a few years ago, though my
understanding of very low level TCP/IP is limited so I'm not sure what it
will tell me. I expect the OS to do that for me! I suspect I'll need to find
an ethernet hub rather that an ethernet switch too - which could be more of a
challenge - may need to visit a museum.

I am afraid you will have to learn to use the sniffer or network
monitor. That way you can see just what happens when your DOS
program does a Send(). You also have to look carefully at the return
values for all functions when you establish the connection. Just
because you can receive data does not mean the socket is properly
established for sending. Doesn't the socket return some error code
on failure that you can interpret? You could also have a problem in
some other area -- switching systems around could mean changing TCP/IP
setup values and mis-setting things like DNS server address and masks.

 

[Guest]

I am afraid you will have to learn to use the sniffer or network
monitor. That way you can see just what happens when your DOS
program does a Send(). You also have to look carefully at the return
values for all functions when you establish the connection. Just
because you can receive data does not mean the socket is properly
established for sending. Doesn't the socket return some error code
on failure that you can interpret? You could also have a problem in
some other area -- switching systems around could mean changing TCP/IP
setup values and mis-setting things like DNS server address and masks.



I obtained a sniffer and have used it to identify the problem. By comparing working and non-working scenarios I noted that the available receive buffer space notified in the tcp/ip packets is around 64K from XP, but much lower e.g. <=16K for NT. I suspect that the legacy DOS TCP/IP package I am using is not correctly interpreting buffer available space when >16K and is perhaps treating this as zero or negative, hence is not attempting to transmit.

I have tried using SetSockOpt() in my code to set SO_RCVBUF to <16K for the
socket I am using. However this does not seem to work. An initial call to
GetSockOpt() is not reporting the same as I am seeing with the sniffer, and
though I use SetSockOpt() to set a different value which a subsequent
GetSockOpt() demonstrates has been set, the buffer space shown by the sniffer
remains unchanged - hence the DOS TCP/IP is still not able to transmit.
The only way I have been able to get successful communications is to force
the XP network card to operate at 10Mb/s rather than the default auto which
results in 100Mb/s. This seems to have the side effect of reducing the
announced buffer space. This is not ideal, but it does at least work though.
This has now allowed me at least to progress, though this has revealed
another unexpected problem. I plan to use 2 ethernet cards, one for a small
isolated network for comms with the set of computers running my specialised
system, and one for wider external comms on our main network for file / print
servers etc. When I plug the 'external' network cable into the 2nd card
communications stops on the original card. It carries on working if I plug
the external cable into the local hub on the other card's network. Is there
some odd problem with having 2 ethernet cards? I've used 2 cards of different
types in the past to enable a PC to access ethernet and token ring
simultaneously OK.

 

[r norman]

I have tried using SetSockOpt() in my code to set SO_RCVBUF to <16K for the
socket I am using. However this does not seem to work. An initial call to
GetSockOpt() is not reporting the same as I am seeing with the sniffer, and
though I use SetSockOpt() to set a different value which a subsequent
GetSockOpt() demonstrates has been set, the buffer space shown by the sniffer
remains unchanged - hence the DOS TCP/IP is still not able to transmit.
The only way I have been able to get successful communications is to force
the XP network card to operate at 10Mb/s rather than the default auto which
results in 100Mb/s. This seems to have the side effect of reducing the
announced buffer space. This is not ideal, but it does at least work though.
This has now allowed me at least to progress, though this has revealed
another unexpected problem. I plan to use 2 ethernet cards, one for a small
isolated network for comms with the set of computers running my specialised
system, and one for wider external comms on our main network for file / print
servers etc. When I plug the 'external' network cable into the 2nd card
communications stops on the original card. It carries on working if I plug
the external cable into the local hub on the other card's network. Is there
some odd problem with having 2 ethernet cards? I've used 2 cards of different
types in the past to enable a PC to access ethernet and token ring
simultaneously OK.

I seem to recall problems with buffer size back a number of years ago
but I can't recall at all how I solved it. I think it was setting the
buffer size in the Windows system through the registry. See, for
example,
http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm

Obviously a DOS system can't handle anything bigger than 64K and it is
indeed possible that a value greater than 32K is misinterpreted.

There is indeed something odd about using several network cards in one
system to get everything to work properly but I am afraid that I don't
understand network communications sufficiently (or at all, for that
matter!) to help you properly with either this problem or the buffer
size problem. My impression is that if the two network cards have
different network IP addresses not within the range of the subnet mask
of each other and you try to connect to an outside system within the
subnet range of either card, then your operating system knows which
card to use. If the IP address is totally different, then I have no
idea how the operating system figures out which one to use. I have
had problems switching connections between different network
connections. There are various caches maintained by the operating
system to indicate how connections can best be maintained and when I
have problems I have to run around looking up reference books to find
out just what the caches are, how to access them, and how to clear
them. After I do this, it all seems to work. But you need somebody
experienced and knowledgeable in what is happening. When they answer
you, I will be sure to carefully read the solution and this time print
it out and paste it on the wall above my work area so I can find it
next time I need it!

 

[r norman]

Perhaps a better place to find out about how to solve the problems
described in TCP/IP communication between systems (which I have
snipped out) would be on microsoft.public.win32.programmer.networks.

Ask there, including the information on buffer size and multiple
hosted systems.

 

[Ben Voigt]

I have tried using SetSockOpt() in my code to set SO_RCVBUF to <16K for
the
socket I am using. However this does not seem to work. An initial call to
GetSockOpt() is not reporting the same as I am seeing with the sniffer,
and
though I use SetSockOpt() to set a different value which a subsequent
GetSockOpt() demonstrates has been set, the buffer space shown by the
sniffer
remains unchanged - hence the DOS TCP/IP is still not able to transmit.
The only way I have been able to get successful communications is to force
the XP network card to operate at 10Mb/s rather than the default auto
which
results in 100Mb/s. This seems to have the side effect of reducing the
announced buffer space. This is not ideal, but it does at least work
though.

I believe that advertising an MSS (maximum segment size) or recvwnd (receive
window) that large requires an extension in the IP header.