[asterisk-scf-dev] PJSIP TCP transport

[Marc Blanchet]

- when I saw the use of link-local, then I jumped on it.
- fact: link-locals need an interface id to become unambiguous (from the 
stack point of view, even if you only have one interface).
for example: ping6 fe80::1234 does not work by default. you need to 
ping6 fe80::1234%en1 or some option flag to ping6 telling which 
interface to send to.
- hypothesis, you are hitting that problem in your code/tests.
- proposed idea: try first using global address space in your test or 
any unicast address space (Unique local is fine too). If it works, then 
you need to look at how to work with link-locals in your structs/code.

a suggestion.

Marc.

Le 10-11-29 14:49, Mark Michelson a écrit :
> Hi list,
>
> One limitation of PJSIP is that it currently does not allow for IPv6 TCP
> transports to be used, because the code is written with the assumption
> that only IPv4 addresses will be used. I have made changes to the code
> to allow for IPv6 to be used for TCP transports. I've been running the
> included transport_tcp_test and it is failing. I'm baffled as to why
> this might be.
>
> The crux of the problem lies in a call to connect() that is failing and
> setting errno to EINVAL. According to the manpage, EINVAL may happen if
> "The address_len argument is not a valid length for the address family;
> or invalid address family in the sockaddr structure." I have added
> printf debugging to be sure that the address_len is correct and the
> address family in the sockaddr structure are set properly. I also have
> added printf debugging to make sure that the address and port in the
> sockaddr structure, as well as the type of socket passed to connect()
> are the correct types.
>
> For reference, if I change the test back to use IPv4, the test passes.
> While this may seem to point to an issue where an IPv4 assumption in the
> code has not been corrected, I contend that such matters would not
> result in the failed connect() call that I'm seeing. The parameters
> passed to connect are all valid, so it should not be failing. Does
> anyone know of any other reasons that connect() might fail and set errno
> to EINVAL?
>
> Here is a snippet of logs from when the test runs. The initial data is
> retrieved by calling pj_getsockname() on the originating socket, and the
> latter data is retrieved from the pj_sockaddr structure passed to
> pj_sock_connect().
>
> "On v6 connect, trying to connect from socket bound to [::]:43702
> Address family is really set correctly
> And the len after getsockname is 28
> On v6 connect, trying to connect to [fe80::221:9bff:fe02:8e33]:44373
> Address family is really set correctly
> And the len is 28"
>
> A few more notes:
> * The "really set correctly" line is to double-check that the address
> family of the pj_sockaddr is AF_INET6.
> * fe80::221:9bff:fe02:8e33 is the link-local IPv6 address of the machine
> on which the test is running.
> * I have confirmed through separate tests that 28 is the correct length
> of a sockaddr_in6 structure on this machine.
>
> If anyone has any idea about what's going on, please push me in a proper
> direction. Also, if you want to see the changes I've made, you can
> checkout the "veesix" branch of the pjproject repo.
>
> Thanks!
>


-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca