SCTP : problems in sending ASCONF chunks

Mon Dec 29 17:12:34 UTC 2008

Hello M.Tüxen,

I performed a quick test and at the INIT/INIT-ACK exchange, I noticed the following :

- In the INIT chunk, the Supported Extensions Parameter field indicates that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET and AUTH are supported
- In the INIT-ACK chunk, there is no field indicating that any of the chunks listed above are supported...

I didn't think about looking in this before >_<

Since there is no indication given to my PC, perhaps my PC assumes that T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET and AUTH.

Could it be that, because it doesn't see any Supported Extensions Parameter field in the INIT-ACK, my PC doesn't try to send any ASCONF chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK and AUTH parameters in the Supported Extensions Parameter, in both the INIT and the INIT-ACK chunks, to have the possibility of sending an ASCONF chunk ?

Kind regards

Aman Jassal

-----Message d'origine-----
De : Michael Tüxen [mailto:Michael.Tuexen at lurchi.franken.de] 
Envoyé : lundi 29 décembre 2008 16:49
À : zze-Abac JASSAL A ext RD-RESA-ISS
Cc : freebsd-net at freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS
Objet : Re: SCTP : problems in sending ASCONF chunks

Hi Aman,

I'm not that familiar with the Linux box configuration. If you look at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and the SCTP-AUTH extension? Both are required...

Best regards
Michael
On Dec 29, 2008, at 2:36 PM, <ajassal.ext at orange-ftgroup.com> <ajassal.ext at orange-ftgroup.com  > wrote:

>
> Hello M.Tüxen,
>
> No, only the PC is running under FreeBSD 7.0. T is running under Linux 
> (kernel version is 2.6.21 and the distribution used is Fedora Core 7). 
> SCTP is running on T thanks to the lksctp implementation, we loaded 
> the sctp module on it and made the necessary configurations so that it 
> is loaded at boot time.
>
> Also, I enable net.sctp.addip_enable=1 on T, just in case, I'm not 
> exactly sure if it has an effect on my tests.
>
> Kind regards
>
>
> Aman Jassal
>
> -----Message d'origine-----
> De : Michael Tüxen [mailto:Michael.Tuexen at lurchi.franken.de]
> Envoyé : lundi 29 décembre 2008 14:09
> À : zze-Abac JASSAL A ext RD-RESA-ISS
> Cc : freebsd-net at freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : 
> Re: SCTP : problems in sending ASCONF chunks
>
> Hi,
>
> are both machines (T and you PC) running FreeBSD?
>
> Best regards
> Michael
>
> On Dec 29, 2008, at 12:33 PM, <ajassal.ext at orange-ftgroup.com> <ajassal.ext at orange-ftgroup.com 
>   > wrote:
>
>> Hi all,
>>
>> I have been working with SCTP and more specifically with the mobility 
>> features of SCTP at my work. Basically, I have been trying to use 
>> SCTP to perform handover tests between 2 separate Wifi networks. I 
>> use
>> IPv6
>> for all my tests.
>>
>> I have a local LAN (wired-network), on which I have 3 machines, one 
>> of them is the machine I use to communicate with for the tests (I'll 
>> call it T to make things simple), and the other two are used as Wifi 
>> Access Points (say Wifi1 and Wifi2 respectively). Since I work with 
>> IPv6, I set up both Access Points to send Router Advertisement 
>> messages periodically (minimum of 3 seconds, maximum of 4 seconds). 
>> That way I can have automatic address reconfiguration when I connect 
>> to either of the access points.
>>
>> The aim of my tests is to use a PC, connect to Wifi1 (for example), 
>> launch an SCTP association with T (T sends data to my PC), and then 
>> perform a handover on Wifi2. I do make address reconfiguration during 
>> the handover process. The important point is that I work with only 
>> ONE address on my network interface. Before I start my tests, I set 
>> the following sysctl parameters :
>>
>> # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w
>> net.inet.sctp.mobility_fasthandoff=1
>> # sysctl -w net.inet.sctp.debug=0x00f301f0		(that is to dump
>> messages in /var/log/messages)
>>
>> net.inet.sctp.auto_asconf is set to 1 by default.
>>
>> I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful 
>> but I'm trying to be thorough. This is the script I use to perform 
>> handover
>> :
>>
>> ifconfig rum0 inet6 <my old address> delete ifconfig rum0 ssid <the 
>> target access point> route del -inet6 default <my old gateway> rtsol 
>> rum0
>>
>> If I'm not mistaken, the PC should have sent an ASCONF chunk to 
>> perform dynamic address reconfiguration. However what I observed is 
>> that nothing happens. No ASCONF chunks are sent, and therefore, T 
>> doesn't ever know that it should send data on the PC's newly acquired 
>> address.
>>
>> I tried to investigate the problem myself, by adding some debug logs 
>> in the sctp source code (to see which functions are called during the 
>> handover process), and it seems as if the kernel doesn't ever add an 
>> ASCONF chunk to send in its queue... But that's just my understanding 
>> of the problem...
>>
>> I looked up in the CVS repository for answers, and to see the various 
>> changes that were gradually brought on the code. There, I noticed 
>> that on the revision dating 24th July 2007, changes were made for 
>> dynamic address reconfiguration : "Change behaviour so that when the 
>> last address is deleted (auto-asconf on a boudall endpoint) no action 
>> is taken until an address is added ; at that time an ASCONF 
>> add+delete is sent (if the asoc is still up)"
>>
>> In my humble opinion, this is exactly the case that corresponds to my 
>> handover scenario. But I just haven't been able to successfully 
>> perform it because I don't seem to send any ASCONF chunk. I'm 
>> struggling to understand why I do not see any ASCONF chunk sent.
>>
>> If it can help, I'm also attaching links to the kind of debug logs I 
>> got when performing a handover test. This is the kind of debug logs 
>> that I got :
>>
>> http://www.divshare.com/download/6200509-560
>>
>> This is another debug logfile, but with my own debug logs added in 
>> the sctp source code :
>>
>> http://www.divshare.com/download/6200504-2e9
>>
>>
>> Many thanks for your work, and I hope someone will be able to help 
>> and shed some light on this problem :-)
>>
>>
>> Aman Jassal
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net- 
>> unsubscribe at freebsd.org"
>>
>
>