"No address associated with hostname" does not make sense

[dash9]

I was trying to connect to an IP:PORT address, and I got this error message:

Code:

Resolving
Sys_StringToSockaddr: Error resolving : No address associated with hostname
Couldn't resolve address
131.155.141.68:27960 resolved to 131.155.141.68:27960
Resolving
Sys_StringToSockaddr: Error resolving : No address associated with hostname
Couldn't resolve address
Resolving
Sys_StringToSockaddr: Error resolving : No address associated with hostname
Couldn't resolve address
Resolving

What exactly is it trying to say?

[Falkland]

Maybe it deals with static assigned hostnames

In /etc/hosts u can associate an address to a name and skips the call to the DNS server :

Code:

...
127.0.0.1 localhost
76.74.252.88 openarena.ws
...

I've heavily used this trick for putting all ads-pr0n sites pointing to 127.0.0.1 ( local interface )

Code:

127.0.0.1 www.badsite.com
127.0.0.1 www.badsite2.com
...

Every program accessing the net will not try to resolv a name if the association NAME-ADDRESS is stored in /etc/hosts ( this deal with the beginning of the internet , when hosts were too few to have a DNS and every hosts knew addresses of all the other relatively few hosts. DNS has been introduced many years later , but /etc/hosts was mantained in all systems for compatibility reasons )

Or maybe the engine interprets the server's address as a hostname instead of an address and tries first to find it on /etc/hosts and then to resolv it through one or more DNS query/queries . Of course the queries fail and that produces the mex "No address associated with hostname"

[dash9]

Maybe it deals with static assigned hostnames

No.

Or maybe the engine interprets the server's address as a hostname instead of an address and tries first to find it on /etc/hosts and then to resolv it through one or more DNS query/queries . Of course the queries fail and that produces the mex "No address associated with hostname"

It's a bug, then?

[davidd]

I see you are trying to connect to my server.
I have had some similar problems. The hostname dragon.zvdk.nl or dragon.stack.nl have an ipv6 address assigned to them as well as an ipv4
so when i type /connect dragon.stack.nl:27690 it tries ipv6, and i dont always have my ipv6 configured failing the connect.
If i have ipv6 enabled i can play on it via ip6.

[Falkland]

It's a bug, then?

why do u ask it if u seem to know the answer  ?

[dash9]

It's a bug, then?

why do u ask it if u seem to know the answer  ?

I take that as a yes.

I was actually asking for details. I want to know exactly what the problem is. Maybe the text of the error is wrong, or maybe the text is correct, but OA displays it for the wrong error..

[Falkland]

I was actually asking for details.

And I was taking time for lurking the code

The file where getting a look at is code/qcommon/net_ip.c ... and the error is generated because it tries to resolv an IPv4 address as a FQN but I'm surprising of how the client is able to exit from the loop generated by the resolv fault ( in the log u've posted : 131.155.141.68:27960 resolved to 131.155.141.68:27960 ) and successfully connects to the server

[davidd]

Ow is that the question?
I think it is a problem reaching your dns server.
ioquake apperently does not check itself if something is an ip, but most dns servers will just return the ip if you send it a xxx.xxx.xxx.xxx like string like it is a hostname, so as long as your dns server works you can connect that way. If you add them in your hosts file ( /etc/hosts  on linux) you will not have this problem.

[dash9]

Ow is that the question?
I think it is a problem reaching your dns server.
ioquake apperently does not check itself if something is an ip, but most dns servers will just return the ip if you send it a xxx.xxx.xxx.xxx like string like it is a hostname, so as long as your dns server works you can connect that way. If you add them in your hosts file ( /etc/hosts  on linux) you will not have this problem.

That explains it. That's dumb. :/

[Falkland]

I think it is a problem reaching your dns server.
ioquake apperently does not check itself if something is an ip, but most dns servers will just return the ip if you send it a xxx.xxx.xxx.xxx like string like it is a hostname, so as long as your dns server works you can connect that way. If you add them in your hosts file ( /etc/hosts  on linux) you will not have this problem.

Uhm ... I think u are right : I've made a few of euristic tests ( half while using routers DNS which queries my ISP DNS , half while putting the ISP DNS IP in the /etc/resolv.conf ) ... If the DNS is specified in the /etc/resolv.conf of the actual machine , it spams less mex errors ( 2 mexs instead of 3 or 4 ) ... so it's a DNS query latency problem. And yes , ioquake3 doesn't check if it's an IP or a FQN.