Help me to understand "hosts" file and socket communication via bluetooth
-
I have read several tutorials how to manipulate (Linux) "hosts" file. I need to "connect" Raspberry Pi to PC , using bluetooth. I really do not care which is server or client end of the connection. I like to test each piece of hardware by doing local loopback first. I would like to run such local loopback on each end of the connection separately , using separate code application. I do have the basic - socket / bind / read / write working. I understand that local "loopback" IP is in range 127.0.0.0 to 127.255.255.255. 1. Can I "bind" created socket to name "localhost" to run such local loopback - using 32 bit address? 2. How can I do same using 128 bit address, ip6 protocol ? AKA how to put ip6 "name" into my C++ code ? ::1 has "multiple" names 3. Is doing "remote loopback" feasible? Ideally - instruct LOCAL hardware to connect via socket to REMOTE hardware running in "remote loopback"? Or in another words - is there REMOTE loopback IP ? Or do I have to have remote software to emulate such loopback? 4. The communication / socket from (local) RPi woudl "connect / bind " to which IP on remote (PC) hardware? 5. Similar - the communication / socket from (local) PC woudl bind to which IP on now remote - RPi hardware? Item 5 and 6 would be in "simplex" communication - each one way only - at least for now. I have not found a decent description of ip6 "names" . For example -what does ip6-allnodes accomplish ? Here is a copy of RPi hosts file
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters127.0.1.1 ARM
10.0.1.76 RPIAnd here is hosts file on PC
127.0.0.1 localhost
127.0.1.1 z-desktopThe following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersMinor comments / questions The RPi has only ONE bluetooth hardware , but in hosts it has TWO IP addresses / names The PC has THREE bluetooth hardware, but blutooth manager will identify only TWO. Appreciate any constructive comments.
-
I have read several tutorials how to manipulate (Linux) "hosts" file. I need to "connect" Raspberry Pi to PC , using bluetooth. I really do not care which is server or client end of the connection. I like to test each piece of hardware by doing local loopback first. I would like to run such local loopback on each end of the connection separately , using separate code application. I do have the basic - socket / bind / read / write working. I understand that local "loopback" IP is in range 127.0.0.0 to 127.255.255.255. 1. Can I "bind" created socket to name "localhost" to run such local loopback - using 32 bit address? 2. How can I do same using 128 bit address, ip6 protocol ? AKA how to put ip6 "name" into my C++ code ? ::1 has "multiple" names 3. Is doing "remote loopback" feasible? Ideally - instruct LOCAL hardware to connect via socket to REMOTE hardware running in "remote loopback"? Or in another words - is there REMOTE loopback IP ? Or do I have to have remote software to emulate such loopback? 4. The communication / socket from (local) RPi woudl "connect / bind " to which IP on remote (PC) hardware? 5. Similar - the communication / socket from (local) PC woudl bind to which IP on now remote - RPi hardware? Item 5 and 6 would be in "simplex" communication - each one way only - at least for now. I have not found a decent description of ip6 "names" . For example -what does ip6-allnodes accomplish ? Here is a copy of RPi hosts file
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters127.0.1.1 ARM
10.0.1.76 RPIAnd here is hosts file on PC
127.0.0.1 localhost
127.0.1.1 z-desktopThe following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersMinor comments / questions The RPi has only ONE bluetooth hardware , but in hosts it has TWO IP addresses / names The PC has THREE bluetooth hardware, but blutooth manager will identify only TWO. Appreciate any constructive comments.
The loopback address is always 127.0.0.1, as shown in your hosts files. 1. You bind sockets to IP addresses, not names. So use the appropriate system call to find the correct local address for the name you wish to bind. 2. Use the first name in the hosts file. Multiple names just provide aliases for the address. 3. Not sure what you mean. Loopback by definition is local to the hardware on which the code is running. 4. The client should connect to the server's public address. That is to say, when the server sets up a listening socket, the client needs to know the server's listening address. In internet terms that would be the address found by using DNS lookups. In your tests you just need to hardcode the address in the client code. 5. see 4. 6. The other IP6 names are (probably) use for broadcast messages. Check the relevant RFC document for details.
-
The loopback address is always 127.0.0.1, as shown in your hosts files. 1. You bind sockets to IP addresses, not names. So use the appropriate system call to find the correct local address for the name you wish to bind. 2. Use the first name in the hosts file. Multiple names just provide aliases for the address. 3. Not sure what you mean. Loopback by definition is local to the hardware on which the code is running. 4. The client should connect to the server's public address. That is to say, when the server sets up a listening socket, the client needs to know the server's listening address. In internet terms that would be the address found by using DNS lookups. In your tests you just need to hardcode the address in the client code. 5. see 4. 6. The other IP6 names are (probably) use for broadcast messages. Check the relevant RFC document for details.
Thanks Richard. I need to keep this short, but Like you to know you are no being ignored. I do understand the 127.0.0.1 as loop back IP . I am still not sure when IP is "internal protocol" and when Internet protocol. I take it 127.0.0.1 is an "internal " "IP" address - singular. I have the "conversion from "nost" name to such IP address done. So far it looks as I have to have TWO sockets - one as "plain network" (with loopback 127.0.0.1) and the other as an addition of "RF communication " for future full usage of bluetooth. I have the "network" socket figured out and working on the RF socket. I assume they have to be "tied together" somehow. As far as "remote loopback " goes - such "feature is part of RS232 / EIA standard allowing the originator of the connection to set the receiving end to "remote loop back" to pass the data from the RS232 hardware back to sender without sending it to the attached hardware. That way the actual transmission path is used both ways without need to communicate to remote system. Perhaps it can be done by controlling the "RF socket" connection itself. But later. Back to entertain visiting grand kids. Sorry.
-
The loopback address is always 127.0.0.1, as shown in your hosts files. 1. You bind sockets to IP addresses, not names. So use the appropriate system call to find the correct local address for the name you wish to bind. 2. Use the first name in the hosts file. Multiple names just provide aliases for the address. 3. Not sure what you mean. Loopback by definition is local to the hardware on which the code is running. 4. The client should connect to the server's public address. That is to say, when the server sets up a listening socket, the client needs to know the server's listening address. In internet terms that would be the address found by using DNS lookups. In your tests you just need to hardcode the address in the client code. 5. see 4. 6. The other IP6 names are (probably) use for broadcast messages. Check the relevant RFC document for details.
Update Start with The “server” ( local PC) allocates a “socket” with parameters s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); and is set ( waits ) to receive connection from “client”. It is unclear , but logical that “client terminal “ should be specified - perhaps “client (host) bluetooth address – array of six entries should be entered somewhere – as a “remote address”. I am using term “terminal X address “ to get away from confusing usage of “address” which can be IP (generic network) or bluetooth address. So far the term “host” is associated with IP name / address and is really not specific to client or server. The bluetooth address seems to have no relations to IP address. Then The “client” (Rpi) software allocates a “socket” with parameters socket_descriptor_local = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); the “client” - (Rpi ) software originates connection to server ( connect to server bluetooth terminal address ) when data is ready to be passed onto “server” . For now I am passing simple message(s) only. It is also unclear how / where to specify “client terminal”. Currently I have two bluetooth hardware (USB) of different class connected. I do not see how "socket" cares about bluetooth class. I managed to run both software and received expected errors. Like to know WHO , not why, actually generates the "connection refused" - logically it should came from "connecting to RECEIVING terminal" , but I am not so sure how to identify that.
-
Update Start with The “server” ( local PC) allocates a “socket” with parameters s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); and is set ( waits ) to receive connection from “client”. It is unclear , but logical that “client terminal “ should be specified - perhaps “client (host) bluetooth address – array of six entries should be entered somewhere – as a “remote address”. I am using term “terminal X address “ to get away from confusing usage of “address” which can be IP (generic network) or bluetooth address. So far the term “host” is associated with IP name / address and is really not specific to client or server. The bluetooth address seems to have no relations to IP address. Then The “client” (Rpi) software allocates a “socket” with parameters socket_descriptor_local = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); the “client” - (Rpi ) software originates connection to server ( connect to server bluetooth terminal address ) when data is ready to be passed onto “server” . For now I am passing simple message(s) only. It is also unclear how / where to specify “client terminal”. Currently I have two bluetooth hardware (USB) of different class connected. I do not see how "socket" cares about bluetooth class. I managed to run both software and received expected errors. Like to know WHO , not why, actually generates the "connection refused" - logically it should came from "connecting to RECEIVING terminal" , but I am not so sure how to identify that.
The sequence should be something like:
To accept connections, the following steps are performed by the server side:
-
A socket is created with socket(2).
-
The socket is bound to a local address using bind(2), so that
other sockets may be connect(2)ed to it. -
A willingness to accept incoming connections and a queue
limit for incoming connections are specified with listen(). -
Connections are accepted with accept(2).
as described at listen(2) - Linux manual page[^]. The client then connects by the following:
Creates the socket
Calls bind to bind the socket to the address of the server
Calls connect
starts sending messagesas described at bind(2) - Linux manual page[^]. I am not sure what special rules are needed when connecting via Bluetooth.
-
-
The sequence should be something like:
To accept connections, the following steps are performed by the server side:
-
A socket is created with socket(2).
-
The socket is bound to a local address using bind(2), so that
other sockets may be connect(2)ed to it. -
A willingness to accept incoming connections and a queue
limit for incoming connections are specified with listen(). -
Connections are accepted with accept(2).
as described at listen(2) - Linux manual page[^]. The client then connects by the following:
Creates the socket
Calls bind to bind the socket to the address of the server
Calls connect
starts sending messagesas described at bind(2) - Linux manual page[^]. I am not sure what special rules are needed when connecting via Bluetooth.
Yes, that is generally my understanding of "how to". Sure makes using socket clearer then working with "HCI". It seems that passing the parameters to "socket" call , especially the DOMAIN and PROTOCOL "bypasses" the "bind" call. I need to work on that. But I got the basic doing expected stuff. Addendum How is this for laymen "definitions "? socket is "high level layer" - overall manager of I/O . bind attaches such socket to "local host" (address) - IP network in general , bluetooth address as option of general. connect attaches such socket via "transmission patch " to "remote" hardware / host , again generally to network (using IP address) , bluetoooth as network specific option using bluetooth address.
-
-
The sequence should be something like:
To accept connections, the following steps are performed by the server side:
-
A socket is created with socket(2).
-
The socket is bound to a local address using bind(2), so that
other sockets may be connect(2)ed to it. -
A willingness to accept incoming connections and a queue
limit for incoming connections are specified with listen(). -
Connections are accepted with accept(2).
as described at listen(2) - Linux manual page[^]. The client then connects by the following:
Creates the socket
Calls bind to bind the socket to the address of the server
Calls connect
starts sending messagesas described at bind(2) - Linux manual page[^]. I am not sure what special rules are needed when connecting via Bluetooth.
I guess I have to establish "my model" first and use appropriate terminology. The objective is to display data processed on "embedded hardware" ( Raspberry Pi ) on PC. Hence (per attached note ) "Client (RPi ) requests a service ( display data passed to it ) from server." " TCP/IP enables peer-to-peer communication." Is very generic term used , however "peer-to- peer" is little misleading since it implies , to me , an equal function of each end of communication path - which "client / server " is NOT. TCP/IP is ONE part of actual implementation of the "transmission path " ( a generic term of describing the actuall communication path) - in this case I have TCP/IP and Bluetoooth RF participating in the "transmission path ". So in terminology of "communication " terms - I have a source - client - RPi communication / transmission path - TCP/IP and RF destination - server For simplicity I am going use SINGLE socket (DONE!) and the actaull communication - from source to destination can be also looked as "simplex" communication. The actaull passing of information between terminal points ( source / destination ) can be reversed. So much for theory. I am still trying to decipher the INDIVIDUAL function of parameters passed to "socket" Mainly the functions of DOMAIN parameter - either AF_x (Address family) or PF_x (Protocol family). I am unable to find decent definition of "AF_BLUETOOTH" DOMAIN parameter. (Time to find source code for "socket" function ) The puzzling part is PROTOCOL parameter by itself and its interaction with DOMAIN and TYPE.
The Client-Server Model
TCP/IP enables peer-to-peer communication. Computers can cooperate as equals or in any desired way. Most distributed applications have special roles. For example: Server waits for a client request. Client requests a service from server. -
-
I guess I have to establish "my model" first and use appropriate terminology. The objective is to display data processed on "embedded hardware" ( Raspberry Pi ) on PC. Hence (per attached note ) "Client (RPi ) requests a service ( display data passed to it ) from server." " TCP/IP enables peer-to-peer communication." Is very generic term used , however "peer-to- peer" is little misleading since it implies , to me , an equal function of each end of communication path - which "client / server " is NOT. TCP/IP is ONE part of actual implementation of the "transmission path " ( a generic term of describing the actuall communication path) - in this case I have TCP/IP and Bluetoooth RF participating in the "transmission path ". So in terminology of "communication " terms - I have a source - client - RPi communication / transmission path - TCP/IP and RF destination - server For simplicity I am going use SINGLE socket (DONE!) and the actaull communication - from source to destination can be also looked as "simplex" communication. The actaull passing of information between terminal points ( source / destination ) can be reversed. So much for theory. I am still trying to decipher the INDIVIDUAL function of parameters passed to "socket" Mainly the functions of DOMAIN parameter - either AF_x (Address family) or PF_x (Protocol family). I am unable to find decent definition of "AF_BLUETOOTH" DOMAIN parameter. (Time to find source code for "socket" function ) The puzzling part is PROTOCOL parameter by itself and its interaction with DOMAIN and TYPE.
The Client-Server Model
TCP/IP enables peer-to-peer communication. Computers can cooperate as equals or in any desired way. Most distributed applications have special roles. For example: Server waits for a client request. Client requests a service from server.There are plenty of samples around the internet that contain the source code of a simple socket program. The key being that it shows the sequence of events for both server and client. Adapting such samples to your own requirements is a fairly simple process. I do not have a current copy but I used one in the past in my professional life.
-
There are plenty of samples around the internet that contain the source code of a simple socket program. The key being that it shows the sequence of events for both server and client. Adapting such samples to your own requirements is a fairly simple process. I do not have a current copy but I used one in the past in my professional life.
SUCCESS ! Richard, thanks for your support. Learn few things about what now looks as easy coding. Managed to pass text message from client to server via bluetooth using socket with these parameters on BOTH ends: s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); However, not home yet. Some “behind the scenes" needs investigating. Given up on local loopback test for now. The complier complains about this assignment, loc_addr.rc_bdaddr = *BDADDR_ANY; but the application works as expected when the loc_addr.rc_bdaddr is NOT assigned, loc_addr.rc_family = AF_BLUETOOTH; loc_addr.rc_bdaddr = *BDADDR_ANY; loc_addr.rc_channel = (uint8_t) 1; In file included from ../src/RPI_BT_SERVER.cpp:54:0: ../src/RPI_BT_SERVER.cpp: In function ‘int main()’: ../src/RPI_BT_SERVER.cpp:133:26: error: taking address of temporary [-fpermissive] loc_addr.rc_bdaddr = *BDADDR_ANY; BTW taken form RFCOMM example, like to know what is the reason for the "temporary" note.
-
SUCCESS ! Richard, thanks for your support. Learn few things about what now looks as easy coding. Managed to pass text message from client to server via bluetooth using socket with these parameters on BOTH ends: s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); However, not home yet. Some “behind the scenes" needs investigating. Given up on local loopback test for now. The complier complains about this assignment, loc_addr.rc_bdaddr = *BDADDR_ANY; but the application works as expected when the loc_addr.rc_bdaddr is NOT assigned, loc_addr.rc_family = AF_BLUETOOTH; loc_addr.rc_bdaddr = *BDADDR_ANY; loc_addr.rc_channel = (uint8_t) 1; In file included from ../src/RPI_BT_SERVER.cpp:54:0: ../src/RPI_BT_SERVER.cpp: In function ‘int main()’: ../src/RPI_BT_SERVER.cpp:133:26: error: taking address of temporary [-fpermissive] loc_addr.rc_bdaddr = *BDADDR_ANY; BTW taken form RFCOMM example, like to know what is the reason for the "temporary" note.
-