Thanks for the very full answer, Andy.
My datagrams are getting through, now that I know more about what I'm
doing. Port 10000 is all there for me to use.
This list gave me really prompt and accurate help in response to my
question.
Ian.
On 10/02/2021 1:51 pm, Andy Smith wrote:
> Hi Ian,
>
> On Wed, Feb 10, 2021 at 12:50:41PM +0000, Ian Bowden wrote:
>> I'm planning to install software on my VPS, which requires incoming UDP on
>> port 10000.
> Note that quite a few network providers block weird UDP traffic
> because they think it might be used for denial of service attacks.
> It is quite possible for some entity in the middle to drop your
> traffic and as you are not a direct customer of it, it can be hard
> to resolve.
>
>> My iptables is set to allow incoming udp on that port, but it remains closed
>> to the outside world.
> There's no such thing as an open UDP port; UDP is a one way
> communications protocol with no inherent signalling so (unlike TCP)
> there is no response expected to an incoming UDP datagram and no way
> for the sender to tell it actually arrived at the other end.
>
> If there is nothing listening at the destination host then the
> destination host MIGHT send back an ICMP Destination Unreachable
> message, but equally it might just not do anything at all. Also any
> intermediary firewall may decide to silently drop the datagram.
>
> It is expected that any application using UDP should do its own
> checking inside its own protocol, like expecting some sort of
> response or acknowledgement back.
>
>> I've set up a simple listener on port 10000
> How? This may not have been done correctly. Here's how to do it
> with netcat:
>
> $ nc -ul 10000
>
> At the other (client) side:
>
> $ nc -u <your bitfolk IP> 10000
> type some stuff here, see it appear other side
>
>> then tested using a web service for port checking, and I've tested
>> using telnet from two other locations.
> As Alarig pointed out, telnet is a TCP application so you probably
> weren't testing against your UDP listener. It seems likely that the
> web site you used worked similarly. What was it?
>
> If you find that your UDP datagrams don't get through, I don't think
> you can diagnose where with a normal traceroute, You can do it with
> OpenBSD netcat (available in Debian/Ubuntu as netcat-openbsd) by
> setting max TTL higher and higher and seeing which hosts respond
> with an ICMP Time Exceeded message:
>
> In one window of client look for ICMP Time Exceeded messages:
>
> $ sudo tcpdump -vpni eth0 'dst host <your IP> and icmp and icmp[icmptype] = 11'
>
> In other window, send a datagram with a max TTL of 1 (I'll use one
> of my IPs and a port of 53 because I know there's something
> listening there):
>
> nc -uv -M 1 172.104.29.216 53
>
> Watch tcpdump see a message:
>
> 13:46:36.901339 IP (tos 0xc0, ttl 255, id 63728, offset 0, flags [none], proto ICMP (1), length 56)
> 85.119.80.3 > 85.119.80.29: ICMP time exceeded in-transit, length 36
>
> First hop was 85.119.80.3.
>
> Set max TTL 2, repeat.
>
> nc -uv -M 2 172.104.29.216 53
>
> 13:49:03.186759 IP (tos 0xc0, ttl 254, id 203, offset 0, flags [none], proto ICMP (1), length 56)
> 194.153.169.238 > 85.119.80.29: ICMP time exceeded in-transit, length 36
>
> Next hop was 172.104.29.216
>
> And so on. If some hop is dropping UDP datagrams you will stop
> getting ICMP type 11 messages beyond that point.
>
> Cheers,
> Andy
>
>
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
