CODEWITHSUNDEEP
clinuxsocketslinux-kernelbluez
Ace
Ace

Reputation: 1601

What is the internal mechanics of socket() function?

I am trying to use the BlueZ HCI function:

int hci_open_dev(int dev_id) {...}

which internally tries to create a socket like this:

socket(AF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC, BTPROTO_HCI);

I tried to understand the linux kernel code for socket() but feel lost.

Id like to know what exactly does it mean to create a socket for the given domain (AF_BLUETOOTH), data transmission type (SOCK_RAW) and protocol (BTPROTO_HCI).

The man page just states that it takes these params, creates a socket and returns a device descriptor.

But id like to understand what exactly happens and the exact kernel steps involved in creating a socket.

Upvotes: 3

Views: 1245

Answers (2)

paulsm4
paulsm4

Reputation: 121619

Please look here: it's a good high-level description of the BlueZ Linux implemention of the Bluetooth stack:

Linux Without Wires The Basics of Bluetooth. Specifically, it gives you a good overview of these BlueZ kernel drivers:

  • bluetooth.ko, which contains core infrastructure of BlueZ. It exports sockets of the Bluetooth family AF_BLUETOOTH. All BlueZ modules utilise its services.

  • Bluetooth HCI packets are transported over UART or USB. The corresponding BlueZ HCI implementation is hci_uart.ko and hci_usb.ko.

  • The L2CAP layer of Bluetooth, which is responsible for segmentation, reassembly and protocol multiplexing, is implemented by l2cap.ko.

  • With the help of bnep.ko, TCP/IP applications can run over Bluetooth. This emulates an Ethernet port over the L2CAP layer. The kernel thread named kbnepd is responsible for BNEP connections.

  • rfcomm.ko is responsible for running serial port applications like the terminal. This emulates serial ports over the L2CAP layer. The kernel thread named krfcommd is responsible for RFCOMM connections.

  • hidp.ko implements the HID (human interface device) layer. The user mode daemon hidd allows BlueZ to handle input devices like Bluetooth mice.

  • sco.ko implements the synchronous connection oriented (SCO) layer to handle audio. SCO connections do not specify a channel to connect to a remote host; only the host address is specified.

Another excellent resource is the BlueZ project page:

Upvotes: 2

prog-fh
prog-fh

Reputation: 16805

Here is a very broad description (hope that helps understanding the main scheme).
Kernel developers will probably be horrified...

A socket is common abstract interface for many different communication means.
It provides many generic operations, such as closing, sending/receiving data, setting/retrieving options, which can be used on almost any kind of socket.

Creating a socket implies specifying the exact properties of this communication means.
It's a bit like the instantiation of a concrete type implementing an interface.

These properties are first organised by protocol families; this is the first argument to the socket() call.
For example:

  • PF_INET is used for communications relying on IPv4,
  • PF_INET6 is used for communications relying on IPv6,
  • PF_LOCAL is used for inter-process communication inside the system (kind of pipe),
  • PF_NETLINK is used for communication with the OS kernel,
  • PF_PACKET is used for direct communication with network interfaces,
  • ... (there exist many of them)

Once a protocol family is chosen, you have to specify, which protocol you want to use amongst those which are provided by this family; this is the second argument to the socket() call.
For example:

  • SOCK_DGRAM is used for UDP over IPv4 or IPv6, or distinct messages in PF_LOCAL,
  • SOCK_STREAM is used for TCP over IPv4 or IPv6, or a continuous byte stream in PF_LOCAL,
  • SOCK_RAW, accesses directly is the raw underlying protocol in the family if any (IPv4, or IPv6 for example),
  • ... (each family can provide many on them)

Some protocols can accept some variants or some restrictions; this is the third argument to the socket() call.
Often 0 is sufficient, but for example we can find:

  • PF_PACKET, SOCK_RAW, htons(ETH_P_ALL) to capture any kind of network packet received on a network interface,
  • PF_PACKET, SOCK_RAW, htons(ETH_P_ARP) to capture only ARP frames,

When we ask for the creation of a socket with these three arguments, the operating system creates an internal resource associated with the socket handle which will be obtained.
Of course, the exact structure of this resource depends on the chosen family/protocol/variant, and it is associated to kernel callbacks which are specific to it.
Each time an operation in invoked on this socket (through a system call), the specific callback will be called.

Upvotes: 3

Related Questions