I was trying to figure out the BT Address of a device and then got in trouble while finding that it follows IEEE 802-2014 standard as well as MAC Address hence which is the difference within MAC Address and BT Address:
Can a phone device (let's say) have BT Address and MAC Address?
If so which would be the impact of having either same MAC Address or BT Address within 2 devices?
Bluetooth addresses are indeed drawn from the same space as the MAC addresses you might be more familiar with -- those on Ethernet adapters or 802.11 WiFi interfaces. In order to assign an address to a Bluetooth interface on say, a phone, the manufacturer must purchase the right to do so from the IEEE in the same way that they must register some portion of the space to assign MAC addresses to 802.11 interfaces. Because of this, it's common to say "Bluetooth MAC", at least in my own experience. The Bluetooth Core Specification says this:
The BD_ADDR shall be created in accordance with Section 9.2 (“48-bit univer-
sal LAN MAC addresses”) of the IEEE 802-2001 standard (http://stan-
dards.ieee.org/getieee802/download/802-2001.pdf) and using a valid
Organizationally Unique Identifier (OUI) obtained from the IEEE Registration
Authority (see http://standards.ieee.org/regauth/oui/forms/ and sections 9 and
9.1 of the IEEE 802-2001 specification).
If a phone has both a Bluetooth and 802.11 chipset, it must have unique hardware identifiers for both. In practice, what I have seen is that manufacturers will assign MAC address X to the 802.11 interface, and MAC address X+1 to the Bluetooth interface on the same phone or vice versa; for example, WiFi MAC 00:11:22:33:44:00 and Bluetooth MAC 00:11:22:33:44:01. There's nothing stating that they must do this, but it seems to be a pretty standard way of divvying up their IEEE allocations.
Related
Does anybody have the BLE Advertising Packet format that shows the relation (e.g. a hierarchy graph) among packet preamble, MAC address, and CRC fields? A graph that shows the length of bits for each field would be the best.
This is written in the Bluetooth Core
Specification https://www.bluetooth.com/specifications/specs/core-specification/ in the Link Layer chapter, section 2.1.
The advertising bluetooth device address is found in section 2.3.1.1 (ADV_IND).
has linux reserved io port numbers for all manufactured devices.
I have devices like intel built-in network card. or another device I have for wifi (usb) from realtek.
On linux repository on github, device drivers use specific io ports to register. And kernel assign those ports to device driver. device drivers normally request for ports using call to request_region function. so for some ethernet device it requests like following
for (id_port = 0x110 ; id_port < 0x200; id_port += 0x10)
{
if (!request_region(id_port, 1, "3c509-control"))
continue;
outb(0x00, id_port);
outb(0xff, id_port);
if (inb(id_port) & 0x01)
break;
else
release_region(id_port, 1);
}
above starts with 0x110 to 0x200, any port can be assigned in this range by kernel to driver and appear in /proc/ioports file means driver is using that io port by the time of success return from request_region.
Question : So my question is has linux assigned io ports to all manufactured devices usable with kernel 5.7 or latest kernel version?
Question : What if I want to write device driver for any device. How can I find the io ports number range to request to. I dont not expect that I have to look into kernel code and find similer driver port range. so How can I find that io port number range. how to achieve this first step required in writing device driver (any device. be it wifi internet device or ethernet device)
Question : So my question is has linux assigned io ports to all manufactured devices usable with kernel 5.7 or latest kernel version?
No.
Question : What if I want to write device driver for any device. How can I find the io ports number range to request to.
You ask the user for it. After all it's the user who set them using jumpers on the ISA card.
Here's a picture of an old Sound Blaster card (taken from Wikipedia, I'm too lazy to rummage around in my basement now). I've highlighted a specific area in the picture:
That jumper header I highlighted: That's the port configuration jumper. As a user you literally connect two of the pins with a jumper connector and that connects a specific address line that comes from the card connectors to the circuitry on the rest of the card. This address line is part of the AT bus port I/O scheme. The user sets this jumper, writes down the number and then tells the driver, which number it was set to. That's how AT style I/O ports.
Or the driver uses one of the well known port numbers for specific hardware (like network controllers) that dates back to the era, where ISA style ports were still are thing. Also there's old ISA-P'n'P where the BIOS and the add-in cards would negotiate the port assignments at power up, before the OS even started. You can read those port numbers with the ISA-P'n'P API provided by the kernel.
We no longer use this kind of hardware in practice! Except for legacy and retro computing purposes.
Over a quarter of century ago, the old AT / ISA bus was superseeded with PCI. Today we use PCIe which, from the point of view of software still looks like PCI. One of the important things about PCI was, that it completely dropped the whole concept of ports.
With ISA what you had were 8 data lines and 16 address lines, plus two read/write enable lines, one for memory mapped I/O and one for port I/O. You can find the details here https://archive.is/3jjZj. But what happens when you're reading from say, port 0x0104, it would physically set the bit pattern of 0x0104 to the address lines on the ISA bus, pull low the read enable line, and then read the voltage level on the data lines. And all of that is implemented as an actual set of instructions of the x86: https://c9x.me/x86/html/file_module_x86_id_139.html
Now look at the PCI bus: There's no longer separate data and address lines. Instead read/write commands would be sent, and everything happens through memory mappings. PCI devices have something called a BAR: a Base Address Register. This is configured by the PCI root complex and assigns the hardware the region of actual physical bus addresses where it appears. The OS has to get those BAR information from the PCI root complex. The driver uses the PCI IDs to have the hardware discovered and the BAR information told to it. It can then do memory reads/writes to talk to the hardware. No I/O ports involved. And that is just the lowest level. USB and Ethernet happen a lot further up. USB is quite abstract, as is Ethernet.
Your other question Looking for driver developer datasheet of Intel(R) Core(TM) i5-2450M CPU # 2.50GHz suggests, that you have some serious misconceptions of what is actually going on. You were asking about USB devices, and Ethernet ports. Neither of those in any way directly interact with this part of the computer.
Your question per se is interesting. But we're also running into a massive XYZ problem here; it's worse than an XY problem; you're asking about X, although you want to solve Y. But Y isn't even the problem you're dealing with in the first place.
You're obviously smart, and curious, and I applaud that. But I have to tell you, that you've to backtrack quite a bit, to clear up some of the misconceptions you have.
OFFICIAL BLE SPEC STATES:
If System ID generated based on a Bluetooth Device Address, it is required to be done as follows. System ID and the Bluetooth Device Address have a very similar structure: a Bluetooth Device Address is 48 bits in length and consists of a 24 bit Company Assigned Identifier (manufacturer defined identifier) concatenated with a 24 bit Company Identifier (OUI). In order to encapsulate a Bluetooth Device Address as System ID, the Company Identifier is concatenated with 0xFFFE followed by the Company Assigned Identifier of the Bluetooth Address.
Question:
If a device's BDA is 12:34:56:9A:BC:DE, then what is the correct format for System ID?
0x123456 FFFE 9ABCDE or
0x563412 FEFF DEBC9A or
0xDEBC9A FFFE 563412
Thanks
Can someone tell me the difference between Mac Address and Bluetooth Address in a BLE device?
Do they both have to be unique?
I've read that changing the bluetooth address affects the mac address?
Is it possible to have a different bluetooth address, but the same mac address?
What you are referring to Bluetooth Address is what more popularly known as static address which is a randomly generated address while the MAC address is unique and public.
The MAC address is created as per the IEEE 802-2001 standards in accordance with section 9.2: "48-bit universal LAN MAC addresses". They have a valid Organizationally Unique Identifier (OUI) obtained from the IEEE Registration Authority.
The MAC address is divided into the following two fields:
company_assigned field is contained in the 24 LSb.
company_id field is contained in the 24 MSb.
Whereas, A static address is a 48-bit randomly generated address created considering these requirements:
The two most significant bits of the static address shall be equal to ‘1’
Not all bits of the random part of the static address shall be equal to ‘1’
Not all bits of the random part of the static address shall be equal to ‘0’
I'm new to Linux Kernel programming and driver programming. I'm working with madwifi drivers, on Linux with kernel version 2.6.32-37 and wish to extract the MAC address of an interface inside the driver code. I know this information supposed to be found in the netdevice structure fields, but not quite sure which one of them is the right one.
My questions are:
What is the difference between the *dev an the *real?
Which one of them should I use? (they're both in use in different parts of the code and I don't understand when should I use the former and when the latter).
Quoting from http://www.makelinux.net/ldd3/chp-17-sect-3:
unsigned char dev_addr[MAX_ADDR_LEN];
Hardware (MAC) address length and device hardware addresses. The Ethernet address length is six octets (we are referring to the hardware ID of the interface board), and the broadcast address is made up of six 0xff octets; ether_setup arranges for these values to be correct. The device address, on the other hand, must be read from the interface board in a device-specific way, and the driver should copy it to dev_addr. The hardware address is used to generate correct Ethernet headers before the packet is handed over to the driver for transmission. The snull device doesn't use a physical interface, and it invents its own hardware address.
Hope that helps.
There is code in a network driver to access/set MAC address.
There is even a callback defined in net_device_ops
.ndo_set_mac_address = netdev_set_mac_address
It is handled differently on each network device depending on HW registers architecture.
For example for Xilinx AXI MAC address is written to net_device structure and specific HW registers of network controller:
static void axienet_set_mac_address(struct net_device *ndev, void *address)
{
struct axienet_local *lp = netdev_priv(ndev);
if (address)
memcpy(ndev->dev_addr, address, ETH_ALEN);
if (!is_valid_ether_addr(ndev->dev_addr))
eth_random_addr(ndev->dev_addr);
/* Set up unicast MAC address filter set its mac address */
axienet_iow(lp, XAE_UAW0_OFFSET,
(ndev->dev_addr[0]) |
(ndev->dev_addr[1] << 8) |
(ndev->dev_addr[2] << 16) |
(ndev->dev_addr[3] << 24));
axienet_iow(lp, XAE_UAW1_OFFSET,
(((axienet_ior(lp, XAE_UAW1_OFFSET)) &
~XAE_UAW1_UNICASTADDR_MASK) |
(ndev->dev_addr[4] |
(ndev->dev_addr[5] << 8))));
}
So once MAC address is set, commands like ifconfig don't get it from device driver accessing HW registers, but from net_device structure.