On Wed, 7 Feb 2007, Vlad Yasevich wrote:
> I think I've tracked this down. Can you apply the attached patch on top
> of the one I posted before and re-run your test.
Using the 2.6.20 kernel on the sending side with both patches applied, the
problem seems to be fixed.
Thanks.
--
-
ets have been transmitted and lost in transit).
Thanks.
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Hampshire, UK
+44-1425-651392
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
"$net" -p sctp -j DROP
echo "set"
sleep 5
iptables -F
echo "flushed"
sleep 5
done
--
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Hampshire, UK
+44-1425-651392
[EMAIL PROTECTED]
-
To unsubscri
(indicated by ping) is on the order of
<0.25ms.
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Hampshire, UK
+44-1425-651392
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
k.
I've tried applying the patch. However, the failure still seems to
happen in the original test system with a patched kernel. A look at the
network traffic shows that the receiving side is still returning a
gap-ack, the chunks in the gap are never resent and I don't see a
FORWARD TSN
the timetolive is set to 0, so this is
what I have now done since I had not intended to set the timetolive in the
first place (but I thought it was still worth posting details of the
problem since it does appear to be a bug).
--
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Ham
t this is not unordered data and I'm not clear on
how abandoned chunks are supposed to be handled - I hadn't intentionally
enabled the abandonment functionality, the timetolive was set on the
transmitted chunks by accident.
--
- Steve Hill
Software Engineer
Dialogic
Ford
