TCP/IP lack of response

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hi,

I have an application which listens for TCP connections. When it receives a
connect notification, it accepts the connection and spawns a process to
handle it (ala inetd). The spawned process reads a message from the socket,
writes a message to the socket, shuts down the socket, then closes the
socket. A very normal application in that respect.

I’ve been receiving reports that every once in a while, for a period of
anywhere from five minutes to an hour, clients time out trying to connect to
the port. These clients come through what I’ll call Router A. At the same
time, clients coming through Router B have no problems.

I have a packet sniffer on the same wire as the server. Normally, the
packet sniffer sees the TCP sync sequence packets to the server and the TCP
ack packets from the server for the connections coming from routers A and B
both. When the “outage” occurs, I can see in the packet sniffer log that
all the TCP sync sequence packets from Router A clients go unanswered, while
the TCP sync sequence packets from Router B are answered with TCP ack
packets.

I’m using Socklet 4.25C dated August 19, 1998. I’ve got four Net.epic
processes running for my various network interfaces, all of which are
version 4.24B dated September 24, 1998.

Any idears?

shawn@nbs-inc.com +1 612 512 9500
shawn@zubenubi.com +1 952 929 5181

2

Shawn,

You are running an older version of Net.epic. Can you upgrade to the latest
driver, which is part of the qnx4.25D patch. You’re Socklet is also older.
Can you also update to the latest tcpip patch C.

Heather


Shawn P. Stanley <shawn@nbs-inc.com> wrote:

Hi,

I have an application which listens for TCP connections. When it receives a
connect notification, it accepts the connection and spawns a process to
handle it (ala inetd). The spawned process reads a message from the socket,
writes a message to the socket, shuts down the socket, then closes the
socket. A very normal application in that respect.

I’ve been receiving reports that every once in a while, for a period of
anywhere from five minutes to an hour, clients time out trying to connect to
the port. These clients come through what I’ll call Router A. At the same
time, clients coming through Router B have no problems.

I have a packet sniffer on the same wire as the server. Normally, the
packet sniffer sees the TCP sync sequence packets to the server and the TCP
ack packets from the server for the connections coming from routers A and B
both. When the “outage” occurs, I can see in the packet sniffer log that
all the TCP sync sequence packets from Router A clients go unanswered, while
the TCP sync sequence packets from Router B are answered with TCP ack
packets.

I’m using Socklet 4.25C dated August 19, 1998. I’ve got four Net.epic
processes running for my various network interfaces, all of which are
version 4.24B dated September 24, 1998.

Any idears?

shawn@nbs-inc.com > +1 612 512 9500
shawn@zubenubi.com > +1 952 929 5181

3

Heather,

Thanks, I’ve upgraded as suggested and I’ll post again if the problem
recurs.

“Heather Johnstone” <heather@qnx.com> wrote in message
news:8om1h1$b3b$2@nntp.qnx.com…

Shawn,

You are running an older version of Net.epic. Can you upgrade to the
latest
driver, which is part of the qnx4.25D patch. You’re Socklet is also
older.
Can you also update to the latest tcpip patch C.

Heather


Shawn P. Stanley <> shawn@nbs-inc.com> > wrote:
Hi,

I have an application which listens for TCP connections. When it
receives a
connect notification, it accepts the connection and spawns a process to
handle it (ala inetd). The spawned process reads a message from the
socket,
writes a message to the socket, shuts down the socket, then closes the
socket. A very normal application in that respect.

I’ve been receiving reports that every once in a while, for a period of
anywhere from five minutes to an hour, clients time out trying to
connect to
the port. These clients come through what I’ll call Router A. At the
same
time, clients coming through Router B have no problems.

I have a packet sniffer on the same wire as the server. Normally, the
packet sniffer sees the TCP sync sequence packets to the server and the
TCP
ack packets from the server for the connections coming from routers A
and B
both. When the “outage” occurs, I can see in the packet sniffer log
that
all the TCP sync sequence packets from Router A clients go unanswered,
while
the TCP sync sequence packets from Router B are answered with TCP ack
packets.

I’m using Socklet 4.25C dated August 19, 1998. I’ve got four Net.epic
processes running for my various network interfaces, all of which are
version 4.24B dated September 24, 1998.

Any idears?

shawn@nbs-inc.com > +1 612 512 9500
shawn@zubenubi.com > +1 952 929 5181

4

Are Router A and B Microsoft Windows platforms? If so then even though the
QNX
app closes the socket I have seen where the MS side does not see it as
closed and
will not allow the client to reopen another socket on the same port. Might
help.

Ivan

Shawn P. Stanley <shawn@nbs-inc.com> wrote in message
news:8ombdi$k2m$1@inn.qnx.com…

Heather,

Thanks, I’ve upgraded as suggested and I’ll post again if the problem
recurs.

“Heather Johnstone” <> heather@qnx.com> > wrote in message
news:8om1h1$b3b$> 2@nntp.qnx.com> …
Shawn,

You are running an older version of Net.epic. Can you upgrade to the
latest
driver, which is part of the qnx4.25D patch. You’re Socklet is also
older.
Can you also update to the latest tcpip patch C.

Heather


Shawn P. Stanley <> shawn@nbs-inc.com> > wrote:
Hi,

I have an application which listens for TCP connections. When it
receives a
connect notification, it accepts the connection and spawns a process
to
handle it (ala inetd). The spawned process reads a message from the
socket,
writes a message to the socket, shuts down the socket, then closes the
socket. A very normal application in that respect.

I’ve been receiving reports that every once in a while, for a period
of
anywhere from five minutes to an hour, clients time out trying to
connect to
the port. These clients come through what I’ll call Router A. At the
same
time, clients coming through Router B have no problems.

I have a packet sniffer on the same wire as the server. Normally, the
packet sniffer sees the TCP sync sequence packets to the server and
the
TCP
ack packets from the server for the connections coming from routers A
and B
both. When the “outage” occurs, I can see in the packet sniffer log
that
all the TCP sync sequence packets from Router A clients go unanswered,
while
the TCP sync sequence packets from Router B are answered with TCP ack
packets.

I’m using Socklet 4.25C dated August 19, 1998. I’ve got four Net.epic
processes running for my various network interfaces, all of which are
version 4.24B dated September 24, 1998.

Any idears?

shawn@nbs-inc.com > +1 612 512 9500
shawn@zubenubi.com > +1 952 929 5181
\

5

Actually, Router A is a Cisco 2600 and Router B is a Cisco 2500. They both
come into a Bay Networks Accelar 1200 switch. The server and the packet
sniffer machine are both on a SynOptics LatticeHub 2813SA connected to the
Accelar 1200. The server is running QNX 4.25, and the client machines are
running some flavor of UNIX, most probably SCO. There are no Microsoft
systems involved.

I am now running Proc32 version 4.25H, Net version 4.25C, Net.epic version
4.25F, and Socklet version 4.25H. I’m still seeing the exact same problem.

Any more ideas?

“Ivan Bannon” <ivan.bannon@rjginc.com> wrote in message
news:8oml2n$osj$1@inn.qnx.com…

Are Router A and B Microsoft Windows platforms? If so then even though
the
QNX
app closes the socket I have seen where the MS side does not see it as
closed and
will not allow the client to reopen another socket on the same port.
Might
help.

Ivan

Shawn P. Stanley <> shawn@nbs-inc.com> > wrote in message
news:8ombdi$k2m$> 1@inn.qnx.com> …
Heather,

Thanks, I’ve upgraded as suggested and I’ll post again if the problem
recurs.

“Heather Johnstone” <> heather@qnx.com> > wrote in message
news:8om1h1$b3b$> 2@nntp.qnx.com> …
Shawn,

You are running an older version of Net.epic. Can you upgrade to the
latest
driver, which is part of the qnx4.25D patch. You’re Socklet is also
older.
Can you also update to the latest tcpip patch C.

Heather


Shawn P. Stanley <> shawn@nbs-inc.com> > wrote:
Hi,

I have an application which listens for TCP connections. When it
receives a
connect notification, it accepts the connection and spawns a process
to
handle it (ala inetd). The spawned process reads a message from the
socket,
writes a message to the socket, shuts down the socket, then closes
the
socket. A very normal application in that respect.

I’ve been receiving reports that every once in a while, for a period
of
anywhere from five minutes to an hour, clients time out trying to
connect to
the port. These clients come through what I’ll call Router A. At
the
same
time, clients coming through Router B have no problems.

I have a packet sniffer on the same wire as the server. Normally,
the
packet sniffer sees the TCP sync sequence packets to the server and
the
TCP
ack packets from the server for the connections coming from routers
A
and B
both. When the “outage” occurs, I can see in the packet sniffer log
that
all the TCP sync sequence packets from Router A clients go
unanswered,
while
the TCP sync sequence packets from Router B are answered with TCP
ack
packets.

I’m using Socklet 4.25C dated August 19, 1998. I’ve got four
Net.epic
processes running for my various network interfaces, all of which
are
version 4.24B dated September 24, 1998.

Any idears?

shawn@nbs-inc.com > +1 612 512 9500
shawn@zubenubi.com > +1 952 929 5181


\

6

I have more information:

During an outage, I have seen ICMP PING requests coming from a client
through Router A, and PING responses going back to the client from the
server. Also, the clients do retransmit their SYN frames. And, I don’t
think it can be a backlog issue, because both Router A and Router B clients
connect to the same socket on the server. But then, I don’t really know how
the backlog has been implemented. There wouldn’t be a separate backlog per
incoming MAC address, would there?

And, can I get a clarification: at one point (before using the packet
sniffer), I’d tried to resolve the problem by increasing the backlog from 5
to 10. Does that actually do anything under QNX? I know that Win95/98’s MS
stack hardwires the backlog to 5, so whether I specify 5, 6, or 10, it’s
always 5.

“Shawn P. Stanley” <shawn@nbs-inc.com> wrote in message
news:8om0h7$ere$1@inn.qnx.com…

Hi,

I have an application which listens for TCP connections. When it receives
a
connect notification, it accepts the connection and spawns a process to
handle it (ala inetd). The spawned process reads a message from the
socket,
writes a message to the socket, shuts down the socket, then closes the
socket. A very normal application in that respect.

I’ve been receiving reports that every once in a while, for a period of
anywhere from five minutes to an hour, clients time out trying to connect
to
the port. These clients come through what I’ll call Router A. At the
same
time, clients coming through Router B have no problems.

I have a packet sniffer on the same wire as the server. Normally, the
packet sniffer sees the TCP sync sequence packets to the server and the
TCP
ack packets from the server for the connections coming from routers A and
B
both. When the “outage” occurs, I can see in the packet sniffer log that
all the TCP sync sequence packets from Router A clients go unanswered,
while
the TCP sync sequence packets from Router B are answered with TCP ack
packets.

I’m using Socklet 4.25C dated August 19, 1998. I’ve got four Net.epic
processes running for my various network interfaces, all of which are
version 4.24B dated September 24, 1998.

Any idears?

shawn@nbs-inc.com > +1 612 512 9500
shawn@zubenubi.com > +1 952 929 5181