家里三个神秘IP查了几个月，结果是我自己干的

路由器后台里躺着三个IP地址，没有主机名，没有反向解析记录，Home Assistant里也找不到任何设备认领它们。其中一个已经折磨了我好几个月，我隐约觉得，那可能是台电视。

正常做法是去问DNS服务器，但这条路很快就走不通了。于是我换了个思路：把Home Assistant的虚拟机变成一台网络探针，让设备自己开口说话。整个过程只需要curl，不用先装NetAlertX或者ntopng这类工具。

唯一能一次问出答案的工具，偏偏下线了

查"这个IP是什么"的时候，我第一站永远是Technitium。它的查询日志会精确记录某个客户端在解析什么域名，一台智能电视向厂商服务器回连，几秒钟就会暴露自己。但那天我通过Technitium的MCP服务发出的每一次调用，返回的都是同一句话：{"error":"fetch failed"}。

DNS本身没问题。对192.168.4.59的查询能正常解析，说明挂掉的是MCP端点，不是解析器。原因完全在我自己身上——当时我正在重建Technitium做高可用，那个本可以一次查询解决问题的DNS服务器，正因为我在让它变得更可靠而处于离线状态。

所以我需要换一条路，从一个根本看不见局域网的会话里，去看清自己的网络。

借一台本来就住在局域网里的机器

我在Proxmox上以虚拟机形式跑Home Assistant OS，并且启用了QEMU guest agent。这个agent的存在是为了让Proxmox能上报虚拟机IP、干净地关机，但它同时允许宿主机在guest内部执行命令。任何能跟Proxmox API通信的东西，都能借用这台虚拟机的网络位置。

我的调用链是这样的：从云端会话到Proxmox API，再到guest agent，最后落到局域网里的一台shell。如果从Proxmox宿主机shell出发，等价操作就是一行命令：qm guest exec [guest编号] -- ping -c 2 目标IP地址。

这套做法并不依赖Proxmox。同一子网里任何带curl的Linux机器都能干这活，树莓派或者闲置的LXC容器都行。guest agent只是在你没有别的办法时的版本。有一个坑要注意：HAOS的shell是BusyBox，相当简陋，没有python3，而且nc在我明知端口开放的情况下也不会报告成功。我在netcat上白耗了两轮才放弃。

神秘设备会装死，先戳一下

第一轮很简单：三个IP全ping一遍，读邻居表，再各做一次反向查询。结果只有一个响应，而且所有PTR记录都返回空。192.168.4.22的邻居表项显示为REACHABLE，另外两个的反向解析则直接报NXDOMAIN。

看起来.44和.81像是离线了。其实没有。处于省电模式的Wi-Fi客户端会睡过ICMP ping，但一次TCP连接尝试往往能把它们唤醒。于是我把curl请求和ping配成一对，然后立刻读邻居表：curl -s -m 2 http://192.168.4.44/ ; ip neigh show 192.168.4.44。

两个设备瞬间都活了。用TCP刺激唤醒、紧接着查ip neigh，这个组合被证明是可靠的套路。现在我拿到了三个设备的MAC地址，真正的揭面从这里开始。

curl的退出码，凑合能当端口扫描器用

没有nmap的时候，就自己想办法。没有nmap、没有netcat、没有Python，curl的退出码能告诉我哪些端口开着、哪些关着。退出码7表示拒绝，28表示超时，其他任何值都意味着有东西应答了。粗糙，但管用。

我写了个循环，依次探测7000、8008、8009、8443、5555、6668这几个端口。在.22这台设备上，8009和8443返回了退出码52（空响应，说明有东西在监听），7000返回0。8009是Google Cast，7000是AirPlay。在我家里，同时跑这两个的东西就是电视。

让设备自己报出名字

Google Cast设备在8008端口暴露了一个无需认证的信息端点，它会直接告诉你自己是什么。请求http://192.168.4.22:8008/setup/eureka_info，返回内容里包含"name":"Office TV"，Cast构建版本3.72.446070，以及一个SSDP UDN：329f5c1c-907b-2cff-d3e1-f3a9ebb94f94。

AirPlay在7000端口的信息端点返回的是二进制plist，格式难看，但只要把字符串抽出来仍然可读。请求http://192.168.4.22:7000/info并管道给strings，里面出现了"TCL"、"Android"、"Smart TV Pro"，以及一个固件构建日期：2026年3月11日。

然后我回到Home Assistant，设备注册表里列着media_player.office_tv，标注为TCL Smart TV Pro，其Cast ID与那个SSDP UDN完全一致。三个独立来源，指向同一个答案。折磨了我几个月的那台电视，就是我自己办公室里的Google TV。这事是我自己造成的，大部分吧。

之后我又在电视的设置页面上做了复核。MAC地址对得上，只是IP地址变了，因为DHCP重新分配了一个。IP地址充其量是个糟糕的标识符，最好还是盯住MAC地址。

MAC地址补上了剩下的拼图

另外两台设备完全没有开放端口。我在每台上扫了大约35个端口，包括5555（ADB）和6668（涂鸦的本地协议），每一个都是拒绝或过滤状态。它们也都没出现在Home Assistant里：我写了个模板循环遍历注册表中全部14台设备，零命中。这两台是纯客户端设备，所以我手上只剩下MAC地址。

MAC地址的前三个字节（OUI）标识制造商。我的第一反应是用Python的netaddr包做离线查询，结果直接失败：NotRegisteredError: OUI 2890554 not registered!。那是TCL的Wi-Fi模块前缀，2025年4月注册，而随包附带的IEEE数据库显然没能覆盖到它。