【罗马仕、安克充电宝召回直指电芯供货商安普瑞斯，无锡市场监管局正调查】
金十数据6月30日讯，针对安普瑞斯的电芯问题，今日上午，无锡市市场监督管理局工作人员表示，目前正在调查中，后续会统一对外发布。(澎湃) (金十数据APP)
金十数据6月30日讯，针对安普瑞斯的电芯问题，今日上午，无锡市市场监督管理局工作人员表示，目前正在调查中，后续会统一对外发布。(澎湃) (金十数据APP)
🤡1
扒拉出来 RouterOS DNS 服务器的一个奇怪问题。
但我希望他解析去
于是在 RouterOS 上做了如下静态条目的添加，看起来没什么问题对吧。
看起来没什么问题就要出问题了，在加好条目后，向 RouterOS DNS 服务器请求解析
然后再一看 RouterOS DNS 设置，好嘛，Dynamic Servers 列表都被清空了，之前从 PPPoE 和 DHCPv6 拿到的 DNS 服务器全不见了。
仅仅是动态服务器不见了也能忍，手动加个上游服务器就行了嘛，结果也不行，加上了之后其他请求是正常的，但是解析
行吧，暂时要么是脱裤子放屁，加个把
MikroTik SUP-192131
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
😁5❤1
Re: searchlight
https://blog.jackywang.page/posts/apenwarr-ipv6-translate/
Tailscale
IPv4 vs IPv6: A Shift in Attitude and the Future of Networking
Explore the evolving perspectives on IPv4 and IPv6. Discover how a shift in design philosophy and the challenges of dual-internet networks shape the future of internet connectivity, with insights on Postel’s Law and the concept of IP mobility.
❤5👍2
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
对于这个问题，MikroTik 提供的解决方案是添加静态 MDB 条目，为全部 VLAN 和全部端口（包括桥接口自身）转发目标为 Link-Local scope All Routers Address
测试表明，当接收 Router Solicitation Message 的桥端口开启并激活了 Hardware Offloading 时，这个静态 MDB 条目就无法生效，桥接口自身依然收不到 Router Solicitation Message。解决方案也很简单，在会接收 Router Solicitation Message 的桥端口上关闭 Hardware Offloading 就好了，关哪个口、哪个口上的设备 IPv6 SLAAC 立刻恢复正常。当然实践中，我就关闭这个桥上所有接口的 Hardware Offloading 了。
这个问题显然不是我首先发现的了，此前报告的用户说 MikroTik 声称已知晓这个问题，并且可以复现，未来会修复，但是尚未提供具体的时间表。那还是再报告一次吧，起码有个 SUP 编号能跟踪一下修复进度不是。
MikroTik SUP-193239
在一个全口开着 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
MikroTik community forum
Enabling IGMP snooping destablizes my network
I can’t really figure out why. But my network is broken when IGMP snooping is enabled. But in 2 different ways, on 2 different Mikrotik devices. For context, rt1 is the gateway to the internet, that’s a Fritzbox. In the logs of the Fritzbox I do see “04.05.25…
👏1
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 不会被转发至桥接口，自然路由器就不会回复…
连带着上次的问题整理到论坛了，希望下一个遇到问题的人能省点时间（
https://forum.mikrotik.com/t/two-bugs-encountered-on-rb5009ug-s-recently/262759
https://forum.mikrotik.com/t/two-bugs-encountered-on-rb5009ug-s-recently/262759
MikroTik community forum
Two bugs encountered on RB5009UG+S+ recently
Static CNAME DNS Entry has to be flattened The first is with the DNS Server, reported in MikroTik SUP-192131, “is identified and will be addressed in further RouterOS releases.” git.kernel.org. resolves as the following in my region… kexybiscuit@ProArtB550…
👏1
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 了
没有 MLD Querier 后就不需要配置静态 MDB IPv6 条目了，当然也就可以重新开启 Bridge Hardware Offloading 了
❤1
Re: searchlight
现在虽然 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…
😡 不玩了，拆了，IPTV 桥接禁用，IGMP Snooping 禁用，MikroTik RouterOS 上 IPv6、VLAN、IPTV (IGMP) 就是无法共存的，忘了他吧
🌚10❤1
Re: searchlight
vBRAS 的 MTU 是 1480
MikroTik 论坛有人指出了这个 1480 MTU 的真实原因，非常详尽
https://forum.mikrotik.com/t/pppoe-compatibility-issues-with-vbras-nfv/182546
https://forum.mikrotik.com/t/pppoe-compatibility-issues-with-vbras-nfv/182546
MikroTik community forum
PPPoE Compatibility Issues with vBRAS/NFV
Hey guys, If you encounter the following problems: a. When PPPoE dial-up, the MTU will auto adjust from 1492 to 1480 after connected 3 seconds. b.If you enable IPv6 you will get many warnings in the log similar to: invalid mtu 1492 on pppoe-out1 from…
❤1😢1
Re: searchlight
DHCPv6 的问题可以通过如下规则绕过 /ipv6/firewall/filter add action=accept chain=input comment="Accept DHCPv6-Client prefix delegation from wrong addresses." dst-port=546 protocol=udp src-address=0:80fe::/32
MikroTik community forum
PPPoE Compatibility Issues with vBRAS/NFV
Huawei products should not be used for a multitude of reasons, and one you probably dont know about is how poorly they treat their workers
❤1
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 不会被转发至桥接口，自然路由器就不会回复…
Hello,
Thank you for contacting MikroTik support.
We appreciate the report.
We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide a release date now.
Regards, Edgars P..
❤1
FBC: Firebreak 在 Steam 上的在线数据简直是前无古人级别的差……虽说应该还有一大部分玩家在两家主机平台（含 Xbox PC），但是依然不改变结论，Remedy 彻底玩脱了……只希望能撑到今年承诺过的两次地图更新，不要搞得我没游戏玩（
Re: searchlight
FBC: Firebreak 在 Steam 上的在线数据简直是前无古人级别的差……虽说应该还有一大部分玩家在两家主机平台（含 Xbox PC），但是依然不改变结论，Remedy 彻底玩脱了……只希望能撑到今年承诺过的两次地图更新，不要搞得我没游戏玩（
虽然游戏烂，但是主菜单音乐好听啊，什么时候单独拿出来发个 OST（虽然好像只有主菜单和撤离这两首好听）
💩1🤡1
Re: searchlight
此前关于上海电信国际精品网附加包不再提供 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 地址是可预测的，为上次地址减一，偶有例外，可能是因为目前这个池子使用率还不高…
【上海市电信用户申诉受理中心】您好，您的申诉事项中心已按《电信用户申诉处理办法》办理，被申诉人反馈未能与您和解。依据规定，您可向我中心申请申诉调解。申请方式：发送邮件、邮寄书面材料等。邮件发送至 sqsstj@mailshca.miit.gov.cn ，书面材料邮寄至上海市黄浦区延安东路1200号10楼申诉中心，邮编： 200003。（邮件或书面材料的标题请注明“申请申诉调解”，内容须包含姓名、联系电话、申诉涉及号码等。）谢谢。
🎉3💩2🤡1