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?

  • Sounds like a firewall issue to me. Do you have any software or hardware firewalls? – Pitto Apr 30 '13 at 15:58
  • You can't ask the customer what their network configuration is set to? – Ramhound Apr 30 '13 at 16:05
  • @Ramhound, ideally not. I don't want to have to dig into a potential customer's router settings every time I want to demo my product :) – Gili Apr 30 '13 at 20:49
  • 2
    Guys, please explain your negative votes, otherwise I can't respond. – Gili Apr 30 '13 at 20:50

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.

  • Your remote command fails for me. The manpage says for -l, “It is an error to use this option in conjunction with the -p, -s, or -z options.”, so I've corrected the command to one that I've tested to work. Also, I've changed ‘ip’ to ‘addr’ because hostnames can also be used, and are in a sense an ‘address’. – James Haigh Jun 18 '13 at 0:07
  • @JamesHaigh: I agree with you on the addr vs. ip point. But now with your command, I get an error: listen needs -p arg (I tested my commands given in the answer, too ;)). There are various nc's out there, if you give some more details like nc version and/or your distro, I will add a note to my answer. – mpy Jun 18 '13 at 14:00
  • Oh right, it's a shame that they are not mutually compatible! :-( Ok, so my remote machine is Debian. The default nc command is symlink /bin/nc -> /etc/alternatives/nc -> /bin/nc.openbsd provided by Debian package netcat-openbsd. My local Ubuntu machine also has nc.openbsd by default. Neither will accept -l -p. I have also installed ncat on both machines from the nmap Ubuntu/Debian package. On the older Debian machine, ncat refuses -l -p, but ncat on Ubuntu accepts both ways. Though the Debian version must be ancient since it annoyingly doesn't have the --sctp option. :-/ – James Haigh Jun 18 '13 at 20:23
  • P.s. What is your distro, and nc variant? I notice that there is a ‘netcat-traditional’ package as well, but I haven't tried that. – James Haigh Jun 18 '13 at 20:30
  • @JamesHaigh: I indeed use netcat-traditional (v 1.10-38) as it ships with debian. Thanks for your hint, I included now both variants into the answer. – mpy Jun 19 '13 at 10:37

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>
  • 1
    This is the real answer. It requires having server access on the other side. But it gives you direct packet loss feedback. And you can also use it test TCP bandwidth. – DragonFax Jul 5 '17 at 17:12

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.


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%)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.