Adding a new IP address to an association when all addresses currently

Adding a new IP address to an association when all addresses currently

[George Cheimonidis]

Hi again!

I am working with the dynamic address reconfiguration features of SCTP. 
I have a single client - server application. Both client and server apps 
are running on Ubuntu 9.10 (kernel 2.6.31).
Initially, the client has only one IPv4 address (on wlan interface) and 
it initiates an association to the server which also has only one IPv4 
address (213.xxx.yyy.vvv). After some time, I bring down the IP address 
of the client. Then, after some seconds I bring up the ethernet 
interface of the client and try to add the ethernet's IPv4 address 
(213.xxx.yyy.zzz) to the association (using sctp_bindx()) and set the 
same address as the peer's primary (using 
setsockopt(SCTP_SET_PEER_PRIMARY_ADDR)). Even though both calls succeed 
on the client and also when I call sctp_getladdrs() I can see both 
addresses on the client's side (wlan's and ethernet's), I don't see any 
ASCONF chunks being sent and consequently the communication between the 
client and the server is not possible.
My question is: Is the LKSCTP implementation capable of handling this 
scenario, I mean trying to add a new IP address to the association using 
as source IP address of the IP packet containing the ASCONF chunk the 
new IP address being added? According to RFC5061 - paragraph 5.3.2, this 
can be feasible given that the IP address included in the Address 
Parameter field of the ASCONF chunk belongs to the association (in my 
scenario it should be the wlan's IP address). If so, then what could be 
the reason for the packet containing the ASCONF chunk not being sent?

I have enabled SCTP debugging in the kernel and I am able to see the 
following lines in /var/log/kern.log when trying to add the new IP 
address (of ethernet interface) to the association:

Apr 12 16:27:54 george-laptop kernel: [23765.692896] 
sctp_setsocktopt_bindx: sk f1069a40 addrs 08ff2368 addrs_size 16 opt 1
Apr 12 16:27:54 george-laptop kernel: [23765.692904] sctp_bindx_add (sk: 
f1069a40, addrs: f3349be0, addrcnt: 1)
Apr 12 16:27:54 george-laptop kernel: [23765.692912] sctp_do_bind(sk: 
f1069a40, new addr: 213.xxx.yyy.zzz, port: 47053, new port: 47053, len: 16)
Apr 12 16:27:54 george-laptop kernel: [23765.692920] sctp_get_port() 
begins, snumG053
Apr 12 16:27:54 george-laptop kernel: [23765.692924] sctp_get_port() 
found a possible match
Apr 12 16:27:54 george-laptop kernel: [23765.692930] 
sctp_send_asconf_add_ip: (sk: f1069a40, addrs: f3349be0, addrcnt: 1)
Apr 12 16:27:54 george-laptop kernel: [23765.692943] sctp_do_sm prefn: 
ep f2273500, EVENT_T_PRIMITIVE, PRIMITIVE_ASCONF, asoc 
c31f4000[STATE_ESTABLISHED], sctp_sf_do_prm_asconf
Apr 12 16:27:54 george-laptop kernel: [23765.692949] sctp_do_sm postfn: 
asoc c31f4000, status: DISPOSITION_CONSUME
Apr 12 16:27:54 george-laptop kernel: [23765.692958] 
sctp_outq_tail(c31f4470, f26d9e40[ASCONF])
Apr 12 16:27:54 george-laptop kernel: [23765.692964] sctp_packet_config: 
packet:eff04318 vtag:0x5246ae45
Apr 12 16:27:54 george-laptop kernel: [23765.692969] 
sctp_packet_transmit_chunk: packet:eff04318 chunk:f26d9e40
Apr 12 16:27:54 george-laptop kernel: [23765.692974] 
sctp_packet_append_chunk: packet:eff04318 chunk:f26d9e40
Apr 12 16:27:54 george-laptop kernel: [23765.692980] 
sctp_packet_append_chunk: packet:eff04318 chunk:f26d9600
Apr 12 16:27:54 george-laptop kernel: [23765.692985] 
sctp_packet_transmit: packet:eff04318
Apr 12 16:27:54 george-laptop kernel: [23765.692992] sctp_v4_get_dst: 
DST:213.xxx.yyy.vvv, SRC:0.0.0.0 -
Apr 12 16:27:54 george-laptop kernel: [23765.693015] NO ROUTE
Apr 12 16:27:54 george-laptop kernel: [23765.693021] 
sctp_assoc_sync_pmtu: asoc:c31f4000, pmtu:1500, frag_point:1432
Apr 12 16:27:54 george-laptop kernel: [23765.693028] sctp_do_sm post 
sfx: error 0, asoc c31f4000[STATE_ESTABLISHED]

Thanks in advance
George

Re: Adding a new IP address to an association when all addresses

[Vlad Yasevich]

George Cheimonidis wrote:
> Hi again!
> 
> I am working with the dynamic address reconfiguration features of SCTP.
> I have a single client - server application. Both client and server apps
> are running on Ubuntu 9.10 (kernel 2.6.31).
> Initially, the client has only one IPv4 address (on wlan interface) and
> it initiates an association to the server which also has only one IPv4
> address (213.xxx.yyy.vvv). After some time, I bring down the IP address
> of the client. Then, after some seconds I bring up the ethernet
> interface of the client and try to add the ethernet's IPv4 address
> (213.xxx.yyy.zzz) to the association (using sctp_bindx()) and set the
> same address as the peer's primary (using
> setsockopt(SCTP_SET_PEER_PRIMARY_ADDR)). Even though both calls succeed
> on the client and also when I call sctp_getladdrs() I can see both
> addresses on the client's side (wlan's and ethernet's), I don't see any
> ASCONF chunks being sent and consequently the communication between the
> client and the server is not possible.
> My question is: Is the LKSCTP implementation capable of handling this
> scenario, I mean trying to add a new IP address to the association using
> as source IP address of the IP packet containing the ASCONF chunk the
> new IP address being added? According to RFC5061 - paragraph 5.3.2, this
> can be feasible given that the IP address included in the Address
> Parameter field of the ASCONF chunk belongs to the association (in my
> scenario it should be the wlan's IP address). If so, then what could be
> the reason for the packet containing the ASCONF chunk not being sent?

Linux doesn't support Break-before-Make add-ip functionality.  In this
case, you bring down your one active path to the destination, and then
add a new path.  The kernel attempts to find the route to the destination
based on it's view of current available paths and can't find one.

The ADD-IP specification allow for this to work, since it states that
ASOCONF chunks may be sent from an address that's in the process of
being added, however lksctp doesn't support that piece of it.

You could try a make-before-break scenario.  Bring up and add a new
address before bringing down the first interface.  That should work.

-vlad

> 
> I have enabled SCTP debugging in the kernel and I am able to see the
> following lines in /var/log/kern.log when trying to add the new IP
> address (of ethernet interface) to the association:
> 
> Apr 12 16:27:54 george-laptop kernel: [23765.692896]
> sctp_setsocktopt_bindx: sk f1069a40 addrs 08ff2368 addrs_size 16 opt 1
> Apr 12 16:27:54 george-laptop kernel: [23765.692904] sctp_bindx_add (sk:
> f1069a40, addrs: f3349be0, addrcnt: 1)
> Apr 12 16:27:54 george-laptop kernel: [23765.692912] sctp_do_bind(sk:
> f1069a40, new addr: 213.xxx.yyy.zzz, port: 47053, new port: 47053, len: 16)
> Apr 12 16:27:54 george-laptop kernel: [23765.692920] sctp_get_port()
> begins, snumG053
> Apr 12 16:27:54 george-laptop kernel: [23765.692924] sctp_get_port()
> found a possible match
> Apr 12 16:27:54 george-laptop kernel: [23765.692930]
> sctp_send_asconf_add_ip: (sk: f1069a40, addrs: f3349be0, addrcnt: 1)
> Apr 12 16:27:54 george-laptop kernel: [23765.692943] sctp_do_sm prefn:
> ep f2273500, EVENT_T_PRIMITIVE, PRIMITIVE_ASCONF, asoc
> c31f4000[STATE_ESTABLISHED], sctp_sf_do_prm_asconf
> Apr 12 16:27:54 george-laptop kernel: [23765.692949] sctp_do_sm postfn:
> asoc c31f4000, status: DISPOSITION_CONSUME
> Apr 12 16:27:54 george-laptop kernel: [23765.692958]
> sctp_outq_tail(c31f4470, f26d9e40[ASCONF])
> Apr 12 16:27:54 george-laptop kernel: [23765.692964] sctp_packet_config:
> packet:eff04318 vtag:0x5246ae45
> Apr 12 16:27:54 george-laptop kernel: [23765.692969]
> sctp_packet_transmit_chunk: packet:eff04318 chunk:f26d9e40
> Apr 12 16:27:54 george-laptop kernel: [23765.692974]
> sctp_packet_append_chunk: packet:eff04318 chunk:f26d9e40
> Apr 12 16:27:54 george-laptop kernel: [23765.692980]
> sctp_packet_append_chunk: packet:eff04318 chunk:f26d9600
> Apr 12 16:27:54 george-laptop kernel: [23765.692985]
> sctp_packet_transmit: packet:eff04318
> Apr 12 16:27:54 george-laptop kernel: [23765.692992] sctp_v4_get_dst:
> DST:213.xxx.yyy.vvv, SRC:0.0.0.0 -
> Apr 12 16:27:54 george-laptop kernel: [23765.693015] NO ROUTE
> Apr 12 16:27:54 george-laptop kernel: [23765.693021]
> sctp_assoc_sync_pmtu: asoc:c31f4000, pmtu:1500, frag_point:1432
> Apr 12 16:27:54 george-laptop kernel: [23765.693028] sctp_do_sm post
> sfx: error 0, asoc c31f4000[STATE_ESTABLISHED]
> 
> Thanks in advance
> George
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Adding a new IP address to an association when all addresses

[George Cheimonidis]

Thanks Vlad!

Are there known problems or limitations when trying to implement such 
functionality in the Linux kernel? Or is it just that it hasn't been 
implemented yet?

Best regards,
George

On 04/12/2010 08:07 PM, Vlad Yasevich wrote:
>
> George Cheimonidis wrote:
>    
>> Hi again!
>>
>> I am working with the dynamic address reconfiguration features of SCTP.
>> I have a single client - server application. Both client and server apps
>> are running on Ubuntu 9.10 (kernel 2.6.31).
>> Initially, the client has only one IPv4 address (on wlan interface) and
>> it initiates an association to the server which also has only one IPv4
>> address (213.xxx.yyy.vvv). After some time, I bring down the IP address
>> of the client. Then, after some seconds I bring up the ethernet
>> interface of the client and try to add the ethernet's IPv4 address
>> (213.xxx.yyy.zzz) to the association (using sctp_bindx()) and set the
>> same address as the peer's primary (using
>> setsockopt(SCTP_SET_PEER_PRIMARY_ADDR)). Even though both calls succeed
>> on the client and also when I call sctp_getladdrs() I can see both
>> addresses on the client's side (wlan's and ethernet's), I don't see any
>> ASCONF chunks being sent and consequently the communication between the
>> client and the server is not possible.
>> My question is: Is the LKSCTP implementation capable of handling this
>> scenario, I mean trying to add a new IP address to the association using
>> as source IP address of the IP packet containing the ASCONF chunk the
>> new IP address being added? According to RFC5061 - paragraph 5.3.2, this
>> can be feasible given that the IP address included in the Address
>> Parameter field of the ASCONF chunk belongs to the association (in my
>> scenario it should be the wlan's IP address). If so, then what could be
>> the reason for the packet containing the ASCONF chunk not being sent?
>>      
> Linux doesn't support Break-before-Make add-ip functionality.  In this
> case, you bring down your one active path to the destination, and then
> add a new path.  The kernel attempts to find the route to the destination
> based on it's view of current available paths and can't find one.
>
> The ADD-IP specification allow for this to work, since it states that
> ASOCONF chunks may be sent from an address that's in the process of
> being added, however lksctp doesn't support that piece of it.
>
> You could try a make-before-break scenario.  Bring up and add a new
> address before bringing down the first interface.  That should work.
>
> -vlad
>
>    
>> I have enabled SCTP debugging in the kernel and I am able to see the
>> following lines in /var/log/kern.log when trying to add the new IP
>> address (of ethernet interface) to the association:
>>
>> Apr 12 16:27:54 george-laptop kernel: [23765.692896]
>> sctp_setsocktopt_bindx: sk f1069a40 addrs 08ff2368 addrs_size 16 opt 1
>> Apr 12 16:27:54 george-laptop kernel: [23765.692904] sctp_bindx_add (sk:
>> f1069a40, addrs: f3349be0, addrcnt: 1)
>> Apr 12 16:27:54 george-laptop kernel: [23765.692912] sctp_do_bind(sk:
>> f1069a40, new addr: 213.xxx.yyy.zzz, port: 47053, new port: 47053, len: 16)
>> Apr 12 16:27:54 george-laptop kernel: [23765.692920] sctp_get_port()
>> begins, snumG053
>> Apr 12 16:27:54 george-laptop kernel: [23765.692924] sctp_get_port()
>> found a possible match
>> Apr 12 16:27:54 george-laptop kernel: [23765.692930]
>> sctp_send_asconf_add_ip: (sk: f1069a40, addrs: f3349be0, addrcnt: 1)
>> Apr 12 16:27:54 george-laptop kernel: [23765.692943] sctp_do_sm prefn:
>> ep f2273500, EVENT_T_PRIMITIVE, PRIMITIVE_ASCONF, asoc
>> c31f4000[STATE_ESTABLISHED], sctp_sf_do_prm_asconf
>> Apr 12 16:27:54 george-laptop kernel: [23765.692949] sctp_do_sm postfn:
>> asoc c31f4000, status: DISPOSITION_CONSUME
>> Apr 12 16:27:54 george-laptop kernel: [23765.692958]
>> sctp_outq_tail(c31f4470, f26d9e40[ASCONF])
>> Apr 12 16:27:54 george-laptop kernel: [23765.692964] sctp_packet_config:
>> packet:eff04318 vtag:0x5246ae45
>> Apr 12 16:27:54 george-laptop kernel: [23765.692969]
>> sctp_packet_transmit_chunk: packet:eff04318 chunk:f26d9e40
>> Apr 12 16:27:54 george-laptop kernel: [23765.692974]
>> sctp_packet_append_chunk: packet:eff04318 chunk:f26d9e40
>> Apr 12 16:27:54 george-laptop kernel: [23765.692980]
>> sctp_packet_append_chunk: packet:eff04318 chunk:f26d9600
>> Apr 12 16:27:54 george-laptop kernel: [23765.692985]
>> sctp_packet_transmit: packet:eff04318
>> Apr 12 16:27:54 george-laptop kernel: [23765.692992] sctp_v4_get_dst:
>> DST:213.xxx.yyy.vvv, SRC:0.0.0.0 -
>> Apr 12 16:27:54 george-laptop kernel: [23765.693015] NO ROUTE
>> Apr 12 16:27:54 george-laptop kernel: [23765.693021]
>> sctp_assoc_sync_pmtu: asoc:c31f4000, pmtu:1500, frag_point:1432
>> Apr 12 16:27:54 george-laptop kernel: [23765.693028] sctp_do_sm post
>> sfx: error 0, asoc c31f4000[STATE_ESTABLISHED]
>>
>> Thanks in advance
>> George
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>