diff options
Diffstat (limited to 'source3/nameservresp.doc')
| -rw-r--r-- | source3/nameservresp.doc | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/source3/nameservresp.doc b/source3/nameservresp.doc new file mode 100644 index 0000000000..2f0d1912c8 --- /dev/null +++ b/source3/nameservresp.doc @@ -0,0 +1,188 @@ +this module deals with the receipt of response packets. the +response packets are expected to be received, and there is a +record of this kept (see also: modules nameresp and namedbresp) + +/************************************************************************* + response_netbios_packet() + *************************************************************************/ + +this function receives netbios response packets. the samba server +(or a rogue tcp/ip system, or nmblookup) will have sent out a packet +requesting a response. a client (or a rogue tcp/ip system) responds +to that request. + +this function checks the validity of the packet it receives. +the expected response records are searched for the transaction id, +to see if it's a response expected by the samba server. if it isn't +it's reported as such, and ignored. + +if the response is found, then the subnet it was expected from will +also have been found. the subnet it actually came in on can be +checked against the subnet it was expected from and reported, +otherwise this function just carries on. + +the number of responses received is increased, and the number of +retries left to be sent is set to zero. + +after debug information is reported, and validation of the netbios +packet (e.g only one response from one machine is expected for some +functions) has occurred, the packet is processed. when the initial +request was sent out, the expected response record was flagged with, +for lack of a better word, a samba 'state' type. whenever a +response is received, the appropriate function is called to carry on +where the program control flow was interrupted while awaiting exactly +such a response. + +please note that _not_ receiving a response is dealt with in another +area of code - expire_netbios_response_entries(). + + +/************************************************************************* + response_name_query_sync() + *************************************************************************/ + +this function receives responses to samba 'states' NAME_QUERY_SYNC and +NAME_QUERY_CONFIRM. + +NAME_QUERY_SYNC: name query a server before synchronising browse lists. +NAME_QUERY_CONFIRM: name query a server to check that it's alive. + +a NAME_QUERY_SYNC will be carried out in order to check that a server +is alive before syncing browse lists. we don't want to delay the SMB +NetServerEnum api just because the server has gone down: we have too +much else to do. + +a NAME_QUERY_CONFIRM is just a name query to see whether the server is +alive. these queries are sent out by samba's WINS server side, to verify +its netbios name database of all machines that have registered with it. + +we don't normally expect a negative response from such a query, although +we may do so if the query was sent to another WINS server. the registered +entry should be removed if we receive a negative response. + + +/************************************************************************* + response_name_query_register() + *************************************************************************/ + +this function receives responses to samba 'states' +NAME_REGISTER_CHALLENGE. + +NAME_REGISTER_CHALLENGE: name query a server to establish whether to +hand over a unique name to another server that asked for that name. + +if a positive response is received to the name query, this indicates +that the current owner still wants the name. we therefore refresh +the name records indicating that the current owner still wants it, +and we inform the potential owner (the other host) that they cannot +have it. + +if a negative response is received, this indicates that for some +reason (for example, it may have just released the name or the +WINS server may have had out-of-date records) the current owner +does not want the name. in this instance, the name records are +updated to give this unique name to the other host that wanted +it, and the other host is informed that they can have it. + +a failure to respond on the part of the current owner of the name +is dealt with in dead_netbios_entry(). + + +/************************************************************************* + response_name_status_check() + *************************************************************************/ + +this function receives responses to samba 'states' NAME_STATUS_CHECK +and NAME_STATUS_MASTER_CHECK + +NAME_STATUS_MASTER_CHECK: name status a primary domain controller, + confirm its domain and then initiate syncing + its browse list. + +NAME_STATUS_CHECK: same as NAME_STATUS_MASTER_CHECK except the name status + is issued to a master browser. + +if we don't know what workgroup a server is responsible for, but we +know that there is a master browser at a certain ip, we can issue a +name status check. from the response received, there will be +a master browser netbios entry. this will allow us to synchronise +browse lists with that machine and then add the information to the +correct part of samba's workgroup - server database. + + +/************************************************************************* + response_server_check() + *************************************************************************/ + +this function receives responses to samba 'states' NAME_QUERY_MST_SRV_CHK, +NAME_QUERY_SRV_CHK and NAME_QUERY_FIND_MST. + +NAME_QUERY_FIND_MST: issued as a broadcast when we wish to find out all + master browsers (i.e all servers that have registered + the NetBIOS name ^1^2__MSBROWSE__^2(0x1), and then + issue a NAME_STATUS_MASTER_CHECK on any servers that + respond, which will initiate a sync browse lists. + +NAME_QUERY_MST_SRV_CHK: same as a NAME_QUERY_FIND_MST except this is sent + to a primary domain controller. + +NAME_QUERY_SRV_CHK: same as a NAME_QUERY_MST_SRV_CHK except this is sent to + a master browser. + +the purpose of each of these states is to do a broadcast name query, or +a name query directed at a WINS server, then to all hosts that respond, +we issue a name status check, which will confirm for us the workgroup +or domain name, and then initiate issuing a sync browse list call with +that server. + +a NAME_QUERY_SRV_CHK is sent when samba receives a list of backup +browsers. it checks to see if that server is alive (by doing a +name query on a server) and then syncs browse lists with it. + + +/************************************************************************* + response_name_reg() + *************************************************************************/ + +this function is responsible for dealing with samba's registration +attempts, by broadcast to a local subnet, or point-to-point with +another WINS server. + +please note that it cannot cope with END-NODE CHALLENGE REGISTRATION +RESPONSEs at present. + +when a response is received, samba determines if the response is a +positive or a negative one. if it is a positive response, the name +is added to samba's database. + +when a negative response is received, samba will remove the name +from its database. if, however, the name is a browser type (0x1b is +a primary domain controller type name; or 0x1d, which is a master +browser type name) then it must also stop being a primary domain +controller or master browser respectively, depending on what kind +of name was rejected. + +(when no response is received, then expire_netbios_response_entries() +is expected to deal with this. the only case that is dealt with here +at present is when the registration was done by broadcast. if there +is no challenge to the broadcast registration, it is implicitly +assumed that claiming the name is acceptable). + + +/************************************************************************* + response_name_release() + *************************************************************************/ + +this function is responsible for removing samba's NetBIOS name when +samba contacts another WINS server with which it had registered the +name. + +only positive name releases are expected and dealt with. exactly what +to do if a negative name release (i.e someone says 'oi! you have to +keep that name!') is received is uncertain. + +(when no response is received, then expire_netbios_response_entries() +is expected to deal with this. if there is no challenge to the release +of the name, the name is then removed from that subnet's NetBIOS +name database). + |