Samba 源码解析之SMBclient命令流

smbclient提供了类似FTP式的共享文件操作功能, 本篇从源码角度讲解smbclient的实现,smbclient命令的具体使用可通过help命令和互联网查到大量资料。

以下从源码角度分析一个smbclient命令是如何发到远端机器上和处理返回结果的。这里以一个简单的命令“close <fnum>”为例,分析程序的整个过程如下:

step 1. cmd_close(void)位于source3/client/client.c中。每个smbclient命令都有一个类似cmd_***命名的函数,这些函数作用是为step 2中的cli_***函数准备参数。

- 从全局内存stackframe获取临时内存“停靠点”。该步主要使用talloc库并配合samba自身的需要完成内存的管理。具体可参见上一篇博文的talloc加深理解。

- 分析传入的<fnum>, 简单调用atoi转换为字符串类型。

- 调用cli_close()。

Step 2. cli_close(cli, fnum)位于source3/client/client.c中。 它接收cmd_***传递的函数,做实质性的工作。这里第一个参数cli是cli_state全局类型数据,该数据结构中几乎包含了当前连接的connection的绝大多数信息,例如:

cli_state的前驱和后继、当前connection 信息、客户domain名、用户名、server domain、os、posix 能力、打开的管道list、机会锁信息、使用smb1 or smb2?及其相关联的session、tree connection、打开的句柄。第二

个参数是上面准备的打开的句柄。不同的cli_***command可能需要另外的参数,这些参数主要是为下层协议具体command准备的。可参见CIFS or SMB2协议来确定每个命令具体需要的参数有哪些。

- 根据cli->connection->protocol类型判断当前connection所使用的协议类型,若为SMB2,则调用SMB2处理函数cli_smb2_close_fnum(位于source3/libsmb/cli_smb2_fnum.c中)。这里重点分析SMB1处理。

- 若当前connection使用smb1,则根据当前connection->的event等待队列来判断是否有outgoing或pending的message,如果有则出错返回。(因为这里我们使用的都是同步的smb1 message)

- 调用samba_tevent_context_init分配tevent

- 调用cli_close_send()发送close immediate CIFS message。后续具体分析这个函数。

- 调用tevent_req_poll()等待event接收事件

- 调用cli_close_recv()接收server返回的close 数据报并返回

上面蓝色标记部分为IO处理的tevent库使用,会另文介绍。本文继续深入分析红色部分的协议处理部分,两个红色标记函数完成了协议组包、协议发送和协议接收处理。

cli_close_send():

Step 1: 调用cli_close_create(),根据协议组包并设置event类型和callback函数

- 调用tevent_req_create()创建一个immediate类型event,并设置状态为TEVENT_REQ_IN_PROGRESS状态;

- 调用cli_smb_req_create(TALLOC_CTX, tevent_context, cli_state, smb_command, additinal_flags, wct, *vwv, iov_count, iovec*),然后又向下调用smb1cli_req_create()(位于libcli/smb/smbXcli_base.c中)完成

按协议的具体组包工作。组包时需要注意,SMB1在组包时并没有定义每个CIFS协议的完整数据包格式,只是定义了header(加上wct)字段,发送是通过控制iov和iov_count来进行的,具体看下面code:

	smb1cli_req_flags(conn->protocol,
			  conn->smb1.capabilities,
			  smb_command,
			  additional_flags,
			  clear_flags,
			  &flags,
			  additional_flags2,
			  clear_flags2,
			  &flags2);  //获取当前命令所需的flags
        //设置CIFS header的各个域,完成大小端转换
	SIVAL(state->smb1.hdr, 0,           SMB_MAGIC);
	SCVAL(state->smb1.hdr, HDR_COM,     smb_command);
	SIVAL(state->smb1.hdr, HDR_RCLS,    NT_STATUS_V(NT_STATUS_OK));
	SCVAL(state->smb1.hdr, HDR_FLG,     flags);
	SSVAL(state->smb1.hdr, HDR_FLG2,    flags2);
	SSVAL(state->smb1.hdr, HDR_PIDHIGH, pid >> 16);
	SSVAL(state->smb1.hdr, HDR_TID,     tid);
	SSVAL(state->smb1.hdr, HDR_PID,     pid);
	SSVAL(state->smb1.hdr, HDR_UID,     uid);
	SSVAL(state->smb1.hdr, HDR_MID,     0); /* this comes later */
	SCVAL(state->smb1.hdr, HDR_WCT,     wct);

	state->smb1.vwv = vwv;// ???

        //计算bcc字段
	SSVAL(state->smb1.bytecount_buf, 0, smbXcli_iov_len(bytes_iov, iov_count));

        //以下为每个SMB1 command都包含的域
	state->smb1.iov[0].iov_base = (void *)state->length_hdr; //“SMB”
	state->smb1.iov[0].iov_len  = sizeof(state->length_hdr);
	state->smb1.iov[1].iov_base = (void *)state->smb1.hdr; //header域
	state->smb1.iov[1].iov_len  = sizeof(state->smb1.hdr);
	state->smb1.iov[2].iov_base = (void *)state->smb1.vwv; //wct字段具体包含的数据
	state->smb1.iov[2].iov_len  = wct * sizeof(uint16_t);
	state->smb1.iov[3].iov_base = (void *)state->smb1.bytecount_buf;//bcc域
	state->smb1.iov[3].iov_len  = sizeof(uint16_t);

        //特殊smb1 command若还有其他字段则通过iov[4]进行发送
	if (iov_count != 0) {
		memcpy(&state->smb1.iov[4], bytes_iov,
		       iov_count * sizeof(*bytes_iov));
	}
	state->smb1.iov_count = iov_count + 4;

- 组包结束后调用tevent_req_set_callbak()设置该event的callback函数为cli_close_done(),在该函数中调用cli_smb_recv()函数完成smb数据包的接收。注意,此时组包和event相关注册活动均已完成,ready for 发送。

Step 2: 调用smb1cli_req_chain_submit(),该函数完成具体的message发送工作。

cli_close_recv():

- 由于注册的是immediate时间,程序将block在上一步的tevent_req_poll()直到对应event接到通知,并从注册的callback中返回。此时我们已经接收收到了close的返回数据报(callback函数接收处理的),针对close command只需要简单处理返回值即可。其他复杂command可能需要对返回值作进一步的分析,如保存打开的文件句柄、保存treeid等信息。

总结:

其实client端的实现还是相对比较简单,关键点是tevent库的使用和协议的组包分析。tevent库的使用可以通过资料快速掌握,但协议的组包和处理包括大量细节,没必要全部掌握,分析一个简单命令即可。

时间: 2024-12-14 08:00:47

Samba 源码解析之SMBclient命令流的相关文章

Samba 源码解析之内存管理

由于工作需要想研究下Samba的源码,下载后发现目录结构还是很清晰的.一般大家可能会对source3和source4文件夹比较疑惑.这两个文件夹针对的是Samba主版本号,所以你可以暂时先看一个.这里我选择Source3. 阅读源码最好要动手编译并安装,但这里我偷个懒直接在ubuntu上安装跳过了编译步骤.首先从client开始看起.SMBclient的所有命令的对应code都在source3/client/client.c中,我们由浅入深,挑一个比较简单的命令来看下它的执行流程,将简单的命令分

GlusterFS源码解析—— GlusterFS 命令行常见错误

问题1 [[email protected] ~]# gluster peer status Connection failed. Please check if gluster daemon is operational. 原因:未开启glusterd服务 解决方法:开启glusterd服务 /etc/init.d/glusterd start 问题2 [[email protected] ~]# gluster peer probe server-130 peer probe: failed

IPerf——网络测试工具介绍与源码解析(1)

IPerf是一个开源的测试网络宽带并能统计并报告延迟抖动.数据包丢失率信息的控制台命令程序,通过参数选项可以方便地看出,通过设置不同的选项值对网络带宽的影响,对于学习网络编程还是有一定的借鉴意义,至少可以玩上一段时间. IPerf开始出现的时候是在03年,版本是1.7.0,在网上找到的仅有的系列源码解析篇 http://blog.chinaunix.net/uid/11568125/cid-131106-abstract-1.html 就是基于1.7.0 进行介绍和解析的,貌似1.7.0还是使用

【Linux笔记】samba源码安装及基本使用说明

前段时间项目中碰到从windows机器上传多媒体文件至linux服务器的需求(人工审核并触发同步),调研了几种上传机制或实现方案: 1) http方式上传至WebServer 用PHP或Python脚本上传给WebServer,但由于多媒体文件动辄几百兆,PHP由于最长执行时间的限制首先被排除,另外由于用脚本上传需要增加失败重试等控制逻辑,Python虽然可以实现这些功能,但考虑到开发成本及服务的稳定性,并不是最优方案 2) flash方式上传 例如百度云web端就使用了flash方式上传,通过

《Druid源码解析(1) Guice和Realtime流程》——图较精简,不错

https://zqhxuyuan.github.io/ 最近两年更新少 任何忧伤,都抵不过世界的美丽 2015-12-08 Druid源码解析(1) Guice和Realtime流程 Source druid Druid is a fast column-oriented distributed data store. http://druid.io/ 当启动Druid的服务,会启动一个java进程,比如run_example_server.sh会启动io.druid.cli.Main exa

socketserver源码解析和协程版socketserver

来,贴上一段代码让你仰慕一下欧socketserver的魅力,看欧怎么完美实现多并发的魅力 client import socket ip_port = ('127.0.0.1',8009) sk = socket.socket() sk.connect(ip_port) sk.settimeout(5) while True: data = sk.recv(1024) print('receive:',data.decode()) inp = input('please input:') sk

GlusterFS源码解析 —— GlusterFS 源码安装

安装环境: CentOS6.2 glusterfs-3.4.3 GlusterFS 挂载需要 fuse 支持,如果你的内核版本低于 2.6.16 则需要下载fuse的源码包自行编译安装,也可下载 fuse 的rpm包.安装fuse的方法我就不说了,不会源码安装的直接去rpmfind.net上下载rpm即可.高于此版本的内核中已经有了fuse.ko的模块,需要的时候可以执行以下命令进行加载: modprobe -b fuse 1.下载GlusterFS的源码包,目前已经有更新版本 : wget h

Andfix热修复框架原理及源码解析-上篇

热补丁介绍及Andfix的使用 Andfix热修复框架原理及源码解析-上篇 Andfix热修复框架原理及源码解析-下篇 1.不知道如何使用的同学,建议看看我上一篇写的介绍热补丁和Andfix的使用,这样你才有一个大概的框架.通过使用Andfix,其实我们心中会有一个大概的轮廓,它的工作原理,大概就是,所谓的补丁文件,就是通过打包工具apkpatch比对新的apk和旧的apk之间的差异.然后让我们的旧包运行的时候,就加载它,把以前的一些信息替换掉.我们现在就抱着这个大方向去深入源码探个究竟!!首先

Android MIFARE NFCA源码解析

Android MIFARE NFCA源码解析TagTechnology定义了所有标签的共有接口类BasicTagTechnology 实现了TagTechnology的一些接口 再有具体的标签协议继承BasicTagTechnologyNFC-A 遵循ISO 14443-3A协议. 关键字ATQA Answer To Request acc. to ISO/IEC 14443-4ATS Answer To Select acc. to ISO/IEC 14443-4DIF Dual Inter