On Fri, 2012-05-25 at 08:45 -0400, Stephen Gallagher wrote:
On Fri, 2012-05-25 at 14:22 +0200, Jakub Hrozek wrote:
> On Fri, May 25, 2012 at 08:12:56AM -0400, Stephen Gallagher wrote:
> > On Fri, 2012-05-25 at 08:09 -0400, Stephen Gallagher wrote:
> > > On Fri, 2012-05-25 at 13:56 +0200, Jakub Hrozek wrote:
> > > > On Fri, May 25, 2012 at 07:28:06AM -0400, Stephen Gallagher wrote:
> > > > > On Fri, 2012-05-25 at 12:46 +0200, Jakub Hrozek wrote:
> > > > > > The sss_client was copying 32bit port value, but the NSS
responder was
> > > > > > reading 16bit port value. This was breaking on Big-Endian
machines where
> > > > > > we read "the other 16bits".
> > > > > >
> > > > > > By the way, is there a reason to use 32bits in the client
in the first
> > > > > > place? IIRC a port number is a 16 bit value..
> > > > >
> > > > > No, you're right. The client should only be sending a 16-bit
value.
> > > > >
> > > > > Nack.
> > > > > Please change the client to send a uint16_t instead.
> > > >
> > > > Attached.
> > >
> > >
> > > Nack (minor).
> > >
> > > Would you mind using SAFEALIGN_SET_UINT16() for the padding? The macro
> > > expands to exactly the same code you have there.
> > >
>
> Sure, new patch is attached.
>
> > > Has this been tested on a little-endian and big-endian system?
> >
> > Replying to myself, I can confirm that this is working on x86_64 at
> > least.
>
> Yes, I also tested on s390x running RHEL6.
Ack
Pushed to master and sssd-1-8.