> Both IPv4 and IPv6 are connected to the Internet, but the Hikari TV multicast packets will stop.

 

To add a bit more detail in the postscript,

the topology is as follows:
ONU->NTT Router (XG100NE)->Router (RTX1300)->L3 Switch (10G08-0800GSM)-+->HikariTV Tuner (ST4500)
                                                                                                                                      +->Archer BE805
                                                                                                                                      +->Archer BE900

 

When the BE900 is set to AP mode and powered off, video is being distributed to the Hikari TV tuner connected to the same L3 switch.
At that time, the L3 switch is sending MLDv2 packets, and the multicast router list recognizes only one uplink router port.

 

However, after about one minute of powering on and starting up the BE900, the BE900 is also listed in the router list of the L2 switch.
In the MLD Snooping settings of the L2 switch, a fixed router port is specified, and the Immediate Leave setting is disabled.
Then, all MLDv2 data disappears from the multicast table, and no multicast packets flow at all.

 

At this time, the BE805, which is placed in the same row, is powered on and has no effect. Only the BE900 creates this state.

This is the situation you are in.

 

Of course, if the Hikari TV tuner is connected directly under the NTT router (XG100NE), this state will not occur.

However, we want to place the Hikari TV tuner in this way because we want it to belong to the same subnet.

 

Best Regards.

Wherever I write "L2 Switch", it is "L3 Switch". Also, please forgive me if the words are a little strange.

@Joseph-TP 

 

I then updated the firmware on my Archer BE900 to the latest version (1.1.7 Build 20250529 rel.12784(4A50)), and my IPTV (Hikari TV) tuner continues to receive TV without any issues.

 

However, there's one issue that concerns me, and I would appreciate it if you could report it to the developers.

 

My home network topology includes a router with a 10GbE L3 switch connected to it. I use that L3 switch to perform MLD snooping. I also perform IGMP snooping at the same time. The L3 switch recognizes the port connected only to the BE900 as an IGMP router. Since the IPTV (Hikari TV) in question only uses MLD v2, this wasn't a problem, but since there's nothing connected to the BE900 at the moment, it seems like the BE900 itself is emitting the router signal. If you think about it, it's clear why the BE900 in AP mode is recognized by the L3 switch as an IGMP router.

 

Incidentally, it is not recognized as an MLD router.

 

Also, the BE805 I have has never been recognized by the L3 switch as either an IGMP or MLD router.

 

I hope this information is helpful.

  @Joseph-TP 

 

I'm sorry, my reply was completely incorrect.

 

I was running the new firmware (Archer BE900(JP)_V2_1.1.7 Build 20250529) that I mentioned last time, but the issue returned today.

In AP mode, IPv6 Multicast was no longer being broadcast on my Hikari TV tuner (ST-4500).

When I reverted to the beta firmware (be900v2-up-ver1-1-7-P1[20250515-rel56887]_nosign.bin) that you released last time, the issue disappeared.

 

In other words, as I reported last time, it appears that the issue has not been fixed in the latest official version 1.1.7, and multicast is still blocked.

 

I suspect that the fix you provided in the beta version I checked has not been reflected in the official version, but could you please confirm this?

 

Best Regards

  @Joseph-TP 

 

Technical Report: Archer BE900 (AP Mode) Sending MLD Queries, Disrupting “Hikari TV” IPv6 Multicast Reception

1. Summary

When using the Archer BE900 in AP Mode, IPv6 multicast video distribution for the “Hikari TV” service stops near the end of the BE900’s boot process. Packet capture analysis confirms that the BE900 is sending unsolicited MLD Queries (ICMPv6 Type 130), which interferes with multicast delivery in the network and causes IPTV playback to stop.

2. Environment

• Service: NTT FLET’S Hikari Cross + Hikari TV (STB model: ST-4500)

• Network topology:

  • HGW: XG-100NE (IPv6 MAP-E)

  • Router: YAMAHA RTX1300 (connected to HGW)

  • L3 switch with multicast snooping enabled

  • STB connected to the L3 switch

  • Archer BE900 in AP Mode connected to the same L3 switch

• IPv6 multicast: Used for Hikari TV channel delivery

3. Reproduction Steps

1. Ensure STB (ST-4500) is playing Hikari TV normally.

2. Connect BE900 (AP Mode) to the same L3 switch, keep it powered off.

3. Start a packet capture on a mirrored port.

4. Power on the BE900.

5. Near the end of the BE900 boot process (~80–100 seconds), IPTV playback on the STB stops.

4. Technical Evidence from PCAP Analysis

4.1 Capture Summary

• Total packets: ~4,391

• BE900 sent two ICMPv6 Type 130 (MLD Query) packets:

  • Source MAC: 68:7F:F0:0D:B7:44 (BE900)

  • Destination: ff02::1 (all-nodes), Group Address: ff00::0 (all groups)

  • Timestamps: ~87.982 s and ~96.032 s after power-on

4.2 Why This Causes Disruption

• Even in AP Mode, the BE900 is acting as an MLD Querier by sending MLD Queries.

• In MLD, the Querier role is elected based on the lowest IPv6 address on the link. The BE900 can become the Querier.

• If the BE900’s Query Interval/Robustness values differ from the existing Querier (HGW/RTX1300), multicast forwarding tables in the switch can age out prematurely.

• Result: multicast delivery to the STB stops, interrupting IPTV playback.

5. Impact

• IPTV services using IPv6 multicast (e.g., Hikari TV) are interrupted.

• Other IPv6 multicast-based services could also be affected.

6. Requested Action

1. Stop sending MLD Queries when in AP Mode.

2. Provide a setting to disable IGMP/MLD Querier functionality entirely.

3. Release updated firmware (beta acceptable) as soon as possible.

 

If needed, I can provide the packet capture files, but only privately via email, not on this post.

 

Best Legards.

  @Joseph-TP 

 

Incidentally, the BE900 firmware version used for this capture was the beta version (BE900v2_1.1.7_250515_beta.zip) previously provided by the development team.