Glenn,

I'm sorry, but I don't have the time to take a deep look right now. If 
you need a response quickly then please go through the support channels.

I'm not sure what you mean by mini-TCP stack? Is it running on QNX? What 
QNX version is this?

Without looking at the traces, it should be ok that the Client 
terminates the connection with a single FIN-ACK or the ACK, FIN-ACK 
sequence. Both should be legal.

What stack implementation is the Server running? Is it really an endless 
loop? Or is it just that it's timing out and resending the last segment? 
Then it will eventually stop...

/P

On 24/03/10 11:35 AM, Glenn Schmottlach wrote:
> I am trouble-shooting with WireShark a TCP termination issue between an off-board service (remote host) running a mini
-TCP stack and a QNX client running 6.4.1 with io-pkt-v4. I have attached two traces that illustrate my issue. I was 
hoping a QNX expert could take a quick look and help me determine if both termination sequences are valid and help 
identify (if it exists) any issue with mini-stack. The sequences are very short and boil down to 3-4 frames that need 
examination.
>
> The first trace (linux_client.pcap) shows a linux client (curl) connecting to the remote service, issuing an HTTP GET 
and then dropping the connection. The sequence behaves properly using the mini-TCP stack and the connection is 
successfully disconnected (see frames 4 - 11).
>
> The second trace (qnx_client.pcap) involves the same client (curl) running under QNX and connecting to the same remote
 host.  The disconnection fails and the link goes into a perpetual FIN, FIN-ACK  sequence between the client and service
. The pertinent frames are 7- 11.
>
> The real difference I can see between the two traces is the fact that the Linux stack shows the following sequence:
>
> Client (192.168.1.2)                          Server (192.168.1.1)
> ACK
> FIN-ACK
>                                                              FIN
>                                                              ACK
>
> whereas the QNX stack does the following:
>
> Client (192.168.1.2)                          Server (192.168.1.1)
> FIN-ACK
>                                                              the wheels fall off and we enter
>                                                              and endless loop
>
> Can someone please take pity on me and verify that QNX's connection termination sequence is legitimate and point out 
any obvious errors with the mini-TCP stack state machine. This is not my area of expertise but I hoped someone with a 
little better understanding on the TCP state transitions could provide some helpful advice.
>
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post50336
>    

On Wed, Mar 24, 2010 at 11:35:15AM -0400, Glenn Schmottlach wrote:
> I am trouble-shooting with WireShark a TCP termination issue between an off-board service (remote host) running a mini
-TCP stack and a QNX client running 6.4.1 with io-pkt-v4. I have attached two traces that illustrate my issue. I was 
hoping a QNX expert could take a quick look and help me determine if both termination sequences are valid and help 
identify (if it exists) any issue with mini-stack. The sequences are very short and boil down to 3-4 frames that need 
examination.
> 
> The first trace (linux_client.pcap) shows a linux client (curl) connecting to the remote service, issuing an HTTP GET 
and then dropping the connection. The sequence behaves properly using the mini-TCP stack and the connection is 
successfully disconnected (see frames 4 - 11).
> 
> The second trace (qnx_client.pcap) involves the same client (curl) running under QNX and connecting to the same remote
 host.  The disconnection fails and the link goes into a perpetual FIN, FIN-ACK  sequence between the client and service
. The pertinent frames are 7- 11.
> 
> The real difference I can see between the two traces is the fact that the Linux stack shows the following sequence:
> 
> Client (192.168.1.2)                          Server (192.168.1.1)
> ACK
> FIN-ACK
>                                                             FIN
>                                                             ACK
> 
> whereas the QNX stack does the following:
> 
> Client (192.168.1.2)                          Server (192.168.1.1)
> FIN-ACK
>                                                             the wheels fall off and we enter
>                                                             and endless loop
> 
> Can someone please take pity on me and verify that QNX's connection termination sequence is legitimate and point out 
any obvious errors with the mini-TCP stack state machine. This is not my area of expertise but I hoped someone with a 
little better understanding on the TCP state transitions could provide some helpful advice.
> 

Their sending the fin without the ack flag set which we ignore.
There's no set behaviour for this but it's often a symptom
of someone trying to probe sequence numbers.  tcpdump seems to
know something's odd as it displays the sequence number of the
fin as an absolute, rather than relative value.

Regards,

-seanb

Hi

I need wireshark software for QNX 6.4, so can you please tell from where I can get it and How to install it on QNX 6.4


 Thanks