POSIX ETIMEDOUT when opening a socket to a DNS server

[Cecil Westerhof]

I defined the following proc:
proc ::dcblUtilities::getInternetConnection {{IPAddress 208.67.222.222}} {
try {
set fd [socket ${IPAddress} 53]
close $fd
set errorMsg {}
set status Connected
} on error msg {
set notConnRegexp "\^couldn't open socket: network is unreachable"
if {[regexp ${notConnRegexp} ${::errorInfo}]} {
set errorMsg {}
set status {NOT connected}
} else {
set errorMsg ${::errorCode}
set status {Unexpected error}
}
}
list ${status} ${errorMsg}
}

Today I got an 'Unexpected error' with errorMsg:
POSIX ETIMEDOUT {connection timed out}

I interpret this as: there was an internet connection, but the DNS
server was not reachable. Is this a correct interpretation, or could
it still be that I did not have an internet connection?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Cecil Westerhof]

Cecil Westerhof <Ce...@decebal.nl> writes:

> I defined the following proc:
> proc ::dcblUtilities::getInternetConnection {{IPAddress 208.67.222.222}} {
> try {
> set fd [socket ${IPAddress} 53]
> close $fd
> set errorMsg {}
> set status Connected
> } on error msg {
> set notConnRegexp "\^couldn't open socket: network is unreachable"
> if {[regexp ${notConnRegexp} ${::errorInfo}]} {
> set errorMsg {}
> set status {NOT connected}
> } else {
> set errorMsg ${::errorCode}
> set status {Unexpected error}
> }
> }
> list ${status} ${errorMsg}
> }
>
> Today I got an 'Unexpected error' with errorMsg:
> POSIX ETIMEDOUT {connection timed out}
>
> I interpret this as: there was an internet connection, but the DNS
> server was not reachable. Is this a correct interpretation, or could
> it still be that I did not have an internet connection?

I should have given a little bit more information. It has been running
for over a month. I have almost 50.000 measurements and this only
happened once.

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> I defined the following proc:
> proc ::dcblUtilities::getInternetConnection {{IPAddress 208.67.222.222}} {
> try {
> set fd [socket ${IPAddress} 53]
> close $fd
> set errorMsg {}
> set status Connected
> } on error msg {
> set notConnRegexp "\^couldn't open socket: network is unreachable"
> if {[regexp ${notConnRegexp} ${::errorInfo}]} {
> set errorMsg {}
> set status {NOT connected}
> } else {
> set errorMsg ${::errorCode}
> set status {Unexpected error}
> }
> }
> list ${status} ${errorMsg}
> }
>
> Today I got an 'Unexpected error' with errorMsg:
> POSIX ETIMEDOUT {connection timed out}
>
> I interpret this as: there was an internet connection, but the DNS
> server was not reachable. Is this a correct interpretation, or could
> it still be that I did not have an internet connection?

DNS is carried over UDP.

So the most that you know is:

1) an outgoing UDP packet, addressed to the destination, was
transmitted

2) no reply packet arrived (within the window of the timeout)

The 'reason' for "no reply packet arrived" can not be determined by the
networking layer (and by extension, your code, nor you).

It could be the outgoing UDP packet was dropped somewhere along the
way.

It could be that the reply UDP packet was dropped somewhere along the
way.

The two above could be indicators of buffer bloat somewhere in the
path.

It could be that some link along the path was down (but not returning
"no route to host" replies).

It could be that a link along the path was down, and was returning "no
route" replies, but the no route reply was itself dropped somewhere.

It could be that the DNS server at the far end was simply hung (such
that the packet went all the way there, but was never handled).

And we could probably spin a hundred more possible reasons why.

[Adam Jensen]

On Thu, 27 Sep 2018 19:50:31 +0000, Rich wrote:

> The 'reason' for "no reply packet arrived" can not be determined by the
> networking layer (and by extension, your code, nor you).

I suppose if a "no reply packet arrived" condition occurs the program
might try some diagnostic checks that might shed some light on the cause
of the problem - for example, the network might not be reachable at the
time.

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:

> Cecil Westerhof <Ce...@decebal.nl> writes:
>> Today I got an 'Unexpected error' with errorMsg:
>> POSIX ETIMEDOUT {connection timed out}
>>
>> I interpret this as: there was an internet connection, but the DNS
>> server was not reachable. Is this a correct interpretation, or
>> could it still be that I did not have an internet connection?
>
> I should have given a little bit more information. It has been
> running for over a month. I have almost 50.000 measurements and this
> only happened once.

It only takes one dropped packet to create.

Given a 1:50,000 occurrence right now, you would have a reasonable
basis to conclude that at this moment, it could be classed in the
"ignore" bin.

[Ralf Fassel]

* Rich <ri...@example.invalid>

| Cecil Westerhof <Ce...@decebal.nl> wrote:
| > I defined the following proc:
| > proc ::dcblUtilities::getInternetConnection {{IPAddress 208.67.222.222}} {
| > try {
| > set fd [socket ${IPAddress} 53]

--<snip-snip>--

>
| DNS is carried over UDP.

Sorry if I'm being dense here, but does not 'socket' always opens a
*TCP* connection, regardless of the port?

man n socket

NAME
socket - Open a TCP network connection

So while the resolution of hostnames on the OS level may work via UDP,
the TCL [socket] command should try to establish a *TCP* connection, and
that may simply time out if the server is not reachable...

| > Today I got an 'Unexpected error' with errorMsg:
| > POSIX ETIMEDOUT {connection timed out}

R'

[Rich]

Ralf Fassel <ral...@gmx.de> wrote:
> * Rich <ri...@example.invalid>
> | Cecil Westerhof <Ce...@decebal.nl> wrote:
> | > I defined the following proc:
> | > proc ::dcblUtilities::getInternetConnection {{IPAddress 208.67.222.222}} {
> | > try {
> | > set fd [socket ${IPAddress} 53]
> --<snip-snip>--
>>
> | DNS is carried over UDP.
>
> Sorry if I'm being dense here, but does not 'socket' always opens a
> *TCP* connection, regardless of the port?

No, you are not. I didn't read his code very well and instead went
with his "socket to a DNS server" subject line to latch onto "DNS" to
mean he was using UDP.

In which case I'm a bit surprised this worked, not all DNS servers even
bother to listen on TCP port 53 for anything.

> So while the resolution of hostnames on the OS level may work via
> UDP, the TCL [socket] command should try to establish a *TCP*
> connection, and that may simply time out if the server is not
> reachable...

Right. The underlying point in the rest of my message does still
apply, in that there are plural possible reasons for a timeout such
that a timeout simply means "nothing happend for a defined time period"
but does not tell one 'why' nothing happened.