[flow-tools] Problems on sparc linux

Mark Fullmer maf@eng.oar.net
Sat, 30 Nov 2002 22:49:18 -0500


I'm going to gess that your implementation of IP_PKTINFO requires
more than just a struct in_pktinfo pktinfo allocated at the end of the
msgip struct.

Try removing the following chunk of code in flow-capture.c and see
if that helps.  This breaks the ability for flow-capture to know
the destination IP of the exports...

#ifdef IP_RECVDSTADDR
  one = 1;
  /* return the destination IP address */
  if (setsockopt(ftnet.fd, IPPROTO_IP, IP_RECVDSTADDR, (char *)&one,
    sizeof(one)) < 0)
    fterr_err(1, "setsockopt(IP_RECVDSTADDR)");
#else
#ifdef IP_PKTINFO
  one = 1;
  /* return the destination IP address */
  if (setsockopt(ftnet.fd, IPPROTO_IP, IP_PKTINFO, (char *)&one,
    sizeof(one)) < 0)
    fterr_err(1, "setsockopt(IP_PKTINFO)");
#endif /* else */
#endif /* IP_RECVDSTADDR */

mark

On Tue, Nov 26, 2002 at 09:52:42AM -0000, Matt Foster wrote:
> Hi,
> 
> Under i386 linux we have in <bits/socket.h>
> struct msghdr
>   {
>     void *msg_name;             /* Address to send to/receive from.  */
>     socklen_t msg_namelen;      /* Length of address data.  */
> 
>     struct iovec *msg_iov;      /* Vector of data to send/receive into.  */
>     int msg_iovlen;             /* Number of elements in the vector.  */
> 
>     void *msg_control;          /* Ancillary data (eg BSD filedesc passing).
> */
>     socklen_t msg_controllen;   /* Ancillary data buffer length.  */
> 
>     int msg_flags;              /* Flags on received message.  */
>   };
> 
> And under sparc we have:
> /* Structure describing messages sent by
>    `sendmsg' and received by `recvmsg'.  */
> struct msghdr
>   {
>     void *msg_name;             /* Address to send to/receive from.  */
>     socklen_t msg_namelen;      /* Length of address data.  */
> 
>     struct iovec *msg_iov;      /* Vector of data to send/receive into.  */
> #if __WORDSIZE == 32
>     int msg_iovlen;             /* Number of elements in the vector.  */
> 
>     void *msg_control;          /* Ancillary data (eg BSD filedesc passing).
> */
>     socklen_t msg_controllen;   /* Ancillary data buffer length.  */
> #else
>     size_t msg_iovlen;          /* Number of elements in the vector.  */
> 
>     void *msg_control;          /* Ancillary data (eg BSD filedesc passing).
> */
>     size_t msg_controllen;      /* Ancillary data buffer length.  */
> #endif
>     int msg_flags;              /* Flags on received message.  */
>   };
> 
> As I'm running on a 64 bit system, I've changed the definition in ftlib.h to
> look like this:
> struct mymsghdr {
>         void            *msg_name;             /* optional address */
>         socklen_t       msg_namelen;           /* size of address */
>         struct iovec    *msg_iov;              /* scatter/gather array */
>         size_t          msg_iovlen;            /* # elements in msg_iov */
>         void            *msg_control;          /* ancillary data, see below
> */
>         size_t          msg_controllen;        /* ancillary data buffer len
> */
>         int             msg_flags;             /* flags on received message
> */
> };
> 
> This seems to have the effect that we now capture 92 bytes before crashing
> in the same way, rather than the 84 we captured before.
> 
> Any further clues?
> 
> Rgds,
> 
> 
> Matt Foster
> 
> ----- Original Message -----
> From: "Mark Fullmer" <maf@eng.oar.net>
> To: "Matt Foster" <Matt.Foster@Unilever.com>
> Cc: <flow-tools@splintered.net>
> Sent: Tuesday, November 26, 2002 3:40 AM
> Subject: Re: [flow-tools] Problems on sparc linux
> 
> 
> > Any luck with this?  I don't have a Sparc/Linux platform to test on.
> >
> > Someplace to start looking is if the struct mymsghdr in ftlib.h
> > is the same as your system include file.  The way I did this is
> > probably not portable if the system struct msghdr changes.
> >
> > mark
> >
> > On Mon, Nov 11, 2002 at 05:08:42PM -0000, Matt Foster wrote:
> > > Hi,
> > >
> > > We are in the process of moving our flow-capture system from
> > > Solaris7 on sparc (which works well) to Linux on Sparc.
> > >
> > > Both 0.62 and 0.59 compile fine, but neither seems to work:
> > >
> > > statto flow-capture[4521]: New exporter: time=1037030360 src_ip=X.X.X.X
> > > dst_ip=Y.Y.Y.Y d_version=5
> > >  statto flow-capture[4521]: New exporter: time=1037030386 src_ip=X.X.X.X
> > > dst_ip=Y.Y.Y.Y d_version=5
> > > statto flow-capture[4521]: ftpdu_seq_check(): src_ip=X.X.X.X
> dst_ip=Y.Y.Y.Y
> > > d_version=5 expecting=787403 received=787414 lost=11
> > > statto flow-capture[4521]: recvmsg(): Bad address
> > >
> > > and then the flow-capture exits. The flow export is from a Cisco 2621
> 12.2.5
> > > and also from 7200 and 7600s.
> > >
> > > [root@statto src]# netstat -s --udp
> > > Udp:
> > >     198 packets received
> > >     353 packets to unknown port received.
> > >     0 packet receive errors
> > >     193 packets sent
> > >
> > > The system is a twin CPU 280R, with no load on it with a 2.4.20-pre1
> kernel.
> > > The distribution is Aurora (Redhat 7.3 clone).  An Intel RedHat 7.3
> system
> > > has no problems at all.
> > >
> > > I suspect it's some kind of architecture wierdness, but am at a loss as
> to
> > > what.
> > > I've tried with both qfe0 and eri0 interfaces, the result is the same.
> > >
> > > Does anyone have and ideas/hints?
> > >
> > > Thanks,
> > >
> > > Matt Foster
> > >
> > >
> > > _______________________________________________
> > > flow-tools@splintered.net
> > > http://www.splintered.net/sw/flow-tools
> >
> > _______________________________________________
> > flow-tools@splintered.net
> > http://www.splintered.net/sw/flow-tools
> 
> 
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools