某客户反应，部分用户偶尔会间歇性断网，时间很短，办公基本上没影响，但是直播的时候会有问题。
远程登录路由器观察，没发现异常，于是登录核心交换机查看日志，发现19端口一直在报错：%ARP-4-DUPADDR:Duplicate address 192.168.1.1 in interface Vlan 101 port GigabitEthernet 0/19，Sourced by fc04.xxxx.bb6b。
意思是19口上有IP冲突了，并且提供了冲突来源的MAC地址，但是这个提示，真实的意思应该是有电脑中了ARP病毒。
在服务器上用工具扫描了一下，把这个MAC地址对应的IP地址找出来，应该是开着系统防火墙的缘故，没有扫描到是什么操作系统。ping一下这个192.168.1.89，一眼就能看到不正常的状态。
无所谓了，让这个用户来找我们比较容易，于是在交换机上限制这个MAC地址的通讯：mac-address filtering fc04.xxxx.bb6b vlan 101，再执行命令：show mac-address-table filtering，确认这个MAC地址已经被过滤了，再ping 192.168.1.89，已经无法通讯了。
等这个用户来找我们，就是给他远程杀毒，大热天的省得上门服务了，大家都方便，嘿嘿。
#IT##网络工程师#
这年头写个漫画爬虫都心力憔悴
写了个自用小爬虫，追漫画用，每天刷一次，稳定运行了几个月。
然而，漫画网站是在 cloudflare 上，突然之间就被识别为 BOT，拒绝访问了。可让我非常意外的是，同样的 IP，浏览器访问一点问题都没有！
查了前人资料，说是 TLS 指纹技术。顺藤摸瓜，发现了每个客户端都有指纹，难怪相同的 UA/Cookie，curl 不行，浏览器却可以，因为两者的 SSL 指纹是不一样的。
于是乎，剩下了二个解决方案：
1. 修改爬虫客户端，模仿浏览器的行为。但问题是，cloudflare 的 tls 指纹算法并没有公开，网上也搜不到相关信息，应该不可能用 JA3 这种开源解决方案。靠猜测编程，是非常不靠谱的行为，遂放弃。
2. 把 google chrome 当成代理服务器，运行一个网页，用 websocket 和爬虫通讯，然后用 ajax 去访问目标站点。
用 AJAX 暂时解决了问题，也不知道几个月后，会不会出现新的问题。怀念以前 http 不加密一把梭的年代，什么都是明文，简单明了直接。
昨天碰到的问题比较棘手，不知道我的分析是否正确。
事情是这样的：一位客户运行在他的客户工厂的系统时不时出现故障，该系统通过三菱的PLC检测开关量输入并通过WiFi无线网络定时上报给服务器。
服务器定时接收到的开关量状态概率性的与实际情况不符。
客户直接将开关量输入状态固定为0，服务器仍会偶尔收到1的状态。
客户分析了一段时间之后，始终找不到原因，最后求助于我。
听完客户的问题描述，我确认了以下问题：
1) PLC将开关量输入状态用代码固定为0，排除了因输入检测未去抖动或者抗干扰差导致的误检测。
2) 服务器通过三菱提供的dll实现TCP/IP通信读取数据，而且只有一个线程操作该dll，排除了因服务器软件资源访问未做互斥处理导致的错误。
随后，我让客户在网上购买了一个带端口镜像功能的交换机，让他按照附图更新一下系统；
测试电脑安排wireshark抓包工具，将抓取的数据包按照时间段自动保存到硬盘。
昨天测试了一天，抓到了几次异常数据，他发给我让我分析。
从数据上来看，
PLC启动了5001和5556两个TCP端口，服务器作为TCP客户端与5556端口的服务端建立长链接，并定时与PLC交互查询位状态，该交互协议并非三菱公开的MC协议，应该是另一套未公开的协议，正常情况下，PLC返回02 30 03 33 33的二进制数据，当出现异常误检测到1时，PLC返回了02 31 03 33 34。
同时，网络上还有另一台设备与PLC的5001端口采用MC协议定时查询位单元。
通过tcp[20:3]==80:00:10筛选采用MC协议的数据，没有发现有返回异常数据。
通过这些分析，我可以断定PLC通过MC协议交互的数据没有问题，而通过另一个未公开协议以dll方式向外提供数据偶尔会出现传输出错。
只是三菱这么大的品牌，其产品拥有大量的用户，怎么会有这样的错误。
