Посылаю такой пакет Код (Text): IP Version:4 Header len.:20 Total len.:144 ID:$83F fragmentation DF=0 MF=0 TTL:128 Protocol:$06 (TCP) Checksum:$5FBC Source IP:172.25.33.33 Dest. IP:172.25.25.25 TCP src_port:1723 dest_port:445 seq_number:2304250942 ack_number:3004036051 data_offset:5 flags (PUSH) urgent :0 ack :1 push :1 reset :0 syn :0 fin :0 window:65001 checksum:$A129 urgent_pointer:$00 Netbios Session Service MSG_YPE:$0 FLAGS:$0 LENGTH:100 SESSION MESSAGE SMB Command:$A2 ProcessID:620 UserID:2049 MultiplexID:4802 Request Должен прийти такой: Код (Text): IP Version:4 Header len.:20 Total len.:179 ID:$3BF2 fragmentation DF=0 MF=0 TTL:128 Protocol:$06 (TCP) Checksum:$2BE6 Source IP:172.25.25.25 Dest. IP:172.25.33.33 TCP src_port:445 dest_port:1723 seq_number:3004036051 ack_number:2304251046 data_offset:5 flags (PUSH) urgent :0 ack :1 push :1 reset :0 syn :0 fin :0 window:65535 checksum:$EC62 urgent_pointer:$00 Netbios Session Service MSG_YPE:$0 FLAGS:$0 LENGTH:135 SESSION MESSAGE SMB Command:$A2 ProcessID:620 UserID:2049 MultiplexID:4802 Response Но в ответ приходит не то что нужно. Как я понимаю надо в посылаемом пакете заполнить поля ProcessID, UserID, MultiplexID ProcessID заполнил GetCurrentProcessID, а чем заполнить оставшиеся два поля?
NIX: int uid; /* номер */ uid = getuid(); :тратата The UID field in an SMB packet is an ID that refers to an authentication that occured previously on the transport. The only way to know which user that ID refers to is to know which user the authentication the ID refers to. And the only way to know which user an authentication refers to is to decode the authentication and extract the user's name (which could be rather difficult if the authentication method is Kerberos).
Код (Text): 3.1.4 Pid Field Pid uniquely identifies a client process. Clients inform servers of the creation of a new process by simply introducing a new Pid value into the dialogue for new processes. In the core protocol, the SMB_COM_PROCESS_EXIT SMB was used to indicate the catastrophic termination of a process on the client. In the single tasking DOS system, it was possible for hard errors to occur causing the destruction of the process with files remaining open. Thus a SMB_COM_PROCESS_EXIT SMB was sent for this occurrence to allow the server to close all files opened by that process. In the LANMAN 1.0 and newer dialects, no SMB_COM_PROCESS_EXIT SMB is sent. The client operating system must ensure that the appropriate close and cleanup SMBs will be sent when the last process referencing the file closes it. From the server's point of view, there is no concept of FIDs "belonging to" processes. A FID returned by the server to one process may be used by any other process using the same transport connection and Tid. There is no process creation SMB sent to the server; it is up to the client to ensure only valid client processes gain access to Fids (and Tids). On SMB_COM_TREE_DISCONNECT (or when the client and server session is terminated) the server will invalidate any files opened by any process on that client. 3.1.5 Mid Field Clients using the LANMAN 1.0 and newer dialects will typically be multitasked and allow multiple asynchronous input/output requests per task. Therefore a multiplex ID (Mid) is used along with Pid to allow multiplexing the single client and server connection among the client's multiple processes, threads, and requests per thread. Regardless of negotiated dialect, the server is responsible for ensuring that every response contains the same Mid and Pid values as its request. The client may then use the Mid and Pid values for associating requests Leach, Naik expires September, 1997 [Page 25] INTERNET-DRAFT CIFS/1.0 03/19/97 and responses and may have up to the negotiated number of requests outstanding at any time to a particular server. Это я нарил в спецификации. Вот только мне оно ничего не дало
