From: Daniel Borkmann <dborkman@redhat.com>
To: linux-sctp@vger.kernel.org
Subject: Re: wrong family for IP addresses given by sctp library
Date: Wed, 03 Dec 2014 11:30:33 +0000 [thread overview]
Message-ID: <547EF459.9000804@redhat.com> (raw)
In-Reply-To: <B8F3375A902A0648BD5D9A5ADDE687B00569F8CC@cadine.france.prosodie.local>
On 12/03/2014 12:25 PM, Michael Tuexen wrote:
> On 03 Dec 2014, at 11:50, Boiteux Frederic <fboiteux@prosodie.com> wrote:
>
>> Hello,
>>
>> I'm trying to use SCTP on Linux machines with 'old' kernels (Debian 5, 2.6.26 kernel and Debian 7, 3.2 kernel). I've setup a program which can handles IPv4 and IPv6 addresses, and for that, I use a socket with AF_INET6 family, then I bind it to IPv4 or v6 addresses with sctp_bindx() (its manual page says this call can handle both v4 and v6 adresses if the socket is an IPv6 one).
>> It seems to work well, but I have a strange behavior : on a test platform with only IPv4 addresses, when I get messages or notifications (using sctp_recvmsg()), the addresses given in it (IP address of the sender, or confirmation/fail of some peer addresses) are always from the IPv6 family !
> Is it possible that the address are mapped V4 addresses?
Hmm, Frederic, could you try with a current kernel? We've had fixes
in the past such as ...
commit 299ee123e19889d511092347f5fc14db0f10e3a6
Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date: Wed Jul 30 12:40:53 2014 -0600
sctp: Fixup v4mapped behaviour to comply with Sock API
> Best regards
> Michael
>> For example, for received messages, the « from » socket address returned by sctp_recvmsg() has always a sa_family field to AF_INET6, even if the address is in fact an IPv4 address ! Using getnameinfo() with NI_NUMERICHOST option, I can get the ascii representation of the address, a 4 dotted address, and then I have to fix the address to use it with its real family (as I expected to receive).
>> It seems to be directly related to the AF_INET6 family of the socket, but I don't know if it' s a known problem, possibly fixed since then in latest linux-sctip library, or probably a programmatic error from me.
>>
>> Have you ever heard for such problem ? What is your feeling about ?
>>
>> With regards,
>> Fred.
>>
>> --
>> 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
>>
>
> --
> 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
>
next prev parent reply other threads:[~2014-12-03 11:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 10:50 wrong family for IP addresses given by sctp library Boiteux Frederic
2014-12-03 11:03 ` Ivan Skytte Jørgensen
2014-12-03 11:25 ` Michael Tuexen
2014-12-03 11:30 ` Daniel Borkmann [this message]
2014-12-03 13:27 ` Boiteux Frederic
2014-12-03 15:30 ` Michael Tuexen
2014-12-03 15:36 ` Vlad Yasevich
2014-12-03 15:41 ` Boiteux Frederic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=547EF459.9000804@redhat.com \
--to=dborkman@redhat.com \
--cc=linux-sctp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.