Возможно ли привязаться к IPv4 "0.0.0.0" после привязки к первичному IPv6 "::"?
Просьба подсобить или ткнуть урл-ом на стандарт или обсуждение.

Исходный выхлоп (gcc -lsctp -o sctp sctp.c && strace ./sctp),
...
socket(PF_INET6, SOCK_STREAM, 0x84 /* IPPROTO_??? */) = 3
setsockopt(3, 0x84 /* SOL_?? */, 11, "\1\1\0\0\0\0\0\0\0", 9) = 0
setsockopt(3, 0x84 /* SOL_?? */, 2, "\4\0\4\0\4\0\0\0", 8) = 0
bind(3, {sa_family=AF_INET6, sin6_port=htons(55555), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
setsockopt(3, 0x84 /* SOL_?? */, 100, "\2\0\331\3\0\0\0\0\0\0\0\0\0\0\0\0", 16) = -1 EINVAL (Invalid argument)

...

Исходник (sctp.c),

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/sctp.h>
#include <arpa/inet.h>
#include <errno.h>

#include "hassalen.h"

#if !defined(SHOULD_IPPROTO_SCTP)
#define SHOULD_IPPROTO_SCTP 132
#endif

#define MAX_STREAM 4

struct sctp_initmsg initmsg = {0};
struct sctp_event_subscribe events = {0};

int fd1;
int fd2;

struct sockaddr *sa;

struct sockaddr_in  a4 = {0};
struct sockaddr_in6 a6 = {0};

char *addr4 = "0.0.0.0";
char *addr6 = "::";

unsigned int port1 = 55555;
unsigned int port2 = 55555;

int main() {

  int ret;

  if (inet_pton(AF_INET6,addr6,(void *) &a6.sin6_addr) <= 0)
    _exit(1);

  a6.sin6_port        = htons((unsigned short) port1);
  a6.sin6_family      = AF_INET6;
#if defined(HASSALEN)
  a6.sin6_len         = sizeof (struct sockaddr_in6);
#endif

  fd1 = socket(AF_INET6,SOCK_STREAM,SHOULD_IPPROTO_SCTP);
  if (fd1 < 0) _exit(1);

  events.sctp_association_event = 1;
  events.sctp_data_io_event = 1;

  ret = setsockopt(fd1, IPPROTO_SCTP, SCTP_EVENTS, &events,sizeof (events));
  if (ret < 0) _exit(1);

  initmsg.sinit_num_ostreams  = MAX_STREAM;
  initmsg.sinit_max_instreams = MAX_STREAM;
  initmsg.sinit_max_attempts  = MAX_STREAM;

  ret = setsockopt(fd1, IPPROTO_SCTP, SCTP_INITMSG, &initmsg, sizeof(struct sctp_initmsg));
  if (ret < 0) _exit(1);

  ret = bind(fd1,(struct sockaddr *) &a6,sizeof(a6));
  if (ret < 0) _exit(1);
//
  if (inet_pton(AF_INET,addr4,(void *) &a4.sin_addr) <= 0)
    _exit(1);

  a4.sin_port        = htons((unsigned short) port2);
  a4.sin_family      = AF_INET;

#if defined(HASSALEN)
  a4.sin_len = sizeof(struct sockaddr_in);
#endif

  sa = (struct sockaddr *) &a4;

  ret = sctp_bindx(fd1,sa,1,SCTP_BINDX_ADD_ADDR);
  if (ret != 0) _exit(1);

  close(fd1);

  _exit(0);
}

• net, SCTP - граблехождение,guest, 20:08 , 13-Мрт-11
  • net, SCTP - граблехождение,nikto, 12:27 , 14-Мрт-11
    • net, SCTP - граблехождение,guest, 13:08 , 14-Мрт-11
      • net, SCTP - граблехождение,nikto, 13:34 , 14-Мрт-11
        • net, SCTP - граблехождение,guest, 13:44 , 14-Мрт-11
        • net, SCTP - граблехождение,guest, 13:47 , 14-Мрт-11
          • net, SCTP - граблехождение,nikto, 13:59 , 14-Мрт-11
            • net, SCTP - граблехождение,guest, 14:03 , 14-Мрт-11
              • net, SCTP - граблехождение,nikto, 14:16 , 14-Мрт-11
                • net, SCTP - граблехождение,guest, 14:22 , 14-Мрт-11
        • net, SCTP - граблехождение,nikto, 13:48 , 14-Мрт-11
          • net, SCTP - граблехождение,guest, 13:55 , 14-Мрт-11

http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-15#se...
Note
   that the wildcard addresses cannot be used with this function, doing
   so will result in an error.

Похоже оно...

> http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-15#se...
> Note
>    that the wildcard addresses cannot be used with this
> function, doing
>    so will result in an error.
> Похоже оно...

В том-то и анекдот, что порядок вызова для разных стеков(v4 & v6) корректен.

>If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
>If the sd is an IPv6 socket, the addresses passed can either be IPv4
>or IPv6 addresses.

Досадно, что в стандарте ничего не сказано по поводу явной привязки ANY_ADDRESS(v4 and v6), тем более что привязка по первичному адрессу IPv6 проходит успешно и параметры второго вызова синтаксически корректны

...
bind(3, {sa_family=AF_INET6, sin6_port=htons(55555), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
setsockopt(3, 0x84 /* SOL_?? */, 100, "\2\0\331\3\0\0\0\0\0\0\0\0\0\0\0\0", 16) = -1 EINVAL (Invalid argument)
...

Вопрос реально очень интересный, сам давно облизываюсь на sctp но работать с ним пока не приходилось.

> В том-то и анекдот, что порядок вызова для разных стеков(v4 & v6)
> корректен.

Эм... лично я понял этот абзац так:
wildcard адрес может быть _только_ один.
Т.е. если мы сделали bind() на in6addr_any то на INADDR_ANY sctp_bindx() уже не пройдет.
Вы понимаете этот текст иначе?

> Эм... лично я понял этот абзац так:
> wildcard адрес может быть _только_ один.
> Т.е. если мы сделали bind() на in6addr_any то на INADDR_ANY sctp_bindx() уже
> не пройдет.
> Вы понимаете этот текст иначе?

Щаз прикручиваю к одному своему проекту.
Явно не указано по поводу количествa ANY, указан только порядок для разных "family"

Граблехождение показало, что после привязки первого ANY, независимо от семейства и OC дальнейшая привязка любого адреса, даже того же семейства, обламывается.

И по поводу SCTP, там есть одна грабля специфическая и возможные пути обхода, описание в поисковик: sctp tsvwg-1.pdf

> Граблехождение показало, что после привязки первого ANY, независимо от семейства и OC
> дальнейшая привязка любого адреса, даже того же семейства, обламывается.

Т.е. тот абзац следует понимать так:
после bind(x) на ANY больше ни к каким адресам не привязаться?

> И по поводу SCTP, там есть одна грабля специфическая и возможные пути
> обхода, описание в поисковик: sctp tsvwg-1.pdf

Это как я понимаю уже про добавление адресов после установки соединения.

>> И по поводу SCTP, там есть одна грабля специфическая и возможные пути
>> обхода, описание в поисковик: sctp tsvwg-1.pdf
> Это как я понимаю уже про добавление адресов после установки соединения.

Нет, там засада с multihoming небольшая, самый изящный вариант решения на ядренном уровне решить, но пока насколько мне известно вопрос открытый.

Стендовые прогоны показали, что к heartbiting`y не хватает, стр.9 документа: Adding New State in Path Management, игры с таймингами RTO/RTT/и пр. - есть полумеры, а выносить в user-space как-то не камильфо, в общем нет в жизни полного счастья.

> Нет, там засада с multihoming небольшая, самый изящный вариант решения на ядренном
> уровне решить, но пока насколько мне известно вопрос открытый.

Тогда вы мне не тот документ подсунули)

>> Нет, там засада с multihoming небольшая, самый изящный вариант решения на ядренном
>> уровне решить, но пока насколько мне известно вопрос открытый.
> Тогда вы мне не тот документ подсунули)

Там другое, имо там самый существенная проблема sctp:
Документ: Quick failover algrotithn in sctp
Авторы: Yoshifumi Nishida, Preethi Natarajan

> Там другое, имо там самый существенная проблема sctp:
> Документ: Quick failover algrotithn in sctp
> Авторы: Yoshifumi Nishida, Preethi Natarajan

Cпс нашлось.
Просто 1е, что выпадает в гугле на "sctp tsvwg-1.pdf" завется Authenticated Chunks for SCTP :)

>> Эм... лично я понял этот абзац так:
>> wildcard адрес может быть _только_ один.
>> Т.е. если мы сделали bind() на in6addr_any то на INADDR_ANY sctp_bindx() уже
>> не пройдет.
>> Вы понимаете этот текст иначе?
> Явно не указано по поводу количествa ANY, указан только порядок для разных
> "family"

Моя вина упустил, все-таки явно указано.

Досадно всё же, что при использовании ANY происходит такая хрень:

>Граблехождение показало, что после привязки первого ANY, независимо от семейства и OC
>дальнейшая привязка любого адреса, даже того же семейства, обламывается.

> Моя вина упустил, все-таки явно указано.
> Досадно всё же, что при использовании ANY происходит такая хрень:

По факту да. происходит.
   A single address may be specified as INADDR_ANY or IN6ADDR_ANY, see
   Section 3.1.2 for this usage.
Меня настораживает, что тут single. Если бы там было что-то вроди only one
то было бы однозначно, а так я не уверен что правильно понимаю.
Но опять же ваш тест показывает...
Наверное надо идти к авторам lksctp и просить разъяснений в их рассылках.