RE: X2AP:handoverPreparationFailure message is not received at source node

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Vlad..

Please check and let me know if any more logs and details are required.

Thanks for your support.


Regards,

Ravi

-----Original Message-----
From: Vlad Yasevich [mailto:vyasevich@xxxxxxxxx]
Sent: Tuesday, January 12, 2016 5:38 PM
To: Ravi Puttachannaiah <ravi.puttachannaiah@xxxxxxxxxxx>; malc <mlashley@xxxxxxxxx>; linux-sctp@xxxxxxxxxxxxxxx
Subject: Re: X2AP:handoverPreparationFailure message is not received at source node

On 01/12/2016 06:29 AM, Ravi Puttachannaiah wrote:
> Hi Vlad, Malc,
>
> I have uploaded the logs in the dropbox. Please use the below URL to access the logs.
>
> https://www.dropbox.com/sh/utmo1jbw7l6itmx/AABSCk04YNxu3XTnq_Bk8l2Ea?d
> l=0

I'll take a look.
>
> Following is the details from the logs.
>
> working_sctp_s1ap_x2ap_logs.pcapng -In-case of an working logs you can observe that:
>
> 1. In packet no-471, the IP 172.33.1.47 is sending the
> X2AP:handoverPreperation message to 172.33.1.46 2. In packet no-475,
> the IP 172.33.1.46 is sending the X2AP:handoverPreperationFailure
> 172.33.1.47
>
> non-working_sctp_s1ap_x2ap_logs.pcappng- In-case of an non-working
> logs you can observe that
>
> 1. In packet no-162, the IP 172.33.1.47 is sending the
> X2AP:handoverPreperation message to 172.33.1.46 2. But in this case we are not seeing the X2AP:handoverPreperationFailure sent by 172.33.1.46. In the application logs we could see that application is writing to the socket successfully (there are no errors).
>
> As indicated previously the issue is not seen "When there is no re-try attempt on-going(between source node to peer-1) then there is no issue observed and we can see that X2AP:handoverPreparationFailure is successfully received at source node."
>
> Response to Malc query.
>
> 1. Is peer-node-2 putting the packet on the wire?
> RAVIP>> Yes.. From the application logs we can confirm that peer-node-2 is writing the message to the socket.

Just because the packet was written to the socket doesn't mean it's on the wire.  It may still by buffered if there hasn't been an ack.  I haven't checked yet, but I hope the logs above contain traces from peer-node-2, so we can see the message.

>
> 2. When you say 'not getting received at source node' - Do you mean at the ethernet layer, the application layer, or ?
> RAVIP>> We are not seeing message both at application level and also at wireshark. I suspect the message could be getting dropped at LKSCTP level.

No, if you are not seeing it in wireshark, then sctp doesn't see the packet either.
The packet capture happens before any protocol have an ability to drop anything.  Even some errors handled by the nic can be observed with wireshark.

-vlad

>
> Regards,
>
> Ravi
>
>
> -----Original Message-----
> From: Vlad Yasevich [mailto:vyasevich@xxxxxxxxx]
> Sent: Monday, January 11, 2016 10:51 PM
> To: Ravi Puttachannaiah <ravi.puttachannaiah@xxxxxxxxxxx>; malc
> <mlashley@xxxxxxxxx>; linux-sctp@xxxxxxxxxxxxxxx
> Subject: Re: X2AP:handoverPreparationFailure message is not received
> at source node
>
> On 01/11/2016 10:27 AM, Ravi Puttachannaiah wrote:
>> Hi Malc,
>>
>> We have collected both working and non-working logs. Could you please let us know where can we share the attachment (since you said the list drop the attachment). How other members share the attachments?
>>
>> Regards,
>
> Providing a pointer to tcpdump logs is the best way.
>
> -vlad
>
>>
>> Ravi
>>
>>
>> -----Original Message-----
>> From: linux-sctp-owner@xxxxxxxxxxxxxxx
>> [mailto:linux-sctp-owner@xxxxxxxxxxxxxxx] On Behalf Of malc
>> Sent: Thursday, January 07, 2016 8:44 PM
>> To: linux-sctp@xxxxxxxxxxxxxxx
>> Subject: Re: X2AP:handoverPreparationFailure message is not received
>> at source node
>>
>> Ravi,
>>
>> I think in order for anyone to help, you're going to need to provide a packet capture from 'source node' and 'peer-node-2', showing the working case, and the failing case, both from INIT onwards. (since the list drops attachments, you will need to post that somewhere we can access it.
>>
>> 1. Is peer-node-2 putting the packet on the wire?
>> 2. When you say 'not getting received at source node' - Do you mean at the ethernet layer, the application layer, or ?
>>
>> Cheers,
>> malc.
>>
>> On Thu, Jan 7, 2016 at 8:55 AM, Ravi Puttachannaiah <ravi.puttachannaiah@xxxxxxxxxxx> wrote:
>>> Could somebody please respond and help.
>>>
>>> -----Original Message-----
>>> From: Ravi Puttachannaiah
>>> Sent: Tuesday, January 05, 2016 2:35 PM
>>> To: 'linux-sctp@xxxxxxxxxxxxxxx' <linux-sctp@xxxxxxxxxxxxxxx>
>>> Subject: X2AP:handoverPreparationFailure message is not received at
>>> source node
>>>
>>> Hi,
>>>
>>>                 We are using X2AP protocol over the LKSCTP (ver 1.0.16) and we are seeing the following issue.
>>>
>>> Scenario:
>>>
>>>                 1.            We have source node connected to the two peer nodes peer-1 and peer-2.
>>>                 2.            Source node does not have a SCTP connectivity with peer-1 because the peer-1 was not reachable. In this case source node will re-try every 4-seconds to establish a SCTP connection by creating a new SCTP association and sending a SCTP:INIT. If there is no response for SCTP:INIT (once all the SCTP:INIT retries are exhausted) then source node will close the socket or sctp association and retry again after 4-seconds.
>>>
>>>
>>> Problem:
>>>
>>>                 1.            It is observed that when the retry attempt is going on for peer-1 the X2AP message sent from peer-2 node to source node is not getting received at source node. The source node is sending X2AP:handoverPreparation to peer-2 node and this is successfully received at peer-2. But when peer-2 sends X2AP:handoverPreparationFailure to source node this message is not received at  source node.
>>>
>>>                 2.            When there is no re-try attempt on-going(between source node to peer-1) then there is no issue observed and we can see that X2AP:handoverPreparationFailure is successfully received at source node.
>>>
>>>                 Could you please help us to resolve this SCTP issue. Please let me know what logs are required to check this issue.
>>>
>>> Regards,
>>>
>>> Ravi
>>>
>>> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp"
>>> in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo
>>> info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp"
>> in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo
>> info at  http://vger.kernel.org/majordomo-info.html
>> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>> N     r  y   b X  ǧv ^ )޺{.n +    {   i {ay ʇڙ ,j   f   h   z  w
>    j:+v   w j m         zZ+     ݢj"  !tml=
>>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f




[Index of Archives]     [Linux Networking Development]     [Linux OMAP]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux