shixudong163.com在《WSL2和VPN》一文后话中简单提了一下WSL2mirrored在支持multicast方面的不足当时并没有开展进一步的深入研究。近日在github上看到多篇issues10735、12344在讨论WSL2的组播问题特别是WSL2mirrored和Windows主机之间无法进行组播通信遂静下心来做了一番功课得以形成此文。一、WSL2的组播支持WSL2新增mirrored模式号称支持multicast但无论是mirrored、bridged还是nat三者其实都使用同一个Linux内核对组播的支持在内核层面是无差别的。只是由于网络层面的不同导致了三种模式对组播的支持程度有所差异而已。在外部设备看来nat模式下组播包无法被转发出去可认为WSL2nat不支持multicastMirrored和Bridged模式对组播的支持程度基本上是一样的只是WSL2一直想要废弃bridged模式所以才有mirrored模式号称支持组播一说。WSL2向外部设备发送组播数据包没有问题但WSL2官方内核不支持CONFIG_IP_MULTICAST因此WSL2在接收组播包时无法发送组播加入信息。当网络上启用了IGMP snooping后因为没有收到WSL2的组播加入信息交换机压根不会将WSL2希望接收的组播包发送到Windows主机导致WSL2无法接收外部设备发来的组播包。对于这一情形有两种解决方法可以让WSL2能够正常接收外部设备发来的组播包。1、由Windows主机代为发送WSL2需要的组播加入信息。2、使用CONFIG_IP_MULTICASTy重新编译WSL2内核支持WSL2发送组播加入信息。二、WSL2bridged的组播优势和不足WSL2bridged使用与主机不同的IP和MACWSL2和Windows主机之间的组播通信与WSL2和外部设备之间的组播通信没有区别因此WSL2可以顺利向Windows主机发送组播数据包。而且由于WSL2和Windows主机之间没有外部网络故即使WSL2使用不支持CONFIG_IP_MULTICAST官方内核也能顺利接收Windows主机发来的组播包。针对WSL2桥接到主机有线网卡的情形考虑到大多数网络已默认启用IGMP snooping功能如前所述WSL2bridged必须使用CONFIG_IP_MULTICASTy的定制内核才能顺利接收外部设备发来的组播包。针对WSL2桥接到主机无线网卡的情形即使外部网络没有启用IGMP snooping功能依然有两种例外情况会导致WSL2无法接收外部设备发来的组播包1、如WSL2使用CONFIG_IP_MULTICASTy的定制内核WSL2在接收组播包时能够发送组播加入信息但有些无线AP在识别到该组播加入信息后将自动启用multicast_to_unicast功能发往Windows主机的组播包被转换为以主机无线网卡MAC为目标的单播包由于Windows网桥驱动功能太烂不能依据三层组播IP对multicast_to_unicast进行逆转换将单播目标MAC恢复成组播目标MAC导致WSL2因使用与主机不同的MAC反而无法接收组播包Vmware桥接主机无线网卡时也有同样的问题VirtualBox桥接可根据三层组播IP对multicast_to_unicast进行逆转换不存在类似缺陷。2、如WSL2桥接的主机无线网卡固件具有multicast filter特性由于WSL2在接收组播包时无法向主机无线网卡添加多址过滤条件主机无线网卡也会主动拦截外部发给WSL2的组播包。针对例外情形1优先使用官方内核不让WSL2发出组播加入信息或者通过防火墙拦截WSL2发出的组播加入信息。此时无线AP一般不会启用multicast_to_unicast功能外部设备发来的组播包能顺利被WSL2接收。针对例外情形2理论上的解决思路是让Windows主机也加入到WSL2接收组播包所需要的同一个组播组此时将由Windows主机向自身无线网卡添加多址过滤条件放行WSL2需要的组播包。该思路看起来很美妙然而却和例外情形1相冲突因为只要Windows主机加入到同一个组播组必然会发送组播加入信息触发无线AP自动启用multicast_to_unicast功能导致WSL2无法接收组播包。因此还需要同时通过防火墙拦截Windows主机或WSL2发出的组播加入信息方能保证WSL2顺利接收外部设备发来的组播包。如外部网络启用了IGMP snooping功能情形稍为复杂这是因为大部分无线AP在检测到网络上启用IGMP snooping功能后也能自动启用multicast_to_unicast功能。根据前面分析此时WSL2将进入无解状态无论内核是否启用CONFIG_IP_MULTICAST都无法接收外部设备发来的组播包。该情形下可以改用WSL2mirrored解决。三、WSL2mirrored的组播优势和不足对于WSL2mirrored来说在和主机无线网卡配合使用时由于使用了和主机无线网卡相同的MAC依然可以顺利接收外部设备通过无线AP发来的multicast_to_unicast组播包不存在类似WSL2bridged的瑕疵。也就是说WSL2无需考虑Win11主机使用有线网卡还是无线网卡只要使用CONFIG_IP_MULTICASTy的定制内核就能顺利接收外部设备发来的组播包。在不考虑WSL2和Windows主机之间相互组播通信时显然WSL2mirrored对组播的支持更胜一筹。然而正是由于WSL2镜像机制的特殊性导致无论内核是否启用CONFIG_IP_MULTICASTWSL2mirrored和Windows主机之间均无法进行组播通信。下面分析具体原因并给出解决方案。四、解决WSL2mirrored的组播不足在《也谈tcpdump抓包》之五“tcpdump和lo”提到Linux在进行本机组播通信时根据默认路由选择对应的网卡并直接在三层调用dev_loopback_xmit发送组播包在该函数中又直接调用netif_rx接收组播包因此本机组播通信全程不使用lo网卡。对于Windows来说根据抓包结果判断本机组播通信和单播通信一样全程必须使用loopback设备。除了这个区别外两者相同点是如果要发送的组播IP未在本机任何网卡完成组播注册工作则不向本机发送组播包。WSL2mirrored镜像了主机所有网卡包括IP和MAC针对主机loopback设备还准备了半镜像网卡loopback0。对于WSL2来说loopback0可不是什么逻辑网卡而是实实在在的物理网卡可用ethtool -i loopback0验证。Windows实时监控WSL2内部系统调用如监控到WSL2内部应用通过系统调用打开了相应端口Windows就将外部设备发往该端口的数据包镜像到WSL2对应网卡的接收方向。Windows自发自收单播通信发生在主机loopback设备上当WSL2内部有相应侦听端口时主机发往loopback设备的数据包也会根据主机不同的发送网卡镜像到WSL2内部对应网卡的接收方向当数据包源IP为主机127.0.0.1时则镜像到loopback0网卡。当我们希望从Windows主机向WSL2mirrored发送组播包时如果主机没有同时加入该组播组如前所述主机并不会向loopback设备发送组播包只会向主机网卡发送组播包而主机发送方向的组播包显然不可能镜像到WSL2对应网卡的接收方向因而WSL2接收不到组播包。针对该情形解决办法是让Windows主机也加入到WSL2接收组播包所需要的同一个组播组实现该组播IP在主机发送网卡的注册。此后Windows主机发送组播包时也会向loopback设备发送一份并根据主机组播发送网卡将组播包镜像到WSL2对应网卡的接收方向使得WSL2能够顺利接收Windows主机发出的组播包。在《也谈tcpdump抓包》一文还提到Linux无法抓取自发自收组播包而Windows则可在loopback设备上抓取自发自收组播包。而且如同Linux一样Windows在loopback设备抓包时也过滤了一半的数据包仅在接收环节显示抓包结果抓包程序的这一设计思路本意是为了消除loopback设备上不必要的显示冗余。然而当Windows主机将发往loopback设备的数据包镜像到WSL2内部网卡时由于主机在发送链路上缺失接收环节导致在loopback设备抓包时根本抓不到从主机发到WSL2的包只能抓到从WSL2回到主机的包可用TCP单播通信验证。因此在前述情形下如Windows主机加入组播组后在另外一个端口侦听那么Windows主机发给WSL2的组播包虽然必须通过loopback设备但由于组播是单向通信并且主机没有接收环节导致出现主机loopback设备上抓不到组播包、而WSL2对应网卡上却能抓到组播包的现象。如果不是对loopback设备抓包机制和数据包方向有清醒的认识详见《也谈tcpdump抓包》之六“tcpdump和数据包方向”Windows下虽无法抓取数据包方向但数据包方向原理雷同就会被搞得一头雾水彷佛主机压根没往loopback设备发送过组播包。当Windows主机加入组播组并且侦听和WSL2一样的端口时两者都需要启用SO_REUSEADDR并且绑定组播地址而非INADDR_ANY主机在loopback设备的发送链路上具备了接收环节就能在loopback设备上正常抓取组播包了。采用上述方案解决WSL2mirrored接收Windows主机发来的组播包显然该过程在WSL2内部是可抓包的在WSL2看来这就是外来组播包而非自发自收组播包。在分析WSL2mirrored无法向Windows主机发送组播包的原因时有必要复习一下WSL2mirrored的镜像原理Windows实时监控WSL2内部系统调用如监控到WSL2内部应用通过系统调用打开了相应端口Windows就将外部设备发往该端口的数据包镜像到WSL2对应网卡的接收方向Windows监控到WSL2向外发送数据包时就将数据包镜像到Windows主机对应网卡的发送方向。至于WSL2的物理网卡loopback0被称之为半镜像网卡是因为主机发往loopback设备的数据包也会根据主机的不同发送网卡镜像到WSL2对应网卡的接收方向当数据包源IP为主机127.0.0.1时则镜像到WSL2的loopback0网卡然而反之却不成立。当WSL2向外发送数据包时如果不加以特殊处理不可能被Windows镜像到主机loopback设备的接收方向。当我们希望从WSL2mirrored向Windows主机发送组播包时WSL2根据默认路由选择对应的网卡发出组播包Windows将其镜像到主机对应网卡的发送方向显然该组播包不可能进入到Windows主机的接收环节。根据这一事实要想WSL2向Windows主机发送组播包只有在路由选择上动手脚设法让Windows将WSL2发出的组播包镜像到主机loopback设备的接收方向从而被Windows主机接收。前文所谓的特殊处理就是用来干这事的其实质就是WSL2mirrored专用的hostAddressLoopback处理机制该机制通过策略路由实现了WSL2内部网卡包括loopback0网卡到主机loopback设备的反向镜像。因此完全可以通过设置hostAddressLoopbacktrue并借用其处理机制改变WSL2内部组播包的走向将其镜像到主机loopback设备的接收方向。对于没有采用connect方式(《TPROXY与Wireguard》文末小插曲也有提到)或者没有调用bind绑定源IP的组播发送程序执行sudo ip route add 组播IP via 169.254.73.152 dev eth0 onlink后此处eth0表示默认路由所在网卡Windows主机就能顺利接收WSL2mirrored发出的组播包。但该方法有两个不足一是改变了组播的走向导致组播包发不到外部设备二是由于Linux的路由查找机制如果组播发送程序采用connect方式或者调用bind绑定了源IP就无法改变组播包的走向。另一种解决方法更为完美完全可以克服以上两个不足那就是同时借用hostAddressLoopback机制和《iptables TEE使用技巧》一文提到的iptables TEE。遗憾的是WSL2官方内核CONFIG_NETFILTER_XT_TARGET_TEE is not set也需要使用CONFIG_NETFILTER_XT_TARGET_TEEy重新编译内核然后执行如下三条命令即可后两条执行顺序不能颠倒。sudo iptables -A OUTPUT -p udp -d 组播IP -j TEE --gateway WSL2的网卡IP该IP表示默认路由所在网卡对应的IPsudo ip rule add from all ipproto icmp lookup localsudo ip rule add from all lookup 128第一条命令通过TEE克隆组播包并且只改变克隆组播包的走向因此不影响原始组播包继续发往外部设备。TEE采取了类似unconnect方式的路由寻址机制故不受组播发送程序使用connect方式或者调用bind绑定源IP的限制。由于TEE在路由寻址时寻址条件相对简陋没有protocol字段而WSLmirrored的hostAddressLoopback机制仅适用于tcp/udp所以还需要第三条命令去除hostAddressLoopback机制对protocol的限制。第二条命令用于保护从WSL2内部ping自身网卡IP不受影响。采用上述两种方法后建议后一种Windows主机能够顺利接收WSL2mirrored发出的组播包。而且在主机看来由于组播包是从loopback设备接收的这就是自发自收组播包而非外来组播包。很显然如同WSL2bridged一样WSL2mirrored和Windows主机之间的组播通信无需经过外部switch/bridge不涉及IGMP snooping所以WSL2内核也无需启用CONFIG_IP_MULTICASTy。五、Linux组播路由选择Linux发送组播包时组播发送程序应使用IP_MULTICAST_IF选项指定组播发送网卡否则将由Linux路由选择相应的组播发送网卡。在IP_MULTICAST_IF指定INADDR_ANY作为组播发送网卡或者组播发送程序干脆没有使用IP_MULTICAST_IF选项时内核将选择默认路由对应的网卡发送组播包如需要通过其他网卡发送组播包则需要添加静态路由指定组播出口网卡无需指定gateway。一旦确定了发送网卡就在该网卡上进行组播发送。通过路由选择组播发送网卡时如静态路由指定了gateway如果组播发送程序没有使用connect方式或者没有调用bind绑定源IP或者静态路由关联的出口网卡和IP_MULTICAST_IF选项指定的组播发送网卡一致时组播包将通过单播方式发送到gateway本文第四部分解决WSL2mirrored向Windows主机发送组播包的第一种方法就是使用了这一思路。即使静态路由指定了gateway由于Linux的路由查找机制如果组播发送程序使用了connect方式或者调用bind绑定了源IP则组播包发送时将忽略该静态路由指定的gateway但仍在该静态路由关联的出口网卡上进行组播发送。在该情形下如继续希望能将组播包通过单播方式发送到指定的gateway可使用本文第四部分第二种方法利用iptables TEE类似unconnect方式的路由寻址机制将组播包通过单播方式发送到TEE指定的gateway。Linux接收组播包时同单播接收侦听一样既可以在组播地址上侦听也可以在INADDR_ANY地址上侦听。同时组播接收程序还必须使用IP_ADD_MEMBERSHIP选项指定需注册的组播IP以及组播接收网卡否则同样由Linux路由选择相应的组播接收网卡。在IP_ADD_MEMBERSHIP选项指定INADDR_ANY作为组播接收网卡时内核将选择默认路由对应的网卡接收组播包。当外来组播包达到本机时IP层需要校验组播包到达网卡是否已注册该组播IP如组播IP未在该网卡注册IP层将丢弃该组播包这也是即便交换机没有启用IGMP snooping单播接收程序能接收广播包、却不能接收组播包的真实原因。组播包通过IP层校验并到达本机UDP协议栈时如组播接收程序已关闭IP_MULTICAST_ALL选项默认开启先前IP层已放行的从非指定组播接收网卡收到的组播包仍会被UDP丢弃此外即使组播接收程序在INADDR_ANY地址上侦听先前IP层已放行的非指定组播IP对应的组播包也会被UDP丢弃。Linux组播接收的上述特点导致和单播接收的行为不完全一致容易引起误解。由于内核只是在IP/UDP层针对组播IP进行了一些额外校验最终仍然要调用单播接收所使用的UDP接收处理函数因此组播接收程序在使用INADDR_ANY侦听时一方面仍可以象单播接收那样接收所有网卡上到达的单播包另一方面却并不能接收所有网卡上到达的组播包。如前所述组播包必须在IP层被强行拦截一道拦截掉那些组播IP未在到达网卡注册的组播包。到了UDP层如组播接收程序没有改变IP_MULTICAST_ALL选项默认开启此时组播接收行为如同单播IP层能放行的组播包都能被接收包括从非指定组播接收网卡收到的组播包组播IP须事先在到达网卡注册以及已注册的其他组播IP对应的组播包。六、多网卡Windows和WSL2mirrored前面提到Windows和Linux本机组播通信有一个共同点即如果要发送的组播IP未在本机任何网卡完成组播注册工作则不向本机发送组播包。换句话说对于那些已在Windows相关网卡自动注册的组播IP224.0.0.1/224.0.0.251/224.0.0.252/239.255.255.250在单网卡环境下Windows主机向这些组播IP发送组播包时主机无需另行开启组播接收程序也会向loopback设备发送组播包并被WSL2mirrored上的组播接收程序顺利接收。在多网卡Windows环境下特别是包含了VPN网卡对于那些已在Windows相关网卡自动注册的组播IPWindows组播发送程序并不按照已有路由选择组播发送网卡虽然这些组播包仍然会被发送到loopback设备但往往被镜像到WSL2另一块网卡的接收方向。对于WSL2mirrored来说如主机发来的这些组播IP224.0.0.252/239.255.255.250未在WSL2的另一块网卡自动注册或者WSL2组播接收程序关闭了IP_MULTICAST_ALL选项WSL2就无法接收这些来自主机loopback设备的组播包除非在WSL2上添加静态路由指定了正确的组播接收网卡。本文第四部分通过hostAddressLoopback处理机制路由指定gateway双管齐下解决了WSL2mirrored向Windows主机发送组播包的问题。然而在多网卡Windows环境下从WSL2mirrored向Windows主机发送那些已在Windows相关网卡自动注册的组播IP时同样也会面临Windows组播接收程序并不按照已有路由选择组播接收网卡的问题。即使WSL2已通过指定gateway将组播包发到了主机loopback设备但由于Windows组播接收网卡和WSL2组播发送网卡的不匹配也会导致Windows主机无法接收这些组播包。此时可在WSL2上调整静态路由所需的网卡或TEE所需的gateway使得WSL2组播发送网卡和Windows组播接收网卡相匹配以便Windows主机能够顺利接收这些WSL2已发送到主机loopback设备、并已在Windows相关网卡自动注册了组播IP的组播包。本文第五部分阐述的Linux组播路由选择机制同样也适用于那些已在Linux相关网卡自动注册的组播IP224.0.0.1/224.0.0.251。鉴于Linux组播路由选择相对Windows更为简洁明了因此针对上述多网卡环境下Windows和WSL2mirrored之间组播通信的特殊情形解决方案一律绕开了Windows不可捉摸的组播路由选择机制而是采用了在WSL2mirrored侧调整组播静态路由的方法加以实现。多网卡Windows环境下非自动注册组播IP的路由选择取决于组播路由224.0.0.0/4对应网卡的跃点数。常规情况下VPN网卡不会添加该路由而Windows本身的物理网卡以及各种虚拟机平台生成的虚拟网卡将各自添加一条组播路由224.0.0.0/4指向对应网卡。鉴于虚拟机平台生成的虚拟网卡不能被WSL2正常镜像无法和WSL2通信因此最简单的做法就是降低Windows主机默认路由对应网卡的跃点数确保Windows始终在主机默认路由对应的网卡上进行非自动注册组播IP的发送和接收。七、Windows和Vmware在分析Windows和WSL2之间组播互通问题的过程中意外发现Vmware虚拟机桥接到Windows无线网卡时Windows主机也无法接收到Vmware虚拟机发送的组播包反之则没有问题。这是由于Vmware采用了简单粗暴的桥接方式将主机桥接网卡发送方向的数据包同时注入到该网卡的接收方向。在虚拟机桥接到主机无线网卡的情形下接收方向被桥接注入的数据包也使用二层nat转换后的主机无线网卡MAC作为源MAC。Vmware虚拟机发出的组播包被桥接网卡分为两路一路向外发送另一路向主机发送Windows内核检测到以自身无线网卡MAC名义发出的组播包同时出现在发送和接收方向误以为产生了二层环路主动丢弃了接收方向的组播包导致Windows无法接收Vmware虚拟机发来的组播包。Windows主机发出的组播包同样被桥接网卡分为两路接收方向的组播包也一样被Windows丢弃但并不影响Vmware虚拟机接收该组播包。显然Windows主机无法接收Vmware虚拟机发送的组播包与WSL2mirrored和Windows主机之间无法组播通信有着本质的区别前者是组播包已到主机无线网卡接收方向并能被主机抓包但后续被Windows内核丢包后者纯粹是路由问题组播包无法发送到接收方接收方也压根抓不到包。因此也就无法用后者改变组播包路由的思路解决前者面临的问题。可通过引入Windows无线网桥来解决这一问题让Vmware虚拟机桥接到Windows无线网桥对于Vmware来说无线桥接变成了有线桥接由无线网桥履行二层nat转换功能。Vmware虚拟机发出的组播包被注入到无线网桥接收方向时其源MAC仍是虚拟机网卡MAC而非主机无线网卡MAC因而能被Windows主机顺利接收。当Vmware虚拟机为Linux并且网络上有IGMP查询器、switch启用了IGMP snooping还有一种更巧秒的办法可以解决前述问题。在Linux虚拟机上执行如下命令后Windows主机也能顺利接收Vmware虚拟机发送的组播包。sudo bash -c echo 1 /sys/class/net/br0/bridge/multicast_queriersudo bash -c echo 1 /sys/class/net/eth0/brport/multicast_to_unicastsudo ebtables -A OUTPUT -p ipv4 --ip-proto igmp --ip-dst 224.0.0.1 -j DROP该解决思路来自于本人疫情期间关于组播学习的一些心得前两条命令用于启用Linux网桥假设为br0物理端口假设为eth0的multicast_to_unicast功能同样可适用于有线网络Linux虚拟机发送的组播包目标MAC被转换为单播MAC主机无线网卡MAC能被Windows主机接收。第三条命令用于防止Vmware虚拟机linux网桥自带的IGMP查询器干涉网络上已存在的IGMP查询器。前提条件是网络上有IGMP查询器、switch启用了IGMP snoopingWindows主机得以将组播IP加入信息定期向Linux虚拟机报告确保虚拟机能长期保存主机发来的组播IP信息持续为multicast_to_unicast功能提供有效的单播MAC。此处关键仍在于Windows主机无法接收虚拟机网桥IGMP查询器发出的组播查询包因此也就无法主动向Linux虚拟机进行定期报告而网络上的IGMP查询器可使Windows主机顺便向Linux虚拟机进行定期报告。本文第二部分提到WSL2桥接到主机无线网卡和无线AP的multicast_to_unicast功能之间的冲突导致WSL2bridged无法接收外部设备发来的组播包。Vmware虚拟机Linux桥接主机无线网卡时也有同样的问题WSL2可以采用mirrored方式解决Vmware虚拟机Linux的类似问题又该如何解决呢先透露一下答案组合使用Windows无线网桥和Linux的ebtables命令。为何一定需要Windows无线网桥呢这和Vmware的二层nat转换机制有关在《Virtualbox配置Linux guest桥和修改网卡MAC》一文中提到在桥接无线网卡时VirtualBox的二层nat转换机制依赖虚拟机网卡MAC导致虚拟机里无法随意更改虚拟机网卡MAC。Vmware的二层nat转换不存在类似问题但也有自己的特色即只有看到了虚拟机外出数据包的源IP才允许同样的IP作为目标IP从外部进入虚拟机。当外部设备发来的数据包目标IP为未知IP时Vmware的二层nat转换压根就不将该数据包传给虚拟机平时感觉不到这个特色是因为ARP在默默起作用验证方法手工修改虚拟机IP主机通过静态ARP映射指向该IP除非虚拟机先ping外部设备否则主机永远无法ping通虚拟机。Vmware虚拟机桥接到Windows无线网桥后无线桥接变成了有线桥接由无线网桥而非Vmware履行二层nat转换功能。即使外部设备发来的数据包目标IP为Vmware未知的IP也会被VMware如数传给虚拟机。一旦数据包到达了虚拟机就可以使用etables对其上下其手在Vmware虚拟机Linux上执行如下命令后便不受无线AP的multicast_to_unicast功能影响可以施施然接收外部设备发来的组播包了。sudo ebtables -t nat -A PREROUTING -p ipv4 --ip-proto igmp --ip-dst 224.0.0.1 -j redirectsudo ebtables -t nat -A PREROUTING -p ipv4 --ip-proto udp --ip-dst 224.0.0.0/4 -j redirect在执行上述命令前虽然外部设备发来的组播包也能到达虚拟机但在经过无线AP的multicast_to_unicast转换后组播包目标MAC被改为主机无线网卡MAC。到达虚拟机时包类型被标记为PACKET_OTHERHOST后续被虚拟机三层DROP导致虚拟机无法接收外部设备发来的组播包。这两条命令的作用都是将满足条件的组播包目标MAC从主机无线网卡MAC修改为Linux网桥MAC同时修改包类型为PACKET_HOST使之能到达虚拟机三层并能被三层进行常规处理详见《Linux二层包类型对网络功能的影响分析》之二“包类型对桥的影响”。第一条命令允许Linux接收IGMP查询器发来的组播查询包并向外部IGMP查询器报告自己的组播加入信息使得外部设备能向Vmware虚拟机Linux发送组播包。第二条命令允许Linux接收外部设备发来的组播数据包并将其转交给上层组播接收程序。这一解决方案无法适用于WSL2bridged这是由于WSL2桥接所依赖的Hyper-v使用了Switch技术而VMware采用的是Hub技术所以当组播包目标MAC被无线AP改成主机无线网卡MAC后根本到不了WSL2bridged。测试中发现Vmware虚拟机桥接到主机无线网卡后除了不支持multicast_to_unicast逆转换居然能向Windows主机无线网卡添加多址过滤条件解除了主机无线网卡拦截外部组播包的隐患。改为桥接Windows无线网桥后这一隐性福利消失了。如遇到主机无线网卡固件具有multicast filter特性还需要让Windows主机也加入到Vmware虚拟机接收组播包所需要的同一个组播组由Windows主机向自身无线网卡添加多址过滤条件放行Vmware虚拟机所需要的外来组播包。
