[FFmpeg-devel] [PATCH] Add code in rtpproto.c/udp.c to test incoming packets against the host/port looked up in rtp/udp_set_remote_url
Mon Sep 27 18:24:54 CEST 2010
On Mon, 27 Sep 2010, Ronald S. Bultje wrote:
> On Mon, Sep 27, 2010 at 12:13 PM, Martin Storsj? <martin at martin.st> wrote:
> > On Mon, 27 Sep 2010, Sam Creasey wrote:
> >> This patch looks somewhat (though not entirely) related to issue 1688,
> >> though I'm attempting to solve a slightly different problem that that
> >> author proposed.
> >> The current ffmpeg source does not look at the source address of
> >> incoming udp/rtp packets (udp uses recv() instead of recvfrom(),
> >> rtpproto uses recvfrom() and discards the from). ?This patch would
> >> check the remote address to match the address from udp_set_remote_url,
> >> and reject the packet unless
> >> *) the specified address was a multicast address
> >> *) the address family is ipv4 or ipv6, and the address and port match
> >> *) the address family is something else (unlikely for udp/rtp, but
> >> might as well let through things we don't know how to test).
> > This looks quite sensible to me.
> > Luca A, Luca B, Ronald, do you think of any situations where this wouldn't
> > be appropriate? Do we need an option for disabling this?
> I need to have a good look at this, this might not be right, see also
> the discussion on the issue tracker earlier...
I read through the issue on roundup, and this is by far the most sane way
of solving that issue, it also is quite the same as one thing Luca A
suggested in that thread:
> If you want to discard packets coming from a "wrong" address, maybe the
> simplest thing to do is to modify udp.c to use recvfrom(), and to
> compare the source address with the address that has been specified
> through udp_set_remote_url().
And that is exactly what this patch does.
Luca A also said:
> (but I imagine this could break stuff in some situation where private
> IP addresses and NAT are used)
I do agree that there might be cases where the remote IP isn't known, but
this seems to be solved by using e.g. rtp://0.0.0.0:4242/ in the patch
More information about the ffmpeg-devel