On 01/14/10 23:18, Marcelo Levalle wrote:
Sometimes sctp_bindx fails to remove an address although it returns 0.
Note that Solaris 10 does not support RFC 4895 (SCTP
Authenticated Chunks), so it is really unsafe to use
address manipulation feature. And the ASCONF feature
in S10 is not fully complaint with RFC 5061 as it
was finalized after S10 was shipped. Unfortunately,
there has not been an update to that.
Details: we have a virtual machine running Solaris 10 intel with 3 NICs.
What is the SunOS version?
Let´s call addr1 to 172.16.97.224, addr2 to 172.16.97.86 and addr3 to
172.16.97.79.
The attached example program, creates a pair of connected one-to-one sctp
sockets:
the client (the one which made connect) and the server (the accepted one).
The server binded to addr1 and the client binded to addr2.
Then it adds addr3 to the client socket.
Then it verify addr3 is added with sctp_getladdrs().
Finally, it tries to remove addr3. Immediately after this, sctp_getladdrs()
doesn´t show addr3, as if it were removed, but after a while another
sctp_getladdrs()
shows addr3 again.
I tried your program. While the address cannot be
removed, sctp_getladdrs() returns both addresses
after sctp_bindx(SCTP_REM_ADDR). The reason why the
address cannot be removed is that the code uses the
address to be removed as source to send the ASCONF
request. This is not correct and the receiver does
not allow that so it rejects the removal. This is a
bug. Please file a report.
BTW, could you explain your app's usage of address
configuration? Is it essential to your app?
Output of the example program<<<<
$ ./a.out 172.16.97.224 172.16.97.86 172.16.97.79 12345
local addresses(1 - client):
::ffff:172.16.97.86:12345
local addresses(1 - server):
::ffff:172.16.97.224:12345
local addresses(1 - before SCTP_BINDX_ADD_ADDR):
::ffff:172.16.97.86:12345
local addresses(2 - after SCTP_BINDX_ADD_ADDR):
::ffff:172.16.97.79:12345
::ffff:172.16.97.86:12345
local addresses(3 - immediately after SCTP_BINDX_REM_ADDR ):
::ffff:172.16.97.86:12345
local addresses(4 - five seconds later):
::ffff:172.16.97.79:12345
::ffff:172.16.97.86:12345
End of output<<<<
Thanks in advance.
--
K. Poon.
kacheong.p...@sun.com
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
