Patrik Lahti
|
Re: TCP Connection Termination Sequence Issue
|
Patrik Lahti
03/24/2010 12:41 PM
post50346
|
Re: TCP Connection Termination Sequence Issue
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
>
|
|
|
Sean Boudreau(deleted)
|
Re: TCP Connection Termination Sequence Issue
|
Sean Boudreau(deleted)
03/24/2010 1:07 PM
post50351
|
Re: TCP Connection Termination Sequence Issue
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
|
|
|
swati jaiswal
|
Re: TCP Connection Termination Sequence Issue
|
swati jaiswal
12/08/2010 4:40 AM
post77752
|
Re: TCP Connection Termination Sequence Issue
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
|
|
|