Mat*_*ips 19 networking mac-address code
在您控制硬件配置并可以确定具有相同硬件模型的所有设备确实为其网络接口具有唯一 MAC 地址的情况下，编写使用该假设的代码是否有任何缺点？（基于一些回复的注意事项：我不会使用这个假设编写网络代码。这只是一种为每个设备提供 uuid 的低接触方式，而无需手动生成和更新设备 HDD 之前的 id部署到现场）
背后的故事是我正在研究为客户端实现私有硬件 IOT 类型的实现。我们将提供一组具有网络功能的硬件设备以安装在远程位置。然后，这些设备将通过发送消息与 API 进行通信。为了降低设置的复杂性，我希望在消息中发送设备上网络接口的 MAC 地址，将这些消息与 API 端的“device_id”联系起来。我的想法是，通过在使用前不必在设备上设置它，它可以在正常操作期间进行查询。我可以安全地假设我们可以确定每个设备的 MAC 地址实际上是唯一的，
Fra*_*mas 34
根据您在配置期间可以确认的声明，制造商 MAC 实际上在您创建的设备网络中是唯一的（这本身并不是确定的，即使它应该是确定的），您可能可以继续进行，但请考虑以下问题：
您是否使用 MAC 进行安全检查（身份验证、授权）？如果是这样，MAC 是不够的。甚至不要考虑它。使用加密结构，并安全地传输任何身份验证请求。
48 位足够宽吗？可能是，但值得一问。
您是否需要通过更换网卡来修复设备？
如果您确实更换了整个设备或更换了它的网卡，您是否需要能够将新地址与数据库中的现有密钥相关联，以确保部署位置的数据收集的连续性？
是否有任何用户（授权或未授权）可以在 ROM、驱动程序或操作系统级别更改网卡的维护接口？如果攻击者要修改 MAC，他们可能会在您的数据中引入缺陷。
您的数据是否会使用 MAC 作为密钥与其他数据源连接？
除了简单地导航设备连接到的第 2 层 LAN（有线或无线）之外，您是否还会将 MAC 用于任何网络目的？
您的设备所连接的 LAN 是专用网络，还是大量临时客户端（如员工手机）将连接到的 LAN？
如果你的答案是
NO, yes, no, no, no, no, no, private
那么我想不出你的计划有什么真正的缺陷。
请记住，您不需要全局唯一的 MAC 来实现这一点；您只需要确保调用您的 API 的 Internet 设备子集是唯一的。就像分配在两个不同城市的重复 nic 不会因为它们位于不同的 LAN 上而发生冲突一样，如果 MAC 不调用您的 API，您就不会在 MAC 上发生数据库密钥冲突。
MAC 可能存在，也将存在重复。这有几个原因，一个是它们不需要（全球）唯一。
MAC 在本地网络上必须是唯一的，这样 ARP/NDP 才能完成它的工作，并且交换机知道将传入的数据报发送到哪里。通常（不一定）该先决条件得到满足并且一切正常，仅仅是因为在同一个 LAN 上具有两个相同的 MAC（即使它们不是唯一的）的可能性非常低。
另一个原因是存在的设备比地址多。虽然 48 位地址听起来好像每个人都有足够的地址直到日子结束，但事实并非如此。
地址空间被分成两个 24 位的一半（稍微复杂一些，但让我们忽略琐碎的细节）。一半是 OUI，你可以在 IEEE 注册并分配给你的公司，大约 2000 美元。剩下的 24 位，你可以为所欲为。当然你可以注册几个OUI，大玩家就是这么做的。
以英特尔为例。他们总共注册了 7 个 OUI，总共给了他们 1.16 亿个地址。
我的电脑主板（使用 X99 芯片组）以及我的笔记本电脑主板以及我在过去 10 到 15 年间拥有的每台基于 x86 的电脑的主板都将英特尔网卡作为芯片组的一部分。当然，世界上有超过 1.16 亿台基于 Intel 的计算机。因此，它们的 MAC不可能是唯一的（在全局唯一的意义上）。
此外，据报道，呃……更便宜……制造商只是从其他人的 OUI 中“窃取”地址。换句话说，他们只是使用了一些随机地址。我也听说过制造商对完整的产品系列使用相同的地址。这两者都不是真的符合或没有多大意义，但是你能做些什么。这些网卡存在。再说一遍：如果地址用于它们的目的，它成为实际问题的可能性仍然很低，您甚至需要在同一个 LAN 上有两个它们才能注意到。
解决方案可能比您想象的要简单。您的 IoT 设备很可能需要一些时间概念，通常时间是通过 NTP 自动获取的。NTP 的典型精度在微秒范围内（是的，那是微，而不是毫）。我只是跑去ntpq -c rl确定并被告知 2 -20。
您的两个设备在精确相同的微秒内首次打开的可能性非常低。这通常是有可能发生的（特别是如果你在很短的时间内卖出了数百万个，恭喜你成功！），当然。但这不太可能——实际上它不会发生。因此，在首次启动永久存储后节省时间。
IoT 设备的启动时间在每台设备上都相同。但那根本不是真的。
给定高分辨率计时器，即使在同一设备上，每次启动时间也有明显差异。它可能只有几个时钟滴答不同（或者几十万，如果你读到像 CPU 的时间戳计数器这样的东西），所以不是很独特，但它确实增加了一些熵。
同样，connect您第一次访问 API 站点时返回所需的时间会略有不同，但每次都会有所不同。同样，getaddrinfo第一次查找您的 Web API 的主机名时，每个设备将花费略有不同的可测量时间。
将这三个或四个熵源（MAC 地址、首次开机时间、首次启动时间、连接时间）连接起来，并从中计算出一个哈希值。为此目的，MD5 会做得很好。在那里，你是独一无二的。
虽然这并不能真正保证唯一性，但它“几乎”保证了唯一性，失败的可能性可以忽略不计。您必须拥有两台具有相同 MAC 的设备，它们在同一微秒内首次打开，并用完全相同的时间启动和连接到您的站点。那不会发生。如果发生这种情况，您应该立即开始玩彩票，因为在所有情况下，您都可以保证中奖。
但是，如果“不会发生”不足以作为保证，只需在每个设备第一次访问您的 Web API 时为其传递一个按顺序递增的数字（在服务器上生成）。让设备存储该号码，完成。