[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

[Martin Storsjö]

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 
suggested.

// Martin