tjbush / mochiweb

Automatically exported from code.google.com/p/mochiweb
Other
0 stars 0 forks source link

Patch for issue #51 breaks ipv4 listening on FreeBSD and possibly other OSes #56

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Run mochiweb on an ipv6 enabled FreeBSD machine
2. Try to telnet to the ipv4 IP with the port mochiweb is running on

What is the expected output? What do you see instead?

I expect the connection to succeed. The connection fails, or fails over to
the ipv6 IP if you use 'localhost'.

What version of the product are you using? On what operating system?

FreeBSD 7.2 and the latest SVN version of mochiweb (r123).

Please provide any additional information below.

Man inet6(4) says the following about wildvard ipv6 sockets:

If you perform a wildcard bind on an AF_INET6 socket (bind(2) to IPv6
address ::), and there is no wildcard bind AF_INET socket on that TCP/UDP
port, IPv6 traffic as well as IPv4 traffic should be routed to that
AF_INET6 socket.  IPv4 traffic should be seen as if it came from an IPv6
address like ::ffff:10.1.1.1.  This is called an IPv4 mapped address.

But it also says the following:

However, RFC2553 does not define the ordering constraint between calls to
bind(2), nor how IPv4 TCP/UDP port numbers and IPv6 TCP/UDP port numbers
relate to each other (should they be integrated or separated).  Implemented
behavior is very different from kernel to kernel.  Therefore, it is unwise
to rely too much upon the behavior of AF_INET6 wildcard bind sockets.  It
is recommended to listen to two sockets, one for AF_INET and another for
AF_INET6, when you would like to accept both IPv4 and IPv6 traffic.

So possibly the solution is to create 2 listen sockets instead of relying
on inet6 wildcard binds? I will look at how to implement a patch for this.

Original issue reported on code.google.com by tetrachl...@gmail.com on 15 Jan 2010 at 12:48

GoogleCodeExporter commented 8 years ago
If you provide a patch that works I'll gladly apply it.

Original comment by bob.ippo...@gmail.com on 16 Jan 2010 at 7:21

GoogleCodeExporter commented 8 years ago
Since no working patch was provided I've rolled back #51 in r135 and will 
consider dual ipv4+ipv6 a wontfix 
unless someone submits a patch with tests that works cross-platform.

Original comment by bob.ippo...@gmail.com on 19 Jan 2010 at 6:22