8

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?

Improve this question
4
  • Sounds like a firewall issue to me. Do you have any software or hardware firewalls?
    – Pitto
    Apr 30, 2013 at 15:58
  • You can't ask the customer what their network configuration is set to?
    – Ramhound
    Apr 30, 2013 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, 2013 at 20:49
  • 2
    Guys, please explain your negative votes, otherwise I can't respond.
    – Gili
    Apr 30, 2013 at 20:50

4 Answers 4

Reset to default
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.

Improve this answer
9
  • 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, 2013 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, 2013 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, 2013 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, 2013 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, 2013 at 10:37
15

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>
Improve this answer
1
  • 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, 2017 at 17:12
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%)
Improve this answer
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.

Improve this answer

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.