As of commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172, the SETATTR nfsv4
command now null terminates fattr_owner and fattr_owner_group.
Here is an example excerpt from a tcpdump
Opcode: SETATTR (34)
stateid
[StateID Hash: 0xafa9]
seqid: 0x00000000
Data: 000000000000000000000000
obj_attributes
attrmask
recc_attr: FATTR4_OWNER_GROUP (37)
fattr4_owner_group: [email protected]
length: 25
This means that even though there are actually 24 characters in
[email protected], we now send 24 characters + 1 null character.
Hence the total length of 25. Previously the client would send just the
24 characters and set length to 24.
This isn't an issue for communication with other Linux machines, but it
is an issue for interaction with AIX machines. As is discussed here.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101292
I attempted to read the RFC available here
http://tools.ietf.org/html/rfc5661, but have not been able to find a
statement instructing one way or the other.
So the question becomes, is it correct for linux to be sending this null
terminator when read against the RFC, or is it AIX's responsibility to
handle null-terminated strings?
Thank you,
Dave.
On 03/08/2013 12:33 PM, Myklebust, Trond wrote:
> On Fri, 2013-03-08 at 11:11 -0600, Dave Chiluk wrote:
>> As of commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172, the SETATTR nfsv4
>> command now null terminates fattr_owner and fattr_owner_group.
>>
>> Here is an example excerpt from a tcpdump
>> Opcode: SETATTR (34)
>> stateid
>> [StateID Hash: 0xafa9]
>> seqid: 0x00000000
>> Data: 000000000000000000000000
>> obj_attributes
>> attrmask
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> fattr4_owner_group: [email protected]
>> length: 25
>>
>> This means that even though there are actually 24 characters in
>> [email protected], we now send 24 characters + 1 null character.
>> Hence the total length of 25. Previously the client would send just the
>> 24 characters and set length to 24.
>>
>> This isn't an issue for communication with other Linux machines, but it
>> is an issue for interaction with AIX machines. As is discussed here.
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101292
>>
>> I attempted to read the RFC available here
>> http://tools.ietf.org/html/rfc5661, but have not been able to find a
>> statement instructing one way or the other.
>>
>> So the question becomes, is it correct for linux to be sending this null
>> terminator when read against the RFC, or is it AIX's responsibility to
>> handle null-terminated strings?
>
> The client is definitely in error here according to RFC3530. Please
> check if the attached patch fixes the issue for you.
>
> Cheers
> Trond
>
Trond,
This appears to work great. Can you give me an idea when this will get
pulled into the the linux-nfs tree and eventually the mainline tree?
Dave.
On Fri, 2013-03-08 at 11:11 -0600, Dave Chiluk wrote:
> As of commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172, the SETATTR nfsv4
> command now null terminates fattr_owner and fattr_owner_group.
>
> Here is an example excerpt from a tcpdump
> Opcode: SETATTR (34)
> stateid
> [StateID Hash: 0xafa9]
> seqid: 0x00000000
> Data: 000000000000000000000000
> obj_attributes
> attrmask
> recc_attr: FATTR4_OWNER_GROUP (37)
> fattr4_owner_group: [email protected]
> length: 25
>
> This means that even though there are actually 24 characters in
> [email protected], we now send 24 characters + 1 null character.
> Hence the total length of 25. Previously the client would send just the
> 24 characters and set length to 24.
>
> This isn't an issue for communication with other Linux machines, but it
> is an issue for interaction with AIX machines. As is discussed here.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101292
>
> I attempted to read the RFC available here
> http://tools.ietf.org/html/rfc5661, but have not been able to find a
> statement instructing one way or the other.
>
> So the question becomes, is it correct for linux to be sending this null
> terminator when read against the RFC, or is it AIX's responsibility to
> handle null-terminated strings?
The client is definitely in error here according to RFC3530. Please
check if the attached patch fixes the issue for you.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
The patch definitely fixes the null termination issue. Hopefully that
is the only issue with AIX.
Thanks,
Dave.
On 03/08/2013 12:33 PM, Myklebust, Trond wrote:
> On Fri, 2013-03-08 at 11:11 -0600, Dave Chiluk wrote:
>> As of commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172, the SETATTR nfsv4
>> command now null terminates fattr_owner and fattr_owner_group.
>>
>> Here is an example excerpt from a tcpdump
>> Opcode: SETATTR (34)
>> stateid
>> [StateID Hash: 0xafa9]
>> seqid: 0x00000000
>> Data: 000000000000000000000000
>> obj_attributes
>> attrmask
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> fattr4_owner_group: [email protected]
>> length: 25
>>
>> This means that even though there are actually 24 characters in
>> [email protected], we now send 24 characters + 1 null character.
>> Hence the total length of 25. Previously the client would send just the
>> 24 characters and set length to 24.
>>
>> This isn't an issue for communication with other Linux machines, but it
>> is an issue for interaction with AIX machines. As is discussed here.
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101292
>>
>> I attempted to read the RFC available here
>> http://tools.ietf.org/html/rfc5661, but have not been able to find a
>> statement instructing one way or the other.
>>
>> So the question becomes, is it correct for linux to be sending this null
>> terminator when read against the RFC, or is it AIX's responsibility to
>> handle null-terminated strings?
>
> The client is definitely in error here according to RFC3530. Please
> check if the attached patch fixes the issue for you.
>
> Cheers
> Trond
>
On 03/08/2013 12:33 PM, Myklebust, Trond wrote:
> On Fri, 2013-03-08 at 11:11 -0600, Dave Chiluk wrote:
>> As of commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172, the SETATTR nfsv4
>> command now null terminates fattr_owner and fattr_owner_group.
>>
>> Here is an example excerpt from a tcpdump
>> Opcode: SETATTR (34)
>> stateid
>> [StateID Hash: 0xafa9]
>> seqid: 0x00000000
>> Data: 000000000000000000000000
>> obj_attributes
>> attrmask
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> fattr4_owner_group: [email protected]
>> length: 25
>>
>> This means that even though there are actually 24 characters in
>> [email protected], we now send 24 characters + 1 null character.
>> Hence the total length of 25. Previously the client would send just the
>> 24 characters and set length to 24.
>>
>> This isn't an issue for communication with other Linux machines, but it
>> is an issue for interaction with AIX machines. As is discussed here.
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101292
>>
>> I attempted to read the RFC available here
>> http://tools.ietf.org/html/rfc5661, but have not been able to find a
>> statement instructing one way or the other.
>>
>> So the question becomes, is it correct for linux to be sending this null
>> terminator when read against the RFC, or is it AIX's responsibility to
>> handle null-terminated strings?
>
> The client is definitely in error here according to RFC3530. Please
> check if the attached patch fixes the issue for you.
>
> Cheers
> Trond
>
Thanks again for the patch. When will this get pushed upstream? I'm
blocked by the upstream commit, since I don't want to pull this in as a
SAUCE patch.
Dave.