Raw UDP packets not being picked up by udpsrc

[twallis]

Hello,

I know that this is a semi-common issue, at least for gstreamer beginners like myself, however I am running into an interesting issue on my embedded linux application.  Using gstreamer 1.6.3 (due to sdk/support reasons from TI) I am trying to receive an mjpg stream from my ip camera.  When I check the tcpdump on hte port the camera is sending to, I see it fine, and when I launch

gst-launch-1.0 udpsrc port=1234, and try to send the stream to a file-sink, I receive nothing in the file I'm trying to send it to.  I've already read through the solution found here:

http://gstreamer-devel.966125.n4.nabble.com/udpsrc-has-no-data-for-windows-td4678014.html

and ran into significant errors attempting to install 1.8.1 (and newer) from source.  As that's the other issue, my embedded system does not have dpkg, or apt!  Everything must be compiled from source!  

Thank you for your help

[Peter Maersk-Moller-2]

3 things (actually a lot more) can prevent you from receiving UDP packets that you can see arrive with tcpdump:

1. UDP packets arriving on an interface from a source where the route to the source is routed via another interface.
2. iptables fw-rule.
3. Multiple listeners on same port without SO_REUSEADDR/SO_REUSEPORT. See also http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

Regards

Peter Maersk-Moller

On Thu, Feb 9, 2017 at 9:33 PM, twallis <[hidden email]> wrote:

Hello,

I know that this is a semi-common issue, at least for gstreamer beginners
like myself, however I am running into an interesting issue on my embedded
linux application.  Using gstreamer 1.6.3 (due to sdk/support reasons from
TI) I am trying to receive an mjpg stream from my ip camera.  When I check
the tcpdump on hte port the camera is sending to, I see it fine, and when I
launch

gst-launch-1.0 udpsrc port=1234, and try to send the stream to a file-sink,
I receive nothing in the file I'm trying to send it to.  I've already read
through the solution found here:

http://gstreamer-devel.966125.n4.nabble.com/udpsrc-has-no-data-for-windows-td4678014.html

and ran into significant errors attempting to install 1.8.1 (and newer) from
source.  As that's the other issue, my embedded system does not have dpkg,
or apt!  Everything must be compiled from source!

Thank you for your help




--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Raw-UDP-packets-not-being-picked-up-by-udpsrc-tp4681796.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[twallis]

As far as the system infrastructure goes, there is a direct ethernet connection between the sender and receiver, and no other traffic is going over that ethernet interface (there are two ethernet connections on the receiver).

After configuring the iptable rules to allow all UDP traffic over the port, there was no difference compared to the default iptables file I was working with.  

After doing some packet sniffing, it appears somewhere down the line the packets have become corrupted.  But only on the receiver side, as transferring the UDP stream to a separate host results in significantly better video.

[Tim Müller]

Hi,

Maybe check with netstat -lnp what interfaces/ports udpsrc is listening
on? A common issue is for example that 'localhost' resolves to the IPv6
loopback address but the packets are sent to IPv4 (127.0.0.1), although
in your case you say data comes from somewhere else of course. It might
still not be listening on the right interface though.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peter Maersk-Moller-2]

How do you determine that the udp packets are corrupted?

First step is to bring down the second interface. and ensure your routing table route out to the source of your IP packets through the receiving interface.

Next step is to allow everything through iptables.

Do you then still receive no packets using udpsrc ?

P

On Fri, Feb 10, 2017 at 4:28 PM, twallis <[hidden email]> wrote:

As far as the system infrastructure goes, there is a direct ethernet
connection between the sender and receiver, and no other traffic is going
over that ethernet interface (there are two ethernet connections on the
receiver).

After configuring the iptable rules to allow all UDP traffic over the port,
there was no difference compared to the default iptables file I was working
with.

After doing some packet sniffing, it appears somewhere down the line the
packets have become corrupted.  But only on the receiver side, as
transferring the UDP stream to a separate host results in significantly
better video.



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Raw-UDP-packets-not-being-picked-up-by-udpsrc-tp4681796p4681824.html

Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[twallis]

After a netstat -nl call I received the following result, where port 1234 is the port I opened on udpsrc.  The netstat result seems to say that gstreamer isn't listening to that port.  Or, and please bear with me as networking is not my strong suit, that the packets are simply being dropped, despite opening port 1234 to udp with iptables



The packet payload appears to be corrupted as when the packets are read from a pc they can be reconstructed into mjpeg, and when the packets I receive (from tcpdump) are reconstructed in the same way, it results in corrupted video.  

[twallis]

Sorry, the image doesn't appear to have uploaded, so here's a link to the screencap

http://imgur.com/a/i0m8s

[twallis]

After doing some more work on this with multicast settings "multicast-iface=eth0" for the udp stream input, I'm still not seeing results.