[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
Ronald S. Bultje
Mon Sep 27 18:41:39 CEST 2010
On Mon, Sep 27, 2010 at 12:24 PM, Martin Storsj? <martin at martin.st> wrote:
> 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's suggestion (I think) is to do it in the application. Not in
udp.c. It is perfectly valid for a packet to come from another source
in some situations.
More information about the ffmpeg-devel