海上的宫殿 - Soha Jin
type: channel
link: https://www.soha.moe/author/1
description: Soha Jin
items: 只有IPv6的网络与IPv4最后的倔强
items: 丙午马年的新年红包
items: 一切都好的2026
items: 最后一张纸质车票
items: 乙巳蛇年的新年红包
items: 迎接甜蜜2025
items: 玩下认证门户的RFC标准
items: 甲辰龙年的新年红包
items: Milk-V Vega 交换机：要啥自行车
items: 2024爱人爱事

只有IPv6的网络与IPv4最后的倔强
type: item
date: 2026-03-15T00:50:00+08:00
description: 464XLAT 是走向 IPv6 单栈的过程中，用来让纯 IPv6 网络能够通过地址翻译访问 IPv4 网络的技术。他的工作流程是：IPv4 应用直接发送 IPv4 分组，到达 CLAT（Customer-side Translator，用户侧翻译器）进行无状态 NAT46 转换成 IPv6 分组，通过 IPv6 网络传输到达 PLAT（Provider-side Translator，运营商侧翻译器）后再进行 NAT64 转换成 IPv4 分组到达目标 IPv4 主机。 有了这个技术，IPv4 协议栈就可以在接入层上完全砍掉了，只需要有 CLAT 将 IPv4 分组送到 IPv4 网络的边界即可。CLAT 之所以叫“用户侧”，是因为他通常运行在光猫，甚至终端设备（如手机、电脑等）上。本文记录的是终端设备运行 CLAT。 2 月春节期间，我在家里的网络上设置了 NAT64 作为 PLAT，并配置了 DHCPv4 的 IPv6-Only Preferred 标记之后，DHCPv4 的地址分配骤减到 4 个，还在使用 IPv4 的只剩下智能家居、无线电台这些嵌入式设备了。 可以见到，图中 3 个平台的 IPv4 地址均为空或者 RFC 7335 指定用于 v4 转换的 192.0.0.0/29。 其实这种事情不是第一次干，早在 2019 年就尝试过一次：当时我用 tayga 在大学寝室的 OpenWrt 上配置了 NAT64，然后使用 bind9 做了 DNS64。这一套方案通过将没有 AAAA 记录的域名的 A 记录转换成 AAAA 的方式来实现 IPv4 网络的访问，也是当时的标准做法。这样操作的问题显而易见，毕竟总有应用不按照你所想的方式去查找服务器：他们使用指定的 DNS 服务器、使用 HTTPDNS，甚至使用了硬编码的 IPv4 地址。这些都是 DNS64 方案无法解决的，因此 DNS64 只能提升接入层的 IPv6 流量比例，而并不能完全抛弃接入层的 IPv4 协议栈。 所以更好的方案是，让设备去完成这个 IPv4→IPv6 的转换。那么问题来了，设备怎么知道 NAT64 可用、怎么知道使用什么前缀呢？当时 RFC 7050 提供了通过查询 ipv4only.arpa 获得 NAT64 前缀自动配置的方案，但是他依旧受到了 DNS 服务器的限制，不适合反映接入网络的真实情况，支持度也基本局限于蜂窝网络。甚至这个域名加入 IANA 的 Special-Use Domain Names 列表都是 2020 年的事情。 到了 2020 年，RFC 8781 往 Router Advertisement 中新增了一个名为 PREF64（Type 38）的选项，路由器可以在宣告默认路由、前缀等 v6 信息的同时，宣告将 IPv4 地址嵌入什么前缀就可以通过 NAT64 访问 IPv4 网络了。这才是自动发现应该有的最佳方案，毕竟 Router Advertisement 作为通常的终端设备自动发现并配置 IPv6 网络的必要手段，反应的也正是当前网络的信息。 2021 年发布的 Android、2022 年发布的 iOS 16 和 macOS 13 都支持了 PREF64 参数。同期支持的还有 RFC 8925：他往 DHCPv4 中新增了一个名为 IPv6-Only Preferred（Option 108）的选项，支持 CLAT 的设备在尝试请求 IPv4 地址时如果收到了这个选项，那么他就会主动放弃 IPv4 协议栈。（当然也可以选择直接关闭 DHCPv4，只是这样不支持 CLAT 的设备就无法访问 IPv4 了。） 2025 年秋天，Windows 发布了 CLAT 的封测，我光速报名了。这下三大厂都支持了，于是便有了文章开头的内容。当然在测试过程中，我也发现了一些问题，已经反馈回相关负责人了。 2 月 19 日，Windows Insider Preview (Canary) 的代码从 Br（溴）更新到了 Kr（氪），build number 为 29531。这个版本引入了 CLAT，只是默认没有启用。如果你家也部署了 IPv6-Only Preferred 的网络，并想体验 Windows 的 CLAT 的话，可以通过以下两个操作开启： 使用 netsh interface clat set global permit=enabled 开启 CLAT。 在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 中新增 DhcpIpv6OnlyPreferred = (DWORD)1，这样 Windows 就会在 CLAT 可用时主动…

丙午马年的新年红包
type: item
date: 2026-02-16T22:00:00+08:00
description: 马年的有趣好玩的解谜夺宝红包来了！快快点击参与吧→ https://hb.lohu.info 下面是一些你应该知道的事情： 这是一个解密寻宝游戏（a.k.a. CTF），利用你的知识（现学大概也是足够的）解决所有题目，获得红包口令，口令可进入支付宝领取红包。 你应该需要电脑才能愉快玩耍，但手机可能也能解一部分。解法取巧，不涉及对服务器的任何暴力解法（爆破等）。 本次活动时间从北京时间 2026 年 2 月 16 日 22 时开始，持续 24 个小时。 你拿到的所有答案都是 8 位数字，为了方便控制红包发放时间，在支付宝领取时，前面需要加上一个“马”字。如解题得到 20260217，那么最后的红包口令是“马20260217”。 共设 3 个红包，数额分别为：总额 52 人民币元，分 68 个；总额 68 人民币元，分 28 个；总额 68 人民币元，分 36 个。红包领取规则均为“拼手气红包”，如果红包被提前领完不会补发。 如果你是和其他人一起完成的，希望你们先让一个人领取一次再瓜分，但可以在快结束的时候进行第二次领取。总之就是要把机会先留给别人。 这个游戏由 Soha 制作，在游戏结束后也将在本页面上放出题解，往年的内容也可以在博客上找到。如有疑问也请通过博客的“关于我”页面上所述的联系方式联系。 本提示可能会更新，别忘了偶尔来看看。 最后祝大家，新年快乐！ [T+03:00] “manian”更新了点提示。 [T+15:00] “ma26”已经领完。有一些人已经摸到了“manian”的最后一步但没有领到红包，他有两个要素，要凑齐以后才能领到红包。 活动结束后将在下面更新题解。已更新，请看下方的题解。 往期回顾 2025 乙巳蛇年 2024 甲辰龙年 2023 癸卯兔年 2022 壬寅虎年 2021 辛丑牛年 2020 庚子鼠年 2019 己亥猪年 2018 戊戌狗年 2016 丙申猴年 这个红包所涉及的一些代码和文件可以在 GitHub 找到。 2015 年支付宝推出了口令红包，那两年也是群友最热衷于制作解谜红包的时候，一个春节在一个群里就可以有好几道题目可以做。大家把 8 位口令按照自己的创意藏在各种地方。在做了各种群友的红包以后，我觉得这个活动形式非常有意思，于是 2016 年我第一次参与了出题，并从 2018 年持续至今。红包口令一直是 8 位数也是从那时候传下来的。 因此，今年出题的想法是返璞归真，回到十年前简单 misc 的乐趣。3 个题目也都是前几个月一个个在脑子里蹦出来，记录下来而产生的。 不得不说，2025 年是 AI agent 发展非常迅速的一年，从日志可以看出很多参与者都“雇佣”了 agent 帮他们干活。虽然我还在坚持“古法编程”，但也经常指使 AI 帮我查资料。提到这个则是因为见到了 AI agent 对红包题目的降维打击，确实没想到最后看日志会发现数名硅基生物的痕迹。向使用了 AI 解题的群友要了思考过程，注意到 AI 虽然也和人类一样，尝试的过程比较随机、会绕弯路，但靠其并发能力和广阔的脑洞，最终可以解出今年的 3 个红包。但是，作为出题人而言，从活动的本意出发，我可以接受把 AI 当作群友一同讨论，但无法接受让 AI 完全自己完成。这不光是对出题人的尊重，也是对其他徒手参与者的尊重。 接下来我们来做一下这些题目。打开页面，还是祖传的页面。有些朋友可能会注意到 .redbag 里面的 transition-duration: 1082.8359ms;，但如果看过去年的题解应该会知道这里是我忘了改（不好意思，嘻嘻），而不是一个红包。 点击“开”之后，可以看到两个域名，一个有链接，一个没链接。查看源代码还可以发现一个注释掉的域名。接下来我将一个个解答。 → 26horse.hb.lohu.info → manian.hb.lohu.info <!--p>→ ma26.hb.lohu.info</p--> 遅延好き 首先查询 DNS 记录，发现 26horse.hb.lohu.info 只有一个 AAAA 的记录，并且这个 IP 什么端口都没开。如果 ping 的话，好像也没……诶，有响应！ Linux 的 ping 工具会明确提示“(truncated)”，那这回包明显是有点东西了。至于为什么要 8、9 秒才会收到，单纯只是我想延迟了，所以把每个返回报文都缓存了一个固定的时间才返回，有些朋友如果不够耐心就会错过回包。 打开 Wireshark 观察 ICMP echo reply 就可以发现红包口令被直接写在回包的 payload 里面。 这个题目设计上是签到题，但是 52 元分 68 个的红包只被领走 41/68 个（共 32.51 元），一血在 T+00:13:20。 发个红邮包 ma26.hb…

一切都好的2026
type: item
date: 2026-01-04T05:54:00+08:00
description: 今年这篇总结写得比较晚，毕竟 31 号从长沙到上海，1、2 号又开车前往苏州，随便游玩并和延迟等人约饭。写总结这种不很重要的事情就咕咕为先了。之前有几年的总结标题都是对新一年的美好祈愿，但 2022 和 2025 年的标题好像都事与愿违了，顿时感觉自己是不是在立 flag。但不管，今年继续许愿，未来总要往好处想对吧。 2024 年底，由于有了明确的生活目标，我做出了离开上海、远程工作的决定。虽然在 2021 年底搬来沪国之前，我一直是远程工作，但 3 年过去，我们公司的规模已经不是那时候的规模了，作为技术负责人还是需要为公司运营考虑，需要有一个能力足够的同事在办公室和其他组的同事协调。虽然甩手离开从待遇来说也许会有更好的选择，但是我看中的更多还是自由。还好有个原本只是打算来 gap 的同事暂时不考虑读研了，我也欣赏他的能力。夏天，老板完成了他的 MBA 进修回来了，我也正式把一部分工作交给该同事，达成了远程工作的目标。 这两年天天上班，住处又有室友做饭，我的生活逐渐变成了只有计算机（不只是工作的部分）。抛去通勤，除了睡觉之外的几乎所有时间都在屏幕前。下半年在长沙开始远程之后，比较开心的是生活的秩序开始重建了。虽然与年初决定远程时预期的生活有较大出入，但大学的电钢琴重新响了起来，锅铲也出现在了我的手里。屏幕时间的减少，也带来了“拖延症”（没错，就是前两年总结经常提到的）的好转，日记的习惯也从 8 月开始恢复了。 我总是想着在过了某个时间点之后，熬过去了，我的生活就会往好的变化。虽然从到长沙以后的表现也确实如此，但这也许是一种逃避（看作不正视当前的问题的话）、也许是一种拖延（看作把问题的解决延后到某时刻）、也许是一种焦虑（看作一种对问题解决的担忧），也有可能这仨本身就是相辅相成的。 但我们不活在未来，而是活在当下。远期的东西依旧是虚无缥缈的，有了想法就要从今天开始。不放过每一天，但也不执著于每一天，没有哪一天是比其他日子更重要或更不重要的。这一年在情感上的问题也是类似，一味地盯着结束异地的目标去实现，而有意无意地忽视、或者不敢正视当下的一些东西，沟通又不足够，最后的结果就是倒闭。能认识到问题去开始修正就是好事，有了修正的效果也是好事，但是弄坏了的关系要想好起来就不容易了。 春节的时候，同事打算开新车回家，因为金华也就两三百公里，所以原计划我开到金华以后，另外俩同事再换班开回福建。结果在杭州被人追尾，解锁了年轻人的第一次事故。本来还打算换个日本的驾照，以便能带人去一些偏远或者乡下的地方玩，但是太君 7 月底把所有没能在拉闸前考完的人全部踹下了车。有点可惜，但用纽西兰之类的 IDP 也不是不行就是了。 另外的，今年初在夏威夷体验了钓鱼和浮潜，6 月在学术会议上蹭饭当蝗虫，9 月获得了浙江省第一张共用对讲机执照，这些也都十分有趣。今年还参加了 3 场朋友和同学的婚礼，观测微信朋友圈，感觉今年、尤其是 10 月，熟的不熟的似乎都在解锁这个副本。高中前桌的婚礼还是带娃的，6 月的时候还就生娃养娃的话题与他进行了学习和讨论。 至于从以前一直有的报菜名环节，今年就不循例了。一开始有这个环节，是以前处于一个比较不自信的时候想要感谢身边朋友的肯定和陪伴，同时明确地表示他们很重要。每年写总结的时候总会参考下前两年写了些什么，就变成了一款定型文一样流传下来了。但其实真正重要的人不需要说出来，只要不掩藏，对方和身边的人自会察觉；真正的朋友放在心里，就算并不常联系，关系也还是会一样地铁。那么感谢你们，祝我们在新的一年的每个瞬间都会收获幸福和快乐！

最后一张纸质车票
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…

迎接甜蜜2025
type: item
date: 2025-01-01T13:46:00+08:00
description: 谢邀，人在美国，刚上飞机。现在是美国太平洋时间 2024 年最后的四个半小时，而中国已经在 2025 年过了半天了。刚刚结束了湾区的旅游，正在返回位于洛杉矶的群友家。这是人生第一次不在东八区跨年，在 2024 年看着认识的朋友们都在庆祝 2025 的到来，感觉有点奇妙。 要说今年和往年的不同，就是大量出境旅游。先是七月底在日本从东京到大阪转了一圈，再是十月份从东京和朋友去丰桥圣地巡礼并在名古屋狂吃，接着十一月在香港和深圳 city walk 并与朋友约饭，最后十二月底在美国和朋友玩了洛杉矶、西雅图、旧金山。当然开头也说了，本次旅行尚未结束，接下来几天将和朋友一同前往夏威夷，最后从东京转机回家。 因为不喜欢特种兵，紧凑的行程会让我觉得累。所以除了和朋友一同进行的部分，基本都是在住处给自己充电干点活，偶尔随机游走。这样呆的时间也会比较久，因此下半年在境外的时间加起来得有俩月了。在外面的时候真的会挺想念国内的亲人的，长这么大也是从来没有像今年一样老是出去晃悠，不过算在新冠时代后再次见识了异域风情吧。 工作的内容依旧没有什么大的变化，但随着业务发展，也确实需要一个同事分担我的工作了。拖延症也依旧存在，今年并未获得什么改进，不过考虑到接下来的人生走向，这些都该好好调整了。今年没有什么开源的贡献，也没怎么配网。 今年的业余无线电活动基本还是在 6m/2m 波长的 VHF 波段用 5W 功率进行，继续钓鱼一般的心态在操作。神奇的大气和太阳总能给人惊喜：今年在 6m 最远触及了南美（根据互联网自动上报数据得知，但没有完成通联），2m 则依旧通上了俄罗斯和日本。之前考的 FCC 的执照也在旅行时派上了用场，我用他换取了日本的电台执照，并在日本和美国用当地的呼号进行了发射。 命运的安排让今年的我感觉十分不真实，十分期待接下来的 2025 年，重要的人一定会让这一年成为甜蜜美好的开始。我也要继续努力，变成更好的自己！ 最后感谢延迟，感谢清粥老师。感谢今年有女儿、阿珍、妹妹亲如家人的相伴。感谢 ltt、laosb、kkk、逐影少爷、Gogo、点心、twz 等朋友，感谢万呆呆、麻田哥哥、cyy、猴哥、zcy、曹老师、学姐、bml、吴小板、贺神、dd 等 foobar 院同事，感谢 wyy、林儿、焕焕、强哥等同学，洛谷的同事们，和其他大量群友。有你们才能让我今年更丰富多彩，我们新的一年再见！

玩下认证门户的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、托尼、赫兹等群友。非常感谢你们，也希望新的一年能继续一起走。