最近遇到一个奇怪的问题，偶尔/tmp目录满了之后，一段时间内就一定会导致/tmp/resolv.conf.d/resolv.conf.auto文件被清空，dnsmasq无法找到上级转发DNS导致断网。 但是查看文件修改时间，如果可用空间一直充足，这个文件的修改时间也不会发生变化；一旦没有可用空间，这个文件就会被替换为空文件。
首先确认下该文件的同于是dnsmasq用于确认转发DNS请求的上级服务器，在luci中可以设定。
既然是写入luci，目标那基本就是netifd这个库；这个库主要职责就是OpenWrt中绝大多数和网络相关配置。
通过搜索我们可以确认__interface_write_dns_entries这个函数负责实际的写入resolve；通过下面其唯一调用者interface_write_resolv_conf的代码，我们就可以确认这件事的元凶。
前两个月在滚Arch的时候，发现滚完之后就无法将Redmi电脑音响设置为默认设备了，一番查找之后发现是PipeWire更新导致的。检查升级记录之后，确认从PipeWire 1.0.5开始就会出现这个问题，不管是用KDE的GUI设定为默认设备，还是通过PipeWire和WirePlumber的CLI都不行。
因为一直没空寻找具体原因，也就直接采用降级大法解决，但是经常会出现开机时初始化PipeWire卡死的问题，还是有点不方便；这两天终于抽空彻底排查了以下。
既然确定了出现问的版本，接下来的事情就很简单了。通过在git提交中搜寻，最终确定了引入该问题的commit是这个cc841a76。
查找的方法使用算法里面经典的图书管理员秘法之二分查找，最开始的时候还是手动二分查找的，后来想到vcs八成有自带这个功能，一搜发现是git bisect；果然大佬们早就想到这个排查bug的方法，今天又学到了新知识很开心，几次搜索之后就将出现问题的commit找到了。
既然找到了引入问题的commit，在提交官方处理的同时，revert这个commit就自然成为目前的dirty workaround了。
将pipewire打包项目从Arch仓库中clone下来，引入下面这个patch，之后在PKGBUILD中应用就大功告成了，具体方法：把下面的patch文件拷贝到仓库所在的文件夹中，在PKGBUILD的prepare方法中使用git apply ../0001-Revert-acp-add-more-properties-for-the-card.patch。
0001-Revert-acp-add-more-properties-for-the-card
最后使用pacman -U安装pipewire-audio这个包就足够了；无意中发现pipewire拆成多个包之后，不同的版本搭配其实也是可以用的，比如说pipewire-audio可以用老点的版本（最新版把我小主机内置音响更没了，虽然不常用吧，但是还是能用用的；等官方处理完这个问题再看看好了没吧，没好再去发个issue看看；主要是遇到了PipeWire的大版本更新，整个设备结构和Profile都变了，估计没这么好查了），其他包用最新版，除了开机时偶尔会卡死无法正常初始化，但是成功之后没有用出什么太大问题。
希望能够快点解决吧，这里留一个issue连接作为记录。
最近在诊断一些ICMP/DHCP问题，使用wireshark的display filter可以直接使用icmp6 or dhcpv6，但是如果是capture filter就不支持dhcpv6这样的语法了。
查询官网文档后发现，wireshark的display filter和capture filter还不一样，前者是wireshark自己解析的高级语法，后者是pcap语法，和tcpdump一样，只支持一些基础过滤。
ICMP/ICMPv6的过滤pcap直接支持，DHCP/DHCPv6使用固定的udp端口，所以可以通过端口过滤实现。
DHCP：56、57
DHCPv6：546、547
比如想过滤DHCPv6和ICMPv6的数据包，则过滤语法为icmp6 or (udp port 546 or 547 )
群里的Lihz菊苣最近在使用广州联通的时候遇到了宽带ICMP丢包/前几个包必丢的问题，经过一番研究确认了是光猫中802.1p的设定值的问题。
802.1p标记用于标记业务优先级，取值为0-7，优先级最低为0，最高为7，优先级越高，保障等级越高，具体可以参考Wiki。
如果是使用的光猫，通过超级管理员账号进入光猫后台，在WAN设置中找到Internet那一条WAN，编辑设置中的802.1p就可以了。
猫棒得看对应固件中支持否有相关选项，如果不支持的话可能暂时就无法修改。
找到对应设置的地方后，设置优先级为最高，即802.1p为7就没再出现问题。初步猜测原因可能是运营商设备设置错误（Lihz菊苣使用的广州联通还下发的是/64的IPv6 PD，很明显还没经过改造，不符合工信部最新的文件中关于IPv6二次下发的要求），直接使用了来自设备端的802.1p值0，即默认为最低优先级；在网络尖峰期，设备资源不足的时候因优先级不足而丢弃；按照通常配置该值一般都会被运营商覆盖掉。
这里记录一下默认值，因为都是使用了原厂/非对应运营商的光猫所以该值仅供参考。
广东电信（MA5671原厂固件）：0
广东联通（HS8145C5/2584.A/2021电信版）：0
广东联通（HS8145C5/180F.A/2019电信版）：0
PS：其他业务WAN的默认802.1p值
TR069：7
OTHER/IPTV：5
2024年的今天，在各方积极的推动下，大陆IPv6的覆盖率已经非常高了；三大运营商新开的家庭宽带已经默认开通了IPv6，现存的宽带也通过改造、下发配置、设备更新的方式在迅速的推进中；而移动端则更是激进，在4G部署时就已经是按照双栈网路配置，可以说是完全覆盖，连二级热点都已经做足了充分的兼容。
就在几天前，工信部还发了一份《两部门关于开展“网络去NAT”专项工作 进一步深化IPv6部署应用的通知》的文件，其中的目标是在进一步的推进IPv6的积极应用的同时，开始为IPv4的NAT网路去除做准备（目前阶段主要关注NAT44设备规模停止增长），同时也提出了IPv6子网标准化要求，要求对IPv6网路的二次分发功能做好兼容。
Ovear自己家的网络在大约五六年前，三大运营商开通IPv6基本厘清大陆内的交换路由后，就实装进来了，也算是见过IPv6早期混乱路由的资深用户了（笑）。
今天看到这个叫做socket的iptables 模块挺有意思的，但是没有找到太多的资料；想了想翻译一下文档，应该可以作为理解一下这个模块的作用的开始。
（然而发现并不能，所以又研究了一大堆相关的其他东西，就有了这一篇）
socket
如果能通过分组执行socket搜索后，能够找到一个打开的TCP/UDP
socket，则会进行匹配。具体来说，这会匹配一条已建立（establshed）
的链接，或者非0绑定监听器（不是监听0.0.0.0或者::/非INADDR_ANY）
socket（比如说有可能是非本地地址）。搜索是通过TCP/UDP分组的元
组进行的，对于ICMP/ICMPv6错误分组来说，则是使用内嵌在内的原始
TCP/UDP头部中的元组。
--transparent
忽略非透明（non-transparent） sockets.
--nowildcard
不要忽略绑定在'任意'地址的sockets。默认情况下，不会
匹配0绑定监听器；因为在那种情况下，本地的服务可以
拦截本来会被转发的流量。因此，在匹配使用策略路由重
定向到本地的转发流量时，本选项有安全影响。当使用
socket 匹配器来实现绑定在非本地地址的完全透明代理
时，更推荐使用 --transparent 选项。
例如（假如被标记为1的分组会被发送到本地）：
-t mangle -A PREROUTING -m socket --transparent -j MARK
--set-mark 1
--restore-skmark
将分组标记设置为匹配到的socket的标记。可以和 --transparent
以及 --nowildcard 选项组合使用来限制恢复分组标记时匹配的
sockets。
例如：一个打开了2个透明（IP_TRANSPARENT）的sockets，并
使用SO_MARK选项设置了一个标记。我们可以这样过滤匹配的分组：
-t mangle -I PREROUTING -m socket --transparent --restore-
skmark -j action
-t mangle -A action -m mark --mark 10 -j action2
-t mangle -A action -m mark --mark 11 -j action3策略路由是个好东西，就是用起来特别麻烦，经常产生一些很奇怪的问题，这次遇到的问题也是特别迷惑。
有一条规则会使用CONNTRACK对链接进行分类，然后把整个链接打上标记，如果不符合任何规则就打一个默认标记。
这条规则看起来一点问题都没有，使用起来也非常正常。但是如果使用MTR对负责这条规则的链接做路由追踪的话，就会出现第一次路由追踪完毕后，从第二跳开始就会丢包。
（还在更新排版中...）
原因
在Apache开启worker或者event配合PHP Thread-safe版本的多线程情况下，环境变量由各个PHP线程共享。
在前一个线程初始化/退出清理环境的时候，会影响到其他线程读取环境变量，导致phpdotenv无法获取到正确的值（被初始化），从而导致Laravel获取不到设定的config，导致config初始化。
（使用方法和地址请直接跳到最后，记得保存下这篇博客噢，如果后续换IP也会同步在这更新的）
最近被Sylar菊苣（Terraria.moe 的菊苣）忽悠着，在拼夕夕上买了一台据说是微软出品的“黑色高级机顶盒”（Xbox One X）。
一收到这机顶盒真的实在是让我惊喜不已，激活的时候竟然要强制更新系统，果然不愧是目前最强的机顶盒，一股浓浓Windows 10的味道。可是更新速度竟然只有50-80KB/s，要顶着这速度下接近1G的“更新文件”还真的遭不住。
更让我惊喜的是，当更新剩余400M的时候，机顶盒一个报错，重试之后竟然从0%开始下了。好不容易再次等到它下完，期盼着马上就可以哈皮了，然后竟然在“检查下载的更新”中失败，直接又跳回0%，我真的是怀疑微软被印度同学入侵了，这个代码质量怎么能散发出如此的咖喱味。Ovear心里想不行啊，等他下完不是又几个小时过去了，于是尝试把线路从电信切到联通，然而发现并没有用。
经过一番紧张与刺激的百度，Ovear看到网上说4G开WiFi可能下载速度会变快，于是赶紧拿出珍藏的三家运营商的流量卡，一顿操作之后，移动100K/s还断流，电信50K/s几秒就断流，幸好联通突然给力有800K/s的速度，就这样才好不容易更新完。
紧接着下来的一顿操作更让Ovear傻了眼，下载游戏的速度竟然只有10KB，还会断流然后就“下载中止”。这是什么概念，在9102年的今天，一般小一点的游戏都有20GB的大小，假如着10KB不断流的情况，一个游戏就要连续下载25天！！！25天！！！这玩个锤子啊
然后Ovear望着空空的XBox里面只有一个“BestTV”在里面，然后去应用商店下载了点其他UWP应用。这时候Microsoft Store的下载速度竟然可以达到Ovear的宽带速度极限，心里想着这还真的是“黑色高级机顶盒”，看来花了几千块买了一台可能还没有电信联通广电送的机顶盒的“货真价实的黑色高级机顶盒”
没错，最近也在折腾，不过太晚了前言不写了，改天有时间补上（→_→）
先说一下硬件以及软件环境
宿主机的网卡 Intel 82579LM
系统 Proxmox VE 5.4
FreeNAS运行在KVM虚拟化创建的VM下面，Proxmox VE内设置的操作系统类型为Other，网卡设置为Virtio。
在使用FreeNAS的SMB服务时，通过任意一台局域网中的Windows 10系统复制共享文件夹中的文件时，宿主机会立即断网，并在message/dmesg提示类似以下的错误消息。