top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Who should send FIN during the CER/CEA exchange? [CLOSED]

+2 votes
1,308 views

Recently I have faced situation described below. Please ignore the dots - there is no table so I could present this in a proper table form.

The question is, when the GGSN/PCEF is establishing the session on TCP level to exchange Capabilities with Diameter Peer, who should be sending the FIN? Or maybe the FIN should not be sent at all?

In the below example, is what I saw in .pcap trace. Strange for me is there is not FIN present just FIN-Ack in this situation.

This was a issue, as I was given different IP for PCRF but I was told "everything else is the same" but it wasnt - the peer name was different.

Packet No......Direction.......Packet/message
1..............Out.............Syn
2..............In..............Syn-Ack
3..............Out.............Ack
4..............Out.............CER (diameter)
5..............In..............Ack of CER (tcp)
6..............In..............CEA (diameter)
7..............Out.............Ack of CEA (tcp)
8..............Out.............***FIN-Ack***
9..............In..............Ack
closed with the note: No more action required, as problem now seems to be solved.
posted May 14, 2014 by Bart Barton

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
My guess is that you are receiving the FIN, ACK where ack is for the previous data. I would suggest check the following thread and clarify if you are not hitting the same issue.
http://stackoverflow.com/questions/21390479/fin-omitted-fin-ack-sent

See the 1st answer of the problem for the explanation.
@Bart: I also have the similar impression what salil has suggested, there is FINACK followed by ACK which seems that FIN contains the ack of previous data received and ack from the other side is for the FIN. Please check the packet in detail and confirm.
Thanks guys for your opinion, I know the FIN is missing.
Question is not why FIN is missing ( realize the FIN-Ack is confirmation of receiving FIN), question is who should send the FIN or should FIN be sent after successful CER/CEA

Now it looks like the scenario is as follows:
On ACK of CEA (pckt7) the side B (PCRF) sends FIN.
this invokes FIN-Ack from A to B
Then B answers with Ack - in other words from now the TCP session is closed.

All the time, I was under impression, that IF anyone should be sending the FIN it would be the side A (pcEf) because it got what it wanted, not side B - the PCRF as we partly-see in this picture.
@Bart: I saw this is a TCP issue rather then Diameter Issue (as I am not Diameter Expert). From TCP point of view once the connection establishes any side can terminate the connection, however it is recommended that client should initiate the connection termination procedure.

For diameter behavior you may need to wait for some Diameter Expert Response.
Thanks,

We can close this topic

1 Answer

+1 vote

I was looking for some sample diameter pcap and found this one
http://www.freediameter.net/trac/browser/VirtualTestbed/mrb/capture.pcap?rev=9e5a3c884de6a635f786aea3e97e7e99f701a022

Just downloaded it from here (using the download option), though it was not between PCRF-PCEF but found that after CER-CEA exchange the FIN should not happen immediately, I believe it should be similar for PCRF-PCEF also.

Waiting for others to comment???

answer May 14, 2014 by Salil Agrawal
Thanks for sharing.

This is different because it's over SCTP.

I got to the idea that the FIN should not happen at all if the DIAMETER session is to be up-and-running.
Logically.. Diameter runs, in my case, on top of TCP session, how the Diameter can exchange any message without the connection on L4/3 and lower layers?

So half-answering my question. The FIN will be sent (still dont know by which side - I would say the Initiating side.) after the Diameter session is stopped.
If the PCRF will send Diameter message Do Not Want To talk To you, this should trigger TCP session to go down. So I would say after confirmation upon reciving Diameter message the FIN will be sent from PCRF side.

Hope I'm clear on this. I'm in a rush and this message was written with 4 interpution because of what I'm currently doing.

Thanks for all your help, looking forward for confirmation form nay side.
Yes FIN should not happen if we want session to continue after CER/CEA exchange. And you are right FIN should initiate by the same fellow who have initiated the SYN (though it should not be a must behavior).

By the way the link I shared has TCP based diameter (not sure why it is showing different at ur end)
Thanks,

I got what I wanted, we can close this topic
Similar Questions
+5 votes

How the scenario will be handled in case both client as well as server sends CER towards each other ?

+3 votes

I am sending CER to Scapv1 peer, but its sending 5015() result code with failed avp as Host-ip-Address.

Unable to solve the issue, help me please

0 votes

In one Diameter blog, I saw a statement in which mentioned, if a Diameter node receive CER from unknown peer it responds back to that peer with Result-Code AVP set to "DIAMETER_UNKNOWN_PEER".
Now my query, Does a Diameter node keep its potential peers information in advance ?

+3 votes

I have a query/doubt on below section of RFC 6733: 1.1.3

Changes from RFC 3588:

" Deprecated the exchange of CER/CEA messages in the open state.

This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document."

Scenario: In case a diameter node using SCTP association and does a restart procedure according to RFC 4960, section 5.2.4.1. Can the node (the one restarted the association) send CER on the association?

From the above RFC-6733 description it looks to me that the node which restart the association should not send CER, is my understanding correct? Please comment on this!

...