Pinging a UDP port is kind of tricky, since there are no connections, per se. If you don't have control over the remote host, then you might never really know whether your UDP datagrams are actually being received. I assume you already know whether the remote host is reachable, via ping, traceroute, mtr, etc. (If not, check that first!)
Next, since you don't have netcat, you'll need some way of generating UDP packets.
The bash shell sends UDP packets when you redirect data to the special device /dev/udp/host/port. For example:
#!/bin/bash
host="10.10.10.10"
port=12345
echo "PING" >/dev/udp/$host/$port
Python, of course, is also fully capable of UDP, e.g.
#!/bin/python
import socket
host="10.10.10.10"
port=12345
udp_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udp_sock.sendto('PING', (host, port))
Regardless of how you contrive to generate your UDP "ping" packet, you'll want to know whether the target received it. If the target port is open (i.e. a service is listening at the given port), then what happens will be application-defined. Hopefully, you will notice some behaviour or indication from the remote system.
If the target port is closed (i.e. no service is listening at that port), then you should get an ICMP error packet back in response. Use your favourite wire-level network sniffer to watch for it. Or, perhaps your HP-UX system logs ICMP errors somewhere (sorry, I don't have any experience with HP-UX).
Unfortunately, if the target is firewalled, you may not get a response when the target port is closed. The only surefire way to know if the remote host is responsive is to run your UDP-data-dependent application and watch the network traffic.
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.
Best Answer
There is no such thing as an "open" UDP port, at least not in the sense most people are used to think (which is answering something like "OK, I've accepted your connection"). UDP is session-less, so "a port" (read: the UDP protocol in the operating system IP stack) will never respond "success" on its own.
UDP ports only have two states: listening or not. That usually translates to "having a socket open on it by a process" or "not having any socket open". The latter case should be easy to detect since the system should respond with an ICMP Destination Unreachable packet with code=3 (Port unreachable). Unfortunately many firewalls could drop those packets so if you don't get anything back you don't know for sure if the port is in this state or not. And let's not forget that ICMP is session-less too and doesn't do retransmissions: the Port Unreachable packet could very well be lost somewhere on the net.
A UDP port in the "listening" state may not respond at all (the process listening on it just receives the packet and doesn't transmit anything) or it could send something back (if the process does act upon reception and if it acts by responding via UDP to the original sender IP:port). So again, you never know for sure what's the state if you don't get anything back.
You say you can have control of the receiving host: that makes you able to construct your own protocol to check UDP port reachability: just put a process on the receiving host that'll listen on the given UDP port and respond back (or send you an email, or just freak out and
unlink()everything on the host file system... anything that'll trigger your attention will do).