[FFmpeg-devel] [PATCH] Make RTP work with IPv6 enabled

[Ronald S. Bultje]

Hi Luca,

On 10/29/07, Luca Abeni <lucabe72 at email.it> wrote:
>
> Ronald S. Bultje wrote:
> > On 10/29/07, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >> Still no idea why the connect() would make it work, though, since the
> >> connect() also takes place after the bind() and should thus fail
> >> similarly...
> >
> >
> > No idea about this, but a quick testcase confirms that this is in fact
> the
> > real problem (see attached testcase - does that work under Linux?).
> I tried it under Linux, and I get
> ok - 2/10
> so I guess it works :)


For me, the bind() fails with EINVAL, as in ffserver... So there *is* a
difference. Now here's the creepy thing: 2/10 are the bind() and sendto()
families (AF_INET/AF_INET6). That means Linux allows cross-family
addressing, whereas MacOSX doesn't (if I change the NULL in the second
getaddrinfo() to 127.0.0.1, it works fine). This will probably expose some
nasty bugs or design issues in the code in random places. For example, what
about the RDWR sockets that rtsp uses for reading (ffplay), which are set up
for reading to start (no target address known) but are used to send data on
shutdown of the rtsp stream? This means the bind()/socket() precede the
point where the target address family is known, which royally sucks. I'll
have to re-engineer the code a bit to take better defaults into account.

However... I decided to have a look at this getaddrinfo() stuff, and the
> first thing that linux manpages say is "creates one or more socket address
> structures that can be used by the bind(2) and connect(2)". sendto() is
> not mentioned. So, I am wondering if an address prepared by getaddrinfo()
> can be used by sendto() or not (it works on Linux, but maybe it is not
> required to work?).


They're the same, these are just examples.

Even after reading Nicolas message, I still do not understand why the good
> old way of filling sockaddr structures should be replaced with this...


Because the size is not the same (28 for ipv6 vs. 16 for ipv4, of which only
8 are used) and the address doesn't fit an integer (so at the very least
you'd need memcpy instead of x.sin_addr.s_addr=htonl(X)): ipv4 addresses are
4 byte, ipv6 is 16 byte. Besides, the offset of the address in the sockaddr
struct is different (4 for ipv4, vs. 8 for ipv6). This is the most portable
they could come up with, apparently... Anyway, we have to live with what we
got.

Ronald