SCTP Discussions

Text archives Help


RE: [SCTP-Discussion] SCTP ABORT ("Connection reset by peer") over high latency link


Chronological Thread 
  • From: Subin Martin <subin.martin AT hotmail.com>
  • To: <sctp-discussion AT sctp.de>
  • Subject: RE: [SCTP-Discussion] SCTP ABORT ("Connection reset by peer") over high latency link
  • Date: Fri, 19 Aug 2011 22:36:57 +0200
  • Importance: Normal
  • List-archive: <http://lists.franken.de/pipermail/sctp-discussion>
  • List-id: SCTP Discussions <sctp-discussion.sctp.de>

Hello All,

I had a discussion with Michael in another mail and it seems that the issue is caused by a NAT box in between the SCTP client and server. The NAT changes the ip address and during the SCTP heart beat message exchange, since the ip address is different, the client cant find the right ip address and because of this SCTP association fails. So SCTP server sends an ABORT to the client. I removed the NAT and everything went fine.

Regards,
Subin



From: subin.martin AT hotmail.com
To: michael.tuexen AT micmac.franken.de
Subject: RE: [SCTP-Discussion] SCTP ABORT ("Connection reset by peer") over high latency link
Date: Thu, 18 Aug 2011 21:28:39 +0200
CC: sctp-discussion AT sctp.de


Hello Michael,

Thanks. I have send the tracebacks to you on a separate email.
I am using the sctp linux kernel implementation. I had complied locally sctplib but when application was linked with this library, it was showing that kernel level sctp available and it wasnt working. I couldnt remove the sctp linux kernel module as it needed that i need to compile the kernel.

Regards,
Subin


> Subject: Re: [SCTP-Discussion] SCTP ABORT ("Connection reset by peer") over high latency link
> From: Michael.Tuexen AT micmac.franken.de
> Date: Thu, 18 Aug 2011 18:37:16 +0200
> CC: sctp-discussion AT sctp.de
> To: subin.martin AT hotmail.com
>
> On Aug 18, 2011, at 4:41 PM, Subin Martin wrote:
>
> > Hello all,
> >
> > I am trying to make a TCP to SCTP protocol translator with SCTP acting as the transport protocol over a high latency link. This will be implemented in an ip gateway PC which also does IP header compression before transmitting it over the high latency link.
> >
> > For testing, I made a SCTP client to send 100 packets of 1000byte data to SCTP server listening on the other side of the high latency link. Now the issue I am facing is that I can send around 12 to 14 packets of 1000 bytes properly. After that the "Connection reset by peer" happens and because of that I am not able to send any more packets. Wireshark showed me that the otherside is sending an SCTP ABORT packet and thats why this issue is happening. But this issue is not seen if i try to send the packets from any PC connected to the gateway. Here everything goes fine.
> Hi,
>
> which SCTP implementation are you using? The sctplib or the Linux kernel implementation or
> a different one?
>
> I looked at the trace and I don't see any suspicious... Maybe having a wireshark
> from all interfaces at the sender of the ABORT chunk might help...
> >
> > In the gateway I have a tun tap device as the default gateway so all the packets are received by it and then IP compression is done and send off as UDP packets to the other gateway over the link. I have also configured SCTP heartbeat, rto max, min etc to suit the channel delay. For channel delay I use tc and netem available under linux. The delay is configured for about 500msec.
> >
> > I am not sure if the lack of MAC address in the tun tap device is causing this issue ie the issue having to do with Linux security than with the SCTP library. I have attached the wireshark dump(of other gateway) for the working and failed conditions. Please let me know where I am going wrong. Also please let me know if anything is not clear in the issue or if you need more information.
> I don't think that this kind of stuff would result in sending an ABORT...
>
> You can send trace files directly to me, since the mailing list enforces strict
> size limits...
>
> Best regards
> Michael
> >
> > Thanks for your help!
> >
> > Regards,
> > Subin Martin
> > <working_dump><failed_dump>_______________________________________________
> > sctp-discussion mailing list
> > sctp-discussion AT sctp.de
> > http://www.sctp.de/mailman/listinfo/sctp-discussion
>

_______________________________________________ sctp-discussion mailing list sctp-discussion AT sctp.de http://www.sctp.de/mailman/listinfo/sctp-discussion



Archive powered by MHonArc 2.6.19+.

Top of page