X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 	tests=AWL,BAYES_20
X-Spam-Check-By: sourceware.org
From: Andrew Schulman <schulman DOT andrew AT epamail DOT epa DOT gov>
To: cygwin AT cygwin DOT com
Subject: Re: missing ipi_spec_dst in struct in_pktinfo
Date: Tue, 08 Sep 2009 10:38:36 -0400
Message-ID: <hrpca5lkt2uaokm0ub99b0vp70a30d2a74@4ax.com>
References: <OF10653B86 DOT 82265559-ON85257627 DOT 006D9ED5-85257627 DOT 006ED0E7 AT epamail DOT epa DOT gov> <20090905161229 DOT GA1869 AT calimero DOT vinschen DOT de>
In-Reply-To: <20090905161229.GA1869@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Archive: encrypt
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> > The IP man page
> > (http://homepages.cwi.nl/~aeb/linux/man2html/man7/ip.7.html) lists
> > in_pktinfo as
> >=20
> > struct in_pktinfo {
> >     unsigned int   ipi_ifindex;  /* Interface index */
> >     struct in_addr ipi_spec_dst; /* Local address */
> >     struct in_addr ipi_addr;     /* Header Destination address */
> > };
> >=20
> > while in /usr/include/cygwin/in.h, it's just
> >=20
> > struct in_pktinfo
> > {
> >   struct in_addr ipi_addr;
> >   uint32_t       ipi_ifindex;
> > };
> >=20
> > Any suggestions for a workaround to this problem?  Why is ipi_spec_dst
> > missing, and more to the point, what can/should I substitute in its
> > place?
>=20
> ipi_spec_dst is missing because the Winsock structure in_pktinfo is
> defined without this field.  The recvmsg function will return the
> Winsock equivalent to this structure, since that's how it gets it from
> Windows.  The workaround is easy: Don't use that field.  Disable the code
> in socat which uses it.  Even if we would go to great lengths to
> add/remove the field when calling WSASendMsg/WSARecvMsg, it would be
> entirely meaningless anyway.

OK, thanks to you both.  It turns out that socat only uses that field for
reporting in one place, so I disabled it as you suggested.  socat is great,
I'll be packaging it for Cygwin shortly.  A.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple