lksctp-developers Mailing List for Linux Kernel SCTP

Hi, Daniel.

For one-to-many mode. Suppose I have a socket which contain several 
associations in it. that means there are several clients connect with 
server.

If I use sendmsg(...) function to send msg from server, How does sctp 
identify which association will receive the data? Does all clients will 
receive the msg?

And, Does sctp provide a way for server to send msg to all associations 
in one syscall ?

Thanks.

[Our apologies if you receive multiple copies of this message.]


CALL FOR PARTICIPATION

We cordially invite you to join us at:

The 1st International NorNet Users Workshop (NNUW-1)
at the Simula Research Laboratory in Fornebu, Akershus/Norway
September 18-19, 2013
http://www.nornet-testbed.no/workshops/nnuw-1/

There is *no* workshop fee! Please register as early as possible.


More than one year ago, the NorNet project has started with the intention to 
build up the world’s first large-scale network  testbed for multi-homed 
systems. NorNet should provide researchers the possibility to perform 
experiments in real-world wired and wireless setups. Now, the wired part – 
denoted as NorNet Core – as well as the wireless part – denoted as NorNet Edge 
– have reached a stage that allows further researchers to start running such 
experiments. That is, currently 11 NorNet Core sites and more than 300 NorNet 
Edge nodes are ready to support your research ideas on resilience, mobility, 
security, multi-path transport and further subjects!

This workshop intends to provide current as well as new and future NorNet 
users the possibility to get information about the NorNet testbed and initial 
research results, to discuss their ideas with the testbed developers and to 
get the possibility for obtaining access to NorNet.


Further details on the workshop are available at:
http://www.nornet-testbed.no/workshops/nnuw-1/

An information sheet in PDF format can be found here:
http://www.nornet-testbed.no/wp-content/uploads/2013/06/NNUW-1-CallForParticipation.pdf

A detailed description of NorNet can be found at:
http://www.nntb.no/


We are looking forward to see you in Fornebu!


The NNUW-1 Organisers

Sourceforge recently changed their Git repository policy and forced
everyone to update their Git origins to a different remote URL.

The previous interface/URL from Sourceforge that we used was located
at [1], and has been placed into read-only mode without receiving
further updates from git pushes ever since. Instead, one would need
to use their web-interface at [2], which is a terrible thing to do.

Therefore, our second (and likely last) structural change for now is
that we have changed the Git upstream location from the lksctp-tools
stable tree into something more desirable and user-friendly for Git
hosting.

Therefore, in case you have a local Git copy of lksctp-tools, please
update your Git origin in the following way:

    git remote set-url origin git://github.com/borkmann/lksctp-tools.git

The web-interface can be found here:

    https://github.com/borkmann/lksctp-tools

We also have updated the lksctp.org website to point to the new upstream
locations, including our recent mailing list announcement.

Thus, Sourceforge is now only used by us for web and tarball hosting for
the lksctp.org domain, which is perfectly fine for our purposes.

Thanks,

Daniel Borkmann et al.

   [1] http://lksctp.git.sourceforge.net/git/gitweb.cgi?p=lksctp/lksctp;a=summary
   [2] http://sourceforge.net/p/lksctp/git/ci/master/tree/

The <lks...@li...> mailing list *migrates*
to the official <lin...@vg...> list for *all* SCTP-related
discussions, questions and development on Linux. Thus, this list
continues its existence on:

   lin...@vg...

We've decided to take this step as the <lin...@vg...> list
is already *the* central place for SCTP discussions and development on
Linux. There is no good reason for multiple lists. Also, it's free of
advertisements unlike Sourceforge, has a well maintained spam filter
and provides searchable archives that have a nice user interface.

Therefore, the <lks...@li...> mailing list
address will be shut down on August, 10th.

How to register to the lin...@vg... list?

   Website: http://vger.kernel.org/vger-lists.html#linux-sctp

   Instructions:

     1. Send a mail to <maj...@vg...> with "subscribe linux-sctp"
        in the mail body (subject can be left empty).
     2. Confirm the majordomo's mail response (instructions to do so are in the
        email itself).

How to post to the linux-sctp list?

   Send your questions, discussions, patches to: lin...@vg...

Archives from past discussions:

   http://www.spinics.net/lists/linux-sctp/
   http://marc.info/?l=linux-sctp

Thanks a lot, and our apologies for any inconveniences!

Vlad Yasevich
Neil Horman
Daniel Borkmann

Hello,

On 06.09.2012 13:23, Matija Glavinic Pecotic wrote:
> Hello,
>
> On 05.09.2012 16:55, ext Vlad Yasevich wrote:
>> On 09/05/2012 07:27 AM, Matija Glavinic Pecotic wrote:
>>> Hello lksctp developers,
>>>
>>> a while back we noticed below described issue.
>>>
>>> In order to quick-fix this, we implemented following workaround:
>>>
>>> 1) added interface to sctp for invalidating all dst entries on all
>>> associations (0002-sctp-export-dst-entries-invalidation-if.patch) - this
>>> is on top of below mentioned patch
>>> (0001-sctp-check-cached-dst-before-using-it.patch)
>>>
>>> 2) in a separate module route and ipsec events are monitored and upon
>>> addition and deletion of routes, along with xfrm events interface is
>>> called. This is done by netlink socket opened within the kernel. If
>>> interested, I can share that one as well.
>>>
>>> Could you please give some comments on both workaround and mentioned
>>> issue?
>>
>> These workarounds should not be needed.  The code should function
>> correctly.  We just need to get to the root cause...
>>

I have taken a look at this again, and just wanted to inform you that 
this isnt sctp problem, but problem with routing cache on 2.6.32.xx. 
Problem is that dst_entry is not getting invalidated. If you are 
interested we can discuss this further, but just wanted to note that 
sctp is fine here :)

>>>
>>> Thanks and regards,
>>>
>>> Matija
>>>
>>> On 12.06.2012 19:10, ext Matija Glavinic Pecotic wrote:
>>>> Hello,
>>>>
>>>> We're facing an issue regarding route change and startup of ipsec
>>>> tunnel. Here is setup and test scenarios:
>>>>
>>>> 1) Setup
>>>> Simple sctp client and server. Client is bound to the loopback address
>>>> 10.0.0.1 and it is connected to the server via eth3 (192.168.2.1) which
>>>> is in LAN with eth2 (192.168.2.2) and eth3 (192.168.2.3) on the server
>>>> and server is bound to the 20.0.0.1 which is loopback.
>>>>
>>>> Client:
>>>>
>>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>>>>        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>>        inet 10.0.0.1/8 scope global lo
>>>>        inet6 ::1/128 scope host
>>>>           valid_lft forever preferred_lft forever
>>>>
>>>> 13: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>> state UP
>>>>        link/ether 00:40:43:30:81:80 brd ff:ff:ff:ff:ff:ff
>>>>        inet 192.168.2.1/24 brd 192.168.2.255 scope global eth3
>>>>        inet6 fe80::240:43ff:fe30:8180/64 scope link
>>>>           valid_lft forever preferred_lft forever
>>>>
>>>> 192.168.2.0/24 dev eth3  proto kernel  scope link  src 192.168.2.1
>>>> 192.168.253.0/24 dev rio0  proto kernel  scope link  src 192.168.253.16
>>>> 192.168.254.0/23 dev eth0  proto kernel  scope link  src 192.168.255.1
>>>> 20.0.0.0/8 via 192.168.2.1 dev eth3  scope link
>>
>> Should the above route be via 192.168.2.2 (typo), or is this correct?
>
> No, I want to say that traffic on the lo is to go over eth3 interface. I
> dont want to tie it directly to 192.168.2.2.
>
>>>>
>>>> Server:
>>>>
>>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>>>>        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>>        inet 20.0.0.1/8 scope global lo
>>>>        inet6 ::1/128 scope host
>>>>           valid_lft forever preferred_lft forever
>>>>
>>>> 12: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>> state UP
>>>>        link/ether 00:40:43:b1:f8:ae brd ff:ff:ff:ff:ff:ff
>>>>        inet 192.168.2.2/24 brd 192.168.2.255 scope global eth2
>>>>        inet6 fe80::240:43ff:feb1:f8ae/64 scope link
>>>>           valid_lft forever preferred_lft forever
>>>>
>>>> 13: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>> state UP
>>>>        link/ether 00:40:43:b1:f8:af brd ff:ff:ff:ff:ff:ff
>>>>        inet 192.168.2.3/24 brd 192.168.2.255 scope global eth3
>>>>        inet6 fe80::240:43ff:feb1:f8af/64 scope link
>>>>           valid_lft forever preferred_lft forever
>>>>
>>>> 192.168.2.0/24 dev eth2  proto kernel  scope link  src 192.168.2.2
>>>> 192.168.2.0/24 dev eth3  proto kernel  scope link  src 192.168.2.3
>>>> 192.168.253.0/24 dev rio0  proto kernel  scope link  src 192.168.253.16
>>>> 192.168.255.0/24 dev eth0  proto kernel  scope link  src 192.168.255.2
>>>> 10.0.0.0/8 via 192.168.2.1 dev eth2
>>>> 10.0.0.0/8 via 192.168.2.1 dev eth3  metric 10
>>>>
>>>> Server listens on 20.0.0.1 and when client is connected it sends
>>>> message
>>>> indefinitely
>>>>
>>>> Kernel is 2.6.32.58 and sctp is applied with patch from this thread:
>>>> http://sourceforge.net/mailarchive/message.php?msg_id=25786006
>>>> (0001-sctp-check-cached-dst-before-using-it.patch)
>>>>
>>>> 2) Test scenario 1
>>>>
>>>> Start sctp_server
>>>> Start sctp_client -> clients receives messages from the server
>>>> Observe traffic flow -> as expected it goes over eth2 on the server
>>>> Delete route 10.0.0.0/8 via 192.168.2.1 dev eth2
>>>> Traffic still goes over eth2, on server restart it goes over eth3
>>
>> Very interesting... Upon route deletion the cache should be invalidated
>> and sctp should look-up a new route.
>>
>> Can you turn on debug output in net/sctp/protocol.c and see what the
>> route printed is after the delete call?
>>
>> You can turn it on by adding #define CONFIG_SCTP_DBG_MSG to the top of
>> protocol.c
>
> attached two logs, in one, cable was plugged out, we can see that stack
> copes with it, especially since we have new dst (I added print of address)
>
>>     if (dst)
>>         SCTP_DEBUG_PRINTK("rt_dst:%pI4, rt_src:%pI4, rt@0x%p\n",
>>                   &rt->rt_dst, &rt->rt_src, rt);
>
>
> other log is as scenario mentioned, additional info inside regarding
> routes. You can look for:
>
> 2004-01-01T00:01:48.329137+00:00 (none) [notice]      root:  Deleting route
>
> Scenario went as described previously, traffic continued over eth2
>
> Thanks and regards,
>
> Matija
>
>>
>> -vlad
>>
>>>>
>>>> For reference, I've run also TCP server/client which does the same
>>>> thing, after deletion of mentioned route traffic continued over eth3.
>>>> Other kinds of traffic are also rerouted on route deletion (icmp)
>>>>
>>>> 3) Test scenario 2
>>>>
>>>> Setup same as before, eth3 on server isn't used.
>>>>
>>>> Start sctp_server
>>>> Start sctp_client -> traffic ok
>>>> Start ipsec tunnel:
>>>>        left=192.168.2.2
>>>>        leftsubnet=20.0.0.0/24
>>>>        right=192.168.2.1
>>>>        rightsubnet=10.0.0.0/24
>>>> After start of ipsec tunnel, traffic went over same dst unencrypted for
>>>> a short period of time.
>>>> For reference, again same scenario with TCP server/client -> traffic
>>>> started to be encrypted immediately
>>>>
>>>> ------
>>>>
>>>> In my opinion there is problem with cached dst_entry. I've tried
>>>> following:
>>>>
>>>> [sctp.h]
>>>> /* The cookie is always 0 since this is how it's used in the
>>>>     * pmtu code.
>>>>     */
>>>> static inline struct dst_entry *sctp_transport_dst_check(struct
>>>> sctp_transport *t)
>>>> {
>>>>      if (t->dst) {
>>>>          dst_release(t->dst);
>>>>          t->dst = NULL;
>>>>      }
>>>>
>>>>      return t->dst;
>>>> }
>>>>
>>>> With this I just wanted to force sctp to route every time it wants to
>>>> send packet, and after this change above mentioned scenarios passed.
>>>> Here is my short analysis, ignore it if I got something wrong: I see
>>>> potential problem with SCTP's dst_entry: struct dst_entry *dst which is
>>>> member of sctp_transport. For example, ipv4&6 implement operations on
>>>> dst_entry (ipv4_dst_ops ) which are to be done when event occurs, such
>>>> as unreachability, route deleteion, etc. SCTP doesn't, and it also
>>>> doesn't use dst_entries from ipv*. In this way, only events which
>>>> impact
>>>> SCTPs dst_entries are default ones, NETDEV_DOWN and NETDEV_UNREGISTER
>>>> and these are only which will be noted with dst_check().
>>>>
>>>> Could you comment please? I'll be glad to make tests/verifications or
>>>> provide any sort of help on this.
>>>>
>>>> Thanks & regards,
>>>>
>>>> Matija
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Lksctp-developers mailing list
>>>> Lks...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions
>>> will include endpoint security, mobile security and the latest in
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>
>>>
>>>
>>> _______________________________________________
>>> Lksctp-developers mailing list
>>> Lks...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Lksctp-developers mailing list
>> Lks...@li...
>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>
>

On Jul 12, 2013, at 2:10 PM, Adam Endrodi <ada...@ns...> wrote:

> On Fri, Jul 12, 2013 at 01:38:39PM +0200, ext Michael Tuexen wrote:
> 
>> In FreeBSD we don't change the primary address if it fails. We just report
>> the failure to the user and use an alternate address for sending data initially.
>> Once the primary address becomes active again, we notify the user and reuse
>> it for sending data initially.
> 
> Yes, this is exactly what I'd like to achieve.  Canyou advise you to get
> it on Linux?  Setting SCTP_PRIMARY_ADDR on the address we'd like to be
> primary?
I guess using SCTP_PRIMARY_ADDR allow you to set the primary address in LKSCTP.
My understanding is that LKSCTP changes the primary address by itself in case
it gets SCTP_ADDR_UNREACHABLE.
To work around this, you should be able to subscribe to the SCTP_PEER_ADDR_CHANGE
and in case you get a notification indicating that the new state of the peer address
you want to be the primary one is SCTP_ADDR_AVAILABLE, you call setsockopt
with SCTP_PRIMARY_ADDR for it. I assume that LKSCTP notifies you about the
automatic change of the primary address by providing a SCTP_PEER_ADDR_CHANGE 
notification indicating SCTP_ADDR_MADE_PRIM.

So you should be able to get what you want also on an SCTP stack which switches
the primary path automatically for you...

Best regards
Michael
> 
> Thanks for the quick answers.
> 
> -- 
> adam
> 

On Fri, Jul 12, 2013 at 01:38:39PM +0200, ext Michael Tuexen wrote:

> In FreeBSD we don't change the primary address if it fails. We just report
> the failure to the user and use an alternate address for sending data initially.
> Once the primary address becomes active again, we notify the user and reuse
> it for sending data initially.

Yes, this is exactly what I'd like to achieve.  Canyou advise you to get
it on Linux?  Setting SCTP_PRIMARY_ADDR on the address we'd like to be
primary?

Thanks for the quick answers.

-- 
adam

On 07/12/2013 01:23 PM, Neil Horman wrote:
> On Fri, Jul 12, 2013 at 03:01:25PM +0800, Hangbin Liu wrote:
>> Use memset as bzero has been deprecated
>>
>> Signed-off-by: Hangbin Liu <liu...@gm...>
> Acked-by: Neil Horman <nh...@tu...>

Applied, thanks.

On Jul 12, 2013, at 1:31 PM, Neil Horman <nh...@tu...> wrote:

> On Fri, Jul 12, 2013 at 12:16:24PM +0200, Adam Endrodi wrote:
>> 
>> Hi everyone,
>> 
>> 
>> I've got a question about primary SCTP addresses, what it exactly means
>> to be primary.
>> 
>> Consider an association with two addresses (ie. two sockaddr:s were
>> supplied to sctp_connectx()).  SCTP starts using the primary path,
>> then after a while the connection goes down.  SCTP tries the secondary
>> path, which is functional.  After a while the primary path becomes
>> operational again.
>> 
>> Now, as far as we've seen the SCTP stack delivers a SCTP_ADDR_AVAILABLE
>> event, but doesn't revert back to the primary path, which would be desirable
>> to us.  We've discovered the SCTP_PRIMARY_ADDR socket option, but looking
>> at the kernel sources the zeroth address specified with sctp_connectx()
>> is always made the primary one, so there would be no benefit in trying
>> to reinforce the primaryness with SCTP_PRIMARY_ADDR on SCTP_ADDR_AVAILABLE.
>> 
>> In summary, I'd like to know how to tell the SCTP stack to prefer the zeroth
>> address of sctp_connectx() to transmit data whenever its path is available?
>> 
>> Thanks,
>> adam
>> 
> All primary addr means is that for as long as that address exists as an active
> association, it will be the source address used when routing packets to a
> destination.  And yes, the primary address might change over the life of a
> connection.
I think the primary address is the address you send data chunk to when sent
initially. When this address fails, you choose a different address. The interesting
point is what you do if this former primary address becomes active again.

In FreeBSD we don't change the primary address if it fails. We just report
the failure to the user and use an alternate address for sending data initially.
Once the primary address becomes active again, we notify the user and reuse
it for sending data initially.
Changing the primary addr requires the user to use the SCTP_PRIMARY_ADDR
option. Therefore it is up to the user to decide that he wants to switch
the primary address when it fails.
I guess, Adam is looking for a similar behaviour.

Best regards
Michael
> 
> I don't understand your concern though.  you've found the SCTP_PRIMARY_ADDR
> socket option, how come you can't issue a setsockopt call in response to the
> reception of a ADDR_AVAILABLE event (or any other address changing event)?
> 
> Neil
> 
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Lksctp-developers mailing list
>> Lks...@li...
>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Lksctp-developers mailing list
> Lks...@li...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
> 

On Fri, Jul 12, 2013 at 12:16:24PM +0200, Adam Endrodi wrote:
> 
> Hi everyone,
> 
> 
> I've got a question about primary SCTP addresses, what it exactly means
> to be primary.
> 
> Consider an association with two addresses (ie. two sockaddr:s were
> supplied to sctp_connectx()).  SCTP starts using the primary path,
> then after a while the connection goes down.  SCTP tries the secondary
> path, which is functional.  After a while the primary path becomes
> operational again.
> 
> Now, as far as we've seen the SCTP stack delivers a SCTP_ADDR_AVAILABLE
> event, but doesn't revert back to the primary path, which would be desirable
> to us.  We've discovered the SCTP_PRIMARY_ADDR socket option, but looking
> at the kernel sources the zeroth address specified with sctp_connectx()
> is always made the primary one, so there would be no benefit in trying
> to reinforce the primaryness with SCTP_PRIMARY_ADDR on SCTP_ADDR_AVAILABLE.
> 
> In summary, I'd like to know how to tell the SCTP stack to prefer the zeroth
> address of sctp_connectx() to transmit data whenever its path is available?
> 
> Thanks,
> adam
> 
All primary addr means is that for as long as that address exists as an active
association, it will be the source address used when routing packets to a
destination.  And yes, the primary address might change over the life of a
connection.

I don't understand your concern though.  you've found the SCTP_PRIMARY_ADDR
socket option, how come you can't issue a setsockopt call in response to the
reception of a ADDR_AVAILABLE event (or any other address changing event)?

Neil

> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Lksctp-developers mailing list
> Lks...@li...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
> 

On Fri, Jul 12, 2013 at 03:01:25PM +0800, Hangbin Liu wrote:
> Use memset as bzero has been deprecated
> 
> Signed-off-by: Hangbin Liu <liu...@gm...>
Acked-by: Neil Horman <nh...@tu...>

Hi everyone,


I've got a question about primary SCTP addresses, what it exactly means
to be primary.

Consider an association with two addresses (ie. two sockaddr:s were
supplied to sctp_connectx()).  SCTP starts using the primary path,
then after a while the connection goes down.  SCTP tries the secondary
path, which is functional.  After a while the primary path becomes
operational again.

Now, as far as we've seen the SCTP stack delivers a SCTP_ADDR_AVAILABLE
event, but doesn't revert back to the primary path, which would be desirable
to us.  We've discovered the SCTP_PRIMARY_ADDR socket option, but looking
at the kernel sources the zeroth address specified with sctp_connectx()
is always made the primary one, so there would be no benefit in trying
to reinforce the primaryness with SCTP_PRIMARY_ADDR on SCTP_ADDR_AVAILABLE.

In summary, I'd like to know how to tell the SCTP stack to prefer the zeroth
address of sctp_connectx() to transmit data whenever its path is available?

Thanks,
adam

Use memset as bzero has been deprecated

Signed-off-by: Hangbin Liu <liu...@gm...>
---
 src/apps/sctp_darn.c          |  4 ++--
 src/apps/sctp_test.c          |  4 ++--
 src/func_tests/test_getname.c | 16 ++++++++--------
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/apps/sctp_darn.c b/src/apps/sctp_darn.c
index 2ae0a20..2cef7a9 100644
--- a/src/apps/sctp_darn.c
+++ b/src/apps/sctp_darn.c
@@ -1467,7 +1467,7 @@ append_addr(const char *parm, struct sockaddr *addrs, int *ret_count)
 	if (NULL != hst4) {
 		for (j = 0; j < i4; ++j) {
 			b4ap = (struct sockaddr_in *)aptr;
-			bzero(b4ap, sizeof(*b4ap));
+			memset(b4ap, 0x00, sizeof(*b4ap));
 			b4ap->sin_family = AF_INET;
 			b4ap->sin_port = htons(local_port);
 			bcopy(hst4->h_addr_list[j], &b4ap->sin_addr,
@@ -1480,7 +1480,7 @@ append_addr(const char *parm, struct sockaddr *addrs, int *ret_count)
 	if (NULL != hst6) {
 		for (j = 0; j < i6; ++j) {
 			b6ap = (struct sockaddr_in6 *)aptr;
-			bzero(b6ap, sizeof(*b6ap));
+			memset(b6ap, 0x00, sizeof(*b6ap));
 			b6ap->sin6_family = AF_INET6;
 			b6ap->sin6_port =  htons(local_port);
 			b6ap->sin6_scope_id = if_index;
diff --git a/src/apps/sctp_test.c b/src/apps/sctp_test.c
index bab3668..2aaf9d3 100644
--- a/src/apps/sctp_test.c
+++ b/src/apps/sctp_test.c
@@ -551,7 +551,7 @@ append_addr(const char *parm, struct sockaddr *addrs, int *ret_count)
 	if (NULL != hst4) {
 		for (j = 0; j < i4; ++j) {
 			b4ap = (struct sockaddr_in *)aptr;
-			bzero(b4ap, sizeof(*b4ap));
+			memset(b4ap, 0x00, sizeof(*b4ap));
 			b4ap->sin_family = AF_INET;
 			b4ap->sin_port = htons(local_port);
 			bcopy(hst4->h_addr_list[j], &b4ap->sin_addr,
@@ -564,7 +564,7 @@ append_addr(const char *parm, struct sockaddr *addrs, int *ret_count)
 	if (NULL != hst6) {
 		for (j = 0; j < i6; ++j) {
 			b6ap = (struct sockaddr_in6 *)aptr;
-			bzero(b6ap, sizeof(*b6ap));
+			memset(b6ap, 0x00, sizeof(*b6ap));
 			b6ap->sin6_family = AF_INET6;
 			b6ap->sin6_port =  htons(local_port);
 			b6ap->sin6_scope_id = if_index;
diff --git a/src/func_tests/test_getname.c b/src/func_tests/test_getname.c
index d7011f6..2340de6 100644
--- a/src/func_tests/test_getname.c
+++ b/src/func_tests/test_getname.c
@@ -89,7 +89,7 @@ main(int argc, char *argv[])
         svr_sk = test_socket(pf_class, SOCK_STREAM, IPPROTO_SCTP);
 	test_bind(svr_sk, &svr_loop.sa, sizeof(svr_loop));
 
-	bzero(&svr_local_addr, sizeof(svr_local_addr));
+	memset(&svr_local_addr, 0x00, sizeof(svr_local_addr));
 	len = sizeof(svr_local_addr);
 	/* Verify that getsockname() on an unconnected socket works fine. */
 	error = getsockname(svr_sk, (struct sockaddr *)&svr_local_addr, &len);
@@ -98,7 +98,7 @@ main(int argc, char *argv[])
 
 	tst_resm(TPASS, "getsockname on an unconnected socket");
 
-	bzero(&svr_peer_addr, sizeof(svr_peer_addr));
+	memset(&svr_peer_addr, 0x00, sizeof(svr_peer_addr));
 	len = sizeof(svr_peer_addr);
 	/* Verify that getpeername() on an unconnected socket fails. */
 	error = getpeername(svr_sk, (struct sockaddr *)&svr_peer_addr, &len);
@@ -122,7 +122,7 @@ main(int argc, char *argv[])
 #endif
 	test_connect(clt_sk, &svr_loop.sa, sizeof(svr_loop));
 
-	bzero(&clt_local_addr, sizeof(clt_local_addr));
+	memset(&clt_local_addr, 0x00, sizeof(clt_local_addr));
 	len = sizeof(clt_local_addr);
 	/* Get the client's local address. */
 	error = getsockname(clt_sk, (struct sockaddr *)&clt_local_addr, &len);
@@ -132,7 +132,7 @@ main(int argc, char *argv[])
 
 	tst_resm(TPASS, "getsockname on a connected client socket");
 
-	bzero(&clt_peer_addr, sizeof(clt_peer_addr));
+	memset(&clt_peer_addr, 0x00, sizeof(clt_peer_addr));
 	len = sizeof(clt_peer_addr);
 	/* Get the client's peer address. */
 	error = getpeername(clt_sk, (struct sockaddr *)&clt_peer_addr, &len);
@@ -146,7 +146,7 @@ main(int argc, char *argv[])
 	len = sizeof(accept_loop);
 	accept_sk = test_accept(svr_sk, &accept_loop.sa, &len); 
 
-	bzero(&svr_local_addr, sizeof(svr_local_addr));
+	memset(&svr_local_addr, 0x00, sizeof(svr_local_addr));
 	len = sizeof(svr_local_addr);
 	/* Get the server's local address. */
 	error = getsockname(accept_sk, (struct sockaddr *)&svr_local_addr,
@@ -157,7 +157,7 @@ main(int argc, char *argv[])
 
 	tst_resm(TPASS, "getsockname on a connected server socket");
 
-	bzero(&svr_peer_addr, sizeof(svr_peer_addr));
+	memset(&svr_peer_addr, 0x00, sizeof(svr_peer_addr));
 	len = sizeof(svr_peer_addr);
 	/* Get the server's peer address. */
 	error = getpeername(accept_sk, (struct sockaddr *)&svr_peer_addr,
@@ -197,7 +197,7 @@ main(int argc, char *argv[])
 #endif
 	tst_resm(TPASS, "getsockname/getpeername server/client match");
 
-	bzero(&clt_local_addr, sizeof(clt_local_addr));
+	memset(&clt_local_addr, 0x00, sizeof(clt_local_addr));
 	len = sizeof(clt_local_addr);
 	/*getsockname():  Bad socket descriptor, EBADF expected error*/
 	error = getsockname(-1, (struct sockaddr *)&clt_local_addr, &len);
@@ -223,7 +223,7 @@ main(int argc, char *argv[])
 
 	tst_resm(TPASS, "getsockname with invalid buffer - EFAULT");
  
-	bzero(&clt_peer_addr, sizeof(clt_peer_addr));
+	memset(&clt_peer_addr, 0x00, sizeof(clt_peer_addr));
 	len = sizeof(clt_peer_addr);
 	/*getpeername():  Bad socket descriptor, EBADF expected error*/
 	error = getpeername(-1, (struct sockaddr *)&clt_local_addr, &len);
-- 
1.8.1.4

On 07/11/2013 10:50 AM, Matija Glavinic Pecotic wrote:
> Hello lksctp developers,
>
> could you please clear to me something. As you now, SPP_PMTUD_ENABLE is
> set by default in sctp_transport_init and based solely on this
> information, sctp_v4_xmit will use this info to set IP_PMTUDISC_* on
> sock. This will in the end have direct consequence in ip_queue_xmit to
> set/unset df flag.
>
> This can be changed by setting:
>
>      spp_pathmtu:  This field contains the current Path MTU of the peer
>         address.  It is the number of bytes available in an SCTP packet
>         for chunks.  Providing a value of 0 does not change the current
>         setting.  If a positive value is provided and SPP_PMTUD_DISABLE is
>         set in the spp_flags field, the given value is used as the Path
>         MTU.  If SPP_PMTUD_ENABLE is set in the spp_flags field, the
>         spp_pathmtu field is ignored.(rfc6548)
>
> but it is not always easy to have exact value of pmtu. Ok, MTU can be used.
>
> What I'm actually worried is that ipv4_config.no_pmtu_disc is ignored in
> this case, its value has no impact on sctp. OK - you provide option for
> setting this, but I amnt 100% sure that behavior is 100% correct here.
>
> I also understand that disabling the pmtu - define it by yourself, it
> makes sense in some way. In the end, its defined by rfc6548, but anyway
> I'd like to ask you for opinion on this.

Hi Matija

Thanks for bringing this up.  Upon taking a closer look, I agree that we
seem to ignore the value of ipv4_config.no_pmtu_disc.  I'll need to look
at some scenarios, but it seem that SCTP should honor the IP/IPv6 pmtu 
setting.

-vlad

>
> Thanks,
>
> Matija
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Lksctp-developers mailing list
> Lks...@li...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>

Hello lksctp developers,

could you please clear to me something. As you now, SPP_PMTUD_ENABLE is 
set by default in sctp_transport_init and based solely on this 
information, sctp_v4_xmit will use this info to set IP_PMTUDISC_* on 
sock. This will in the end have direct consequence in ip_queue_xmit to 
set/unset df flag.

This can be changed by setting:

    spp_pathmtu:  This field contains the current Path MTU of the peer
       address.  It is the number of bytes available in an SCTP packet
       for chunks.  Providing a value of 0 does not change the current
       setting.  If a positive value is provided and SPP_PMTUD_DISABLE is
       set in the spp_flags field, the given value is used as the Path
       MTU.  If SPP_PMTUD_ENABLE is set in the spp_flags field, the
       spp_pathmtu field is ignored.(rfc6548)

but it is not always easy to have exact value of pmtu. Ok, MTU can be used.

What I'm actually worried is that ipv4_config.no_pmtu_disc is ignored in 
this case, its value has no impact on sctp. OK - you provide option for 
setting this, but I amnt 100% sure that behavior is 100% correct here.

I also understand that disabling the pmtu - define it by yourself, it 
makes sense in some way. In the end, its defined by rfc6548, but anyway 
I'd like to ask you for opinion on this.

Thanks,

Matija

On 07/10/2013 12:13 PM, Hangbin Liu wrote:
> As sys/errno.h only include errno.h, remove or change it to errno.h
>
> Signed-off-by: Hangbin Liu <liu...@gm...>

Applied, thanks.

As sys/errno.h only include errno.h, remove or change it to errno.h

Signed-off-by: Hangbin Liu <liu...@gm...>
---
 src/apps/myftp.c                       | 1 -
 src/apps/nagle_rcv.c                   | 1 -
 src/apps/nagle_snd.c                   | 1 -
 src/apps/sctp_darn.c                   | 1 -
 src/apps/sctp_test.c                   | 1 -
 src/func_tests/test_1_to_1_connect.c   | 2 +-
 src/func_tests/test_1_to_1_connectx.c  | 2 +-
 src/func_tests/test_1_to_1_rtoinfo.c   | 2 +-
 src/func_tests/test_1_to_1_shutdown.c  | 2 +-
 src/func_tests/test_assoc_abort.c      | 1 -
 src/func_tests/test_assoc_shutdown.c   | 1 -
 src/func_tests/test_autoclose.c        | 1 -
 src/func_tests/test_basic.c            | 1 -
 src/func_tests/test_fragments.c        | 1 -
 src/func_tests/test_sctp_sendrecvmsg.c | 1 -
 src/func_tests/test_sockopt.c          | 2 +-
 src/func_tests/test_timetolive.c       | 1 -
 src/testlib/sctputil.c                 | 2 --
 18 files changed, 5 insertions(+), 19 deletions(-)

diff --git a/src/apps/myftp.c b/src/apps/myftp.c
index 6b81098..993e591 100644
--- a/src/apps/myftp.c
+++ b/src/apps/myftp.c
@@ -51,7 +51,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h> /* for sockaddr_in */
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 
diff --git a/src/apps/nagle_rcv.c b/src/apps/nagle_rcv.c
index cb2ea8f..16e559f 100644
--- a/src/apps/nagle_rcv.c
+++ b/src/apps/nagle_rcv.c
@@ -51,7 +51,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/apps/nagle_snd.c b/src/apps/nagle_snd.c
index 4c41e63..8d66c48 100644
--- a/src/apps/nagle_snd.c
+++ b/src/apps/nagle_snd.c
@@ -50,7 +50,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/apps/sctp_darn.c b/src/apps/sctp_darn.c
index 527a4fc..2ae0a20 100644
--- a/src/apps/sctp_darn.c
+++ b/src/apps/sctp_darn.c
@@ -60,7 +60,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <sys/param.h>
 #include <sys/poll.h>
 #include <arpa/inet.h>
diff --git a/src/apps/sctp_test.c b/src/apps/sctp_test.c
index 0e4695b..bab3668 100644
--- a/src/apps/sctp_test.c
+++ b/src/apps/sctp_test.c
@@ -48,7 +48,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <string.h>
diff --git a/src/func_tests/test_1_to_1_connect.c b/src/func_tests/test_1_to_1_connect.c
index 6670f72..b4721af 100644
--- a/src/func_tests/test_1_to_1_connect.c
+++ b/src/func_tests/test_1_to_1_connect.c
@@ -54,7 +54,7 @@
 #include <linux/socket.h>
 #include <netinet/in.h>         /* for sockaddr_in */
 #include <arpa/inet.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/uio.h>
 #include <netinet/sctp.h>
 #include "sctputil.h"
diff --git a/src/func_tests/test_1_to_1_connectx.c b/src/func_tests/test_1_to_1_connectx.c
index 04e20bf..3cb18b3 100644
--- a/src/func_tests/test_1_to_1_connectx.c
+++ b/src/func_tests/test_1_to_1_connectx.c
@@ -54,7 +54,7 @@
 #include <linux/socket.h>
 #include <netinet/in.h>         /* for sockaddr_in */
 #include <arpa/inet.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/uio.h>
 #include <netinet/sctp.h>
 #include "sctputil.h"
diff --git a/src/func_tests/test_1_to_1_rtoinfo.c b/src/func_tests/test_1_to_1_rtoinfo.c
index cb46e39..02dd477 100644
--- a/src/func_tests/test_1_to_1_rtoinfo.c
+++ b/src/func_tests/test_1_to_1_rtoinfo.c
@@ -48,7 +48,7 @@
 #include <linux/socket.h>
 #include <linux/in.h>         /* for sockaddr_in */
 #include <linux/in6.h>         /* for sockaddr_in6 */
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/uio.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_1_to_1_shutdown.c b/src/func_tests/test_1_to_1_shutdown.c
index de505f7..3519434 100644
--- a/src/func_tests/test_1_to_1_shutdown.c
+++ b/src/func_tests/test_1_to_1_shutdown.c
@@ -41,7 +41,7 @@
  */
 
 #include <stdio.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/socket.h>
 #include <netinet/in.h>
 #include <arpa/inet.h>
diff --git a/src/func_tests/test_assoc_abort.c b/src/func_tests/test_assoc_abort.c
index 7e9a0b5..f8019c7 100644
--- a/src/func_tests/test_assoc_abort.c
+++ b/src/func_tests/test_assoc_abort.c
@@ -49,7 +49,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_assoc_shutdown.c b/src/func_tests/test_assoc_shutdown.c
index dcdb377..a007117 100644
--- a/src/func_tests/test_assoc_shutdown.c
+++ b/src/func_tests/test_assoc_shutdown.c
@@ -48,7 +48,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_autoclose.c b/src/func_tests/test_autoclose.c
index b5368e7..e65fac0 100644
--- a/src/func_tests/test_autoclose.c
+++ b/src/func_tests/test_autoclose.c
@@ -49,7 +49,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_basic.c b/src/func_tests/test_basic.c
index b8d4eae..92288b2 100644
--- a/src/func_tests/test_basic.c
+++ b/src/func_tests/test_basic.c
@@ -52,7 +52,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_fragments.c b/src/func_tests/test_fragments.c
index 86262ce..7feb2b2 100644
--- a/src/func_tests/test_fragments.c
+++ b/src/func_tests/test_fragments.c
@@ -60,7 +60,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_sctp_sendrecvmsg.c b/src/func_tests/test_sctp_sendrecvmsg.c
index 21ba867..6ec08ef 100644
--- a/src/func_tests/test_sctp_sendrecvmsg.c
+++ b/src/func_tests/test_sctp_sendrecvmsg.c
@@ -50,7 +50,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_sockopt.c b/src/func_tests/test_sockopt.c
index a31c5d3..2bd1097 100644
--- a/src/func_tests/test_sockopt.c
+++ b/src/func_tests/test_sockopt.c
@@ -52,7 +52,7 @@
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/uio.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <netinet/in.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_timetolive.c b/src/func_tests/test_timetolive.c
index d13168e..4a57b42 100644
--- a/src/func_tests/test_timetolive.c
+++ b/src/func_tests/test_timetolive.c
@@ -64,7 +64,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/testlib/sctputil.c b/src/testlib/sctputil.c
index abf80fa..5a18eb8 100644
--- a/src/testlib/sctputil.c
+++ b/src/testlib/sctputil.c
@@ -42,14 +42,12 @@
  */
 
 #include <stdio.h>
-#include <errno.h> 
 #include <ctype.h>
 #include <string.h>
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h> 
-#include <sys/errno.h>
 #include <errno.h>
 #include <malloc.h>
 #include <netinet/sctp.h>
-- 
1.8.1.4

As sys/errno.h only include errno.h, remove or change it to errno.h

Signed-off-by: Hangbin Liu <liu...@gm...>
---
 src/apps/myftp.c                       | 1 -
 src/apps/nagle_rcv.c                   | 1 -
 src/apps/nagle_snd.c                   | 1 -
 src/apps/sctp_darn.c                   | 1 -
 src/apps/sctp_test.c                   | 1 -
 src/func_tests/test_1_to_1_connect.c   | 2 +-
 src/func_tests/test_1_to_1_connectx.c  | 2 +-
 src/func_tests/test_1_to_1_rtoinfo.c   | 2 +-
 src/func_tests/test_1_to_1_shutdown.c  | 2 +-
 src/func_tests/test_assoc_abort.c      | 1 -
 src/func_tests/test_assoc_shutdown.c   | 1 -
 src/func_tests/test_autoclose.c        | 1 -
 src/func_tests/test_basic.c            | 1 -
 src/func_tests/test_fragments.c        | 1 -
 src/func_tests/test_sctp_sendrecvmsg.c | 1 -
 src/func_tests/test_sockopt.c          | 2 +-
 src/func_tests/test_timetolive.c       | 1 -
 src/testlib/sctputil.c                 | 2 --
 18 files changed, 5 insertions(+), 19 deletions(-)

diff --git a/src/apps/myftp.c b/src/apps/myftp.c
index 6b81098..993e591 100644
--- a/src/apps/myftp.c
+++ b/src/apps/myftp.c
@@ -51,7 +51,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h> /* for sockaddr_in */
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 
diff --git a/src/apps/nagle_rcv.c b/src/apps/nagle_rcv.c
index cb2ea8f..16e559f 100644
--- a/src/apps/nagle_rcv.c
+++ b/src/apps/nagle_rcv.c
@@ -51,7 +51,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/apps/nagle_snd.c b/src/apps/nagle_snd.c
index 4c41e63..8d66c48 100644
--- a/src/apps/nagle_snd.c
+++ b/src/apps/nagle_snd.c
@@ -50,7 +50,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/apps/sctp_darn.c b/src/apps/sctp_darn.c
index 527a4fc..2ae0a20 100644
--- a/src/apps/sctp_darn.c
+++ b/src/apps/sctp_darn.c
@@ -60,7 +60,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <sys/param.h>
 #include <sys/poll.h>
 #include <arpa/inet.h>
diff --git a/src/apps/sctp_test.c b/src/apps/sctp_test.c
index 0e4695b..bab3668 100644
--- a/src/apps/sctp_test.c
+++ b/src/apps/sctp_test.c
@@ -48,7 +48,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <string.h>
diff --git a/src/func_tests/test_1_to_1_connect.c b/src/func_tests/test_1_to_1_connect.c
index 6670f72..b4721af 100644
--- a/src/func_tests/test_1_to_1_connect.c
+++ b/src/func_tests/test_1_to_1_connect.c
@@ -54,7 +54,7 @@
 #include <linux/socket.h>
 #include <netinet/in.h>         /* for sockaddr_in */
 #include <arpa/inet.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/uio.h>
 #include <netinet/sctp.h>
 #include "sctputil.h"
diff --git a/src/func_tests/test_1_to_1_connectx.c b/src/func_tests/test_1_to_1_connectx.c
index 04e20bf..3cb18b3 100644
--- a/src/func_tests/test_1_to_1_connectx.c
+++ b/src/func_tests/test_1_to_1_connectx.c
@@ -54,7 +54,7 @@
 #include <linux/socket.h>
 #include <netinet/in.h>         /* for sockaddr_in */
 #include <arpa/inet.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/uio.h>
 #include <netinet/sctp.h>
 #include "sctputil.h"
diff --git a/src/func_tests/test_1_to_1_rtoinfo.c b/src/func_tests/test_1_to_1_rtoinfo.c
index cb46e39..02dd477 100644
--- a/src/func_tests/test_1_to_1_rtoinfo.c
+++ b/src/func_tests/test_1_to_1_rtoinfo.c
@@ -48,7 +48,7 @@
 #include <linux/socket.h>
 #include <linux/in.h>         /* for sockaddr_in */
 #include <linux/in6.h>         /* for sockaddr_in6 */
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/uio.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_1_to_1_shutdown.c b/src/func_tests/test_1_to_1_shutdown.c
index de505f7..3519434 100644
--- a/src/func_tests/test_1_to_1_shutdown.c
+++ b/src/func_tests/test_1_to_1_shutdown.c
@@ -41,7 +41,7 @@
  */
 
 #include <stdio.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <sys/socket.h>
 #include <netinet/in.h>
 #include <arpa/inet.h>
diff --git a/src/func_tests/test_assoc_abort.c b/src/func_tests/test_assoc_abort.c
index 7e9a0b5..f8019c7 100644
--- a/src/func_tests/test_assoc_abort.c
+++ b/src/func_tests/test_assoc_abort.c
@@ -49,7 +49,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_assoc_shutdown.c b/src/func_tests/test_assoc_shutdown.c
index dcdb377..a007117 100644
--- a/src/func_tests/test_assoc_shutdown.c
+++ b/src/func_tests/test_assoc_shutdown.c
@@ -48,7 +48,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_autoclose.c b/src/func_tests/test_autoclose.c
index b5368e7..e65fac0 100644
--- a/src/func_tests/test_autoclose.c
+++ b/src/func_tests/test_autoclose.c
@@ -49,7 +49,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_basic.c b/src/func_tests/test_basic.c
index b8d4eae..92288b2 100644
--- a/src/func_tests/test_basic.c
+++ b/src/func_tests/test_basic.c
@@ -52,7 +52,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_fragments.c b/src/func_tests/test_fragments.c
index 86262ce..7feb2b2 100644
--- a/src/func_tests/test_fragments.c
+++ b/src/func_tests/test_fragments.c
@@ -60,7 +60,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_sctp_sendrecvmsg.c b/src/func_tests/test_sctp_sendrecvmsg.c
index 21ba867..6ec08ef 100644
--- a/src/func_tests/test_sctp_sendrecvmsg.c
+++ b/src/func_tests/test_sctp_sendrecvmsg.c
@@ -50,7 +50,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_sockopt.c b/src/func_tests/test_sockopt.c
index a31c5d3..2bd1097 100644
--- a/src/func_tests/test_sockopt.c
+++ b/src/func_tests/test_sockopt.c
@@ -52,7 +52,7 @@
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/uio.h>
-#include <sys/errno.h>
+#include <errno.h>
 #include <netinet/in.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/func_tests/test_timetolive.c b/src/func_tests/test_timetolive.c
index d13168e..4a57b42 100644
--- a/src/func_tests/test_timetolive.c
+++ b/src/func_tests/test_timetolive.c
@@ -64,7 +64,6 @@
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h>
-#include <sys/errno.h>
 #include <errno.h>
 #include <netinet/sctp.h>
 #include <sctputil.h>
diff --git a/src/testlib/sctputil.c b/src/testlib/sctputil.c
index abf80fa..5a18eb8 100644
--- a/src/testlib/sctputil.c
+++ b/src/testlib/sctputil.c
@@ -42,14 +42,12 @@
  */
 
 #include <stdio.h>
-#include <errno.h> 
 #include <ctype.h>
 #include <string.h>
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/uio.h>
 #include <netinet/in.h> 
-#include <sys/errno.h>
 #include <errno.h>
 #include <malloc.h>
 #include <netinet/sctp.h>
-- 
1.8.1.4

Thanks your confirm. I will try sctp. its features are quite fantastic.

On 2013年07月08日 17:26, Daniel Borkmann wrote:
> On 07/08/2013 10:57 AM, xiong wei wrote:
>> one more question. Is redhat 6, centos6 is OK to build sctp, which 
>> kernel is 2.6.32. From 2.6.32 to latest version. Does sctp experience 
>> big changes? I need to consider customer's working environment.
>
> Yep, SCTP is supported on RHEL6 of course.
>
> In the kernel code there are a number of changes, but that's mostly
> improvements under the hood that are transparent to user space apps.
>

On 07/08/2013 10:57 AM, xiong wei wrote:
> one more question. Is redhat 6, centos6 is OK to build sctp, which kernel is 2.6.32. From 2.6.32 to latest version. Does sctp experience big changes? I need to consider customer's working environment.

Yep, SCTP is supported on RHEL6 of course.

In the kernel code there are a number of changes, but that's mostly
improvements under the hood that are transparent to user space apps.

On 07/08/2013 11:12 AM, xiong wei wrote:
> Oh, yes, I paste wrong code here. my test case is like below:
>
> while (1) {
>                  snd_sinfo.sinfo_ppid = 0;
>                  snd_sinfo.sinfo_flags = 0;
>                  snd_sinfo.sinfo_stream = 0;
>                  snd_sinfo.sinfo_timetolive = 0;
>                  snd_sinfo.sinfo_assoc_id = associd;
>                  printf("send info\n");
>                  memset(strmsg, 0, 10);
>                  sprintf(strmsg, "%d", time(NULL));
>                  result = sctp_send(sd, strmsg, 10, &snd_sinfo, 0);
>
>                  printf("send result is %d, err is %s, msg is %s\n", result, strerror(errno), strmsg);
>                  sleep(1);
>          }
>
> And, I check the fix. Yes, I think 100% that's the reason. I also trace like it. The sendmsg realize the problem of the len and through out invalid parameters.
>
> That's great. thanks for all your guy's help.

Yep, since you've used sctp_send(), that was the fix you've needed.

Cheers,
Daniel

Oh, yes, I paste wrong code here. my test case is like below:

while (1) {
                 snd_sinfo.sinfo_ppid = 0;
                 snd_sinfo.sinfo_flags = 0;
                 snd_sinfo.sinfo_stream = 0;
                 snd_sinfo.sinfo_timetolive = 0;
                 snd_sinfo.sinfo_assoc_id = associd;
                 printf("send info\n");
                 memset(strmsg, 0, 10);
                 sprintf(strmsg, "%d", time(NULL));
                 result = sctp_send(sd, strmsg, 10, &snd_sinfo, 0);

                 printf("send result is %d, err is %s, msg is %s\n", 
result, strerror(errno), strmsg);
                 sleep(1);
         }

And, I check the fix. Yes, I think 100% that's the reason. I also trace 
like it. The sendmsg realize the problem of the len and through out 
invalid parameters.

That's great. thanks for all your guy's help.



On 2013年07月08日 17:05, Daniel Borkmann wrote:
> On 07/08/2013 10:36 AM, xiong wei wrote:
>> Anyway, here is the code, I you guys like to take a look and test, 
>> that's appreciated.
>
> Hm, you are talking about problems in sctp_sendmsg/sctp_send (?), but 
> your code below
> does not even use those functions. Is this really the same code you 
> are talking about?
>
> In case you used sctp_send, then this was fixed in 1.0.12:
>
> commit c5336c5eb01e72683ccaf44a0879ffa4ce3a69bf
> Author: Daniel Borkmann <dbo...@re...>
> Date:   Mon Dec 17 17:32:04 2012 +0100
>
>     sctp_send: fix msg_control data corruption
>
>     The byte array outcmsg is allocated on the stack within the if-block
>     that test for a valif sctp_sndrcvinfo structure. There, it is 
> assigned
>     to outmsg.msg_control, which is later on after leaving the if-block
>     passed to sendmsg. With this minimal example, the following is
>     happening:
>
>     int main(void)
>     {
>         int fd;
>         struct sctp_sndrcvinfo sndinfo;
>
>         fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
>         assert(fd > 0);
>
>         sctp_send(fd, "bla", strlen("bla") + 1, &sndinfo, 0);
>
>         return 0;
>     }
>
>     strace ./a.out before this patch:
>
>       sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"bla\0", 4}],
>               msg_controllen=48, {cmsg_len=3364590592, 
> cmsg_level=0x4003e8
>               /* SOL_??? */, cmsg_type=, ...}, msg_flags=0}, 0)
>
>       --> cmsg_len corrupted
>
>     strace ./a.out after this patch:
>
>       sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"bla\0", 4}],
>               msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* 
> SOL_??? */,
>                                   cmsg_type=, ...}, msg_flags=0}, 0)
>
>     This is basically the case since 2005, introduced in the commit 
> 91239acf
>     ("Add sctp_send() API support and testcases"). However, probably this
>     changed due to a different compiler behaviour / optimization (?), 
> since
>     it was not visible / affected by older Linux versions.
>
>     Cc: Vlad Yasevich <vya...@gm...>
>     Signed-off-by: Daniel Borkmann <dbo...@re...>
>
>> On 2013年07月08日 16:28, Daniel Borkmann wrote:
>>> On 07/08/2013 09:41 AM, xiong wei wrote:
>>>> forget to attach the lksctp version
>>>> the version is 1.0.11. this is also fedora 18 provided by default.
>>>>
>>>> attached file is the code sample, Please check it.
>>>
>>> It looks like sourceforge does not allow attachments. Please place
>>> the C code directly into the mail.
>>>
>>>> BTW, I use lksctp 1.0.15, the latest lib, to make a test, it looks 
>>>> everything is fine. I don't know if any significant change happened 
>>>> from 1.0.11 to 1.0.15.
>>>
>>> Yep, a lot of fixes and cleanups happened since then, so update is
>>> recommended.
>>>
>>>> I use 2 NICs to do the test.
>>>>
>>>> how to run it :
>>>>
>>>> Server side :
>>>> basic_server port ip1 ip2
>>>>
>>>> client side:
>>>> basic_client port ip1 ip2
>>>>
>>>> before using basic_client, please modify the code in line 127 and 
>>>> 131 to bind your local IPs.
>>>>
>>>> this simple example is used to test multihome and failover function 
>>>> provided by SCTP.
>>>>
>>>> I'm not sure if sctp is mature enough to make big project, I'm 
>>>> evaluating this protocol, this protocol looks great, but I'm not 
>>>> sure if all the functions are implemented as well as it declares.
>>>>
>>>> On 2013年07月08日 15:29, Hangbin Liu wrote:
>>>>> 2013/7/8 Hangbin Liu <liu...@gm...>:
>>>>>> 2013/7/8 xiong wei <xio...@sk...>:
>>>>>>> HI, everyone.
>>>>>>>
>>>>>>> I met a wired problem on fedora 18 64 bit platform by using sctp,
>>>>>>>
>>>>>>> lksctp version is
>>>>>> Hi, what's the version ??
>>>>>>
>>>>>>>
>>>>>>> When I use multi-home function to setup link between 2 fedora 18 
>>>>>>> hosts,
>>>>>>> I can not use sctp_sendmsg to send any message and return error 
>>>>>>> "Invalid
>>>>>>> Parameters" . but the same program runs well in Centos 6.
>>>>> And could you provide more details about your steps. e.g. which tool
>>>>> you use, what's the parameters, how many NICs you have ? and giving a
>>>>> testing topo is better.
>>>>>
>>>>> Thanks
>>>>> Hangbin Liu
>>>>>>> And the most wired thing is when I run Server side in centos and 
>>>>>>> run
>>>>>>> Client side in fedora, I have the problem, but everything is 
>>>>>>> fine when I
>>>>>>> run client side in centos but run server side on fedora.
>>>>>>>
>>>>>>> Does anyone has the same problem?
>>>
>>
>

On 07/08/2013 10:36 AM, xiong wei wrote:
> Anyway, here is the code, I you guys like to take a look and test, that's appreciated.

Hm, you are talking about problems in sctp_sendmsg/sctp_send (?), but your code below
does not even use those functions. Is this really the same code you are talking about?

In case you used sctp_send, then this was fixed in 1.0.12:

commit c5336c5eb01e72683ccaf44a0879ffa4ce3a69bf
Author: Daniel Borkmann <dbo...@re...>
Date:   Mon Dec 17 17:32:04 2012 +0100

     sctp_send: fix msg_control data corruption

     The byte array outcmsg is allocated on the stack within the if-block
     that test for a valif sctp_sndrcvinfo structure. There, it is assigned
     to outmsg.msg_control, which is later on after leaving the if-block
     passed to sendmsg. With this minimal example, the following is
     happening:

     int main(void)
     {
         int fd;
         struct sctp_sndrcvinfo sndinfo;

         fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
         assert(fd > 0);

         sctp_send(fd, "bla", strlen("bla") + 1, &sndinfo, 0);

         return 0;
     }

     strace ./a.out before this patch:

       sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"bla\0", 4}],
               msg_controllen=48, {cmsg_len=3364590592, cmsg_level=0x4003e8
               /* SOL_??? */, cmsg_type=, ...}, msg_flags=0}, 0)

       --> cmsg_len corrupted

     strace ./a.out after this patch:

       sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"bla\0", 4}],
               msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */,
                                   cmsg_type=, ...}, msg_flags=0}, 0)

     This is basically the case since 2005, introduced in the commit 91239acf
     ("Add sctp_send() API support and testcases"). However, probably this
     changed due to a different compiler behaviour / optimization (?), since
     it was not visible / affected by older Linux versions.

     Cc: Vlad Yasevich <vya...@gm...>
     Signed-off-by: Daniel Borkmann <dbo...@re...>

> On 2013年07月08日 16:28, Daniel Borkmann wrote:
>> On 07/08/2013 09:41 AM, xiong wei wrote:
>>> forget to attach the lksctp version
>>> the version is 1.0.11. this is also fedora 18 provided by default.
>>>
>>> attached file is the code sample, Please check it.
>>
>> It looks like sourceforge does not allow attachments. Please place
>> the C code directly into the mail.
>>
>>> BTW, I use lksctp 1.0.15, the latest lib, to make a test, it looks everything is fine. I don't know if any significant change happened from 1.0.11 to 1.0.15.
>>
>> Yep, a lot of fixes and cleanups happened since then, so update is
>> recommended.
>>
>>> I use 2 NICs to do the test.
>>>
>>> how to run it :
>>>
>>> Server side :
>>> basic_server port ip1 ip2
>>>
>>> client side:
>>> basic_client port ip1 ip2
>>>
>>> before using basic_client, please modify the code in line 127 and 131 to bind your local IPs.
>>>
>>> this simple example is used to test multihome and failover function provided by SCTP.
>>>
>>> I'm not sure if sctp is mature enough to make big project, I'm evaluating this protocol, this protocol looks great, but I'm not sure if all the functions are implemented as well as it declares.
>>>
>>> On 2013年07月08日 15:29, Hangbin Liu wrote:
>>>> 2013/7/8 Hangbin Liu <liu...@gm...>:
>>>>> 2013/7/8 xiong wei <xio...@sk...>:
>>>>>> HI, everyone.
>>>>>>
>>>>>> I met a wired problem on fedora 18 64 bit platform by using sctp,
>>>>>>
>>>>>> lksctp version is
>>>>> Hi, what's the version ??
>>>>>
>>>>>>
>>>>>> When I use multi-home function to setup link between 2 fedora 18 hosts,
>>>>>> I can not use sctp_sendmsg to send any message and return error "Invalid
>>>>>> Parameters" . but the same program runs well in Centos 6.
>>>> And could you provide more details about your steps. e.g. which tool
>>>> you use, what's the parameters, how many NICs you have ? and giving a
>>>> testing topo is better.
>>>>
>>>> Thanks
>>>> Hangbin Liu
>>>>>> And the most wired thing is when I run Server side in centos and run
>>>>>> Client side in fedora, I have the problem, but everything is fine when I
>>>>>> run client side in centos but run server side on fedora.
>>>>>>
>>>>>> Does anyone has the same problem?
>>
>

Great.  I will make more tests.

one more question. Is redhat 6, centos6 is OK to build sctp, which 
kernel is 2.6.32. From 2.6.32 to latest version. Does sctp experience 
big changes? I need to consider customer's working environment.

Thanks.

On 2013年07月08日 16:48, Daniel Borkmann wrote:
> On 07/08/2013 10:36 AM, xiong wei wrote:
>> If 1.0.15 fix many bugs, It's good for me to build confidence to 
>> choose SCTP as my base protocol.
>>
>> actually, My key question is : is SCTP implementation is mature to 
>> build big project on it. ;-)
>
> Yes, it is. Note that lksctp-tools only provides the header file and 
> wrapper functions as a
> library (e.g. bindx et al). The core protocol is in the Linux kernel 
> and well maintained.
> Since February 2013, the kernel implementation is also not marked as 
> experimental anymore.
>

2013/7/8 xiong wei <xio...@sk...>:
> If 1.0.15 fix many bugs, It's good for me to build confidence to choose SCTP
> as my base protocol.
>
> actually, My key question is : is SCTP implementation is mature to build big
> project on it. ;-)

I think yes, lots of companies use it for their products.  I think
Daniel can give you more info on it.
>
> Anyway, here is the code, I you guys like to take a look and test, that's
> appreciated.
>
> client.c
>
> int main (int argc, char **argv)
> {
>     void *addr_buf, *buf_ptr;
>     void *addr_buf_size = 0;
>     size_t addrs, cnt;
>     int sd, result, port;
>     struct sockaddr_in self_addr[2];
>     sctp_assoc_t associd;
>
>     if (argc < 3) {
>         fprintf(stderr,
>             "Usage: bindx_test PORT IPADDR1 [IPADDR2 [...]]\n");
>         return 1;
>     }
>
>     port = atoi(argv[1]);
>     printf("bindx_test: INFO: Port is %d\n", port);
>
>     /* Allocate the maximum space for the specified no. of addresses.
>      * Assume all of them are v6 addresses.
>      */
>     addr_buf = malloc((argc -2) * sizeof(struct sockaddr_in6));
>     if (addr_buf == NULL) {
>         perror("bindx_test: ERROR: addr buf allocation failed");
>         return 1;
>     }
>
>     /* Get the addresses from the cmd line */
>     addrs = 0;  /* healthy address iterator [and total counter] */
>     cnt = 2;    /* argument iterator */
>     buf_ptr = addr_buf;
>     while (cnt < argc) {
>         printf("bindx_test: INFO: Arg %d: %s", cnt, argv[cnt]);
>         fflush(stderr);
>         if (strchr(argv[cnt], ':')) {
>             struct sockaddr_in6 *sa6;
>
>             sa6 = (struct sockaddr_in6 *)buf_ptr;
>             printf(" IPv6 address number %d", addrs);
>             sa6->sin6_family = AF_INET6;
>             sa6->sin6_port = port;
>             if (inet_pton(AF_INET6, argv[cnt], &sa6->sin6_addr)) {
>                 addrs++;
>                 addr_buf_size += sizeof(struct sockaddr_in6);
>                 buf_ptr += sizeof(struct sockaddr_in6);
>             } else
>                 printf(" error");
>         } else if (strchr(argv[cnt], '.')) {
>             struct sockaddr_in *sa;
>
>             sa = (struct sockaddr_in *)buf_ptr;
>             printf (" IPv4 address number %d", addrs);
>             sa->sin_family = AF_INET;
>             sa->sin_port = port;
>             if (inet_pton (AF_INET, argv[cnt], &sa->sin_addr)) {
>                 addrs++;
>                 addr_buf_size += sizeof(struct sockaddr_in);
>                 buf_ptr += sizeof(struct sockaddr_in);
>             } else
>                 printf (" error");
>         } else
>             printf (" Unknown");
>         putchar ('\n');
>         cnt++;
>     }
>
>     printf ("bindx_test: INFO: Got %d addrs\n", addrs);
>
>     /* Create the socket */
>     sd = socket(PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);
>     if (sd == -1) {
>         perror("bindx_test: ERROR: Cannot open socket");
>         return 1;
>     }
>
>     self_addr[0].sin_family = AF_INET;
>         self_addr[0].sin_addr.s_addr = inet_addr("192.168.1.33");
>         self_addr[0].sin_port = port;
>     self_addr[1].sin_family = AF_INET;
>         self_addr[1].sin_addr.s_addr = inet_addr("192.168.1.62");
>         self_addr[1].sin_port = port;
>
>
>     /* add all */
>     result = sctp_bindx(sd, (struct sockaddr *)self_addr, 2,
>                 SCTP_BINDX_ADD_ADDR);
>     if (result == -1) {
>         perror("bindx_test: ERROR: bindx addition error");
>         return 1;
>     } else {
>         printf("bindx_test: OK: bindx address addition\n");
>
>     }
>
>     result = sctp_connectx(sd, (struct sockaddr *)addr_buf, addrs,
> &associd);
>     if (result != 0) {
>         printf("sctp connectx error is %d\n", result);
>         return 1;
>     }
>
>     return result;
> }
>

I didn't see any sctp_sendmsg usage in Client.c , did I missed something?

>
> Server.c
>
> int main (int argc, char **argv)
> {
>     void *addr_buf, *buf_ptr;
>     void *addr_buf_size = 0;
>     size_t addrs, cnt;
>     int sd, result, port;
>     struct msghdr inmessage;
>         struct iovec iov;
>         char *big_buffer;
>         char incmsg[CMSG_SPACE(sizeof(sctp_cmsg_data_t))];
>     int error;
>     int assoc_num =0;
>     sockaddr_storage_t msgname;
>     char message[10];
>     struct sctp_sndrcvinfo sinfo;
>     socklen_t msgname_len;
>     int msg_flags;
>
>
>     if (argc < 3) {
>         fprintf(stderr,
>             "Usage: bindx_test PORT IPADDR1 [IPADDR2 [...]]\n");
>         return 1;
>     }
>
>     port = atoi(argv[1]);
>     printf("bindx_test: INFO: Port is %d\n", port);
>
>     /* Allocate the maximum space for the specified no. of addresses.
>      * Assume all of them are v6 addresses.
>      */
>     addr_buf = malloc((argc -2) * sizeof(struct sockaddr_in6));
>     if (addr_buf == NULL) {
>         perror("bindx_test: ERROR: addr buf allocation failed");
>         return 1;
>     }
>
>     /* Get the addresses from the cmd line */
>     addrs = 0;  /* healthy address iterator [and total counter] */
>     cnt = 2;    /* argument iterator */
>     buf_ptr = addr_buf;
>     while (cnt < argc) {
>         printf("bindx_test: INFO: Arg %d: %s", cnt, argv[cnt]);
>         fflush(stderr);
>         if (strchr(argv[cnt], ':')) {
>             struct sockaddr_in6 *sa6;
>
>             sa6 = (struct sockaddr_in6 *)buf_ptr;
>             printf(" IPv6 address number %d", addrs);
>             sa6->sin6_family = AF_INET6;
>             sa6->sin6_port = port;
>             if (inet_pton(AF_INET6, argv[cnt], &sa6->sin6_addr)) {
>                 addrs++;
>                 addr_buf_size += sizeof(struct sockaddr_in6);
>                 buf_ptr += sizeof(struct sockaddr_in6);
>             } else
>                 printf(" error");
>         } else if (strchr(argv[cnt], '.')) {
>             struct sockaddr_in *sa;
>
>             sa = (struct sockaddr_in *)buf_ptr;
>             printf (" IPv4 address number %d", addrs);
>             sa->sin_family = AF_INET;
>             sa->sin_port = port;
>             if (inet_pton (AF_INET, argv[cnt], &sa->sin_addr)) {
>                 addrs++;
>                 addr_buf_size += sizeof(struct sockaddr_in);
>                 buf_ptr += sizeof(struct sockaddr_in);
>             } else
>                 printf (" error");
>         } else
>             printf (" Unknown");
>         putchar ('\n');
>         cnt++;
>     }
>
>     printf ("bindx_test: INFO: Got %d addrs\n", addrs);
>
>     /* Create the socket */
>     sd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
>     if (sd == -1) {
>         perror("bindx_test: ERROR: Cannot open socket");
>         return 1;
>     }
>
>     /* add all */
>     result = sctp_bindx(sd, (struct sockaddr *)addr_buf, addrs,
>                 SCTP_BINDX_ADD_ADDR);
>     if (result == -1)
>         perror("bindx_test: ERROR: bindx addition error");
>     else {
>         printf("bindx_test: OK: bindx address addition\n");
>
>     }
>
>     result = listen(sd, 2);
>     if (result != 0) {
>         printf("error to listen\n");
>     } else {
>         printf("listen successfully\n");
>     }
>
>     memset(&inmessage, 0, sizeof(inmessage));
>         iov.iov_base = big_buffer;
>         iov.iov_len = 65536;
>         inmessage.msg_iov = &iov;
>         inmessage.msg_iovlen =1;
>         inmessage.msg_control = incmsg;
>         inmessage.msg_controllen = sizeof(incmsg);
>         inmessage.msg_name = &msgname;
>         inmessage.msg_namelen = sizeof (msgname);
>
>
>     while (1) {
>         msgname_len = sizeof(msgname);
>         error = sctp_recvmsg(sd, message, 10, (struct sockaddr *)&msgname,
> &msgname_len, &sinfo, &msg_flags);
>         //error = recvmsg(sd, &inmessage, MSG_WAITALL);
>                 if (error < 0) {
>                         printf("Receive Failure: %s\n",
>                         strerror(errno));
>                 } else {
>                     printf("recv message %s\n", message);
>                 }
>
>     }
>
>     return result;
>
> }
>
>
>
>
> On 2013年07月08日 16:28, Daniel Borkmann wrote:
>>
>> On 07/08/2013 09:41 AM, xiong wei wrote:
>>>
>>> forget to attach the lksctp version
>>> the version is 1.0.11. this is also fedora 18 provided by default.
>>>
>>> attached file is the code sample, Please check it.
>>
>>
>> It looks like sourceforge does not allow attachments. Please place
>> the C code directly into the mail.
>>
>>> BTW, I use lksctp 1.0.15, the latest lib, to make a test, it looks
>>> everything is fine. I don't know if any significant change happened from
>>> 1.0.11 to 1.0.15.
>>
>>
>> Yep, a lot of fixes and cleanups happened since then, so update is
>> recommended.
>>
>>> I use 2 NICs to do the test.
>>>
>>> how to run it :
>>>
>>> Server side :
>>> basic_server port ip1 ip2
>>>
>>> client side:
>>> basic_client port ip1 ip2
>>>
>>> before using basic_client, please modify the code in line 127 and 131 to
>>> bind your local IPs.
>>>
>>> this simple example is used to test multihome and failover function
>>> provided by SCTP.
>>>
>>> I'm not sure if sctp is mature enough to make big project, I'm evaluating
>>> this protocol, this protocol looks great, but I'm not sure if all the
>>> functions are implemented as well as it declares.
>>>
>>> On 2013年07月08日 15:29, Hangbin Liu wrote:
>>>>
>>>> 2013/7/8 Hangbin Liu <liu...@gm...>:
>>>>>
>>>>> 2013/7/8 xiong wei <xio...@sk...>:
>>>>>>
>>>>>> HI, everyone.
>>>>>>
>>>>>> I met a wired problem on fedora 18 64 bit platform by using sctp,
>>>>>>
>>>>>> lksctp version is
>>>>>
>>>>> Hi, what's the version ??
>>>>>
>>>>>>
>>>>>> When I use multi-home function to setup link between 2 fedora 18
>>>>>> hosts,
>>>>>> I can not use sctp_sendmsg to send any message and return error
>>>>>> "Invalid
>>>>>> Parameters" . but the same program runs well in Centos 6.
>>>>
>>>> And could you provide more details about your steps. e.g. which tool
>>>> you use, what's the parameters, how many NICs you have ? and giving a
>>>> testing topo is better.
>>>>
>>>> Thanks
>>>> Hangbin Liu
>>>>>>
>>>>>> And the most wired thing is when I run Server side in centos and run
>>>>>> Client side in fedora, I have the problem, but everything is fine when
>>>>>> I
>>>>>> run client side in centos but run server side on fedora.
>>>>>>
>>>>>> Does anyone has the same problem?
>>
>>
>