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

Question

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

Comments

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

Answer 1

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???

Comments

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