Recently I encountered several questions on SO regarding working with sockets on a very low level. Here's an example. While looking for an answer, I realised that sockets have relatively low capabilities on OSI Level 2. On Linux, we can specify a protocol when creating a socket, but obviously not all Level 2 protocols are present in the list.
While it is possible to assemble and send an ethernet frame, it's (presumably) not possible to send a 802.11 packet - though it looks like wifi device drivers do convert ethernet frames to wifi packets and vice versa.
This made me wonder, if there are more possibilities in reading and writing directly to device files like eht0, ath0? Is it a socket implementation who usually writes to these files, or a device driver? And who's on receiving side - a NIC driver, a peripheral bus controller?
Related
I know that bluetooth uses hoping, and because of this difficult to intercept traffic.
Сan i put my dong into monitoring mode?
If for example are 30 devices nearby, and i will always listen just one bluetooth channel, and my dongle works in monitor mode, should i get sometimes some data?
Can i use for these purposes Hcidump or tcpdump?
If I understand correctly, if bluetooth device does not have a password, i can directly interact with its services(with hcitool and tmux).?
I read that i can watch the battery level, device name, and other information.
PS: sorry for bad english.
It is possible to monitor traffic between Bluetooth devices but I am quite sure that your default laptop dongle is not capable of doing that.
Before establishing connection between two Bluetooth devices, they send connection request/response packets on primary advertising channels (37th, 38th, 39th channel). You need to capture these packets to learn hopping pattern, connection interval and etc. After receiving packets, you can monitor insecure Bluetooth connections. However it is hard to monitor 30 device simultaneously because you need to make time division between each connection.
Let's answer your questions.
It might be possible but you need to write driver level code.
It might be possible. As I mentioned, it is good approach to capture connection request/response packets before monitoring devices.
I have no idea about these tools.
To manipulate services, you need to know service handle and duplicate GATT client's mac address. I am not sure that, this method will work.
I'm writing an application that interfaces with Bluetooth devices using Headset Profile. These devices primarily communicate via AT commands send over a Serial Port Profile (SPP) connection. SPP is directly on top of RFCOMM.
My concern is whether or not I am guaranteed to receive "whole" packets (AT commands), or if there is a possibility that I will need to be able to handle an AT command split across multiple packets.
Furthermore, if the RFCOMM protocol does not guarantee this, does the protocol stack do any processing to guarantee receiving "whole" AT commands? I am using BlueZ 5.46 on a Linux 4.12 kernel.
If possible, please reference the standard or an external source that details how RFCOMM guarantees this so I can learn a bit more about it.
I'm currently planning to do cheap wireless video transmission from mobile, battery powered devices to a base station.
To be clear, I did not do any tests so far, but because the required range will be quite large (>2000ft/600m) and by my experience on wifi I'm quite sure this won't work using a standard wifi connection using standard german wifi cards (max 100mW power). Wifi requires a two-way connection to keep associated with each other.
However, I don't really care if my device can receive data from my base station.
I can use large antennas on the receiving side (base station) but not on the device. So I thought what is not there can't break. So my intention is to send 802.11 packets without beeing connected.
How can I send and receive 802.11 frames in Linux without the network stack adding or removing any data (or even dropping the packet because it does not know how to handle it) ?
An 802.11 frame at it's lowest level consists of the following fields:
Preamble | PLCP header | MPDU (MAC PDU)
My intent is to control anything that's inside the MPDU.
Thanks in advance.
I want to implement a driver in Linux, that has a Ethernet stack but the data going out on hardware will be a serial port. Basically, I want to register my serial port as a Ethernet driver. Does anyone have any idea if this is possible?
I want to be able to push IPv6 and/or UDP packets out of the serial port and in a similar way receive the packets via a serial port and pass it up the Ethernet stack.
I do not want to use the solution of serial-to-ethernet convertors(external hardware that convert a serial port to a ethernet port) but have that in my PC itself.
I tried PPP over the serial port and it works well. I am also told that I can do FTP, HTTP etc using the PPP. Reference to this - http://www.faqs.org/docs/Linux-HOWTO/Serial-Laplink-HOWTO.html
I have tried to hack the code from a RealTek Ethernet driver with a serial driver but not able to gain much success. Rather I do not know the stack of either to actually do anything meaningful. Any advice, guidance or tutorials would be helpful.
Thanks
Aditya
You need to get back to de basics on networking, the way I understand you question is: "I have a serial port and I want to use is an Ethernet link". Sorry to crush your dreams but you don't have the real hardware to do so, I'll elaborate on it.
A serial connection is a physical connection that requires 3 wires (at least) tx, rx and ground. On the logical side you have an IC that coverts binary data into signals that are represented by discrete voltage ranges.
Ethernet is a layer 2 protocol, the layer 1 is provided by the technology used to transmit the signals (coax, up, fiber etc.) As you might see by now, you need a different set of hardware to convert the logical Ethernet frames into a stream of digital numbers, in fact this is call framing.
Since Ethernet has been an easy to use protocol it has been implemented as e preferred protocol for many network operators, of course one of the biggest is PPPoE where you have a PPP session over an Ethernet link. Of course this won't work with your example neither since you're trying the opposite.
If you're just learning and have all the time in the world you can attempt to write your own Ethernet framer over serial lines. This means you need to implement IEEE802.3 into the driver and then you need to serialize the data to push it as a stream of bits over the serial line. Of course note the following drawbacks:
Your driver won't be able to fully support Ethernet, you need some support at hardware level to implement some signaling (example, auto negotiation, CSMA/CD, etc)
You driver will be pretty much useless unless you back in time where 115.2kbps is top speed in data transfers
IMHO there are more exciting projects that you can pick up in the networking field for device drivers. You can for example attempt to buy a NIC and develop the device driver for it from scratch and you can optimize certain areas. Finally, remember that most of the Ethernet implementations are now done in hardware so you don't have to do anything but filling a few registers on the MAC and voila!
SLIP and PPP do already what you want.
I've been playing around with an ethernet protocol (not IP) constructed using
socket(PF_PACKET, SOCK_RAW, ether_type)
I have a small problem. I've got a packet constructed that has the source and destination mac set to my local cards mac that I've also bound the socket to with bind.
I can receive packets fine from the network.
I'm able to send packets to the degree where I see them appear in wireshark.
However, my listening app doesn't see those packets. It is able to see packets from other sources on the network however.
I should point out that my mac addresses do appear to be being sent in the correct byte order.
Can you send packets to yourself?
Do network cards not loopback?
Does the linux kernel do something special at the IP level for loopback and because I'm below that, ignore me?
Yes, IP "loopback" packets, as you put it, are treated specially. They're looped back internally, not sent out through the interface. So ethernet-level loopback, in this sense, is a special case that doesn't normally need to be supported. Some old 10Mbit ethernet cards were even half-duplex, so it couldn't have worked on that hardware :).
On the other hand, you can buy/make loopback adaptor cables to test network cards. So it must be possible on (hopefully all) modern hardware. And people have used them under linux with AF_PACKET (evidence, though no more details, here).
I guess the next question would be whether your switch supports this. A dumb hub would have to support it, but there's room for a modern switch to get confused. Or maybe disallowing it in fear of an infinite loop of packets.