[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:51:59 CEST 2010
On Mon, 27 Sep 2010, Ronald S. Bultje wrote:
> 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
There are many suggestions by Luca in that thread, and one of them is
exactly this what this patch is. There are other suggestions too, that
well may be architecturally way too complicated (i.e. ugly) compared to
what is gained.
> It is perfectly valid for a packet to come from another source
> in some situations.
Yes, in some situations. If we want that to be the default, that's
probably quite ok, then we'd just have to enable this "only accept packets
coming from the peer we've specified in the URL" feature with some
flag/option. Still fits well into the design, and is very very neat
compared to all the solutions discussed later in issue1688.
More information about the ffmpeg-devel