2

In a VPS (webfaction) I opened a port 14152 and I am running an application which is listening connections on that port, this is the output of netstat -putan | grep 14152

udp6       0      0 :::14152         :::*        79238/./server.x86_

So is this server.86 (.net code) listening on 0.0.0.0:14152? on ipv6 port type udp? I am not sure how to confirm it.

If I have a client application which is trying to connect to this port would it work with ipv4? or it has to be ipv6?

I cannot find anything to configure webfaction to listen through ipv4 which is strange.

lapinkoira
  • 191
  • 2
  • 8
  • 1
    This question is somewhat unclear. Are you asking how to tell whether a listening socket is set up as dual stack or IPv6-only? – kasperd Apr 10 '18 at 23:18
  • Yes, I have a plug and play server which the installation on the VPS is pretty straightforward, just copy it and run it ./ but doing a netstat I am not sure wether an ipv4 client would have troubles connecting to this socket – lapinkoira Apr 11 '18 at 07:45

2 Answers2

2

So is this server.86 (.net code) listening on 0.0.0.0:14152?

If you have provided the complete output from that command, then no. Twice over if being overly technical.

First, in a technical sense, UDP doesn't have a "listen" system call, so UDP will never listen, it will only receive. However you are likely asking in a more general sense, so...

Second, two pieces of information in the output you provide show that this is an IPv6 socket. The udp6 that starts the line signifies this is IPv6 UDP socket as opposed to an IPv4 UDP socket.

Is UDP different between IPv4 and IPv6? No. So why the difference? The socket is tied to both L3 and L4 addressing; this simply helps the user to more easily distinguish IPv4 and IPv6 sockets when viewing the output (or using sort, grep, etc).

Then you have :::14152 which clearly shows an IPv6 address. How so? Well, with both IPv4 and IPv6 the trailing :<port> indicates the port portion of the socket and removing this section of the socket leaves the IP address. In this case you get :: which is the "undefined" IPv6 address of all zeroes.

If you aren't familiar with IPv6 addressing, there are several rules that are allowed to make them more humanly readable when possible. The one in play here is called "Zero Compression" and allows the use of "::" to represent "one or more groups of 16 bits of zeros" (RFC 5952 - although section 4.2.2 further specifies it should only apply to more than one group). So an address of just :: as indicated in the output is the address of all zeroes.

on ipv6 port type udp?

Exactly.

If I have a client application which is trying to connect to this port would it work with ipv4? or it has to be ipv6?

Again, if the output you gave is complete, there is no socket for 0.0.0.0:14152. Therefore nothing set to receive IPv4 UDP on port 14152. So no, IPv4 should not work. The only way it might work if there was some sort of 6-to-4 translation (i.e. NAT-PT/NAT64) in play somewhere converting the IPv4 traffic to IPv6 traffic.

Community
  • 1
YLearn
  • 1,247
  • 7
  • 17
  • The output of the command is complete. So as far as I have understood the socket is not listening on 0.0.0.0 so, if my VPS ipv4 is for example 11.22.33.44 and I tried to telnet 11.22.33.44 14152 its normal it would timeout – lapinkoira Apr 11 '18 at 07:46
  • Linux is single-stack and a listen or receive on ::0 will handle both IP4 and IP6 connections (TCP) or packets (UDP) 'normally' but this can be changed. See https://serverfault.com/questions/21657/semantics-of-and-0-0-0-0-in-dual-stack-oses – dave_thompson_085 Apr 11 '18 at 08:55
  • 1
    "_Is UDP different between IPv4 and IPv6? No._" Well, there is one difference that can be important. For IPv4, the UDP checksum is _optional_, but it is _required_ for UDP on IPv6. I saw where this really messed up a programmer who kept setting the UDP checksum to `0` when using IPv6, just as he had always done for IPv4, but he did not understand why it would not work. – Ron Maupin Dec 31 '20 at 03:18
0

A properly written IPv6 client using udp will be able to interact with your server, (if there is no drop of packets), which is 'listening' on that port. But it's not a listen() call. It differs from tcp.

See these articles:

https://stackoverflow.com/questions/8194323/why-the-listen-function-call-is-not-needed-when-use-udp-socket

https://unix.stackexchange.com/questions/228506/how-to-verify-a-service-is-listening-on-both-ipv4-and-ipv6

There's no guarantee this will for IPv4 based on that output. Ultimately you'll want to test all your use cases.

jouell
  • 621
  • 1
  • 5
  • 20