Overlapped UDP port unreachable errors on Vista x64

168 views
Skip to first unread message

Len Holgate

unread,
Dec 3, 2007, 4:34:25 AM12/3/07
to
When an overlapped WSASendTo to results in a 'port unreachable' ICMP
response from the remote host a pending WSARecvFrom on the socket that
you sent the sendTo from will complete with 0 bytes read and an error
of ERROR_PORT_UNREACHABLE. However, the WSARecvFrom "from address" is
not set as I would expect it to be. The address portion is "correct"
in that it is the address of the host that sent the ICMP port
unreachable but the port is set to the local port rather than the
"remote" port (i.e it's not set to the port that the SendTo was
addressed to on the host that sent the ICMP message). Since the remote
port is included in the ICMP message it seems strange (to me at least)
that this information isn't used to fill in the port in the from
address.

I haven't yet run up VMs to check to see if this behaviour is
different on pre Vista OSs.

Does anyone know if this behaviour is by design or if it's a winsock
bug?

Len Holgate
http://www.lenholgate.com/

David Schwartz

unread,
Dec 5, 2007, 11:41:52 AM12/5/07
to
On Dec 3, 1:34 am, Len Holgate <len.holg...@jetbyte.com> wrote:

> When an overlapped WSASendTo to results in a 'port unreachable' ICMP
> response from the remote host a pending WSARecvFrom on the socket that
> you sent the sendTo from will complete with 0 bytes read and an error
> of ERROR_PORT_UNREACHABLE. However, the WSARecvFrom "from address" is
> not set as I would expect it to be. The address portion is "correct"
> in that it is the address of the host that sent the ICMP port
> unreachable but the port is set to the local port rather than the
> "remote" port (i.e it's not set to the port that the SendTo was
> addressed to on the host that sent the ICMP message). Since the remote
> port is included in the ICMP message it seems strange (to me at least)
> that this information isn't used to fill in the port in the from
> address.

Are you sure that's not just junk that was left there from before? I
would expect that when you get an error, the output parameters are not
set at all and might just have whatever was in them before.

Does any documentation suggest that meaningful values are put in this
field if the operation returns an error? I personally find that quite
surprising.

DS

Len Holgate

unread,
Dec 5, 2007, 2:09:36 PM12/5/07
to
You may be right. I'll do some tests.

However, it would be very useful if the stack actually reported which
port was unreachable (since it knows!). If it isn't going to bother
then why fail an overlapped WSARecvFrom anyway?

Len Holgate

unread,
Dec 5, 2007, 2:33:56 PM12/5/07
to
Well, it doesnt seem to be left over rubbish. I now clear the address
to 0 before issuing any WSARecvFroms and I'm still seeing that the
local address is filled in when the WSARecvFrom returns with
ERROR_PORT_UNREACHABLE...

On Dec 5, 4:41 pm, David Schwartz <dav...@webmaster.com> wrote:

David Schwartz

unread,
Dec 6, 2007, 6:17:18 AM12/6/07
to
On Dec 5, 11:33 am, Len Holgate <len.holg...@jetbyte.com> wrote:

> Well, it doesnt seem to be left over rubbish. I now clear the address
> to 0 before issuing any WSARecvFroms and I'm still seeing that the
> local address is filled in when the WSARecvFrom returns with
> ERROR_PORT_UNREACHABLE...

That's really odd. My guess would be that it does this for no
particular reason, maybe even by accident, and there's no rational
reason to check. If you get an error, there's no reason to expect the
fields to contain valid data.

Your other post brings up a good question -- why report the error? I
can think of no good reason to do so by default, since in most cases
there is nothing you can do with the information and it just wastes
time and cycles.

DS

Len Holgate

unread,
Dec 6, 2007, 12:17:47 PM12/6/07
to
> Your other post brings up a good question -- why report the error? I
> can think of no good reason to do so by default,

True, but it just so happens that in this case I could do something
useful with it which is why I started investigating it...

Reply all
Reply to author
Forward
0 new messages