From: Tim Gardner <timg@tpi.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org, Steve French <sfrench@samba.org>
Subject: Re: [PATCH 2/2 linux-next] cifs: Make big endian multiplex ID sequences monotonic on the wire
Date: Wed, 16 Oct 2013 09:02:49 -0700 [thread overview]
Message-ID: <525EB8A9.1040802@tpi.com> (raw)
In-Reply-To: <20131016114007.3b7d4fc6@tlielax.poochiereds.net>
On 10/16/2013 08:40 AM, Jeff Layton wrote:
> On Wed, 16 Oct 2013 09:09:50 -0600
> Tim Gardner <timg@tpi.com> wrote:
>
>> The multiplex identifier (MID) in the SMB header is only
>> ever used by the client, in conjunction with PID, to match responses
>> from the server. As such, the endianess of the MID is not important.
>> However, When tracing packet sequences on the wire, protocol analyzers
>> such as wireshark display MID as little endian. It is much more informative
>> for the on-the-wire MID sequences to match debug information emitted by the
>> CIFS driver. Therefore, one should write and read MID in the SMB header
>> assuming it is always little endian.
>>
>> Observed from wireshark during the protocol negotiation
>> and session setup:
>>
>> Multiplex ID: 256
>> Multiplex ID: 256
>> Multiplex ID: 512
>> Multiplex ID: 512
>> Multiplex ID: 768
>> Multiplex ID: 768
>>
>> After this patch on-the-wire MID values begin at 1 and increase monotonically.
>>
>> Introduce get_next_mid64() for the internal consumers that use the full 64 bit
>> multiplex identifier.
>>
>> Introduce the helpers get_mid() and compare_mid() to make the endian
>> translation clear.
>>
>> Cc: Steve French <sfrench@samba.org>
>> Signed-off-by: Tim Gardner <timg@tpi.com>
>> ---
>>
>> I'm looking at some of this code in excrutiating detail because I'm having trouble
>> with a backport of CIFS from 3.9.7 on an embedded 2.6.31 powerpc. Its failing the RawNTLMSSP
>> authentication and is almost certainly an endian issue. x86 on the same code base works
>> quite well. Am I making a rash assumption that CIFS in 3.9 stable worked on big endian ?
>>
>> fs/cifs/cifsglob.h | 25 ++++++++++++++++++++++++-
>> fs/cifs/misc.c | 9 +++++----
>> fs/cifs/smb1ops.c | 4 ++--
>> fs/cifs/smb2transport.c | 2 +-
>> fs/cifs/transport.c | 2 +-
>> 5 files changed, 33 insertions(+), 9 deletions(-)
>>
>> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
>> index 52b6f6c..535e324 100644
>> --- a/fs/cifs/cifsglob.h
>> +++ b/fs/cifs/cifsglob.h
>> @@ -620,11 +620,34 @@ set_credits(struct TCP_Server_Info *server, const int val)
>> }
>>
>> static inline __u64
>> -get_next_mid(struct TCP_Server_Info *server)
>> +get_next_mid64(struct TCP_Server_Info *server)
>> {
>> return server->ops->get_next_mid(server);
>> }
>>
>> +static inline __u16
>> +get_next_mid(struct TCP_Server_Info *server)
>> +{
>> + __u16 mid = get_next_mid64(server);
>> + /*
>> + * The value in the SMB header should be little endian for easy
>> + * on-the-wire decoding.
>> + */
>> + return cpu_to_le16(mid);
>> +}
>> +
>> +static inline __u16
>> +get_mid(const struct smb_hdr *smb)
>> +{
>> + return le16_to_cpu(smb->Mid);
>> +}
>> +
>> +static inline bool
>> +compare_mid(__u16 mid, const struct smb_hdr *smb)
>> +{
>> + return mid == le16_to_cpu(smb->Mid);
>> +}
>> +
>> /*
>> * When the server supports very large reads and writes via POSIX extensions,
>> * we can allow up to 2^24-1, minus the size of a READ/WRITE_AND_X header, not
>> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
>> index 298e31e..c851d41 100644
>> --- a/fs/cifs/misc.c
>> +++ b/fs/cifs/misc.c
>> @@ -295,7 +295,8 @@ check_smb_hdr(struct smb_hdr *smb)
>> if (smb->Command == SMB_COM_LOCKING_ANDX)
>> return 0;
>>
>> - cifs_dbg(VFS, "Server sent request, not response. mid=%u\n", smb->Mid);
>> + cifs_dbg(VFS, "Server sent request, not response. mid=%u\n",
>> + le16_to_cpu(smb->Mid));
>> return 1;
>> }
>>
>> @@ -358,11 +359,11 @@ checkSMB(char *buf, unsigned int total_read)
>> return 0; /* bcc wrapped */
>> }
>> cifs_dbg(FYI, "Calculated size %u vs length %u mismatch for mid=%u\n",
>> - clc_len, 4 + rfclen, smb->Mid);
>> + clc_len, 4 + rfclen, le16_to_cpu(smb->Mid));
>>
>> if (4 + rfclen < clc_len) {
>> cifs_dbg(VFS, "RFC1001 size %u smaller than SMB for mid=%u\n",
>> - rfclen, smb->Mid);
>> + rfclen, le16_to_cpu(smb->Mid));
>> return -EIO;
>> } else if (rfclen > clc_len + 512) {
>> /*
>> @@ -375,7 +376,7 @@ checkSMB(char *buf, unsigned int total_read)
>> * data to 512 bytes.
>> */
>> cifs_dbg(VFS, "RFC1001 size %u more than 512 bytes larger than SMB for mid=%u\n",
>> - rfclen, smb->Mid);
>> + rfclen, le16_to_cpu(smb->Mid));
>> return -EIO;
>> }
>> }
>
> It would be more efficient to byte-swap smb->Mid only once and store
> that in a u16 here and then print that out instead of doing it multiple
> times.
>
OK, I'll send out V2.
--
Tim Gardner timg@tpi.com www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357
next prev parent reply other threads:[~2013-10-16 16:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 15:09 [PATCH 1/2 linux-next] cifs: Remove redundant multiplex identifier check from check_smb_hdr() Tim Gardner
2013-10-16 15:09 ` [PATCH 2/2 linux-next] cifs: Make big endian multiplex ID sequences monotonic on the wire Tim Gardner
2013-10-16 15:40 ` Jeff Layton
2013-10-16 16:02 ` Tim Gardner [this message]
2013-10-16 16:25 ` Shirish Pargaonkar
2013-10-16 16:39 ` Tim Gardner
2013-10-16 15:36 ` [PATCH 1/2 linux-next] cifs: Remove redundant multiplex identifier check from check_smb_hdr() Jeff Layton
2013-10-28 14:37 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525EB8A9.1040802@tpi.com \
--to=timg@tpi.com \
--cc=jlayton@redhat.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox