I just read about the mac address at wiki.
The mac address should uniquely identify a wifi device and is a 48-bit number separated in two parts, while the first 24-bit are reserved for manufacturer identification. The last 24-bit are actually the unique ones, which can be set through the manufacturer.
2^24 = 16,7 millions
How can this be a unique id, when for example Apple alone is selling over 50 million wifi devices in one quarter, according to techcrunch.com. I would also think, that Apple has only one manufacturer for their wifi chips. Also today cameras, cars, watches.. ah everything has wifi.
They could gather a new manufacturer id, but it seems to me, that every manufacturer has really only one. Also the relation of 24-bit manufacturer and 24-bit device I don't understand. Why should there be as many manufacturers as devices.
So, how can this be a unique id?
First 2^24 are purchasable, so technically 2^48 is the limit.
This 48-bit address space contains potentially 2^48 or 281,474,976,710,656 possible MAC addresses.
Related
I want to know is it possible to track physically or Get Information
about the smartphone by just knowing its MAC address connected to our
Wifi.
Yes, it is see e.g. https://ssd.eff.org/en/module/problem-mobile-phones
Smartphones send their MAC address which is visible for surroundings near by, a bit like car register plate in concrete world.
But you don't know who is in the car just based on the plate and the car could be empty.
With smartphone its more likely that same person is using the machine. So if you are able to link MAC address with another personal identifier like name, phone number, SIM info then tracking is better enabled.
Is there a way to uniquely identify a BTLE device (something like hardware ID)? I have 2 hardware BTLE devices and 2 soft BTLE devices (using CBCentralManager). All these devices are sending same UUID.
I want to identify the exact BTLE device when all the devices are lying near me. Any clue?
The devices should have unique Bluetooth addresses. If they don't then you wouldn't be able to properly connect to them without them interfering with each other. However, with BTLE it's possible for a device to have a randomized address for privacy (but those conform to a particular pattern so you can detect if you get that kind of address). The address is 6 bytes and is usually displayed in hex (ex A1-B2-C3-D4-E5-F6). The first 2 bytes usually indicate the manufacturer.
UPDATE: My answer is valid for most BLE usage, but as the question is tagged ios you may want to look at this other answer about getting a unique id on ios as a possible way to get the bluetooth address
For a simulation project, I am trying to simulate multiple MAC addresses from a single physical adapter. What I basically want is to send raw WiFi frames (both, data as well as management) for two virtual MAC addresses so that they both associate with a wireless AP. To the AP they should appear as if two different wireless devices/adapters (with different MAC addresses) have associated with it and are sending traffic. I just wanted to confirm if this seems feasible. I have achieved the same thing with wired LAN in the past but want to confirm the same for WiFi.
Thanks,
Yes, it's feasible. Make sure the virtual MAC addresses aren't random but in an acceptable format - http://en.wikipedia.org/wiki/MAC_address, otherwise the AP might reject the connection attempt.
We're looking to develop a mobile website. On this mobile website, we'd like to automatically populate a user's location (with proper fallback) based on their IP address. I'm aware of geocoding a location based on IP address (mapping to latitude, longitude and then getting the location with that information).
However, I'm curious how accurate this information is? Are mobile devices assigned IPs when they utilize 3G, EDGE, and GPRS connections? I think so. If that is so, does it map to a relatively accurate location? It doesn't have to be spot on, but relatively accurate would be nice.
Short answer: No.
The network assigns an IP address to the phone when the PDP context is activated (activation of PDP context is telecomms-speak for 'asking for packet data services'). It can be changed under network control, but this usually only happens when the connection has been dormant for some time.
You need to bear in mind that a typical mobile network may have several million users, and since signaling (i.e. address reconfiguration and the like) doesn't generate revenue, but costs the network scarce radio resources, it gets avoided as far as possible.
There is a further issue. Due to the architecture of mobile networks, if you have a visitor to a country who is operating using the roaming service with their home operator, they will in fact 'appear' to be in their home country. This is because the mobile device always connects to the internet through a node called the GGSN in their home network.
This is a major issue for websites which must deal with rightsholders. As an example, the BBC iPlayer service allows people located in the UK to 'catch up' on any BBC TV or radio content free of charge. In many cases, TV rights are geographically licensed, so the BBC is required to make every effort to ensure that the service is only available to users located in the UK.
This is, as I have explained above, impossible for mobile users. If I am using the SIM card of a UK network, I will 'appear' by geolocation to be in the UK regardless of where I actually am in the world.
This is not so much of a problem as yet: streaming a TV program over a 3G connection when roaming in a foreign network is prohibitively expensive (could easily be $100 or upwards for a single program), so this theoretical problem doesn't arise very often as yet. However, as roaming data costs fall (and everyone knows they will), it will become a real issue.
New smart phones (like Apple's iPhone) generally have web browsers that support HTML5 and/or some other form of client-side geolocation.
HTML5, for example, has the ability to geolocate the computer or mobile device based on a) position of the device's GPS, b) Wifi Triangulation and then c) IP address.
This is a client-side approach, and the browser will ask the user if they wish to share their location with you (which may or may not be a deal-breaker for you), but it is capable of providing < 20m accuracy.
See: About Geolocation in HTML 5
I'm curious how the windows device manager obtains the hardware IDs for a device, even though no device driver may be loaded for the device yet. Anybody have a clue on how Windows goes on about this?
On a related note, I am interested in supporting language localization for the software we are writing; is it possible for a device and/or driver to report back its friendly name and description in a localized fashion? Is there a common practice for this already?
Thanks for your time.
First, to understand the order of drivers being loaded, you're recommended to switch the Device Manager into View | Devices by Connection mode.
As you would notice, the devices are located below their bus driver. For PCI devices, it'll be "PCI bus". For USB devices, it would be their USB hub. Each bus driver has its own idea about how the identifier strings should be formatted:
Device Instance Id
Hardware Ids
Compatible Ids
Location, etc.
It returns them in response to IRP_MN_QUERY_ID (BusQueryInstanceID, BusQueryHardwareIDs, BusQueryCompatibleIDs) and IRP_MN_QUERY_DEVICE_TEXT (DeviceTextDescription, DeviceTextLocationInformation etc.)
Of course, since the bus driver enumerated the devices (i.e. created the child devices you're seeing) in the first place (through whatever standard interface appropriate for the bus; e.g. 'Get Device/String Descriptor' on USB), it knows their vendor ID, product ID etc.
The device's driver does not have to be loaded at this time. In fact, it can't be loaded. The device IDs are precisely what instructs the PnP system as to which driver matches the device.
As to localization:
Unlike IRP_MN_QUERY_ID, which provides opaque strings intended for device matching, the IRP_MN_QUERY_DEVICE_TEXT information was indeed intended to be localized. For that purpose, you receive the requested Locale ID (LCID) in the input data (Parameters.QueryDeviceText.LocaleId).
[As Alphaneo noted, a USB hub driver might pass this LCID onwards to the USB device (within a Get String Descriptor request), hoping that the USB device itself has localized strings.]
The top level process is called enumeration. Most modern device buses support a mechanism that lets the OS query the buss and determine what devices are connected to the bus.
The PCI family of buses all support enumeration. The PCI bus has a special enumeration space just for this. This is where "Plug-n-Play" ID's come from.
The device id's uniquely identify a device on the bus and enable the OS to find the correct driver for that device.
Other buses, including USB and FireWire have enumeration strategies
Device ID, is a combination of information given from the device. For example, for a USB device, the string is based on the VID and PID (Vendor ID and Product ID). Now, this cannot happen if no driver is loaded. Atleast some driver, bus driver would have to be loaded for the OS to get the Device ID.
Now, for language support, I guess for WDM driver, there is a QUERY_LANG or something, I dont remember properly, alternatively some devices like USB, have Language ID support. This language ID determines the language of the Product descriptor string.
Please note that there is a difference between the hardware identifier/serial number and the true unique hardware ID. Maybe this will explain it better:
http://www.soft.tahionic.com/download-hdd_id/hardware%20ID%20programmer%27s%20DLL.html