Couple of quick questions:

	What is the command line you use to start the stack (including
the parameter for the priority setting)?
	What driver are you using (is it a custom driver for Modbus)?
	Can you post a pidin / pidin mem output for io-net for us?

	Thanks!
		Robert.

 

-----Original Message-----
From: Oleh Derevenko [mailto:community-noreply@qnx.com] 
Sent: Friday, February 20, 2009 5:58 PM
To: general-networking
Subject: TCP Communication Problem

I would like to ask for assistance with investigating a communication
problem we have with Modbus device over TCP. We use 6.3.0 SP3 with all
the network patches available for that release. 
The code was running correctly until we raised priorities of
communication thread to 52 (it was running with default priority of 10
before). Now, once every 15 minutes or something, TCP communication
stops for a second (like a packet is lost) and then, after a second it
continues, but hardware times out without data until that.
I have attached an excerpt from Wireshark capture file with the incident
(I can provide full file, if necessary).
So, if to look at packet #13, it's a Modbus query with Seq=37,
NextSeq=49. The packet #16 is the response for the query,  it has
Seq=34, NextSeq=45 and it contains Ack=49 confirming that the query has
been received by the device. The next packet from the node to the device
(#17) contains Ack=45, confirming that the response has been received by
the stack. However its Seq=64 and NextSeq=79 instead of expected Seq=49
and Wireshark states in packet analysis that previous segment has been
lost. Is not that sequence chain break strange? 
Indeed, the application does not receive the data from packet #16 (the
response for Modbus query). I have added receive timeout and attempted
to resend original query hoping that it will force packet retransmission
from Modbus device (user level resend - this is what packet #17 and all
the next packets from node to device with Transaction Id increasing
are). But as you can see from the logs, it had no effect. The node and
the device keep acknowledging they both have received the last packets
but it looks like they do not understand each other, as if they speak
different languages. At last, after a second, the node stack retransmits
original packet #13 on its own with packet #31 and the device answers it
once again with packet #35. The node accepts this answer, confirms it
with Ack in packet #36 and device starts answering all the 14 user-level
retries I've sent during that second of delay (#39, #42, #46, #49 and so
on). So, even though the communication restores after a second, it's
already too late for the hardware and node terminates the socket.
Could someone tell me, please, what was wrong with the first
communication attempt (packets #13-#16)? Why did not the data reach the
application? Which side has lost the packet (the node or the device)?
Everything looks exactly the same both times except for strange sequence
chain break I don't know how to explain.
Thank you for the help and sorry for taking your time.

_______________________________________________
General
http://community.qnx.com/sf/go/post22675

As far as I can tell from the packet log, there suppose to be a segment
from 192.168.10.13 to .111, sequence 49 - 63. This one never reaches the
.111's stack.

.111 report that with a dup ack at pkt# 24, and .13 retransmitted that
segment (with all other outstanding data), and things start to rolling
again.

Is .13 not send that out, or is .111 not receive it? I am not sure.
Where did you get this log. On .13, on .111, or a 3rd sniff machine?

If I had to guess, I would guess the packet is sent out, but .111 failed
to receive it. Because you indicated this only happened after you raise
your application priority to 52, I would guess that is higher enough to
starve the driver's receiving processing thread (typically running at
21, and there is a command line option to adjust it). Depends on what
network card you have, this may causing an overrun in driver.

Something you can try to see:

1) is nicinfo report any errors in driver?
2) Either lower your application to priority 20/21, or increas the
driver priority to 52/53, see if that help?

-xtang

> -----Original Message-----
> From: Oleh Derevenko [mailto:community-noreply@qnx.com]
> Sent: February 20, 2009 5:58 PM
> To: general-networking
> Subject: TCP Communication Problem
> 
> I would like to ask for assistance with investigating a communication
> problem we have with Modbus device over TCP. We use 6.3.0 SP3 with all
the
> network patches available for that release.
> The code was running correctly until we raised priorities of
communication
> thread to 52 (it was running with default priority of 10 before). Now,
> once every 15 minutes or something, TCP communication stops for a
second
> (like a packet is lost) and then, after a second it continues, but
> hardware times out without data until that.
> I have attached an excerpt from Wireshark capture file with the
incident
> (I can provide full file, if necessary).
> So, if to look at packet #13, it's a Modbus query with Seq=37,
NextSeq=49.
> The packet #16 is the response for the query,  it has Seq=34,
NextSeq=45
> and it contains Ack=49 confirming that the query has been received by
the
> device. The next packet from the node to the device (#17) contains
Ack=45,
> confirming that the response has been received by the stack. However
its
> Seq=64 and NextSeq=79 instead of expected Seq=49 and Wireshark states
in
> packet analysis that previous segment has been lost. Is not that
sequence
> chain break strange?
> Indeed, the application does not receive the data from packet #16 (the
> response for Modbus query). I have added receive timeout and attempted
to
> resend original query hoping that it will force packet retransmission
from
> Modbus device (user level resend - this is what packet #17 and all the
> next packets from node to device with Transaction Id increasing are).
But
> as you can see from the logs, it had no effect. The node and the
device
> keep acknowledging they both have received the last packets but it
looks
> like they do not understand each other, as if they speak different
> languages. At last, after a second, the node stack retransmits
original
> packet #13 on its own with packet #31 and the device answers it once
again
> with packet #35. The node accepts this answer, confirms it with Ack in
> packet #36 and device starts answering all the 14 user-level retries
I've
> sent during that second of delay (#39, #42, #46, #49 and so on). So,
even
> though the communication restores after a second, it's already too
late
> for the hardware and node terminates the socket.
> Could someone tell me, please, what was wrong with the first
communication
> attempt (packets #13-#16)? Why did not the data reach the application?
> Which side has lost the packet (the node or the device)? Everything
looks
>...