Re: bind() allowed to non-local addresses

From: Matt Peterson (mpeterson@calderasystems.com)
Date: Wed Oct 18 2000 - 18:20:22 EST


kuznet@ms2.inr.ac.ru wrote:
>
> Hello!
>
> > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> > address. The correct behavior should be a return code of -1 with errno
> > set to EADDRNOTAVAIL.
>
> You can bind to any address, it is your right. You will not able
> to receive on or to send from such socket until address will become
> really local.
>
> Such bind is allowed because the address can be dynamic.
> Nobody wants that a service did not start only because
> the moment of start address was temporarily off-line.
>
> Alexey

This issue here is mostly one of compatibility and standards
compliance. You may not be able to obtain the Posix draft P1003.1g but
you should be able to see XNS Issue 5.2 which defines the
industry-standard Open Systems interfaces to communications services
(including Sockets). You might be required to supply name and email
address to see the free online copy:

http://www.opengroup.org/onlinepubs/009619199/bind.htm#tagcjh_03_03

According to the specs and numerous implementations, looks like the way
bind() is supposed to work is that it returns EADDRNOTAVAIL if the
specified address is not available from the local machine rather than
waiting for a recv() or send() to fail. Many developers working on
software ports have felt the pain of loose interpretations of the
Sockets interface. This divergence would add yet another headache.

Your argument for supporting dynamic interfaces is valid, I really like
the idea of being able to bind to an interface that is not up yet. I can
definitely see where this would be helpful -- too bad is is not part of
the spec. What I don't like about it is that it may break existing
applications. Is the Socket spec so loose that Linux 2.4 can be
comfortable in its current condition? I hope not.

Since it is possible that this "bug" un-repairably breaks the
portability of our application (a Java virtual machine) to the new
kernel, I suspect that there may be other applications that it breaks
too.

Assuming that my "compatibility argument" is not considered valid. What
I really need is some good ammunition for going back to Sun to ask them
to change the JRE spec -- like some significant kernel features or Linux
applications that relies on this new bind() behavior.

-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
mpeterson@caldera.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:14 EST