[ruby-core:38603] Re: [Ruby 1.9 - Feature #5097] Supported platforms of Ruby 1.9.3

2011/7/30 Jeremy Evans <[e-mail]>:

> It looks like the socket failure on OpenBSD is because in Socket.udp_server_recv, you are adding the pktinfo in the sendmsg call, and OpenBSD appears not to like that in all cases, specifically when you are sending from a link-local IPv6 address to the same link-local IPv6 address on a different port.  It causes the client to not receive the reply, which makes the test fail since the response is not received within 10 seconds.  I think adding the pktinfo is unnecessary in the sendmsg call (the server needs pktinfo to know the address of the client, but the client must already know the address of the server in order to communicate), so I removed it.  This causes the test to pass, and still should work with dynamic IPv6 address changes.

The pktinfo for sendmsg is required to specify the source address of the
sending packet.

UDP server should reply from the address which client sent to.

If the server machine is multi-homed, the UDP server may reply from
different address without pktinfo for sendmsng.
I.e. if the server has addresses X and Y and the client send to a packet to X,
the server should reply from X.
But the server may reply from Y without pktinfo.

RFC 1123:
      When the local host is multihomed, a UDP-based request/response
      application SHOULD send the response with an IP source address
      that is the same as the specific destination address of the UDP
      request datagram.  The "specific destination address" is defined
      in the "IP Addressing" section of the companion RFC [INTRO:1].

RFC 3542:
   (Note: The hop limit is not contained in the in6_pktinfo structure
   for the following reason.  Some UDP servers want to respond to client
   requests by sending their reply out the same interface on which the
   request was received and with the source IPv6 address of the reply
   equal to the destination IPv6 address of the request.  To do this the
   application can enable just the IPV6_RECVPKTINFO socket option and
   then use the received control information from recvmsg() as the
   outgoing control information for sendmsg().  The application need not
   examine or modify the in6_pktinfo structure at all.  But if the hop
   limit were contained in this structure, the application would have to
   parse the received control information and change the hop limit
   member, since the received hop limit is not the desired value for an
   outgoing packet.)

If this doesn't work, I think it is a bug of OpenBSD.
-- 
Tanaka Akira