How to get a TCP/IP packet over an serial connection (Bluetooth) - c

I'm developing an TCP/IP stack that will run on another device connected by bluetooth.
But I want to test against an working Stack. My testing scenario would be:
MY DEVICE TCP/IP STACK --------------BLUETOOTH ----------------- WINDOWS/MAC TCP/IP Stack.
Anyone have any idea how could I write IP packets over an Bluetooth connection on Linux/Windows or mac ??

One way is you could establish a ppp connection between the device and the PC over bluetooth first. For this you will need support for ppp on the device side. Once you are able to dial-up and establish a ppp connection, tcp/ip can be run over ppp.
These links may be useful (although they are specific to linux):
http://www.daybefore.net/bluetooth_ppp.html
http://www.rpgameplace.de/blog/index.php?/archives/19-Networking-over-Bluetooth-using-BlueZPPP.html

Related

Force connection on specific USB port/symlink

I am planning to use Dump1090 and I want to have 2 RTLSDR dongles on the same computer, always plugged into the same USB port. I am planning to assign a symlink "adsb" to the port for the RTL dongle that has an ADS-B antenna connected to it. Is there a way to force the connection on this specific USB port?
By default, the code takes the first device available.
Thank you
https://github.com/antirez/dump1090/blob/master/dump1090.c

ARM MBED CoAP example mot opening port

I have succesfully built the CoAP protocol example for ARM mbed (https://developer.mbed.org/teams/sandbox/code/coap-example/file/0681e205d0e9/) on a K64F board. It comes out of the box, except for the server name (coap.me) changed to an internal IP address.
I see that it runs correctly and connects to the network:
[EasyConnect] Using Ethernet
[EasyConnect] Connected to Network successfully
[EasyConnect] IP address 192.168.1.15
[EasyConnect] MAC address 0e:43:54:d9:7c:71
Connected to the network. Opening a socket...
Calculated message length: 11 bytes
Starting server
Sent 11 bytes to coap://192.168.1.10:5683
I have set a computer that can connect to it. It can ping correctly to the board and I see that the ARP is negotiating with the correct MAC address.
I have launched an NMAP test and I see that the port is closed:
PORT STATE SERVICE
5683/udp closed unknown
If I set a CoAP client in the computer (Copper) I see no connection in the terminal.
What I am missing?
Moving this to the answer section as well, in case someone else runs into this problem.
If you want to use an mbed OS 5 device as a UDP server, make sure to call .bind() on the socket.

MAC Address of other wifi device in a wifi network

Is it possible to find the MAC address of all other wifi enabled device in a wifi network programmatically by using C or C++, if so then please tell me the way or direction, how can i do that Visual Studio 2012.
If they are in same LAN next to your device (no router/switch in the middle, The scope of ARP is link-layer.) you should use sending ARP packets to devices.
Address Resolution Protocol (ARP) is a telecommunications protocol
used for resolution of network layer addresses into link layer
addresses.
To send ARPs you can use Pcap or SendARP.

listening to communication between a local application and a device

I have a windows application on my PC which connects to a device over telnet. It sends a series of commands to the device, and the device responds to it.
Is there any way I can listen to what that program is writing to the device?
I tried using win32 socket programming to create a client that connects to the application. But, I get an error saying connection refused. When I analyze the traffic between the application and device on wireshark, I can see that the application uses different ports each time it reads from or writes to the telnet port(23) of the device.
Is there any way I can read the commands sent by the program to the device?
If you want to capture program's output to the device
programmatically, the right way is not to connect to the program (you
can't tap into an existing connection), but instead provide a server
that will stand for target device from the program's point of view.
It's going to work if the program can be configured to connect to the
device at different address and port. Write a "proxy" that listens on
some fixed port, and for any accepted connection, opens a client
connection to the real device. Then it should forward data in both
directions between the accepted connection from the program and the
client connection to the device. During this, you can also parse data
or do whatever you want with them, e.g. forward them to yet another
connection to another real device.

Network Discovery of Servers

Ok, so I understand that communication between a client computer and a server computer can be initiated in windows with the creation of a socket between the two computers, but every tutorial that I have seen depends on the End User knowing the IP address of the computer that they wish to connect to.
In local network LAN games, however, the clients somehow autodetect the server. How is this done? Does the client autocheck every possible IP, is there some sort of "GetDetectedIPs" api, etc?
Im looking for answers that can be implemented in standard WIN32 API in straight C. No MFC, .NET, or C++ please. Thank you.
The technique you need is called broadcasting. It's used, for example, in BOOTP and DHCP protocols.
Sending a packet with broadcast destination address results in it being received by all devices in LAN. Broadcast address is an IP address in which the host identification field is filled with ones:
bcast_addr = ~netmask | my_addr;
The discovery process is usually like follows:
The client sends a UDP datagram with broadcast destination address at specific port.
The server listens on this port and receives the datagram. Other computers discard it.
Server sends all the necessary info about itself to the client by a usual UDP datagram.
This is usually done with zero-conf. Microsoft version of it is Simple Service Discovery Protocol.
You could just let the client send an UDP packet to every IP in a specified range and let the server answer with another UDP packet.

Resources