Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 06 Sep 2007 09:18:37 -0500
From:      "Peter Lei (peterlei)" <peterlei@cisco.com>
To:        Randall Stewart <rrs@cisco.com>, sazzadur rahman <rahman.sazzadur@gmail.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: A query regarding sctp_bindx api in SCTP
Message-ID:  <46E00C3D.1010009@cisco.com>
In-Reply-To: <46DFFC8E.2030502@cisco.com>
References:  <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> <46DFFC8E.2030502@cisco.com>
index | next in thread | previous in thread | raw e-mail 

[-- Attachment #1 --]
Randall Stewart wrote:
> sazzadur rahman wrote:
>> Hello,
>> I am using sctp patch for freebsd6.1. For dynamic address
>> configuration, I
>> am calling sctp_bindx() API after successfull bind() and connect() API's.
>> Although sctp_bindx() API successfully returns 0, the debug message
>> shows:
>>
>> addr_mgmt_assoc: added to pending list...
>> asconf_queue_add: appended asconf ADD_IP_ADDRESS...
>>
>> And I didn't see any ASCONF chunk sent to the peer in the tcpdump.
>> Hence, I
>> am confused why it should be in the pendling list instead of immediate
>> send
>> to peer?
> 
> Hmm.. I would like to see a packet trace of this as well..
> 
> A couple of thoughts.
> 
> a) The 6.x code is a bit out of date.. I need to update
>    and get a new patch out for you.. I know Peter did some
>    work on the ASCONF code recently.. so there may be some
>    fixes that have not been propagated to 6.x.. which could
>    be a problem (added Peter for that reason even though I
>    know he subscribes.. not sure how often he reads net).

I don't recall if there was something in the timeframe of 6.1
where bindx() broke or not... there were a number of bugs fixed
surrounding bindx() though for 7.0/-current for the new address
list handling and change to use the iterator work thread.

> b) Whenever an address gets added like this, then the address will
>    go into a pending point in the assoc. Since it can't be used
>    yet i.e. the ASCONF-ACK must be returned BEFORE the address
>    is part of the assoc. I am also not sure of the state of your
>    association at this point. I will try testing this... since it
>    is most likely in a front state, this may also be a problem.
>    The ASCONF cannot be sent until after we reach ESTABLISHED... not
>    sure we have tested this scenario.

Any queued asconf's would go out after hitting the established
state...

There was a bug in the 7.0 code where the asconf would not get
queued at all in the early front state (COOKIE-WAIT) because
the 'peer supports addip' flag had not been set yet.

> c) Normally I would think you should do all the bindx BEFORE the
>    connect. When you do subset binding (which you are doing here
>    since you are NOT bound-all) then what you are saying is that
>    YOU the application wish to manage the addresses.. no automatic
>    ASCONF will be done for you. When you do the bindx() it is supposed
>    to kick off the ASCONF.. but again.. this may be an issue
>    since you are in a front state... I will test this scenario
>    with the latest 7.0 code and see if I can recreate it.

This works fine on 7.0.

If Randy can update the patch for 6.1, we might be able to better
assist.

--peter


> R
> 
>>
>> In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that
>> "If an
>> ASCONF chunk is outstanding, then the ASCONF chunk should be queued for
>> later transmission and no further action should be taken until the
>> previous
>> ASCONF is acknowledged or a timeout occurs." But as I am calling
>> sctp_bindx() for the first time, there should not be any previous ASCONF
>> existing.
>>
>> Does anyone have any idea what I am missing here?
>> I would appriciate any help in this regard.
>>
>> Best Regards,
>> Md. Sazzadur Rahman,
>> Graduate Student,
>> School of Computer Science,
>> University of Oklahoma,
>> Norman, USA
>>
>> ---------------------------code segment I have used---------------------
>> //socket
>>         s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP);
>>
>> //bind
>>         memset(&myAddr, 0, sizeof myAddr);
>>         myAddr.sin_family = AF_INET;
>>         myAddr.sin_port = htons(5060);
>>         myAddr.sin_addr.s_addr = inet_addr("129.15.78.125");
>>         if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) {
>>                 goto close;
>>         }
>> //connect
>>         memset(&farAddr, 0, sizeof farAddr);
>>         farAddr.sin_family = AF_INET;
>>         farAddr.sin_port = htons(6060);
>>         farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" );
>>         int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof
>> farAddr);
>>
>> //sctp_bindx
>>         struct sockaddr_in my2ndAddr;
>>         memset(&my2ndAddr, 0, sizeof my2ndAddr);
>>         my2ndAddr.sin_len = sizeof my2ndAddr;
>>         my2ndAddr.sin_family = AF_INET;
>>         my2ndAddr.sin_port = htons(5060);
>>         my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126");
>>
>>         iRet = sctp_bindx(s,(struct
>> sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR);
>>
>> ------------------------------------------
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
> 
> 

-- 
Peter Lei
IP Engineering Tech Center
Cisco Systems, Inc.
office: (773) 695-8201
mobile: (847) 830-8869
peterlei@cisco.com

[-- Attachment #2 --]
0	*H
010	+0	*H
	00G.5L1&!;0
	*H
0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
070505191640Z
080504191640Z0D10UThawte Freemail Member1!0	*H
	peterlei@cisco.com0"0
	*H
0
'E^)ߢBS4C{TH|o}Y/¯=a)$*͐?/T8;KzH=ݣ%Dgݕ_O#Η	zzڀ8 YPU+U=usEK1`v礮V1T2![+yǸ.'Fr\XnQ9iV9I'5,0Nv1(9t!+ޟJD̿Ƿ/0-0U0peterlei@cisco.com0U00
	*H
=<*F;ѷb'aDAf8]%4v9 l^ɞr/ꏋ@8oLy]::zT	:c!lYF(?u"%@$}&̓QP`[jαo00G.5L1&!;0
	*H
0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0
070505191640Z
080504191640Z0D10UThawte Freemail Member1!0	*H
	peterlei@cisco.com0"0
	*H
0
'E^)ߢBS4C{TH|o}Y/¯=a)$*͐?/T8;KzH=ݣ%Dgݕ_O#Η	zzڀ8 YPU+U=usEK1`v礮V1T2![+yǸ.'Fr\XnQ9iV9I'5,0Nv1(9t!+ޟJD̿Ƿ/0-0U0peterlei@cisco.com0U00
	*H
=<*F;ѷb'aDAf8]%4v9 l^ɞr/ꏋ@8oLy]::zT	:c!lYF(?u"%@$}&̓QP`[jαo0?0
0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
030717000000Z
130716235959Z0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA00
	*H
0Ħ<UsUNʙZhup[v:aQP
0cZ,p+Z?qV˯<6$*+w=+>@dקe*TH<a@dr`00U00CU<0:08642http://crl.thawte.com/ThawtePersonalFreemailCA.crl0U0)U"0 010UPrivateLabel2-1380
	*H
HP.
fgCL!6-6/P p<ab:~t%Pb'qW%ݩ9 Oe_N4[5MwV!x!5$F]_eO1d0`0v0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA.5L1&!;0	+0	*H
	1	*H
0	*H
	1
070906141837Z0#	*H
	1^Hao)`hyUX0R	*H
	1E0C0
*H
0*H
0
*H
@0+0
*H
(0	+71x0v0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA.5L1&!;0*H
	1xv0b10	UZA1%0#U
Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA.5L1&!;0
	*H
`կ&!\.Etv쾜'.;Ujqa]+8RXgSc>P
ǠC[QsjҐW٠$4	g
LTm/3n_1Nܑ\v*CS~enQ؊r"_dݼB~NivfjIT,1HCz8ŝpֵ׳{A8~͐];!1vxdAF5-s8KX W_l".^$
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E00C3D.1010009>