Chronological Thread 

< Chronological >      < Thread >

---

hi!, i think the following is the solution to the problem.
Go to the function check_if_complete_nrDLiLi(streamid),
and add the following code.
just below the statement,

<<streaminfolst[stream_id].nextRsn = nextRsn + 1;>>

#ifdef SCTP_FIXES
DLL_CurrentPointerToHead(nrDLiLi);
DLL_GetCurrentRecord(nrDLiLi, &nrChunk);
check_if_complete_nrDLiLi(stream_id);
#endif /* SCTP_FIXES */

Let me know the results and pro's and con's of this addtion of code.
-Rgds
Harish K.

-----Original Message-----
From:
discussion-admin AT sctp.de

[mailto:discussion-admin AT sctp.de]On
Behalf Of
discussion-request AT sctp.de
Sent: Friday, June 29, 2001 3:31 PM
To:
discussion AT sctp.de
Subject: discussion digest, Vol 1 #101 - 6 msgs


Send discussion mailing list submissions to

discussion AT sctp.de

To subscribe or unsubscribe via the World Wide Web, visit
http://www.sctp.de/mailman/listinfo/discussion
or, via email, send a message with subject or body 'help' to

discussion-request AT sctp.de

You can reach the person managing the list at

discussion-admin AT sctp.de

When replying, please edit your Subject line so it is more specific
than "Re: Contents of discussion digest..."


Today's Topics:

1. Discard server's incorrect behaviour (Marjan Bozinovski)
2. Re: Discard server's incorrect behaviour
(=?ISO-8859-1?Q?Michael=20T=FCxen?=)
3. SCTP queries (kusum)
4. RE: Discard server's incorrect behaviour (Yeo Choon Kiat ICM CA MS MI
E7 Extern)
5. RE: SCTP queries (Tuexen Michael)
6. RE: Discard server's incorrect behaviour (Tuexen Michael)

--__--__--

Message: 1
From: "Marjan Bozinovski"
<marjanb AT kom.auc.dk>
To:
<discussion AT sctp.de>
Date: Thu, 28 Jun 2001 21:38:07 -0700
charset="iso-8859-1"
Subject: [SCTP-Discussion] Discard server's incorrect behaviour
Reply-To:
discussion AT sctp.de

Hi,

I tried the "discard_server" application at one PC and the
"terminal_application" at another PC, and started to send packets from the
terminal side to the discard server side. I was watching the traffic on the
interfaces with Ethereal. What I noticed (after many times repeating the
same procedure) is that, the association is always successfully established,
as well as the first sent packet, which is normally received and
acknowledged. But, starting from the second sent packet, any subsequent
packet does not trigger a display on the screen that a new data has arrived,
neither causes acknowledgments, instead, the discard server screen gets
frozen. Also, as a consequence, relatively large files are created in the
memory, probably depending on the number of sent packets.
Please check out if this is a bug or just my mistake.

Best regards,
Marjan


--__--__--

Message: 2
From: =?ISO-8859-1?Q?Michael=20T=FCxen?=
<Michael.Tuexen AT micmac.franken.de>
To:
<discussion AT sctp.de>
Cc: Marjan Bozinovski
<marjanb AT kom.auc.dk>
Subject: Re: [SCTP-Discussion] Discard server's incorrect behaviour
Date: Thu, 28 Jun 2001 22:27:29 +0200
Reply-To:
discussion AT sctp.de

Dear Marja,

I will look into this tomorrow. Thank you very much for the report.

Best regards
Michael

--
e-mail:
Michael.Tuexen AT micmac.franken.de

On Thu, Jun 28, 2001, Marjan Bozinovski
<marjanb AT kom.auc.dk>
wrote:

>Hi,
>
>I tried the "discard_server" application at one PC and the
>"terminal_application" at another PC, and started to send packets from the
>terminal side to the discard server side. I was watching the traffic on the
>interfaces with Ethereal. What I noticed (after many times repeating the
>same procedure) is that, the association is always successfully
established,
>as well as the first sent packet, which is normally received and
>acknowledged. But, starting from the second sent packet, any subsequent
>packet does not trigger a display on the screen that a new data has
arrived,
>neither causes acknowledgments, instead, the discard server screen gets
>frozen. Also, as a consequence, relatively large files are created in the
>memory, probably depending on the number of sent packets.
>Please check out if this is a bug or just my mistake.
>
>Best regards,
>Marjan
>
>_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion



--__--__--

Message: 3
Date: Fri, 29 Jun 2001 08:29:34 +0530
From: kusum
<kusum AT india.mercurykr.com>
To: discussion
<discussion AT sctp.de>
Subject: [SCTP-Discussion] SCTP queries
Reply-To:
discussion AT sctp.de

Hi! all,

Here are some queries for SCTP which i couldn't understand...
1)what kind of security is provided by cookie mechanism and how?As every
feature of SCTP has reason behind it like multiple streams resolves the
problem of head of line blocking,and during association iniitalization
we deal the temperory TCB for resolving SYN attack problem of TCP .So
for which purpose we r using cookie mechanism?

2)It is mentioned in RFC that a host is multihomed if it is having
multiple transport address.but i think it shouldn't be like this.it
should be a host is multihomed if it support multiple IP addresses.
as we know that if we have one IP address and two ports
in that case we have two different transport address with same IP
address and different port numbers.but i think this is not
multihoming.multihoming is same port different IP addresses.Please
correct me......
regards.....
KK


--__--__--

Message: 4
From: Yeo Choon Kiat ICM CA MS MI E7 Extern
<ChoonKiat.Yeo.extern AT icn.siemens.de>
To:
"'discussion AT sctp.de'"

<discussion AT sctp.de>
Cc: Marjan Bozinovski
<marjanb AT kom.auc.dk>
Subject: RE: [SCTP-Discussion] Discard server's incorrect behaviour
Date: Fri, 29 Jun 2001 09:09:21 +0200
charset="iso-8859-1"
Reply-To:
discussion AT sctp.de

hi Michael and all,=20
we have looked into the problem and we found that there is a typo in =
the
file wrapper.c.
The problem is caused by the function int SCTP_receive ( unsigned int
associationID, unsigned short streamID, unsigned char *buffer, unsigned =
int
*length) in wrapper.c.=20

The SCTP_receive function should call sctp_receive, instead it calls
SCTP_receive (itself) resulting in a loop.
Just change this, do a 'make' again and all is back to normal.

Regards,=20
eric and gang.

-----Original Message-----
From: Michael T=FCxen
[mailto:Michael.Tuexen AT micmac.franken.de]
Sent: Thursday, June 28, 2001 10:27 PM
To:
discussion AT sctp.de
Cc: Marjan Bozinovski
Subject: Re: [SCTP-Discussion] Discard server's incorrect behaviour


Dear Marja,

I will look into this tomorrow. Thank you very much for the report.

Best regards
Michael

--=20
e-mail:
Michael.Tuexen AT micmac.franken.de

On Thu, Jun 28, 2001, Marjan Bozinovski
<marjanb AT kom.auc.dk>
wrote:

>Hi,
>
>I tried the "discard_server" application at one PC and the
>"terminal_application" at another PC, and started to send packets from =
the
>terminal side to the discard server side. I was watching the traffic =
on the
>interfaces with Ethereal. What I noticed (after many times repeating =
the
>same procedure) is that, the association is always successfully
established,
>as well as the first sent packet, which is normally received and
>acknowledged. But, starting from the second sent packet, any =
subsequent
>packet does not trigger a display on the screen that a new data has
arrived,
>neither causes acknowledgments, instead, the discard server screen =
gets
>frozen. Also, as a consequence, relatively large files are created in =
the
>memory, probably depending on the number of sent packets.
>Please check out if this is a bug or just my mistake.
>
>Best regards,
>Marjan
>
>_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion


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

--__--__--

Message: 5
From: Tuexen Michael
<Michael.Tuexen AT icn.siemens.de>
To:
"'discussion AT sctp.de'"

<discussion AT sctp.de>
Subject: RE: [SCTP-Discussion] SCTP queries
Date: Fri, 29 Jun 2001 10:56:58 +0200
Reply-To:
discussion AT sctp.de

Dear all,
see my comments below.
Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: kusum
> [SMTP:kusum AT india.mercurykr.com]
> Sent: Friday, June 29, 2001 5:00 AM
> To: discussion
> Subject: [SCTP-Discussion] SCTP queries
>
> Hi! all,
>
> Here are some queries for SCTP which i couldn't understand...
> 1)what kind of security is provided by cookie mechanism and how?As every
> feature of SCTP has reason behind it like multiple streams resolves the
> problem of head of line blocking,and during association iniitalization
> we deal the temperory TCB for resolving SYN attack problem of TCP .So
> for which purpose we r using cookie mechanism?
>
[Tuexen Michael] Consider an attacker who is flooding you with
INITs. He is using his own IP address or is using a different
(spoofing).
The receiver will send back INIT-ACKs and forget about the assoc. So
NO resources at the receiver will be reserved for the attacker. Only
if
you got back the COOKIE from the sender of the INIT you will reserve
some
resources. If the attacker is spoofing the IP Address, this will never
happen.
> 2)It is mentioned in RFC that a host is multihomed if it is having
> multiple transport address.but i think it shouldn't be like this.it
[Tuexen Michael] Where do you find this? I don't find the
place where this is stated. I find a lot of 'multi-homed endpoints'.
> should be a host is multihomed if it support multiple IP addresses.
> as we know that if we have one IP address and two ports
> in that case we have two different transport address with same IP
> address and different port numbers.but i think this is not
> multihoming.multihoming is same port different IP addresses.Please
> correct me......
> regards.....
> KK
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

--__--__--

Message: 6
From: Tuexen Michael
<Michael.Tuexen AT icn.siemens.de>
To:
"'discussion AT sctp.de'"

<discussion AT sctp.de>
Cc: Marjan Bozinovski
<marjanb AT kom.auc.dk>
Subject: RE: [SCTP-Discussion] Discard server's incorrect behaviour
Date: Fri, 29 Jun 2001 10:59:29 +0200
charset="ISO-8859-1"
Reply-To:
discussion AT sctp.de

Dear all,
thanks for the help. To much of copy and paste..
Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Yeo Choon Kiat ICM CA MS MI E7 Extern =
[SMTP:ChoonKiat.Yeo.extern AT icn.siemens.de]
> Sent: Friday, June 29, 2001 9:09 AM
> To:
> 'discussion AT sctp.de'
> Cc: Marjan Bozinovski
> Subject: RE: [SCTP-Discussion] Discard server's incorrect behaviour
>=20
> hi Michael and all,=20
> we have looked into the problem and we found that there is a typo in =
the
> file wrapper.c.
> The problem is caused by the function int SCTP_receive ( unsigned int
> associationID, unsigned short streamID, unsigned char *buffer, =
unsigned int
> *length) in wrapper.c.=20
>=20
> The SCTP_receive function should call sctp_receive, instead it calls
> SCTP_receive (itself) resulting in a loop.
> Just change this, do a 'make' again and all is back to normal.
>=20
> Regards,=20
> eric and gang.
>=20
> -----Original Message-----
> From: Michael T> =FCxen
> [mailto:Michael.Tuexen AT micmac.franken.de]
> Sent: Thursday, June 28, 2001 10:27 PM
> To:
> discussion AT sctp.de
> Cc: Marjan Bozinovski
> Subject: Re: [SCTP-Discussion] Discard server's incorrect behaviour
>=20
>=20
> Dear Marja,
>=20
> I will look into this tomorrow. Thank you very much for the report.
>=20
> Best regards
> Michael
>=20
> --=20
> e-mail:
> Michael.Tuexen AT micmac.franken.de
>=20
> On Thu, Jun 28, 2001, Marjan Bozinovski
> <marjanb AT kom.auc.dk>
> wrote:
>=20
> >Hi,
> >
> >I tried the "discard_server" application at one PC and the
> >"terminal_application" at another PC, and started to send packets =
from the
> >terminal side to the discard server side. I was watching the traffic =
on the
> >interfaces with Ethereal. What I noticed (after many times repeating =
the
> >same procedure) is that, the association is always successfully
> established,
> >as well as the first sent packet, which is normally received and
> >acknowledged. But, starting from the second sent packet, any =
subsequent
> >packet does not trigger a display on the screen that a new data has
> arrived,
> >neither causes acknowledgments, instead, the discard server screen =
gets
> >frozen. Also, as a consequence, relatively large files are created =
in the
> >memory, probably depending on the number of sent packets.
> >Please check out if this is a bug or just my mistake.
> >
> >Best regards,
> >Marjan
> >
> >_______________________________________________
> >discussion mailing list
> >discussion AT sctp.de
> >http://www.sctp.de/mailman/listinfo/discussion
>=20
>=20
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion


--__--__--

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


End of discussion Digest_______________________________________________
discussion mailing list
discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/discussion

---

• [SCTP-Discussion] RE: discussion digest, Vol 1 #101 - 6 msgs, hari, 07/03/2001
  • Re: [SCTP-Discussion] RE: discussion digest, Vol 1 #101 - 6 msgs, Andreas Jungmaier, 07/03/2001

---

Archive powered by MHonArc 2.6.19+.