已知家里的移动宽带挂载的NAS是Full Cone（全锥型），校内使用运营商提供的校园网接入（中国移动宽带）极有可能为Port Restricted Cone（端口限制圆锥型）或更糟糕的Symmetic（对称型）PS：2022年11月19日确认校内为：Port Restricted Cone

纸上谈兵

xtcp使用P2P的方式完成点对点穿透，根据2020-6-10-理解NAT穿越——黄腾霄可见，理论上全锥形NAT可以和四种常见NAT类型完成P2P链接。
通过查看Frp官方Git仓库的Issues记录，可以看到2019年12月30日leveljiujiu提出的新实现方式理论上可以实现全锥形和端口限制圆锥型的点对点NAT穿透。参见优化XTCP穿透性能的代码修改——leveljiujiu 而2020年5月19日rvier明确提出

一边Full Clone 一边 Symmetric（Visitor） 打洞成功，一边Full Clone 一边Port Restricted Cone（Visitor） 型NAT 经测试目前无效。
但是，目前该分支和另一个具有类似效果的分支被拒绝合并，fatedier的理由是：我们专注于 v2 体系结构
What Fuck ，我根本没时间等fatedier撮出来FrpV2主线的release啊！
PS:我记得Frp的竞争者NPS也有点对点内网穿透的功能，既然Frp的作者不想合并，那就看看NPS的P2P写的怎么样。扒拉了一些资料，可以确定NPS的点对点实现（P2P）比Frp要完善的多，NPS在国内三大运营商环境下打洞应该比Frp效果好很多，理论上P2P可以连接的情况下NPS都能打通！那就暂定使用NPS吧。

预期实现

J3160 NAS（全锥型NAT客户端）——>公网服务器——>OrangePi Zero2开发板（对称型/端口限制圆锥型 armv8-a客户端）
或
J3160 NAS（全锥型NAT x86_64客户端）——>公网服务器——>Xiaomi R3G路由器（对称型/端口限制圆锥型 mipsel客户端 ）

实践

2022年11月19日,检查并查看NPS官方文档修正了在家部署时配置的一些错误。
经过尝试，没能打通NAS（Full Cone）和校园网（Port Restricted Cone）
2022年11日20日：凌晨SSH打通了一次，此后再也没打通过,RDP是一直打不通只能走中转。
发现家里NAS终端崩溃了，因为我之前一直靠终端直接运行NPC客户端。官方提供的npc install 在Debian11下无法正确的固化进程，我就干脆上docker了，效果还不错。

从七月份开始我在手机上通过Via浏览器使用必应搜索时响应非常缓慢（间歇性），而且在我的Edge浏览器上遇到了相同的问题（但是在PC上Edge浏览器使用代理后解决了问题，而手机出现连接中断）。
通过Ping测试和Web直接访问确定无论是www.bing.com还是cn.bing.com都可以在手机和PC上正常响应请求，因此网络问题暂时排除。

观察通过cn.bing.com页面搜索关键词“你好世界”得到请求链接为：
https://www.bing.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C&form=QBLH&sp=-1&pq=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C&sc=10-4&qs=n&sk=&cvid=C0CF3A940E544E51803E83A679BCB081&ghsh=0&ghacc=0&ghpl=
而我在Via浏览器上使用必应搜索是通过直接在cn.bing.com/search?q=后添加关键词，PC端Edge则是通过www.bing.com域名以%s参数为搜索关键词{bing:baseURL}search?q=%s&{bing:cvid}{bing:msb}{google:assistedQueryStats}构造URL。
综上所述，可能是构造URL的时候参数由于微软更新服务器出现了问题。
随后挂上代理通过搜索引擎查询又刚好看到这篇文章Bing搜索突然变得很慢 - Microsoft Community
似乎手机和PC遇到问题的原因是不完全一样的？

通过不断的测试，以你好世界为关键词，进行搜索得到正确响应所需的最小参数数量的URL是https://cn.bing.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C&cvid=3c98a5db8b2d4cfdad53d30f28b73706
也就是只需要q和cvid参数。那么Edge里搜索引擎的请求URL改为填写：https://cn.bing.com/search?q=%s&{bing:cvid}即可。
但是问题又来了，Via的自定义URL根本不支持%s参数替换关键词......WTF。更有趣的是，就在我撰写这篇文章的时候，我发现我在Via浏览器直接使用cn.bing.com/search?q=的构造速度又恢复正常了，那么显然是官方服务器的问题了。

人民日报：中国人民解放军空军正在穿越台湾海峡

人民日报（People's Daily）是中国共产党中央委员会机关报。人民日报作为党和政府的喉舌，作为中国对外文化交流的重要窗口，作为展现蓬勃发展社会主义新中国的舞台，人民日报积极宣传党和政府的政策主张，记录中国社会的变化，报道中国正在发生的变革。摘自百度百科

🤔渲染战争气氛的是官媒，呼吁冷静的还是官媒。

今天看到群友发的截图，觉得很有趣。
基于认同价值的价值观导向让这群小朋友能和谐的聚在一起。

给自己的行为找借口特别是能自动脑补虚构事实的人是最为恐怖的，因为在这类人脑子里他的一切行为都是正当的。和这样的人打交道，就像你在和一个能说出抛开事实不谈......这样句式的人辩论，毫无意义。特别是对方大脑里甚至可能会理性思考并将自己放在受害者或者说弱者的角度提出其他扭曲的价值观。
此类情况出现在某些人因自己目的未能完成而歇斯底里的发泄情绪时。
个人认为🤔这个应该也算一种精神疾病吧，特殊的生活环境造就千奇百怪的人。看着手上又新增的伤口还能淡定的写博客记录和感慨，总觉得自己也不太正常了。
推一本书：实用辩论技法大全 出自实用文库编委会

没想到无意间路过那附近的路口能看到那个身影，我知道她搬家到那个社区了，但是一直没再联系也没再碰面。
真是造化弄人，她终于长高了，不再是那个一年长一厘米的159小女生。我完全不怀疑自己是不是认错人了，路过的时候我看到了她半个正脸，还有那条熟悉的裙子 而且我听到她说了一声再见，这个声音绝对错不了。
也许大家都是对方人生里的过客，但也确实给对方的生活增添别样的滋味。不知道我们的刘同学能不能碰到一个这样的女孩，带他走过那一片绝望的荒漠。但是若真有，我未免也太自私了吧xd。
只要岁岁平安，即使生生不见。
愿君安好。

这是我写的DS18B20用户态驱动

Goodspeed最近好像比较清闲，所以这位有点闲的同学跑来远程我的OrangePi Zero2 完成了一份正经的单总线驱动。实现后效果如下：

root@orangepizero2:~# cd /sys/bus/w1/devices/28-0721c061a6ac/
root@orangepizero2:/sys/bus/w1/devices/28-0721c061a6ac# ls
alarms eeprom_cmd hwmon power temperature
conv_time ext_power id resolution uevent
driver features name subsystem w1_slave
root@orangepizero2:/sys/bus/w1/devices/28-0721c061a6ac# cat w1_slave
bb 01 4b 46 7f ff 0c 10 74 : crc=74 YES
bb 01 4b 46 7f ff 0c 10 74 t=27687

显而易见大约27摄氏度，详细过程会在他的博客写好后在下方公开。（人比人气死人:)

给香橙派 Zero 2 适配 1-wire 总线

给香橙派 Zero 2 适配 1-wire 总线————William Goodspeed
在向Goodspeed抱怨此事之前，香橙派官方4群里邹明燊先生也曾经写过一个dts文件，也是根据其他已经支持1-wire的设备简单改写的（如下），但是我通过orangepi-add-overlay xxx.dts 添加后会在日志中看到错误信息，即我上一篇文章里写被占用的哪些错误信息，并且经过测试dts生成的dtb文件没有正常工作。而Goodspeed提供的截图中可以看到，这个dts文件并没有写错，只是设置的GPIO不同。

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun50i-h616";

    fragment@0 {
        target = <&pio>;
        __overlay__ {
            w1_pins: w1_pins {
                pins = "PC9";
                function = "gpio_in";
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            onewire@0 {
                compatible = "w1-gpio";
                pinctrl-names = "default";
                pinctrl-0 = <&w1_pins>;
                gpios = <&pio 2 9 0>; /* PC9 */
                status = "okay";
            };
        };
    };
};

二者的主要不同在于Goodspeed是在 arch/arm64/boot/dts/allwinner/overlay/Makefile 中加入一行 sun50i-h616-w1-gpio.dtbo，make dtbs让构建系统编译新的 overlay，而邹明燊先生试图让我直接通过orangepi-add-overlay将改写好的单总线支持dts文件编译并自动添加到overlay路径。
这两者方法不太一样，Goodspeed的方法是从orange-pi-5.16-sunxi64 linux分支源码中自动编译生成dtbo文件，而邹明燊先生是自己写dts从写好的dts去编译得到dtbo文件。但是不知道为什么后者无法生效，从内核日志里的报错看是和pinctl冲突了，也就是说比pinctl抢先占用了pin，但是理论上应该先由pinctl统一管理，驱动应该基于pinctl运行。从这点看，由linux分支源码去自动编译可能会得以避开这一问题，但是具体避开抢占问题的原理就不得而知了，我也不打算深究。

Goodspeed编译好的单总线设备树overlay文件

prebuilt-dtbs.tar

关于linux设备树，请参考如下内容深入浅出理解Linux设备树(DTS)
Dts：DTS即Device Tree Source，是一个文本形式的文件，用于描述硬件信息。一般都是固定信息，无法变更，无法overlay。
Dtsi：可以理解为dts的公共部分，添加、变更非常灵活。Dtsi包含在dts中。
Dtb：Dtb编译出来的二进制
Dtbo：Overlay编译出来的二进制
dtbo-base：指定overlay是以哪个dtb为base来覆盖的。
Node：树的节点
Property：属性

研究一番发现官方没有现成的单总线驱动可用，必须得自己写一个驱动驱动单线设备。

 +------+-----+----------+------+---+  Zero 2  +---+------+----------+-----+------+
 | GPIO | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | GPIO |
 +------+-----+----------+------+---+----++----+---+------+----------+-----+------+
 |      |     |     3.3V |      |   |  1 || 2  |   |      | 5V       |     |      |
 |  229 |   0 |    SDA.3 |  OUT | 1 |  3 || 4  |   |      | 5V       |     |      |
 |  228 |   1 |    SCL.3 |  OUT | 1 |  5 || 6  |   |      | GND      |     |      |
 |   73 |   2 |      PC9 |  OUT | 1 |  7 || 8  | 1 | OUT  | TXD.5    | 3   | 226  |
 |      |     |      GND |      |   |  9 || 10 | 1 | OUT  | RXD.5    | 4   | 227  |
 |   70 |   5 |      PC6 |  OUT | 1 | 11 || 12 | 1 | OUT  | PC11     | 6   | 75   |
 |   69 |   7 |      PC5 |  OUT | 1 | 13 || 14 |   |      | GND      |     |      |
 |   72 |   8 |      PC8 |  OUT | 1 | 15 || 16 | 1 | OUT  | PC15     | 9   | 79   |
 |      |     |     3.3V |      |   | 17 || 18 | 1 | OUT  | PC14     | 10  | 78   |
 |  231 |  11 |   MOSI.1 |  OUT | 1 | 19 || 20 |   |      | GND      |     |      |
 |  232 |  12 |   MISO.1 |  OUT | 1 | 21 || 22 | 1 | OUT  | PC7      | 13  | 71   |
 |  230 |  14 |   SCLK.1 |  OUT | 1 | 23 || 24 | 1 | OUT  | CE.1     | 15  | 233  |
 |      |     |      GND |      |   | 25 || 26 | 1 | OUT  | PC10     | 16  | 74   |
 |   65 |  17 |      PC1 |  OUT | 1 | 27 || 28 |   |      |          |     |      |
 |  272 |  18 |     PI16 |  OUT | 1 | 29 || 30 |   |      |          |     |      |
 |  262 |  19 |      PI6 |  OUT | 1 | 31 || 32 |   |      |          |     |      |
 |  234 |  20 |     PH10 | ALT3 | 0 | 33 || 34 |   |      |          |     |      |
 +------+-----+----------+------+---+----++----+---+------+----------+-----+------+
 | GPIO | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | GPIO |
 +------+-----+----------+------+---+  Zero 2  +---+------+----------+-----+------+

端口占用情况：
已占用：
PC1,pin PC1 already requested by onewire@0; cannot claim for 300b000.pinctrl:65
PC5,pin PC5 already requested by onewire@0; cannot claim for 300b000.pinctrl:69
PC9，pin PC9 already requested by onewire@0; cannot claim for 300b000.pinctrl:73
PC6, pin PC6 already requested by onewire@0; cannot claim for 300b000.pinctrl:70
PC8,pin PC8 already requested by onewire@0; cannot claim for 300b000.pinctrl:72
PC10，pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74
PC11,pin PC11 already requested by onewire@0; cannot claim for 300b000.pinctrl:75
PC12,PC13是两个板载LED
PH3,w1-gpio onewire@0: gpio_request (pin) failed