mapping ICMP codes to Unix errno code numbers

[Erik E. Fair]

I just filed PR kern/47693 which deals with an immediate deficiency
in our ICMP handling - we don't handle unreachable code 13 valid
code as valid. That needs to be fixed ASAP, and the patch pulled
up to both netbsd-6 and netbsd-5.

However, there's an additional semantic issue for programmers: I
believe Unix needs an additional errno code to indicate "remote
permission denied" as distinct from "connection refused" (daemon's
not listening on that port). There are multiple ICMP unreachable
codes which make this semantic error distinction.

I don't think we can use EPERM itself because using EPERM would
likely confuse the programmer/user as to where permission is being
refused: locally or remotely, and that's a key piece of information
needed to diagnose and remedy application failure.

This is something that all the BSDs (and Linux) should do, too.

I suggest:

EPEERPERM (number TBD) "peer refused permission"
or
ERMTPERM (number TBD) "remote host refused permission"

Erik <***@netbsd.org>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Erik E. Fair
I just filed PR kern/47693 which deals with an immediate deficiency
in our ICMP handling - we don't handle unreachable code 13 valid
code as valid. That needs to be fixed ASAP, and the patch pulled
up to both netbsd-6 and netbsd-5.

Just don't do what Linux did and start returning EHOSTUNREACH when transmitting UDP packets if an ICMP Port Unreachable has been received in response to previous messages transmitted on that socket. This is completely useless because the errno mechanism provides no way to communicate *which* packet generated the ICMP response. This is not a problem for TCP sessions, so I think your proposed fix is correct in that case.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lloyd Parkes]

Post by Erik E. Fair
EPEERPERM (number TBD) "peer refused permission"
or
ERMTPERM (number TBD) "remote host refused permission"

How about EACCESS? EACCESS is within the POSIX spec for connect(), but it currently has no documented use for TCP connections. That way we don't need to invent a non-standard error number so the userland code is more portable and the patch may end up being mostly documentation to explain how the use of EACCESS has been extended.

Cheers,
Lloyd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Erik E. Fair
I just filed PR kern/47693 which deals with an immediate deficiency
in our ICMP handling - we don't handle unreachable code 13 valid
code as valid. That needs to be fixed ASAP, and the patch pulled
up to both netbsd-6 and netbsd-5.
However, there's an additional semantic issue for programmers: I
believe Unix needs an additional errno code to indicate "remote
permission denied" as distinct from "connection refused" (daemon's
not listening on that port). There are multiple ICMP unreachable
codes which make this semantic error distinction.

Erik,

How do you know that the administratively prohibited ICMP error
will 100% of the time come from a remote network?

Afterall, it could also be generated by your local firewall or perhaps
even the host itself!

Kind Regards,
Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Erik Fair]

Post by Darren Reed
How do you know that the administratively prohibited ICMP error
will 100% of the time come from a remote network?
Afterall, it could also be generated by your local firewall or perhaps
even the host itself!

And the difference between those cases to the application is … ?

Erik <***@netbsd.org>
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lloyd Parkes]

Post by Erik Fair

Post by Darren Reed
How do you know that the administratively prohibited ICMP error
will 100% of the time come from a remote network?
Afterall, it could also be generated by your local firewall or perhaps
even the host itself!

And the difference between those cases to the application is … ?

Documentation. If the error code is well documented then the application author is less likely to do the wrong thing with it.

Cheers,
Lloyd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Erik Fair

Post by Darren Reed
How do you know that the administratively prohibited ICMP error
will 100% of the time come from a remote network?
Afterall, it could also be generated by your local firewall or perhaps
even the host itself!

And the difference between those cases to the application is … ?

None and that's the point.

It is not possible to tell why the error is generated, so calling
it "remote" when it may not be can be misleading.

Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Erik E. Fair]

Darren, under what conditions will a host generate ICMP to a local
application sending packets?

Erik <***@netbsd.org>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Erik E. Fair
Darren, under what conditions will a host generate ICMP to a local
application sending packets?

When you use a tool such as ipf or npf to block the packet.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de