1

I have an Ubuntu Server 10.04 application I've developed that receives messages over a UDP port. The ultimate purpose of this application is to receive messages sent from workers' 3G modems out in the field.

If use netcat on either another ubuntu Server or my Vista laptop (both on the same LAN as my test machine) to send a message, the message arrives correctly and appears in my application. However, if I go out to my car and use its 3G modem to send a message from the same Vista laptop, it doesn't work. If I run tcpdump -A, I see the message arrive correctly, but it's never delivered to my application. Clearly, the OS is the one making the choice not to deliver the messages (else they wouldn't appear in tcpdump nor would my app receive them when coming from local machines). I have not installed any firewall software on this machine, nor am I aware of anything installed by default that would block the traffic.

sudo iptables --list returns 

Chain INPUT (policy ACCEPT)  
target     prot opt source               destination           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I'm not too familiar with iptables, but it looks to me like that's telling it to not do anything.

What could be going on that's preventing my messages from being delivered?

Edit with requested information:

My local address is 10.222.110.79/24.

My tcpdump command is

sudo  tcpdump -i eth0 udp port 6203 -A -f -n

For the messages sent internally, tcpdump is showing 

IP 10.222.110.75.60856 > 10.222.110.79.6203: UDP

The ones sent externally show 

IP 108.116.172.0.3072 > 10.222.110.79.6203: UDP

(I assume the second message is reflecting the corporate firewall rerouting the message. I'm sending it to our public IP, and the firewall has a (temporary) rule that sends all UDP 6203 traffic to my dev box.)

This is my netcat command

nc -u 10.222.110.79 6203

And then I just type stuff in and hit enter to send. From outside, I replace the IP with our public IP, but don't make any other changes.

Improve this question
6
  • You have correctly interpreted your iptables configuration. What does the network configuration of your local system look like (ip/netmask)? What does the ip address information look like on the packets you're capturing with tcpdump? What exactly does your netcat command line look like?
    – larsks
    Jan 13, 2011 at 1:02
  • When you use your 3G modem, if traffic arrives, try netcat as daemon on the port you app is listening (nc -ul <port> - you will have to stop you app), and check if messages are seen (just to double check there is no problem with your app handling external traffic).
    – Torian
    Jan 13, 2011 at 1:27
  • Thanks for the update...unfortunately, nothing there stands out. I have a new question for you: are you certain that the application is not seeing the packet? Specifically, I am curious if you have determined that the problem is with the request rather than the reply. Your questions suggests that you have verified that your application isn't seeing the incoming request, but I wanted to make sure.
    – larsks
    Jan 13, 2011 at 1:48
  • Yes, I'm sure. The first line of my message received event handler is printf("Got a message\n");, so if it makes it to my app, I'll know about it. I suppose there could be a bug in my UDP library that is only manifesting when messages come from outside. Would be a pretty strange one (especially since the destination IP address has been swapped out by the time it gets to my machine, so the library really shouldn't know the difference), but stranger things have happened. Thanks for the help.
    – Warren Pena
    Jan 13, 2011 at 1:55
  • I tried using netcat -l to receive messages on the UDP socket outside of my application, and it didn't receive them either, so I don't think it's a bug in my UDP library.
    – Warren Pena
    Jan 13, 2011 at 16:08

2 Answers 2

Reset to default
0

I would start by removing 3G from the equation. It sounds like you have already done this, and have found it to work. If so, the 3G service may be blocking the UDP traffic. Alternatively, the UDP packets may simply not be surviving, UDP is designed for high-throughput, low-availability. The volatile 3G network is precisely the environment that TCP was designed for and is sub-optimal for UDP applications.

Improve this answer
1
  • The UDP traffic is surviving its trip through the cell network, as it's appearing in tcpdump on the server. My application is resistant to the occasional dropped message, and being able to guarantee the data usage of each message is valuable to my customers.
    – Warren Pena
    Jan 13, 2011 at 1:38
0

It looks like the problem was actually caused by Netcat itself. Initially, the 3G modem was misconfigured, which is why I fired up Netcat in the first place. I found out that, even though UDP is connectionless, Netcat does some funky stuff to simulate being connected over UDP. I won't claim to fully understand it, but somehow this was causing the data to not be delivered. Eventually, I ended up just letting the 3G modem do its thing without netcat running, and it worked. The data was delivered correctly. As soon as I fired up netcat sending test data again, the data stopped being delivered. Kill netcat, and it starts being delivered again. Bizarre.

Thanks for the help, everyone.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .