Re: searchlight
671 subscribers
455 photos
7 videos
17 files
386 links
「祭壇はなく、断罪だけがある。幸いはなく、弾丸だけがある。それでも僕らは、生存戦略する。」
-やくしまるえつこ

@KexyBiscuit
Download Telegram
Re: searchlight
没有预下载啊啊啊啊
FPS 萌新一晚体验:
- 画面元素果然还是太多了,眼花缭乱,尤其是后期的权限区域
- 新手引导还是不够好的感觉,不知道为什么没有设计练习场之类的功能,腐化物品也有点解谜
- 那个背上嵌了个人,拿着大管子的怪物好难打啊啊啊啊
- 手柄好难瞄准(但我不会用键鼠,再练练)(我的问题)
- 但是好好玩,忙完继续()
今年以来,消费品以旧换新政策“加力”又“扩围”,不仅增加了手机、平板、洗碗机等新品类,安排的超长期特别国债资金规模也翻了一番,从去年的1500亿元增至今年的3000亿元。

  这3000亿元超长期特别国债,再加上地方按比例配套和自行安排的资金,共同构成了“国补”的资金来源。

  记者了解到,这3000亿元是“切块”分配到地方的。在分配时,会综合各地区常住人口数量、地区生产总值、汽车和家电保有量、2024年消费品以旧换新政策及资金执行情况等因素,资金分配向2024年消费品以旧换新工作成效较好的地区适度倾斜。

  今年中央安排超长期特别国债支持消费品以旧换新的资金总规模是3000亿元,这个额度是确定的。为了让地方合理有序可持续地使用中央资金,在下达流程上,今年的3000亿元中央资金按批次下达。

  记者从有关部委了解到,今年1月和4月已分别下达两批共计1620亿元中央资金,支持地方做好一、二季度消费品以旧换新工作。后续还有1380亿元中央资金将在三、四季度分批有序下达,同时地方也将相应配套和自行安排足够的地方资金,“国补”还将继续惠及广大消费者。

  消费品以旧换新政策落地的相关链条长、环节多。在6月初推出的“中国经济圆桌会”访谈中,国家发展改革委综合司副司长丁琳在介绍扩内需的一系列政策举措中提及,将加快消费品以旧换新资金下达。


https://www.news.cn/20250618/90e59ae504d440f6afca8fc01f92d48e/c.html
1
此前关于上海电信国际精品网附加包不再提供 CN2 (AS4809) IP,转而仅提供 163 QoS (AS4134) 服务的传言大概是落地了,昨晚 21:32 PPPoE 连接被动中断后发生了如下变化

- IPv4 池子变了,我这边 BRAS 大部分时候是 218.80.64.0/22 ,vBRAS 大部分时候是 218.80.68.0/22 ,偶有例外,之前的情况大家都很熟悉了不提
- 大部分情况下,重拨前后 PPPoE IPCP 下发的 IPv4 地址是可预测的,为上次地址减一,偶有例外,可能是因为目前这个池子使用率还不高
- IPv6 池子也变了,我这边 DHCPv6-PD 和 RA SLAAC 分到的前缀都在 240e:b88::/29 (240e:b8f::/32),之前 DHCPv6-PD 分到的前缀在 240e:38b::/32 ,RA SLAAC 前缀在 240e:38f::/32
- DHCPv6 服务器错误地使用了 0:80fe::/32 作为源地址(而非正确的 fe80::/10 ),导致了如 https://www.chiphell.com/thread-2675022-1-1.html 的问题
- 目前 BRAS 的 MTU 是 1492 、vBRAS 的 MTU 是 1480 ,之前都是 1442
- 尽管昨晚被动断连后出现了上述情况,但是 BRAS (PPPoE AC) 的名字和 MAC 地址在近期都没有发生变化

https://v2ex.com/t/1140538
https://v2ex.com/t/1139770
🎉3🤡1
【2025-06-26 10:33:37】
国家发改委:第三批消费品以旧换新资金将于7月下达。 (金十数据APP)


【国家发改委:第三批消费品以旧换新资金将于7月下达】
金十数据6月26日讯,国家发展改革委召开6月份新闻发布会。会上,国家发展改革委政研室副主任李超表示,消费品以旧换新方面,超长期特别国债的支持力度是3000亿元,前两批一共1620亿元,已经按照计划分别在今年1月份和4月份下达。并将在7月份下达今年第三批消费品以旧换新资金。同时,将协调有关方面,坚持更加注重持续性和均衡性原则,分领域制定落实到每个月、每一周的国补资金使用计划,保障消费品以旧换新政策全年有序实施。 (金十数据APP)
👏4
🤣62😁1
忍不了一年不更新 FANBOX 的创作者……退订了,再喜欢也不想连续第 12 个月花了钱啥也没给
🥰8👍1
露露的故事·六

“请注意,本轮射击测验到此结束,请安全员确认学员已将枪支保险关闭后,带领学员依次有序从侧方退场。请注意……”

在同批参与集训的同学里,露露的能力不算出色,不过对于此前没有接受过专业射击训练的她,已经相当令人满意了。毕竟,她所拥有的,只有一支前辈留下来、不知道转手几次的步枪,以及为找到「同类」,不惜粉身碎骨的决心。

孤身一人的露露在人群中辗转腾挪,终于回到了大厅。望着三三两两勾肩搭背离开的同学,她仿佛又回到了还在研究所的那段时间……自己逃走之后,她们还好吗?那位最讨厌的研究员,真的……露露猛地摇了摇头,对人类抱有任何一丝同情,都有可能将自己陷于无法挽回的境地。

「不会忘记爱意,不会放弃爱意,即使……」

天色渐晚,是时候离开了呢,露露将帽檐又拉低了一点,很快便消失在了熙熙攘攘的大街上。


非常感谢 ulan 老师的赠图,这么会挑!还跟咱探讨查证了那么久这支步枪可能的来源和详细参考图,啵啵啵爱您!!
Illust: 渔刀速递
14
【罗马仕、安克充电宝召回直指电芯供货商安普瑞斯,无锡市场监管局正调查】
金十数据6月30日讯,针对安普瑞斯的电芯问题,今日上午,无锡市市场监督管理局工作人员表示,目前正在调查中,后续会统一对外发布。(澎湃) (金十数据APP)
🤡1
扒拉出来 RouterOS DNS 服务器的一个奇怪问题。

git.kernel.org. 的解析本来长这样:

kexybiscuit@ProArtB550-CREATOR [ linux@master ] $ dig git.kernel.org

; <<>> DiG 9.20.4 <<>> git.kernel.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31730
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 6

;; QUESTION SECTION:
;git.kernel.org. IN A

;; ANSWER SECTION:
git.kernel.org. 1686 IN CNAME geo.source.kernel.org.
geo.source.kernel.org. 600 IN CNAME sg2.source.kernel.org.
sg2.source.kernel.org. 1686 IN A 172.236.150.65

……(以下省略)


但我希望他解析去 sea.source.kernel.org. ,毕竟 sg2.source.kernel.org. 背后对应的 Akamai Cloud (Linode) 新加坡到中国电信上海丢包丢的惨绝人寰,完全没法用。

于是在 RouterOS 上做了如下静态条目的添加,看起来没什么问题对吧。

/ip dns static add cname=sea.source.kernel.org name=geo.source.kernel.org type=CNAME


看起来没什么问题就要出问题了,在加好条目后,向 RouterOS DNS 服务器请求解析 git.kernel.org. 就失败了。

kexybiscuit@ProArtB550-CREATOR [ linux@master ] $ dig git.kernel.org

; <<>> DiG 9.20.4 <<>> git.kernel.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62647
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;git.kernel.org. IN A

……(以下省略)


然后再一看 RouterOS DNS 设置,好嘛,Dynamic Servers 列表都被清空了,之前从 PPPoE 和 DHCPv6 拿到的 DNS 服务器全不见了。

仅仅是动态服务器不见了也能忍,手动加个上游服务器就行了嘛,结果也不行,加上了之后其他请求是正常的,但是解析 git.kernel.org. 依然是跟没加静态条目前一样的结果,静态条目完全没效果。

行吧,暂时要么是脱裤子放屁,加个把 git.kernel.org. 解析到 geo.source.kernel.org. 的静态条目了,但是一旦有其他域名解析到 geo.source.kernel.org. 还是会炸我 DNS 服务器;要么是拍扁 CNAME 关系,直接把 git.kernel.org. 解析到 sea.source.kernel.org. ,大概不会有什么域名 CNAME 去 git.kernel.org. 吧。

MikroTik SUP-192131
😁51
Re: searchlight
扒拉出来 RouterOS DNS 服务器的一个奇怪问题。 git.kernel.org. 的解析本来长这样: kexybiscuit@ProArtB550-CREATOR [ linux@master ] $ dig git.kernel.org ; <<>> DiG 9.20.4 <<>> git.kernel.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:…
Hello,
Thank you for contacting MikroTik Support and for your report!
The issue is identified and will be addressed in further RouterOS releases.
We are sorry for the inconvenience caused.
Regards, Matīss O..
2🤡1
Re: searchlight
Hello, Thank you for contacting MikroTik Support and for your report! The issue is identified and will be addressed in further RouterOS releases. We are sorry for the inconvenience caused. Regards, Matīss O..
我又来了,这次是 RB5009UG+S+ 上 IGMP Snooping 与 Bridge Hardware Offloading 不兼容的问题。

在一个全口开着 Bridge Hardware Offloading 的桥上,开启 IGMP Snooping,这时因为桥自身的接口往往不会主动发送目标为 Link-Local scope All Routers Address ff02::2 的多播包,MDB 中也就不会有相应的条目,导致 Router Solicitation Message 不会被转发至桥接口,自然路由器就不会回复 solicited Router Advertisement Messages,这时 IPv6 SLAAC 处于半坏不坏的状态:每隔几分钟,路由器还是会发送 unsolicited Router Advertisement Messages,但是新入网的设备在收到 unsolicited Router Advertisement Messages 之前都没有前缀信息,也就没有 IPv6 地址。

对于这个问题,MikroTik 提供的解决方案是添加静态 MDB 条目,为全部 VLAN 和全部端口(包括桥接口自身)转发目标为 Link-Local scope All Routers Address ff02::2 的包,这样桥接口就能收到 Router Solicitation Message 了,也就能及时回复 solicited Router Advertisement Messages……了吗?

测试表明,当接收 Router Solicitation Message 的桥端口开启并激活了 Hardware Offloading 时,这个静态 MDB 条目就无法生效,桥接口自身依然收不到 Router Solicitation Message。解决方案也很简单,在会接收 Router Solicitation Message 的桥端口上关闭 Hardware Offloading 就好了,关哪个口、哪个口上的设备 IPv6 SLAAC 立刻恢复正常。当然实践中,我就关闭这个桥上所有接口的 Hardware Offloading 了。

这个问题显然不是我首先发现的了,此前报告的用户说 MikroTik 声称已知晓这个问题,并且可以复现,未来会修复,但是尚未提供具体的时间表。那还是再报告一次吧,起码有个 SUP 编号能跟踪一下修复进度不是。

MikroTik SUP-193239
👏1
你怎么知道
2🥰2😢2
Re: searchlight
我又来了,这次是 RB5009UG+S+ 上 IGMP Snooping 与 Bridge Hardware Offloading 不兼容的问题。 在一个全口开着 Bridge Hardware Offloading 的桥上,开启 IGMP Snooping,这时因为桥自身的接口往往不会主动发送目标为 Link-Local scope All Routers Address ff02::2 的多播包,MDB 中也就不会有相应的条目,导致 Router Solicitation Message 不会被转发至桥接口,自然路由器就不会回复…
现在虽然 RS/RA 正常了,但是目标为 ff02:0:0:0:0:1:ff00::/104 也就是 Solicited-Node Address 的 Neighbor Solicitation Message 还是不转发(实际上应该泛洪),IPv6 Neighbor 条目过期后就没法通信了,真正的解决方案是关掉网络中的所有 MLD Querier,让 IPv6 多播泛洪,运营商 IPTV 网络侧有 IGMP Querier 所以我也不需要单独开一个了

没有 MLD Querier 后就不需要配置静态 MDB IPv6 条目了,当然也就可以重新开启 Bridge Hardware Offloading 了
1