两年前我就想写一篇关于飞机GPS干扰的文章，一直没找到机会写，直到昨天我自己遭遇了一次严重的GPS干扰事件。
昨天飞晚班回重庆，着陆前10分钟，在我们飞过沙坪坝上空时，飞机弹出一个“ADS-B故障”的信息，我们明白这是遇到了GPS干扰。但这时候我们还以为这只是一次普通的干扰，对这种由于GPS干扰导致的ADS-B故障我们最近几年经常遇到，早就习以为常了，一般这种干扰只会持续几秒钟就会消失，因为通常干扰范围是局部的，以我们飞机的速度很快就能脱离这个干扰区域，而且就算是持续受到干扰，对我们飞机影响也不大，因为我们飞机有三套高精度的惯性导航系统，它们可以完全不依赖外部的GPS信号来工作。
空客A319飞机在飞高原的时候，座舱压力控制计算机有一个BUG，偶尔小概率会触发一个假警告，空客公司认为只是个假警告而已，不理他就行了，所以一直不去修复。但CAAC太卷，领导说了哪怕是假警告也坚决不能响，所以制定了一套补充程序要求机组在座舱高度达到8500ft时执行，以避免这个假警告。但是机组有时候事太多，经常忘了去做这个程序，如果运气不好碰巧这个警告响了的话，回来就会被收拾。所以我做了这个物理外挂，在需要执行程序的时候来提醒机组。使用ESP32处理器，MS5611高精度气压传感器，1.3寸低功耗OLED显示屏，三个物理按键，内置500mAh电池。
先插入一个我自己开发的CPC转换提醒器的广告，详情点击：“飞行员专用座舱高度监控报警器”
进入主题之前我先说一个很多人对于CPC转换的误解。可能很多人都认为CPC转换的作用是强制让备用CPC跟主用CPC“同步”，其实这个理解是不正确的。转换CPC并不会立刻让两部CPC的工作模式同步，每一部CPC原本处于什么模式，转换之后还是什么模式。既然这样，那为什么在下降之后当座舱高度达到8500ft的时候进行一次CPC转换能有效避免虚假的“座舱高度过高”警告呢？我来仔细分析一下这个CPC转换程序背后的逻辑：
我们先来看一个某公司最近的事件报告中的片段：
“机组在做进近准备收到签派电话：告知西双版纳/嘎洒机场盲降不工作，因机场温度过高不能使用 RNP LNAV/VNAV进近程序，可能使用 LNAV 或 VOR/DME 进近。机组收到消息后主计划按 RNP LNAV 程序准备，二计划按 VOR/DME 程序准备……。13:56 机组首次联系嘎洒进近（后简称进近），被告知使用 16 号 RNP 程序进近，机组考虑温度超限制，提出使用 LNAV 进近，进近告知机组：不能使用 LNAV 程序，更改指令使用 16 号跑道 VOR/DME 进近……”
基本原理：在电脑上运行抓包工具Fiddler，安卓手机跟电脑在同一个局域网内，Fiddler会启动一个网络代理，在安卓手机的WIFI设置里面手动指定这个代理，手机所有的流量都会通过Fiddler来转发，于是Fiddler就能抓取手机的http数据包了。但是https的包是经过加密的，Fiddler抓到的包无法显示包的内容，这时我们就需要在手机上安装Fiddler的证书，并信任这个证书。在安卓手机上安装和信任证书需要Root，由于手机Root不太方便，所以我使用的是夜神安卓模拟器。
方法很简单，教程如下：
由于各种网络设备默认的IP地址都是192.168.1开头，新的设备接上家庭内网之后可能会有冲突，所以我将原来内网使用的192.168.1开头的网段改成了10.10.1开头的网段。改完之后才发现原来有几台设备没有启动DHCP，而是192.168.1网段的固定IP地址。为了保持对原网段的兼容，我想在内网中使用双网段，这样就不用手动指定IP地址就能直接访问内网中的两个网段的设备。
我的思路是将LAN口增加绑定一个192.168.1.1的地址，然后添加一条静态路由，让192.168.1.0/24网段的数据包不被转发到WAN口，而是强行转发到LAN口。
两处住所A和B都是家用宽带，A处有一台wifi打印机，但是在外网不能打印，需要外网打印的时候可以通过OpenVPN连接到A的内网来打印。B处有一台威联通的NAS，虽说可以通过动态域名加端口转发来远程访问，但是想要用Windows的文件共享也只能用OpenVPN连接到B的内网来使用。虽说OpenVPN能满足外网访问的需求，但是需要在局域网内每台设备上都安装OpenVPN的客户端，每次使用之前要先连接到对方的内网，用完之后要断开连接，不够方便。
最近发现了一个叫Wireguard的组网神器，它能在两台网络设备上建立一个加密隧道，并将部分或者所有流量通过这个隧道转发。比方说如果在两台网关路由器上通过Wireguard建立一个隧道，然后将对方的局域网段IP地址设置为通过这个隧道转发，这两个路由器下的所有网络设备就可以直接访问对方的局域网了，非常方便。据说Wireguard的代码非常精简，只有4000多行，而OpenVPN大约有10万行代码，而且Wireguard以Linux内核模块的形式运行，资源占用小。从2020年1月开始，它已经并入了Linux内核的5.6版本，这意味着大多数Linux发行版的用户不用安装任何三方软件就能直接使用。连Linux创始人Linus Torvalds都称其为“一件艺术品”。
昨天给NAS换了一块硬盘，顺便把厚卷改成了静态卷。
过程很简单，先把新硬盘插到4号空盘位，新创建一个静态卷Volume4，然后用HBS把数据从Volume3同步到Volume4，完了之后取下3号硬盘。
本以为大功告成，结果后来却发现有些应用出了问题，经过一番排查发现在这些应用的设置中使用了绝对路径：
原来的/share/CACHEDEV3_DATA现在变成了/share/CACHEDEV4_DATA，导致应用无法找到文件。
这个简单，安全卸载Volume4，然后将这块4号盘位的硬盘换到3号盘位，恢复存储池。
以下方法只适用于威联通NAS的静态卷（single static volume），厚卷和精简卷（薄卷）暂时无法在Ubuntu中读取。
先使用lsblk命令列出磁盘分区：
～# lsblk sdb 8:16 0 1.8T 0 disk ├─sdb1 8:17 0 517.7M 0 part │ └─md9 9:9 0 517.6M 0 raid1 ├─sdb2 8:18 0 517.7M 0 part │ └─md256 9:256 0 517.7M 0 raid1 ├─sdb3 8:19 0 1.8T 0 part │ └─md127 9:127 0 1.8T 0 raid1 ├─sdb4 8:20 0 517.7M 0 part │ └─md13 9:13 0 448.1M 0 raid1 └─sdb5 8:21 0 8G 0 part └─md322 9:322 0 6.9G 0 raid1
sdb就是这块硬盘，sdb1-5代表这块硬盘的第1到5个分区，下面的md是磁盘阵列（Raid）。
最近研究SnapDrop，发现它既可以发送文件又能发送文本消息，那岂不是可以把它改造成一个聊天APP？
但是，等等...为什么我要自己做一个聊天的APP，微信他不香吗？管他呢，耿哥出品，必属废品！先做了再说吧。微信也能传文件，为什么还会有人做SnapDrop这个东西呢。
有了这个想法，那就开始做吧。我首先想到的是直接利用它的WebRTC来做一个两人点对点互聊的东西。但是想了想，两个人有什么好聊的，人多才有意思，于是我决定做一个群聊工具。
