using public MAC address

We are using public MAC that was purchased from IEEE (20 low bits are available for us to set and the upper 28 bits are constant to value assigned to us by the IEEE).

We also see this code in your library (components/ble/nrf_ble_scan.c):

static uint16_t nrf_ble_scan_address_type_decode(uint8_t const * p_addr)
{
    uint8_t addr_type = p_addr[0];
    addr_type = addr_type >> 6;
    addr_type &= 0x03;
    switch (addr_type)
    {
        case 0:
        return BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_NON_RESOLVABLE;

        case 1:
        return BLE_GAP_ADDR_TYPE_PUBLIC;

        case 2:
        return BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE;

        case 3:
        return BLE_GAP_ADDR_TYPE_RANDOM_STATIC;

        default:
        return BLE_ERROR_GAP_INVALID_BLE_ADDR;
    }
}

1. isn't this code conflict with the use of IEEE MAC addresses?

2. if our MAC is "uint8_t mac[6];" then these two bits settings the address type should be bits 6:7 in mac[5] or bits 6:7 in mac[0]?

Parents
  • Hello,

    At first glance, this looks a bit weird, I agree. 

    I believe it is the bit 6:7 in mac[0], but I have not tested this in Zephyr yet. I am not 100% sure it is the same endianness as it was in the nRF5 SDK. I will check this tomorrow. 

    Some places I find indications that these bits can be anything (assigned by IEEE), while other places it looks like they need to be 0b01.

    I am sorry. I ran out of time today, but I will try to clear this up tomorrow. I have seen this question a couple of times before, but I don't remember what the conclusion was. I will try to dig up some old cases tomorrow. 

    Best regards,

    Edvin

Reply
  • Hello,

    At first glance, this looks a bit weird, I agree. 

    I believe it is the bit 6:7 in mac[0], but I have not tested this in Zephyr yet. I am not 100% sure it is the same endianness as it was in the nRF5 SDK. I will check this tomorrow. 

    Some places I find indications that these bits can be anything (assigned by IEEE), while other places it looks like they need to be 0b01.

    I am sorry. I ran out of time today, but I will try to clear this up tomorrow. I have seen this question a couple of times before, but I don't remember what the conclusion was. I will try to dig up some old cases tomorrow. 

    Best regards,

    Edvin

Children
No Data
Related