Chronological Thread 

< Chronological >      < Thread >

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Jye,

that should be a problem that was fixed in some of our newer
releases. Please upgrade to sctplib-1.0.0-pre18 and have a
try again. Then, if it still appears to be buggy, send another
mail.

Thanks,

Regards,

Andreas

Am Dienstag, 2. Juli 2002 02:03 schrieb 송제영:
> Hi,
>
> I've been testing Multihoming functionality of SCTP with sctplib-pre17 and
> found something strange with establishing associations.
>
> My testbed topology is simple as follows:
>
> INIT
> ---------->
> ---------------------
>
> | 1.1 1.2 |
>
> --------- ---------
>
> | Host A | | Host B |
>
> --------- ---------
>
> | 2.1 2.2 |
>
> ---------------------
>
> Routing tables
> A: 1.1-->1.2 B: 1.2-->1.1
> 2.1-->2.2 2.2-->2.1
>
>
> Both ends are multihomed and directly connected to each other through a
> pair of links. Under the normal circumstaces, everything works fine. Link
> failover worked great when I cut off 1.1-1.2 link. What I mean by the
> normal circumstances is that the IP setup of SCTP is like this:
>
> Host A(Client) : Primary=1.1 Secondary=2.1 Destination=1.2
> Host B(Server): Primary=1.2 Secondary=2.2
>
>
> But, if I try to make a connection using only one IP of one end, the
> connection ends up with INIT ACK discarded at the one that sent INIT in
> some cases. In one of those cases, the setup is like this:
>
> Host A(Client) : Primary=1.1 Secondary=none Destination=2.2
> Host B(Server) : Primary=1.2 Secondary=2.2
>
> The way the connection failed is:
> 1) Host A: INIT is sent from 1.1 through 2.1 to 2.2
> 2) Host B: INIT ACK is sent from 1.2 to 1.1 due to the routing table of
> Host B 3) Host A: INIT ACK is discarded because INIT ACK is regarded to be
> coming from 1.2 by looking at the src IP of INIT ACK 4) Association fail
>
> I don't know whether you've designed sctplib this way on purpose or already
> noticed this problem. However, this problem should be fixed because I see
> some other Association failure from the same reason when the routing tables
> of Host A and Host B are "cross- matched".
>
> I won't describe the detail of it now. If you need more detail, let me know
> then I'll post it here later.
>
> The possible fix for this seems like this:
> When the INIT sender checks the IP address of INIT ACK from the other end
> to validate the INIT ACK, every multihoming IP address contained in the
> payload of INI T ACK should be checked.
>
> In the expample above, INIT ACK is supposed to have the multihoming IP
> addresses of 1.2 and 2.2, and the Host A will check the validity by
> looking at those add ress contained in the payload, not the IP address(1.2)
> of IP header.
>
>
> I would like you to clear this up and possibly fix it.
>
> Thank you.
>
> Jye
> SCTP research from Samsung
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

- --
- ---------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS !
Computer Networking Technology Group | Send E-MAILS -- Use PGP !
University of Essen |
http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org
My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net
- ---------------------------------------------------------------------------
My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0
- ---------------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9IauYXAsLBNOCSsARAtArAJ0a25+e0NiIdE0mlh1Rh31On71zIgCg6Jo6
fWOU0JqaUkDUBX/tyk5EgaY=
=ymi9
-----END PGP SIGNATURE-----

---

• [SCTP-Discussion] Validity of INIT ACK, 송제영, 07/02/2002
  • Re: [SCTP-Discussion] Validity of INIT ACK, Andreas Jungmaier, 07/02/2002
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] Validity of INIT ACK, Tuexen Michael, 07/02/2002

---

Archive powered by MHonArc 2.6.19+.