海上的宫殿 - Soha Jin
type: channel
link: https://www.soha.moe/author/1
description: Soha Jin
items: 最后一张纸质车票
items: 乙巳蛇年的新年红包
items: 玩下认证门户的RFC标准
items: 甲辰龙年的新年红包
items: Milk-V Vega 交换机：要啥自行车
items: 2024爱人爱事
items: DOS下也要色色文字
items: 我家踏上了信息光速路
items: 从腾讯企业邮卷铺盖跑路
items: 在90年代的笔记本上使用ChatGPT

最后一张纸质车票
type: item
date: 2025-10-01T23:35:00+08:00
description: 昨天是国铁可以打出纸质车票（报销凭证）的最后一天，我购买了金华南→金华的 G2317 次列车的车票并乘坐，打印出我收集的最后一张国铁车票。把藏品掏出来清点，一共 278 张，按年份整理如下： 2010 1 2015 8 2016 8 2017 12 2018 30 2019 43 2020 24 2021 22 2022 9 2023 34 2024 46 2025 41 当然这并不代表实际乘车的次数。我正式开始收藏国铁车票是从 2015 年开始的，在 2015 年前因为回老家、旅游等原因还是坐过不少火车。而且在大学的时候也有使用积分兑换过车票，积分票是不能打印出报销凭证的。 2010 年那一张杭州→金华西（后改名“金华”）的车票是今年在家里找东西的时候意外发现的。那一年我 10 岁，好朋友的爸爸的单位里正好有到杭州的自由疗养，所以他把我和朋友一起带去了。去的时候，他只有一张车票，正值国庆假期，因此是带着我和好朋友逃票到杭州的。我还记得我在路上做了若干年的 NOIP 初赛题（虽然那一年我依旧没有通过初赛）。现在逃票已经没有那么容易了，真是很有趣的经历。 从上面的数据来看，也可以看出一些有意思的记录。 我 2015 年读高中，基本只有暑假的时候和朋友出去旅游、“办会”的时候出门。但 2017 年因为“染上”了 FRC，为了外出比赛所以坐了不少车。2018 年也是，光是高三下半学期就有 14 张车票，都是因为比赛往外跑，书也不读了（所以最后考了个三本）。那时候国内的大学并不会在招生的时候考虑这个比赛的获奖，纵使我们队拿了国内的冠军、进入了世锦赛，也并不会给我的大学招生带来什么好处。但这个比赛给当时焦虑甚至可能有抑郁的我带来了不少快乐。 上大学后，时间自由不少，经常从温州往返上海去公司摸鱼，亦或是去杭州找以前的同学约饭、闲逛。所以 2019 年有 43 张车票。而 2020、2021 年均只有 2019 年的一半，更不用说和高一时期差不多数量的 2022 年，发生了什么，大家懂的都懂。 翻阅收藏的车票的时候，看着那一个个熟悉的站名、熟悉的车次，当时的记忆与情绪也会随之一点点浮现。即将见到恋人的激动、分别时的不舍，搬去其他城市的期待，办理美国签证的紧张，逃离困了我两月的上海的舒畅，和朋友旅行的悠闲。这些都停留在那一张张红色蓝色的小纸片里，在翻到他们的时候触发回忆。

乙巳蛇年的新年红包
type: item
date: 2025-01-28T20:00:00+08:00
description: 蛇年的有趣好玩的解谜夺宝红包来了！快快点击参与吧→ https://hb.lohu.info 下面是一些你应该知道的事情： 这是一个解密寻宝游戏（a.k.a. CTF），利用你的知识（现学大概也是足够的）解决所有题目，获得红包口令，口令可进入支付宝领取红包。 你应该需要电脑才能愉快玩耍，但手机可能也能解一部分。不涉及任何暴力解法（爆破等）。 本次活动时间从北京时间 2025 年 1 月 28 日 20 时开始，持续 24 个小时。 你拿到的所有答案都是 8 位数字，为了方便控制红包发放时间，在支付宝领取时，前面需要加上一个“蛇”字。如解题得到 20250129，那么最后的红包口令是“蛇20250129”。 共设 2 个红包，数额分别为：总额 68 人民币元，分 48 个；总额 88 人民币元，分 28 个。红包领取规则均为“拼手气红包”，如果红包被提前领完不会补发。 如果你是和其他人一起完成的，希望你们先让一个人领取一次再瓜分，但可以在快结束的时候进行第二次领取。总之就是要把机会先留给别人。 这个游戏由 Soha 制作，在游戏结束后也将在本页面上放出题解，往年的内容也可以在博客上找到。如有疑问也请通过博客的“关于我”页面上所述的联系方式联系。 本提示可能会更新，别忘了偶尔来看看。 最后祝大家，新年快乐！ [T+03:00] 某生气的玩家说：“我只是把 Soha 打晕了啊，并没有把第一个红包下掉。”Soha（揉揉头）：“确实，解析是全球任意可解的，红包也是点击就送的。” [T+05:30] It is really easy to get the first Red Packet once you resolved the address: request it & get it. 活动结束后将在下面更新题解。已更新，请看下方的题解。 往期回顾 2024 甲辰龙年 2023 癸卯兔年 2022 壬寅虎年 2021 辛丑牛年 2020 庚子鼠年 2019 己亥猪年 2018 戊戌狗年 2016 丙申猴年 这个红包所涉及的一些代码和文件可以在 GitHub 找到。 今年的红包字面上非常直白。打开页面，还是熟悉的配方，还是熟悉的味道。 嗯，看起来是有两个红包。第一个红包直接给了一个地址，第二个红包则是以一个“生气的玩家”的口吻，介绍了一个“从 Soha 电脑上抄出的内存数据”。那么接下来逐个介绍。 “红”“包” 今年研究了一些新东西，访问 HTTPS://shebao25yisi.hb.lohu.info/ 就可以获得红包啦！ [T+03:00] 某生气的玩家说：“我只是把 Soha 打晕了啊，并没有把第一个红包下掉。”Soha（揉揉头）：“确实，解析是全球任意可解的，红包也是点击就送的。” [T+05:30] It is really easy to get the first Red Packet once you resolved the address: request it & get it. 直接访问给出的链接，打不开。要获得这个红包，共有两个关键点：第一个关键就是获得解析，而“新东西”和大写的“HTTPS”就是提示。在 2023 年 11 月，定义 SVCB（Service Binding）这个 DNS 记录的 RFC 9460 正式获得了编号。而 HTTPS 作为互联网的一大基础协议，针对其特别定义的 SVCB 记录则被命名为 HTTPS 记录。 常规的 A/AAAA 记录没有解析，加上我在开始后 3 小时强调了“第一个红包依旧存在”且“解析是全球任意可解的”。因此，解析应该是通过其他手段获得。除了常规的 A/AAAA 记录之外，就是 SRV 记录和 SVCB/HTTPS 记录了。 查询 SRV _https._tcp.shebao25yisi.hb.lohu.info 是没有相关的结果的，但是 HTTPS shebao25yisi.hb.lohu.info 就不一样了： $ dig +short HTTPS shebao25yisi.hb.lohu.info 1 . port=443 ipv6hint=2402:4e00:1801:ef0c:0:9e11:82c3:2531 不光明确了 IPv6 地址为何，还确定地告诉你就是 443 端口。 接下来就是第二个关键，怎么获得红包。原文是说“访问就可以获得”，第一个提示说“点击就送”。但是很多朋友没能理解它们的含义，不断在问“为什么端口没开”，有没有一种可能，没开就是预期的。而如果我们使用 termshark 或者 Wireshark 抓包，节目效果就非常充分了。 你就说这个 TCP RST 的 IP 分组（也叫做“IP 包”）是不是红色的吧！“Sequence Numb…

玩下认证门户的RFC标准
type: item
date: 2024-03-22T22:39:00+08:00
description: 认证门户（Captive Portal）是生活中非常常见的上网准入方式。当我们连上一个开放式（不需要密码即可连接）的 Wi-Fi 接入点以后，几乎都不能直接访问互联网，而是需要在一个网页上进行一些认证后才可以访问，这就是认证门户。 从这种 Wi-Fi 接入点的准入方式来说，我们很容易就发现一个问题：需要访问网页才能让用户开始准入认证，但怎么才能让用户去访问呢？目前通行的一种做法是直接劫持 DNS 请求或者 HTTP 请求，重定向到认证页面。这种做法在 HTTPS 时代之前很容易做到，但是 HTTPS 时代之后就遇到了困难：由于认证门户并没有用户访问的网站的证书，要劫持用户就势必要用假的证书来进行，这样一来二去也会给用户带来信任不安全证书的坏习惯。 当然，现在的系统也都有自己的做法。比如 Windows 就会尝试用 http 连接 www.msftconnecttest.com，如果请求被重定向了，那么就会弹出页面让用户进行登录。这虽然解决了一部分问题，但是怎么看怎么不清真对吧，所以在 2015 年，RFC 7710 规定了一种方式：如果 DHCP 或 RA 在指定的 option 中发送了一个 URL，那么就引导用户前往该页面进行认证。 RFC 7710 看起来确实解决了一些问题，但是如果用户此前已经登录，其实是没必要再次登录的。这样系统还是绕不开一次互联网连通性的测试，当然 DHCP 服务器可以在通过认证的情况下不发送有关 option，然而 DHCP 服务器并不一定和计费系统是耦合的，做这种耦合也是复杂且不合适的。所以 capport 工作组设计了一套认证门户的标准，也就是 RFC 8908 和 RFC 8910（代替 RFC 7710）。 我了解到 capport 工作组的这些内容，是因为前两天名为菜色狼的群友去了澳门，在澳门线下赌场看完性感荷官在线发牌之后回到了他下榻的喜来登酒店，连上 Wi-Fi 后发现了名为“到期时间”的内容。 一开始我猜测是 DHCP 租约到期时间，但是菜色狼说之前在家里和别的地方都没见过，于是猜测是某种标准，我便顺藤摸瓜找到了上面提到的两个 RFC。 RFC 8908 规定了认证门户对客户端提供一些信息的 API 格式，API 返回格式为 JSON 对象，IANA 也维护了一个注册表来登记可用的字段。目前只有随着 RFC 发布的这几个，其中 captive 字段是必须包含的： captive: boolean 表示用户是否需要登录。 user-portal-url: string 描述了用户完成准入所需访问的页面，也是之前 RFC 7710 中规定的 URL。 venue-info-url: string 描述了网络运营者想向用户展示的内容（例如地图、航班信息等）。 can-extend-session: boolean 表示用户当前的会话是否可以被延长（时间、流量等），这个字段可以让系统在时间或流量将要耗尽的时候让用户访问 user-portal-url 重新认证。 seconds-remaining: number 描述了用户当前会话的剩余时间。 bytes-remaining: number 描述了用户当前会话的剩余流量（字节数）。 其中菜色狼看到的“到期时间”就是 seconds-remaining 带来的。 RFC 8910 则是替代了之前的 RFC 7710，将 URL 的定义改成了 RFC 8908 中提到的 API 端点，同样也有 3 种通告方式： DHCPv4 Option 114 DHCPv6 Option 103 IPv6 Router Advertisement Option 37 有了这两个 RFC，认证门户上网准入的流程就是这样的了： 连上网络、从 DHCP/RA 获得地址的同时知道认证门户 API 的地址。 系统请求 API，得知设备当前的准入状态，如果需要认证则让用户访问 user-portal-url。 设备已经准入，根据 API 返回的信息选择性地进行一些信息展示。 相比劫持用户的连接、系统自己探测这些做法之外，就清晰和明确很多，也安全很多了。 而且这样一来，只需要提供一个 API 地址并返回规定的内容，并不需要一个真实的认证门户就能复现，折腾的劲儿也就上来了。接着我创建了这样一个 PHP 文件： <?php header('Content-Type: application/captive+json'); echo json_encode([ 'captive' => false, 'venue-info-url' => 'https://jin.sh', 'seconds-remaining' => 4555739950 - time(), 'bytes-…

甲辰龙年的新年红包
type: item
date: 2024-02-11T20:00:00+08:00
description: 一年一度的有趣好玩的龙年解谜红包来了！快快点击参与吧→ https://hb.lohu.info 下面是一些你应该知道的事情： 这是一个解谜游戏，利用你的知识（现学大概也是足够的）解决所有题目，获得红包口令，口令可进入支付宝领取红包。 除去红包不说，游戏的过程也是很快乐的。 你应该需要电脑才能愉快玩耍。不涉及任何暴力解法（爆破等），为节约时间也会复用一些往年做的 UI，因此不要被往年的答案套走。 你拿到的所有答案都是 8 位数字，为了方便控制开始和结束时间，在支付宝领取时，前面需要加上一个“龙”字。如解题得到 20240210，那么最后的红包口令是“龙20240210”。 如果你是和其他人一起完成的，希望你们只领取一次，但可以在快结束的时候进行第二次领取。总之就是要把机会先留给别人。 本次活动时间从北京时间 2024 年 2 月 11 日 20 时开始，持续 24 个小时。如果红包被提前领完不会补发。 共设 2 个红包，数额分别为：总额 78 人民币元，分 16 个；总额 88.88 人民币元，分 18 个（题目简单，红包太少了，更换成）总额 58 人民币元，分 36 个。红包领取规则均为“拼手气红包”。 这个游戏由 Soha 制作，在游戏结束后也将在 Soha 的博客 https://soha.moe 上放出题解，往年的内容也可以在博客上找到。如有疑问也请通过博客的“关于我”页面上所述的联系方式联系。 最后祝大家，新年快乐！ 活动结束后将在下面更新题解。已更新，请看下方的题解。 往期回顾 2023 癸卯兔年 2022 壬寅虎年 2021 辛丑牛年 2020 庚子鼠年 2019 己亥猪年 2018 戊戌狗年 2016 丙申猴年 这个红包所涉及的一些代码和文件可以在 GitHub 找到。 连续两三年的红包领取情况都不容乐观，我十分难过和担心，虽然每年这个形式非常有趣、我出题也乐在其中，但没人领取说明大家在游戏过程中是痛苦的，比如投入了时间却没有收获。其实这八年来，我最喜欢的题目是去年的题目，环环相扣、体验完整，但这恰恰也是他的缺点，毕竟卡了一个就全卡了，有人连第一关的入口都没摸到，游戏体验极差。 今年题目在设计的时候还是以创意为主，只有两个小题目，来源于和群友的吹水以及个人今年的研究。题目其实真不难（虽然我好像每年都这么说），只需要稍微提一句，真相就会浮出水面。甚至两个红包都能一句话解，但想不出来也确实怎么想都想不出来。 因为抗击新冠的原因，本来就没回过几次老家的我已经好久没回去过了。为了回家给老人家看看，今年我在老家过年。老家在一个皖北小农村，联网、用电不太方便，经常是蹲着充笔记本并干活。出题也是断断续续的，导致活动延期到了初二才开始。不巧初二晚上走亲戚吃饭，我下午又忘了 commit 代码并在服务器上 pull，活动开始后几分钟的时候得知红包 1 出锅了，也只能先下掉红包 1，等回到住处再开通。这篇题解是在我返程的高铁上写成的，那么我们开始吧。 进入红包落地页，映入眼帘的还是这个祖传的、带生肖图案的红包。点击“开”以后，会出现两个链接： 入口1：https://loongbao24.hb.lohu.info/ 入口2：telnet://loongbao24.hb.lohu.info 再闯研究所 第一个红包的背景还是去年的“红包研究所”，因为直接用了去年的一部分 UI，我特意在游戏提示里面说“不要被往年的答案套走”。我在 2020 年的时候把一个彩蛋红包放在了落地页小图标 SVG 的注释里面，后面几年总有人分析 SVG 里面有什么特殊的，所以一定要提醒大家不要被往年的题目养成思维定势了，不可能连着两年出一样的套路对吧。 跟着入口链接可以看到一个“foobar 院新年红包研究所·所内综合办公系统”的登录页面，但是点击登录按钮之后提示“系统维护中，暂不能登录”，因为根本没有这个所谓的系统。可以看到有好些朋友尝试了访问常见的登录路径，当然都是 404。这时候其实应该考虑肯定和这个“办公系统”没关系了吧，但有朋友还是在这上面死磕，我不得已在登录按钮附近加了个“有没有一种可能，这真的只是个摆设”的注释。 这个红包的内容都在左侧的一堆“新闻”中，这道题和去年一样，模拟的是一个网络安全方面千疮百孔的倒闭研究所。纵使网安方面千疮百孔，行政人员总还是知道什么能说、什么不能说的。因此直接展示在台面上的新闻，有关的可能也只有《2023年所长办公室工作报告》里面暗示的“就只有这些新闻，凑合看下就可以了”，肯定有些神秘的东西不是直接展示在外面的。回到这些新闻，其实可以注意到 id 并不是连续的： 防范极端天气与寒潮的紧急通知 关于研究所2024年春节假期安排的通知 2023年所长办公室工作报告 2023年第一批研究所公开选聘岗位 2023年“温暖送学生…

Milk-V Vega 交换机：要啥自行车
type: item
date: 2024-02-04T19:00:00+08:00
description: 在 2023 年的 RISC-V 中国峰会上，cyy 和万呆呆见到了一款看起来只是一款平平无奇的交换机，但他既然出现在了这个会场上，那就肯定和 RISC-V 有那么几毛钱关系。这个交换机采用的轩辕 1030M 以太网交换芯片来自武汉飞思灵，而里面用于管理的 CPU 就是基于 RISC-V 架构的，主频 400MHz。除此之外，这个芯片还集成了 8 路 10/100/1000BASE-T 或 100BASE-FX 的 PHY、4 路支持 1000BASE-X、SGMII 的 1G serdes、2 路支持 1000BASE-X、10GBASE-R、SGMII、QSGMII、O-USGMII 的 10G serdes，接口数量还算客观、对于各类 SFP(+) 模块的支持也不会有多大困难。另外一些参数如下： 最大帧长 16000 字节 片上缓存 1.5MB MAC 表 16K 项 VLAN 支持 4K 个 二层组播支持 4K 个 ACL 支持 256 条 典型功耗 4.5W 参数很好看，作为一个办网专家，背包里怎能不常备 10G 网卡、光纤跳线、光模块等必备工具？cyy、Easton Man、Yuuta 三人共凑出 x86/ARM MacBook 各一台、ConnectX-4/AQC107 芯片的网卡各一张，并使用 DAC 线和光模块+跳线两种方式，当场对该交换机的 10G 口双向转发能力和 RSTP 工作能力进行了测试，均正常完成。因此群友们也都挺期待该交换机面市。前两天 Milk-V 在淘宝店上架该交换机后，群友马上组团进行了购买。数辆泥头车从深圳启程，创（撞）向群友的家中。 收到以后，我连晚饭都没来得及吃就开始拆箱。该交换机一共有 8 个 1G 电口、4 个 1G SFP 接口、2 个 10G SFP+ 接口，还有一个用于连接 UART 和 JTAG 的 USB-C 精致调试接口。他没有附送 USB-C 线可以理解，毕竟只是调试接口需要，并不是一个必备的东西，但居然连电源线也不给一根，十分小气。好在我有 12V 的 PD 协商模块，配合 5.5x2.1 转 5.5x2.5 的 DC 头，可以使其正常上电。 吃完饭后便着手开始测试，首先将其连接到了电脑和家中一台闲置的路由器上，为了测试 SFP 口，还插入了闲置的 GPON/EPON 光猫 SFP 模块一根。所有端口均正常工作，并在默认配置的情况下，所有业务均能相互访问，一切工作正常。 接上串口，在开机的时候可见 OpenSBI 信息。 OpenSBI v0.7 ____ _____ ____ _____ / __ \ / ____| _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ \____/| .__/ \___|_| |_|_____/|____/_____| | | |_| Platform Name : Nuclei UX600 Platform Features : timer,mfdeleg Platform HART Count : 1 Boot HART ID : 0 Boot HART ISA : rv64imafdcsu BOOT HART Features : pmp,scounteren,mcounteren,time BOOT HART PMP Count : 16 Firmware Base : 0x41000000 Firmware Size : 76 KB Runtime SBI Version : 0.2 接下来按照背面贴纸的说明，在电脑上配置了 192.168.40.0/24 内不与 .253 冲突的地址，使用 admin/admin 访问了交换机管理页面。从管理页面可以看出，该交换机有 802.1q、QinQ（及 map）、基于 MAC/IPv4 子网/以太网协议的 VLAN、风暴抑制、端口限速、流量控制、802.1p、DSCP、GVRP、GMRP、LLDP、IGMP、静态组播、基于 MAC/IPv4/IPv6 地址的 ACL、ERPS、静态/LACP 端口汇聚、RSTP、802.1x、RADIUS 服务器、SNMP、RMON、端口镜像等功能。 我试着配置 VLAN trunk，看看能否与图中下面那台 NEC 路由器（也有点灵，因此我称该测试为“灵车对创”）互联互通，测试是能用的。就是我配置某个端口 tagged 1-4094 的时候网页卡了好几秒，以至于我以为被我配掉线了，又等了几秒，发现页面的列表上直接多了 4094 个 VLAN…

2024爱人爱事
type: item
date: 2024-01-02T03:21:00+08:00
description: 2024 新年快乐！标题是我对于自己在新的一年的希望：能够多爱身边的人、身边发生的各种事。（谐音梗扣钱！） 刚刚过去的 2023 让我感到有些疲倦，不知道是不是躺了三年之后突然动起来的不适应，还是作为 i 人消耗了过多的社交能量，这我就不知道了。高中毕业后只过了一年就来到了新冠时代，其实我不了解在“正常情况下”我应该是怎样的感觉，但是 2023 过得经常觉得身体被掏空。说到身体被掏空，今年发了两次烧。9 月底在杭州得了新冠，12 月底又在北京得了甲流。可能是因为去年年底刚新冠过，9 月那次新冠很快就好了。但是甲流体验了新冠类似的病程：烧了两天，然后低烧一天才好，但咳嗽依旧。不过，相对于 2022 一年，离开了防疫政策的不确定性，离开了两三天一次的“通行证”续期，总是好的。 2023 作为后新冠时代的第一年，我去了很多地方玩。光是 4 月就去了苏州、香港、南京等地，后面还去了济南、北京、天津等地，见识到了一些不同的人文景观，见了不少许久没见的朋友，也到处吃了些美食。来来去去一共在 9 卷 135 胶卷上留下了记忆，尽管好看的没几张。这一年还是没有出过国，不知道 2024 年的情况有没有不同。 随着疫情政策的放开，境外的高水平艺术团们也都来到了期待已久的中国观众身边。今年我有幸欣赏了圣彼得堡爱乐乐团、华沙爱乐乐团以及亚历山大·罗曼诺夫斯基带来的数场听觉盛宴。为了陪伴数位朋友圆梦上海彩虹室内合唱团的现场，我今年观看的彩虹现场数量也高达 4 场。 我在进一步提升嗖蛤网内服务的全面自主不可控程度、建设邮局的时候，为 rspamd 新增了一个 feature。同样是在办网的时候，我发现了 BIRD 中 OSPF 的实现的一个小 bug，和我院万呆呆同志研究确认后也提交了 patch。这俩是我过去一年在开源方面的贡献。其他的，就还是专有软件的普通工作为主，毕竟是工作内容。 这一年的拖延症情况比前一年好点，但没好多少。还是有一些事情正在拖，当然拖了的都不算是太要紧的事情，但确实维持那些工作的动力不是很强。前段时间感觉互联网上一片网友都在确诊 ADHD，开始吃精品神药按照网上的说法，我也是有点相似“症状”的。不过感觉自己的状态还算良好，并没达到那种地步。无论如何，自己还是需要往合理安排时间方向努力。这里的努力是指旅游、看剧、打电动等与计算机方面工作之间的平衡，不能说劳逸结合，因为很多计算机方面的工作对我来说也属于“逸”的部分。 这一年是第七年参与 FRC，但现在已经是一个高中毕业五年、看着年轻人感叹后生可畏的老年人了。这个比赛因为政策（教育部、新冠）失去了五年。没了本土赛区，赴外参赛的难度无论是技术方面还是资金方面都会大很多，因此很多队伍就这么放弃了。当初两年正赛的六七十支中国队伍，到 2023 年季后赛只剩下了二十来支，实在是可惜。期待中国正赛能够尽快回归，能够看到更多中国队伍出现在世界舞台。 在 2023 发表的总结中，我提到刚过去的一年是我接触计算机二十周年，会有一些怀念的内容发布出来。确实有一篇名为《网龄二十岁》的文章还躺在草稿箱里，十二月开始写，而我现在只写完了三分之一。不能鸽了！再鸽就二十一了！赶紧得写完了！除此之外，我在这一年倒确实研究了一些怀旧的玩意儿，比如一些小时候玩过的硬软件，比如在一些老设备上使用新技术，比如之前发过博文的有关于当年在 MS-DOS 或一些终端设备上用于控制序列的 ANSI 跳脱序列等。 在这年，我通过了 FCC 规定的三个业余无线电爱好者等级——Technician、General、Amateur Extra——的考试，并获得了 FCC 核发的呼号 NS0HA，也在和其他持有 FCC 许可的群友谋划在美国设置集体台的事宜。12 月在北京，我以 Volunteer Examiner 的身份监考了一场 FCC 考试。国内的呼号在这年主要还是在 10m、6m 波段监听比较多，偶尔看到稀有的、没见过的字头可能会发射一下，但也是佛系追台了。 2023 年感谢你们的陪伴：清粥、阿珍、女儿、妹妹等家人或亲如家人，鹤子、Gogo、逐影少爷、我越、kkk、ltt、laosb、点心、twz、库老爷等朋友，cyy、万呆呆、麻田哥哥、猴哥、杰哥、曹老师、霜酱、bml、dd、吴小板、贺神、masnn、付学长、cc、樵老师、学姐等 foobar 院同事，wyy、林儿、强哥等同学，洛谷的同事们，Rongrong、蚊子、摸鱼哥、大a、托尼、赫兹等群友。非常感谢你们，也希望新的一年能继续一起走。

DOS下也要色色文字
type: item
date: 2023-12-10T15:10:00+08:00
description: 最近一个项目需要通过 telnet 展示一些 16 色前景和背景的内容，我使用了 ANSI 转义序列（escape sequence）中的 SGR（Select Graphic Rendition，图形表现选择，CSI … m）序列来控制前景和背景色。写好测试文本后在现代终端输出上是没问题的，而当我来到 MS-DOS 6.22，才发现一切并不是我想的那么简单，展示出来的数据只有一部分颜色是正常的。 xterm 和 MS-DOS 对比 我是一个出生在 00 年的人，几十年前的人们对于电脑显示颜色的追求和技术发展速度之间的矛盾，是我没经历过的。而我这里使用的 SGR 历史比较久远且现在还在广泛使用，老的资料不是很好找。下面提到的内容对于一些专家、一些古董爱好者来说可能是常识，但我觉得解决这个问题的探究过程、发掘背后的发展历史是很有意思的，故将其整理成文。 TL;DR: 太长不读版： 为了节约空间，CGA/EGA/VGA 模式的显卡如果想要使用 16 色背景色，需要关闭硬件闪烁卸载（我写了一个 BLINK.EXE 来开关），否则背景最高位会作为文本闪烁与否的标记。 维基百科中所标注的、目前被广泛使用的 ANSI 转义序列中编号 90-97、100-107 的 8 种亮度提升的颜色是后来的非标准扩展，在现代使用没有任何问题，但没法在 MS-DOS 中使用。 在上古时代，“终端”（terminal）是物理的设备，比如最古早的电传打字机，或者一个通过串口之类的接口或协议连接到计算机的显示器。它们的工作十分轻松：从数据接口获取数据，然后打印、显示出来。而如果想让终端完成一些响铃、换行、回车之类的操作，就要靠一些不显示出来的控制字符实现（这种随着数据传输控制信息的方式也叫做带内传输）。ASCII（ANSI X3.4）中就有很多的控制字符来完成不同的功能，只是一套编码系统的容量是有限的，随着人们玩的花样越来越多，比如移动光标控制字符打印的位置、修改输出颜色等功能都需要有指令来交互。于是各个终端厂商都开发了自己的控制指令，用来实现各种高级功能，当然这样他们也就相互都不兼容了。 正是为了解决这种情况，ANSI 组织专家们设计了 ANSI X3.64（这个标准也被接受为国际标准 ISO/IEC 6429 和 ECMA-48、联邦信息处理标准 FIPS 86、日本产业标准 JIS X 0211），也就是前文提到的“ANSI 转义序列”（终于讲到正题了）。VT100 是第一个实现了这个标准的终端机，因此大家也经常能看到以 VT100 命名的终端类型，它指的就是原版 ANSI 转义序列的实现。ANSI 转义序列定义了 7 位数据和 8 位数据两种写法，大家熟悉的 ESC（\x1b 或 \033）起头的序列就是 7 位的写法，ESC 后面跟着的就是 C1 控制序列，例如常用的 ESC [ 起头的是 CSI 控制序列，CSI … ; … m 这种模式的就是 CSI 控制序列下的的 SGR 序列。8 位数据的写法就不介绍了，因为它和扩展 ASCII、Unicode 系列等编码方式冲突，没有使用意义。 即使大家后来抛弃了终端、用上了显卡，各种操作系统、虚拟终端也支持使用 ANSI 转义序列来实现光标、颜色、显示模式的操作。微软在 1986 年发布的 MS-DOS 4 中带上了 ANSI.SYS，即用于支持 ANSI 转义序列的驱动。只需要在 CONFIG.SYS 中加入 DEVICE=C:\PATH\TO\ANSI.SYS 即可开启。接着输出我生成的测试文本……诶？！怎么颜色不对？（见前文第一张图） 我在生成测试文本的时候使用的是维基百科上介绍的 SGR 颜色定义：30-37（40-47 为对应的背景色）分别是黑、红、绿、黄、蓝、洋红、青、白 8 种颜色，90-97（100-107 为对应的背景色）是上面 8 种颜色的亮度提升版。那么是哪里出了问题呢。 其实，这是现代终端处理 SGR 所使用的颜色表，我这么多年也一直以为八九十年代的终端使用同样的定义，毕竟 1981 年的 CGA 显卡已经支持了 16 色的文本模式，并没有觉得有什么不对。实际上，在 1979 年发布的 ANSI X3.64 中的 SGR 部分（5.77 节）只定义了字形的变换操作。一直到 1982 年的 ISO/IEC 6429 才增加了颜色变换的部分，且只有 30-37 前景色、40-47 背景色两部分。而上面 90-97、100-107 的定义来自 IBM 后来发布的 AIX 系统自带的虚拟终端程序（即 aixterm），后来被包括 xterm 在内的多个虚拟终端程序接纳，才变成了我们现在使用的事实标准。 研究到这里，我以为这个项目在 MS-DOS 这边只能用 8 色降级处理了。正当我准备放弃…

我家踏上了信息光速路
type: item
date: 2023-11-18T20:24:00+08:00
description: “别人家拉宽带最多俩小时，我家拉宽带得要俩礼拜。” “怎么有人办个宽带还得自己砸墙（实际上没砸）拉线上楼的啊。” 以上是自己和群友的吐槽，因此我专门写了篇流水账记录下我家光改。 在 10 年前，也就是 2013 年，跟随着国务院的“宽带中国”战略（在此悼念一下提出“提速降费”的李克强总理），各大运营商都开始了光纤入户改造。这次改造的目的就是将各个小区的上联从铜线改为光纤，并尽可能实现光纤入户（FTTH）。很可惜，我所居住的小区的高层楼房在建造时并没有设置弱电井，八芯双绞网线和电话线是进线管以后直接上到每一户、而不是像强电一样跟着桥架上楼。这种情况换线不太现实，所以电信当时也只进行了光纤入楼（FTTB）改造，对当时使用 20M 速率宽带的我家来说倒是没有什么影响。 又过了两年升级成了 100M 宽带，也只是刚刚触到了电信的 FTTB 容量限制，只是无缘了之后的 200M、500M 甚至 1000M 宽带。这几年来我也多次向电信了解光改的事情，得到的答复都是“小区容量不足，不支持 100M 以上速率”。唯一的好处可能就是宽带的资费每次续约都比之前便宜不少，毕竟现在 2000M 宽带都有了，我们家的速率却没有变化。 今年七月底，电信业务员突然联系我：“你们家的宽带可以升级成光宽带了，要不要办理？”我不敢相信：“是改成光纤到户吗？”等了这么多年的我十分激动，在得到对方肯定的答复之后，我火速订了张票准备回家，约了周六上门。但其实这次上门只是业务员上门来谈套餐，爸爸刚好不在家没法签字，而且就算签了，师傅上门还得等排期、并没有这么快，所以这次回家啥都没干成。 这次电信上门给我推销这推销那的套餐，我都是拒绝的、要求只光改（288 元调测费）。后来恰好妈妈说自己流量不太够，我在看了一圈现在运营商的套餐后，重新考虑了电信业务员的套餐。最后选定的是 500M 宽带融合套餐，可以融 3 张卡，每张 40G 通用流量，携转优惠后 85 元/月。但我们家人都是移动用户，还有个大亲情网，不方便携转。于是我给妈妈办了一张联通的新卡，并将其携转到电信，利用起了一直空闲的第二卡槽。八月我周末都有事、九月爸爸因为亚运会没空，一直到十月亚运会结束后，才正式签了合约、等我回家后约师傅上门。 第一天，电信师傅上门，说了一些东西。第一，我们小区其实容量是不够的，他得从片区光交拉一路新的过来，需要花点时间；第二，他考察了我们楼，没有弱电井、强电井，高层也没法墙外走线。所以他只能把光猫放在一楼 FTTB 的设备那边，然后继续利用开发商预埋的双绞线上楼。想不到啊想不到，我心心念念的光纤入户死在了最后 50m。说完以后，他在我家找到了楼下 FTTB 设备上对应的网线，就离开了。 我们单元不像别的单元有强电井这一点我是早就知道的，但从便利性、安全性和可维修性考虑，我不想把光猫放在公共地方，想着最坏情况也得顺着楼梯间一圈圈转上来吧。所以晚上我叫上住在附近的移动装维表弟，把整栋楼几个单元都考察了一下。最后确认了以下几点： 整栋楼都没有弱电井。 我们单元的强电井是和隔壁单元一起走的，除了我们单元，强电井都在电梯边上（也就是他们可以直接从强电井出去进家门）。 确实在哪里都找不到网线与电话线的进线管，应该就是一楼直接上来、开发商一开始并没有考虑网线、电话线的维护的。 高层也不可能考虑走外墙拉线。 可喜的是，我们发现了广电的线管可以利用。广电入户是这样的：进楼的总线在 1 楼分成 3 路支线，分别通往 3 楼、9 楼、14 楼，这三个楼层再通过分路器分出上下几层的入户线，换句话说，只有这三个楼层才能直达 1 楼。支线是单独的管线上楼，但在 3 楼和 9 楼的接线箱中都有开口。所以我们可以利用广电线管从 1 楼顺着支线上 14 楼，再从 14 楼顺着入户线下 12 楼（因为 12 楼入户线走的是 14 楼支线，所以得先上后下），这样就不用在楼道里走明线了。 第二天，没有观测到电信师傅出现，下午我在家里翻箱倒柜找了一下以前买的穿线钢丝。等表弟下班，我们就开始从广电走线。从 1 楼到 3 楼到 9 楼都非常顺利，但是 9 楼到 14 楼卡住了，钢丝从上面怎么捅都下不去。我和表弟在 9 楼接线箱发现，9 楼分给 11 楼的入户线和 1 楼上 14 楼的支线，在 9-11 段共用了一根管子。而 9 楼接线箱往上有个管子被水泥封住了，可能是开发商一开始埋管子的时候埋错了，只能让这一段共用了。 那么我猜测可能是在 11 楼的接线盒里卡住了，没法准确插入往下走的线管。我们跑到 11 楼，墙壁光秃秃，没有接线盒，但在本应有接线盒的位置看到墙壁有粉刷的痕迹。在 9 楼与 14 楼抽支线，难以抽动。动了动支线和 11 楼进户线，有不少腻子碎块掉落，是内层粗糙、外层是光滑的管道模样。之前楼道粉过墙，会不会是工人看到接…

从腾讯企业邮卷铺盖跑路
type: item
date: 2023-07-16T17:13:00+08:00
description: 去年 6 月，企业微信把腾讯企业邮箱合并了，因此我的企业微信中冒出了一车企业：毕竟一个企业邮箱只能绑一个域名。问题倒是也不大，只是看着不舒服，能忍。后来企业邮箱中的所有用户都在企业微信创建了一个人员，必须绑定微信之后才能登录、修改密码。问题也不大，毕竟我该配的多少年前就配完了，我自己可能平时要用的邮箱那绑定一下本来就要用的企业微信倒也无妨，而且可以给邮件客户端生成密码甚至关掉强制微信登录，也能忍。不过从腾讯企业邮卷铺盖跑路的想法已经种下了种子，只是平时确实忙碌。 If it ain't broke, don't fix it. 但是年初开始，QQ 告诉我，它 broke 了。老用户也不再享有 2G 的空间，而是降到 1G。（邮件类似于下面这张图，就不翻最早的了。）经过十年的积累，我已经使用了 1.1G，所以 7 月 12 日以后就收不进邮件了。删邮件是不可能删的，挑选过程很麻烦。加钱是不可能加钱的，本来功能就没很好用，和企业微信绑定后就更没有用的必要了。于是只能宣布它 broke 了，是时候 fix 了。 从腾讯离开后该去哪儿呢？其实随便找一个商业方案都比腾讯企业邮箱（包括高级版）好用很多，至于免费方案只能说“要啥自行车”了。对于市场上比较常见的选项，twz 列了一些国内外的服务对比，有想要了解的可以去看看。数年前其实就想自建邮箱，因此我就没选择这些商业方案，而是利用这个契机完成了邮箱的自建。当然，这篇文章主要是讲述从腾讯企业邮箱跑路的故事，而不是讲怎么自建，所以这里就不展开了。 因为不给钱只能一个域名，因此我在腾讯上部署的域名邮箱一共有 4 个：lohu.info、sohaj.in、soha.moe、oiinhand.info。这几个的管理员账号都跟随手机账号绑定在了我的企业微信上。中间两个域名都是一个 mailbox，然后所有 catch all 到这个 mailbox，所以直接迁移就好，没什么困难。oiinhand.info 也随着 OI in Hand 项目的倒闭而倒闭了，这个只需要看看有没有什么邮件需要备份，然后直接扬掉就好。 关键就是 lohu.info 这个域名，几个 mailbox 都干着不同的事情，有些东西已经都忘了是干什么用的、有什么了，这都得一个一个去看。现在腾讯又强制一个账户绑定一个企业微信账号，不能直接切换也不能直接改密码进去看。最后研究来研究去，发现需要两个微信+企业微信的账号才能去一个个看并备份。 首先准备好第二个微信/企业微信，因为自己的微信已经绑定管理员账号，且管理员操作没法完成下面的操作。接着在企业微信后台创建一个新用户，绑定第二个微信/企业微信。接着把所有要看邮箱的账号全删了，只剩下管理员和新创建的用户。邮件-协作-邮箱管理-邮箱回收站里面就会有删掉的邮箱了。 接着再利用分配功能，把其中一个邮箱分配给新创建的账户，就可以用新创建的账户的微信扫码登录邮箱了。登录上去看完觉得需要迁移，就去设置里面接收短信验证码设置一个密码来做迁移。迁移我用的是 imapsync，使用类似下面的命令。 imapsync \ --ssl1 --host1 imap.exmail.qq.com --port1 993 \ --ssl2 --host2 imap.pobox.soha.foo --port2 993 \ --user1 'example@lohu.info' --password1 '114514' \ --user2 'soha@jin.sh' --password2 '1919810' \ --addheader --automap \ #--justfolders --dry \ 最后花了点时间，对这个繁琐流程一共操作了十多次，把所有的账号都检查并迁移走了。但当迁移完成想删库跑路（解散企业微信）的时候会发现，跑不了。 后来联系了客服才知道，企业邮箱迁移过来的企业微信都是不能自主解散的。是为了防止企业邮箱迁移过来的人不知道解散企业同时也会删除企业邮箱，才有这么一个防呆的措施。最后进行了两次确认，等他们后台工作人员帮我恢复了自主解散权限以后，就可以自己去企业微信解散了。 然后找客服用下面的说辞解散了另外 3 个企业，算是彻底从腾讯企业邮箱跑路了。 你好，ID 为 <redacted> 的企业无法解散，提示如图。 我是当初的腾讯企业邮箱自动迁移过来的企业，我了解企业解散后邮箱等记录会全部消失，我已做好迁移和备份，请帮我恢复解散权限。 管理员的绑定手机是 <redacted>。 这次一整套流程下来让我感觉挺悲哀的：腾讯的重点不是想着怎么优化自己的产品、让产品更好用，而是把用户绑架在自己的生态里面，只要进了他的门就别想把钱送给别人家。毕竟使用腾讯的企业邮箱需要腾讯系的工具是一种必然的话，对于不想或者不方便…

在90年代的笔记本上使用ChatGPT
type: item
date: 2023-06-28T23:38:00+08:00
description: 好久没写博客了，来水一篇。昨晚在水群的时候看到 dialup.net 编写了一个 16 位 Windows 版本的 ChatGPT 客户端——WinGPT，这样 Windows 3.x 也可以使用上人工智能聊天技术了。之前还看过 Squirrel Monkey 做的整活视频《If ChatGPT were around in the 1980s...》，这次属于是成真了。 这是怎么做到的？根据作者的介绍，他把较新的 WolfSSL 移植到了 16 位 Windows 上，这样应用程序就可以使用其接口直接处理 TLS 1.3 而不需要其他主机当代理来终结 TLS 了。当然由于时代的限制，只能使用一些比较弱的加密方式，是有安全隐患的。另外，当今的 API 并不太会考虑传输内容的尺寸进行优化，JSON 的处理同样需要一些内存。在那个年代的系统上，内存的使用是一件非常痛苦的事情，因此 WinGPT 的单次交互内容需要尽可能小，作者就限制了输入文本的长度，也一并把上下文的发送给砍掉了。 顺便一提，这个作者在写 WinGPT 的时候，也问过 ChatGPT 怎么样来实现软件中的状态栏，但是它给了一个错误的答案。 下面则是记录一下老爷车上网开上了信息高速路，去和那“谈天吉批提”聊天的技术细节。 手里刚好有一台 Toshiba Satellite Pro 480CDT 笔记本，因此我准备在它上面运行，来一场划时代的碰撞。这台笔记本搭载了 Intel 的 Pentium w/MMX @233MHz 处理器（代号 P55C）和 160MB EDO DRAM 内存，以及 Yamaha OPL3-SA3 声卡、Chips & Technologies 65555 显卡、800x600 TFT 24 位真彩色显示器、33.6Kbps 调制解调器（但我没买 DAA 模块，没法插电话线）、USB 控制器、两个 32 位 CardBus 卡片扩展槽。是一个还算高级的笔记本，毕竟在 97 年卖两万多人民币呢。我在他上面装了 MS-DOS 6.22 + Windows 3.2、Windows 98 SE、Windows 2000 Professional 和 Alpine Linux，使用 GRUB2 引导。 我没有 Windows 3.x 下有驱动的 PCMCIA 以太网卡，也没有给内置 MODEM 买 DAA 模块，因此选择使用串口上网。其实串口上网是和拨号上网一样的，MODEM 只不过是把串口信号调制成音频信号通过电话网络传输。在这里，我使用一条 USB 的 RS-232 串口线连接现代笔记本（Linux）与上古笔记本（Windows 3.2），图中的 DB9 到 RJ45 console 接口的转换器是昨晚看到 WinGPT 以后加急购买的。 在串口上跑 TCP/IP 常见的有两种协议，SLIP（Serial Line Internet Protocol）和 PPP（Point-to-Point Protocol）。PPP 有协商鉴权和分配 IP 的过程，因此在那个年代多是使用 PPP 来上网。我只需要让 Windows 3.2 通过 Linux 的网络上网，不需要那些有的没的，因此使用 SLIP 即可。SLIP 和 PPP 都可以在 Windows 3.x 上使用 Trumpet Winsock 实现。Trumpet Winsock 通过提供 Winsock 兼容接口的方式来为使用 Winsock 的应用程序提供更高级的网络连接。 Linux 上可以使用 slattach -s 115200 -p slip -L /dev/ttyUSB0 在 tty 上以 115200 的波特率处理 SLIP，并创建一个网络接口。 一般来说，创建的这个接口是 sl0。同样的，在 Trumpet Winsock 上配置好串口号和波特率，以及奇偶校验、停止位等参数，最后写好 IP 地址、DNS 服务器，这样就完成了。 接着回到 Linux 添加 IP 并拉起网卡，Linux 主机就和 Windows 3.x 连接起来了。 # 因为是点对点连接，因此用这种写法来添加 IP，内核会自动添加一个到对端的直连路由。 ip addr add dev sl0 44.159.73.196/32 peer 44.159.73.203 # 拉起 sl0 并设置其 MTU 为 576，对于这种连接来说小 MTU 会好点。 ip link set dev sl0 up mtu 576 因为是第 3 层的点对点协议，并不是基于以太网，因此不能直接将其桥接到 Linux 的外网接口上来上网。这里我通过开启 ARP 代理的方式，把外网接口和 sl0 连接起来。ARP 代理的原理是以被代理主机（这里是…