Excessive device authorization sets

General Discussions
,
21

No results for eeprom here’s what I see in those directories though:

ps157:~$ sudo find / -name eeprom
ps157:~$ sudo find / -name i2c   
/sys/kernel/debug/tracing/events/i2c
/sys/bus/i2c
ps157:~$ cd /sys/bus/i2c
ps157:/sys/bus/i2c$ ls -al
drwxr-xr-x    4 root     root             0 Jan  1 00:00 .
drwxr-xr-x   23 root     root             0 Jan  1 00:00 ..
drwxr-xr-x    2 root     root             0 Jan  1 00:00 devices
drwxr-xr-x   11 root     root             0 Jan  1 00:00 drivers
-rw-r--r--    1 root     root          4096 Jan  1 00:02 drivers_autoprobe
--w-------    1 root     root          4096 Jan  1 00:02 drivers_probe
--w-------    1 root     root          4096 Jan  1 00:00 uevent
ps157:/sys/bus/i2c$ cd devices/
ps157:/sys/bus/i2c/devices$ ls -al
drwxr-xr-x    2 root     root             0 Jan  1 00:00 .
drwxr-xr-x    4 root     root             0 Jan  1 00:00 ..
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 0-0024 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 0-0034 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0034
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 0-0050 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 0-0070 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0070
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 2-0054 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0054
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 2-0055 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0055
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 2-0056 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0056
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 2-0057 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0057
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 i2c-0 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 i2c-1 -> ../../../devices/platform/ocp/4802a000.i2c/i2c-1
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 i2c-2 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2
ps157:/sys/bus/i2c/devices$
22

depending on your kernel version it might be nvmem somewhere rather than eeprom

23

I do see nvmem but nothing in either of the files/directories

ps157:~$ sudo find / -name nvmem
/sys/devices/platform/ocp/44e3e000.rtc/rtc/rtc0/omap_rtc_scratch0/nvmem
/sys/bus/nvmem

ps157:/sys/bus/nvmem$ ls -al
drwxr-xr-x    4 root     root             0 Jan  1 00:00 .
drwxr-xr-x   23 root     root             0 Jan  1 00:00 ..
drwxr-xr-x    2 root     root             0 Jan  1 00:00 devices
drwxr-xr-x    2 root     root             0 Jan  1 00:00 drivers
-rw-r--r--    1 root     root          4096 Jan  1 00:05 drivers_autoprobe
--w-------    1 root     root          4096 Jan  1 00:05 drivers_probe
--w-------    1 root     root          4096 Jan  1 00:00 uevent
ps157:/sys/bus/nvmem$ cd devices/
ps157:/sys/bus/nvmem/devices$ ls -al
drwxr-xr-x    2 root     root             0 Jan  1 00:00 .
drwxr-xr-x    4 root     root             0 Jan  1 00:00 ..
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 omap_rtc_scratch0 -> ../../../devices/platform/ocp/44e3e000.rtc/rtc/rtc0/omap_rtc_scratch0
24

As an example of things to check, below are some links to not exactly what you use but should highlight what you should be double checking on your OS build to see if you have eeprom fully configured in your kernel.

Looks like there is some kernel device tree config you can check

looks like there is also kernel driver config to check you have enabled

25

Thanks, will take a look at the kernel configurations and see if we can pull the serial number instead.

As I’ve been decommissioning and re-authorizing the devices creating this issue, I am noticing that all of the duplicate devices reporting with the same mac address are coming from a single customer in South Korea. And a few of the devices we have records for, seemingly had different MAC addresses when we tested them in our factory prior to delivery.

Is it at all possible that there’s a networking device in the middle of their devices and the mender server that’s reporting out the same address? Otherwise, since their hostnames and IP Addresses are different would that mean that they all have BBB’s with the same eth0 network interface?

26

As I’ve been decommissioning and re-authorizing the devices creating this issue, I am noticing that all of the duplicate devices reporting with the same mac address are coming from a single customer in South Korea. And a few of the devices we have records for, seemingly had different MAC addresses when we tested them in our factory prior to delivery.

thats intriguing

Is it at all possible that there’s a networking device in the middle of their devices and the mender server that’s reporting out the same address? Otherwise, since their hostnames and IP Addresses are different would that mean that they all have BBB’s with the same eth0 network interface?

i don’t think that any intermediate networking device is involved here as the mender device identity data (which you are using BBB MAC address for) is passed at the application layer of the OSI model and protected between BBB and server with TLS in transit. I would of expected them to need to get access to the root filesystem of your device to be able to attempt to modify it in some way, or rewrite the eeprom data. I should state I am in no-way a security professional so could be wrong.

1 Like