11

I'm got a video streaming application that runs fine in my office but fails miserably at the customer location. The symptom is that every couple of seconds, I stop receiving UDP packets for 2 seconds, then the stream resumes as if nothing is wrong.

I ran http://www.pingtest.net/ at the customer location and it came back excellent. No dropped packets and low latency. The only difference I noticed between our two locations is that ping google.ca times-out at their location but works in mine.

How do I test whether the network I am on blocks incoming UDP packets? Is there a way for me to isolate who is dropping the packets?

Gili
  • 1,901

4 Answers4

18

at server side, establish a UPD server with

iperf -s -u

at client side, check UDP connection with

iperf -u -c <IP Address of Server>
ckarrie
  • 181
4

You can try to establish a UDP connection with netcat.

On a machine A outside the consumer's network run:

nc -u -l -p 1234            # if using netcat-traditional
nc -u -l 1234               # if using netcat-openbsd (as pointed out by @JamesHaigh)

Note the -u which instructs netcat to use UDP. (And also be aware, that there are different versions of netcat, which will need the -p parameter or not; given are the variants for the two most common(?) ones, both included in Debian.)

On consumer location: nc -u [addr of machine A] 1234.

Try to send send some text, or even better use pipes to send a file between both locations and do a diff afterwards.

mpy
  • 28,816
2

On serverside use 

iperf -u -p <port> -s

On client side use

iperf -u -p <port> -c <domain or ip>

Make sure port allowed on firewall. This will give u a report like this after test

[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams

[  1]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   3.722 ms    1/  893 (0.11%)
Dilushan
  • 21
0

The netcat commands in mpy's answer are useful for diagnostic purposes, but I'm complementing that answer with another approach to your underlying problem.

It may be worth making your application fall back to SCTP, or even TCP. I actually found this question because I was looking for how to reject incoming UDP packets from users using more than their share of the downlink when it is congested, because unlike SCTP and TCP, UDP has no congestion control making it very difficult to prioritise the downlink traffic.

Both SCTP and TCP have congestion control and play nicely with QoS, but SCTP has the additional benefit over TCP that it was designed for real-time streaming applications, making it a good replacement for both TCP and UDP. In effect, SCTP is the best of both of the 2 most common transport protocols.

It can't be a bad idea to have a fallback, rather than to rely on just UDP. Even if you only fall back to TCP, then at least you can say it's working, maybe just not optimally.

James Haigh
  • 614