@INCerry 读出来内容可能和实际文件内容不一样，并且没有任何报错。

开启选项后遇到读取文件会有静默错误

@iTYC Surveillance Station 有版本要求吧。有条件的可以提交工单问问，没条件等待 Device Pack 更新通道下发吧。

@KATTEN 不太清楚这个

@KATTEN 群晖技术支持回复如下：

1.将摄影机的编码格式调整为 H.264

请先透过摄影机的网页管理介面或官方 App ，将影像编码格式由 H.265 改为 H.264 。
（目前遇到此问题的摄影机在 H.265 相关功能上可能无法正常建立连线。）

2.手动安装附件中的 Device Pack

请前往 Surveillance Station > 应用程式中心 > 手动安装，并安装附件中提供的 Device Pack 版本。
重新新增摄影机

3.安装完成后，请再次尝试于 Surveillance Station 中新增摄影机，确认是否可以正常完成设定。

-----

实际测试使用 H.265 配合最新的 Device Pack (6.2.7-6722) 已经可以正常添加摄像头。

Device Pack (6.2.7-6722)：
https://drive.google.com/file/d/16wVHGxmRmCDW1Zeep2f8GAIgxAmFbsu3/view?usp=sharing

@KATTEN "您的问题已经提交给相关工程师查看，一般需要 1~2 个工作天，烦请您耐心等待。"

@KATTEN 已经提交工单了，等待回复。

有同样的问题，型号也是 IPC48DW

@tool2dx 正常流程是客户提供信息，机房在设备加白。不过黑产直接利用了设备检测漏洞绕过了这个正常流程。没有 80 端口 TCP 阻断。

@COW 是的

认同上面关于协议开销其实可以忽略不计, 个人认为主要的 PPPoE 问题是在很多实现上都是单线程的。

上面各位提到的 cgo 开销问题可以用魔法缓解下

https://github.com/petermattis/fastcgo

前几年用 TypeScript 实现的 SSTAP, 包含了 TUN 操作、 精简 TCP 协议栈。
https://github.com/Srar/node-tap

猜测可能是硬件多次中断在短时间内会合并成一个中断来通知，这个是 intel 网卡关于中断合并的表述:

```
When an event occurs, the adapter generates an interrupt, which allows the driver to handle the packet. At greater link speeds, more interrupts are created, and CPU rates also increase. This results in poor system performance. When you use a higher ITR setting, the interrupt rate is lower, and the result is better system performance.
```

看下 /ipv6/settings 的 Disable IPv6 是不是勾着

尝试下 runtime.KeepAlive? 可能是被 gc 收走了

ARP 代理尝试下，可能是广播域问题