From: Tim Gardner <timg-l6nL5VImRDY@public.gmane.org>
To: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.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-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On 10/16/2013 08:40 AM, Jeff Layton wrote:
> On Wed, 16 Oct 2013 09:09:50 -0600
> Tim Gardner <timg-l6nL5VImRDY@public.gmane.org> 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-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
>> Signed-off-by: Tim Gardner <timg-l6nL5VImRDY@public.gmane.org>
>> ---
>>
>> 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-l6nL5VImRDY@public.gmane.org www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357
WARNING: multiple messages have this Message-ID (diff)
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: 15+ 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 ` 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 15:40 ` Jeff Layton
[not found] ` <20131016114007.3b7d4fc6-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2013-10-16 16:02 ` Tim Gardner [this message]
2013-10-16 16:02 ` Tim Gardner
[not found] ` <1381936190-67628-2-git-send-email-timg-l6nL5VImRDY@public.gmane.org>
2013-10-16 16:25 ` Shirish Pargaonkar
2013-10-16 16:25 ` Shirish Pargaonkar
[not found] ` <CADT32e+hGPe5WpNk-Bh-GVotQM2+-J458D1GNaRp55s3vcQWSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-16 16:39 ` Tim Gardner
2013-10-16 16:39 ` Tim Gardner
[not found] ` <1381936190-67628-1-git-send-email-timg-l6nL5VImRDY@public.gmane.org>
2013-10-16 15:36 ` [PATCH 1/2 linux-next] cifs: Remove redundant multiplex identifier check from check_smb_hdr() Jeff Layton
2013-10-16 15:36 ` Jeff Layton
[not found] ` <20131016113632.6548d399-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2013-10-28 14:37 ` Steve French
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-l6nl5vimrdy@public.gmane.org \
--cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org \
--cc=sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.