Inquiring surrounding devices

The inquiring begins when the server, or client modules are registered with the hci_core module. The command is passed as follows:

 billotooth_register_mod

- this function sends the description of the the device, its id num and function responsible for the incoming packets.

so the hci_core, increments a list of modules and saves the address for the receiving function. After this the inquiry process really begins.

billotooth_inq_req

- this function is called to initiate the inquiry process. It fills a hci command packet with the inquiry code as follows:

 OGF = OGF_LINK_CTL (0x01)

 OCF = OCF_INQUIRY (0x0001)

 LAP =

    - lap[0] = 0x33

    - lap[1] = 0x8B

    - lap[2] = 0x9E
  LENGTH = INQUIRY_CP_SIZE (5)
  NUM_RESPONSES = 10

- then it sends to another function that will prep it to send down the pipe: billotooth_send_cmd(OGF_LINK_CTL, OCF_INQUIRY, INQUIRY_CP_SIZE, &ic);

where ic is a structure with the above parameters.

billotooth_send_cmd

- this function receives the OCF and OGF codes, the parameter length and the actual parameter and packs it all in a sk_buffer representing the hci command packet. The packet type is set and the new formed frame is sent to the hci_usb layer via billotooth_send_frame.

- it generates a response via a command complete event as soon as it's completed.

billotooth_send_frame

- this function takes out the owner field of the skb frame and passes to the hci_usb layer.

from this point the module completed the task of sending the inquiry command. We now have to wait for a inquiry result event to arrive.

Every device that receives an inquiry request event and is on visible mode responds the inquiry request with an inquiry result event.

This arrives at the billotooth_recv_frame.

billotooth_recv_frame

- this function receives an incoming frame in the form of a sk_buffer. It then look in the packet type field of the skb frame and switches to the appropriate function.

In this case the inquiry result event is, obviously, an event packet, so the billotooth_recv_frame calls the billotooth_event_packet function.

billotooth_event_packet

- this function, much like the billotooth_recv_frame hadles the event packets analyzing their type. In our case the ((hci_event_hdr *) skb->data)->evt is an EVT_INQUIRY_RESULT (0x02) so the message is passed along to the billotooth_inquiry_result_evt

billotooth_inquiry_result_evt

- this function handles the specific inquiry result event frame. Which tell how many and which bluetooth devices responded the inquiry request. Then updates a list of successful inquiries for future use.

billotooth_inquiry_list_update

- this function updates the inquiry list creating a dynamic list of devices in the list attribute of the inq_cache structure.

Now the module know how many devices are available and have some information to establish a connection with each and every one of them. In our case, this inquiry process has the sole purpose of gathering parameters to establish a connection, such as offset_clock for synchronization, and page scan settings.