- From: Michael Tuexen <michael.tuexen AT micmac.franken.de>
- To: Subin Martin <subin.martin AT hotmail.com>
- Cc: sctp-discussion AT sctp.de
- Subject: Re: [SCTP-Discussion] SCTP ABORT ("Connection reset by peer") over high latency link
- Date: Thu, 18 Aug 2011 22:06:25 +0200
- List-archive: <http://lists.franken.de/pipermail/sctp-discussion>
- List-id: SCTP Discussions <sctp-discussion.sctp.de>
On Aug 18, 2011, at 9:28 PM, Subin Martin wrote:
>
>
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.
I responded to the private mail... You can't use the sctplib when there is an
SCTP kernel
implementation. But I would recommend the kernel implementation anyway...
Best regards
Michael
>
>
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
>
>
Archive powered by MHonArc 2.6.19+.