[sctp-dev] RFC 5061 is implemented or not?

[Chris Hegarty]

Hi Mehmet,

I have tests for just such a scenario ( add/remove addresses from 
connected channel ) in the test regression library of the JDK 
repository, but unfortunately they are not enabled by default as most 
platforms do not support Dynamic Address Reconfiguration.

Testing on Fedora 11 with lksctp 1.0.10 I do see similar behavior to 
what you seen, bindAddress appears to succeed but the peer does not 
report the address as one of its remote addresses. Strange!  This could 
only be a bug in the lksctp stack. I'll have to investigate further and 
report it to them.

That being said without enabling the following (see below) Dynamic 
Address Reconfiguration is not expected to work correctly on lksctp. Can 
you please try enabling the following sysctls? When I enable them remote 
addresses reports the correct addition of the new address.

# /sbin/sysctl net.sctp.addip_noauth_enable=1
net.sctp.addip_noauth_enable = 1
## /sbin/sysctl net.sctp.addip_enable=1
net.sctp.addip_enable = 1

-Chris.


Mehmet Aslan wrote:
> Hello All,
> I am trying to use the functionalities brought by RFC5061 extension to 
> the SCTP protocol RFC4960, like binding or unbinding IP addresses to a 
> connected association (I mean after the connection established, during 
> communication). My configuration is very simple and is as follows:
> 
> Server:                                           Client:
> 192.168.1.25 <http://192.168.1.25>: 3456                         
> 192.168.1.133:6060 <http://192.168.1.133:6060>
> 
> With this configuration I can communicate with the server and I can 
> transfer a file from the server to the cllient successfully. However, 
> following the connection to the server, when I tried binding another 
> address (192.168.1.25:6060 <http://192.168.1.25:6060>) to the client, 
> using "/bindAddresses()/" method, the client does not inform server 
> about this binding. On the client side, it is shown as if the new 
> address has been bound as the result of "/getAllLocalAdresses()/". But 
> when it is tested on the server side, the server always gives the same 
> result to "/getRemoteAddresses()/" call, before and after binding the 
> new address. Binding a new addres to a connected association does not 
> have any effect on the other endpoint.
> 
> Besides, for the following configuration;
> 
> Server:                                           Client:
> 192.168.1.25 <http://192.168.1.25>: 3456                         
> 192.168.1.133:6060 <http://192.168.1.133:6060>
>                                                      192.168.1.25 
> <http://192.168.1.25>:  6060
> 
> (The 2 IP addresses on the client side are bound before "/connect()/", 
> otherwise I cannot bind after connection as explained above.)
>  I could not achieve to use 
> "/setOption(SctpStandardSocketOption.SCTP_SET_PEER_PRIMARY_ADDR, 
> socketaddr)/" For example, on the client side the PRIMARY_ADDR is 
> ...133:6060, I want to change this adress to be ...25:6060 by using the 
> "setOption()" method initiated from the client side. But what I get is;
> 
> "/setOption exception: java.net.SocketException: Operation not permitted/"
> 
> It seems that RFC5061 is not implemented. But then, what is the meaning 
> of the following quotation, taken from SCTP API "/bindAddresses()/" 
> description of SctpChannel:
> "Adding addresses to a connected association is optional functionality. 
> If the endpoint supports dynamic address reconfiguration then it may 
> send the appropriate message to the peer to change the peers address 
> lists."
> Since both of the endpoints (server and client) are on the same comuter, 
> using the same library, they should support dynamic address 
> reconfiguration. However they don't.
> So, how is it possible to clarify if RFC5061 is implemented or not? If 
> it has been already implemented, why can not I achive using RFC5061 
> functionalities. Am I doing something wrong or what?
> 
> My platform is: Ubuntu 10.10, OpenJDK7 - b118, NetBeans 6.9, one 
> computer with two interfaces; cabel and wireless.
> 
> Thanks in advance.