IP Multicast Support

[Tom Moulton]

Try as I might, I cannot receive IP Multicast based video streams under Android x86.  For clarity I'm running Android-x86 9.0-R2 under VirtualBox (6.1.12) with a Bridged Network Adapter configuration.

Here is what I am doing...

• I am streaming an MP4 file via VLC 64-bit v3.0.11 under a Windows 10 system via Multicast (udp://@224.1.1.1:1234/).
• I have a Windows 10 VM under VirtualBox (w/ a Bridged Network Adapter) that is able to receive this video via Multicast using VLC 64-bit v3.0.11.
• I have a CentOS 7.8 VM under VirtualBox (w/ a Bridged Network Adapter) that is able to receive this video via Multicast using VLC 64-bit v3.0.11.
• I have a Google Pixel 3 on this same network that is also able to receive this video via Multicast using MX Player v1.26.4.
• Lastly, I have my Android-x86 9.0-R2 VM (under VirtualBox w/ a Bridged Network Adapter) this is NOT able to receive this video via Multicast using MX Player v1.26.4; however, I can stream it via unicast (from the same Windows 10 system using VLC) and receive it using MX Player on this Android-x86 VM.  I have also tried XPlayer v2.1.8.1 and get the same result (Multicast & unicast).
  

What do I have to do to get IP Multicast to work on Android-x86?

I know IP Multicast can be a little finicky on systems with multiple NICs, especially under Windows.  Windows tends to add IP Multicast routes for all active network interfaces and when streaming/receiving it seems to default to the first IP Multicast route it finds, so I have had more success when I remove all the IP Multicast routes and add the IP Multicast route back only for the network interface I am wanting to send/receive IP Multicast.  I also have disabled the Windows Firewall on both the above Windows 10 systems, but unsure if this was required.  Just removing all of the encumbrances that could possibly cause issues.

I tried adding a Multicast route to the Android-x86 system as one didn't show when I did a "netstat -rn" under the console (CTRL-ALT-F1), but that didn't help.  I cannot find a way to disable IPSEC or the firewall under Android-x86 to see if that is interfering with the receiving of Multicast.  On a side note, I will say that when I stream unicast to my Google Pixel, I get a better video playback than when I stream using Multicast (anecdotally speaking).

Any help is appreciated!.

Regards,

Tom Moulton

[Mauro Rossi]

Hello,

You could try to have a look here:

https://stackoverflow.com/questions/13221736/android-device-not-receiving-multicast-package

I don't know if permission / group is enabled. Interesting the App "Multicast tester"

https://stackoverflow.com/questions/37293456/why-does-multicast-reception-not-work-on-some-android-devices

CONFIG_IP_MULTICAST=y # this is enabled in android-x86{,_64}_defconfig

Mauro

[Tom Moulton]

Thanks for your reply on this.  The second link you provided, referenced a tool called Multicast Tester.  Using that I was able to validate the kernel in the Android-x86 9.0-R2 release does NOT appear to have IP Multicast enabled.  I installed this Multicast Tester Android app on two separate Android-x86 9.0-R2 instances (one under VMware Player 15.5.6 and one under VirtualBox 6.1.12) and I also installed it on my Google Pixel 3 (Android 10).  I could receive the IP Multicast messages sent from both Android-x86 9.0-R2 VMs but they (i.e., the Android-x86 9.0-R2 VMs) could NOT receive IP Multicast messages sent from each other or from the Google Pixel 3.  They could receive their own IP Multicast messages though.

So it appears I need an Android-x86 release with an kernel that is compiled with IP Multicast support.  Anyone know of one that exists or do I have to go through the "slog" of building from source?

Regards,

Tom Moulton

[Tom Moulton]

OK, so I've gotten up to speed on building Android-x86 from the source code (w/ OpenGAPPS) following guidance from these links...

1. https://www.android-x86.org/source.html  - if you just use this guidance, you will not have an image with Google Play Services/Store
2. https://groups.google.com/g/android-x86/c/XkPdT1hwpps/m/4Y84kwh1BQAJ
3. https://github.com/opengapps/aosp_build

I successfully built the x86_64 ISO versions of Android-x86 Q (10.0) and Pie (9.0) and installed them as VMs under VirtualBox (6.1.12).  Before doing so, I ripped through the source code looking for "CONFIG_IP_MULTICAST" and all references had the value set to "y" (YES).  After installing "Multicast Tester" and "MX Player" under both VMs, I got the same results as I described above.  I could NOT receive any IP Multicast video (via MX Player - udp://@224.2.4.8:1234) or text (via "Multicast Tester" - 224.2.4.8:5000) but my Google Pixel 3 (running Android Q on the same local network) is able to receive IP Multicast video (via MX Player - udp://@224.2.4.8:1234) and text (via "Multicast Tester" running on the other Android-x86 VMs - 224.2.4.8:5000).  To reiterate from my previous post, this is NOT a VirtualBox issue, as I have the same problem using an Android-x86 VM under VMware Player.

Rereading the 2nd link provided by Mauro (https://stackoverflow.com/questions/37293456/why-does-multicast-reception-not-work-on-some-android-devices), the "Answer" states...

"Bad news: This seems to be related to the affected devices. There is no /proc/net/igmp available exactly on those devices that can not receive the multicast traffic. As already expected this very likely leads to the missing join group request (IP_ADD_MEMBERSHIP)."

In all my Android-x86 VMs, the /proc/net/igmp file exists and has data inside of it, so it appears IP Multicast is configured properly in the kernel (see attached screenshot).  I notice that there is NOT a multicast route associated with IP Multicast when I run "netstat -rn" from the console, which may NOT be an issue, as on my Ubuntu 18.04 & CentOS 7 VirtualBox VMs (running on the same host platform as the Android-x86 VMs), this is also the case and I am able to successfully receive IP Multicast traffic.  Incidentally, manually adding in an IP Multicast route from the console does NOT help (i.e., "route add -net 224.0.0.0 netmask 240.0.0.0 wlan0").

BOTTOM LINE:  Has anyone been successful receiving (i.e., subscribing to) IP Multicast traffic within Android-x86?  I am still feeling this is an Android-x86 firewall issue, as with my CentOS 7 system, if I do NOT disable firewalld (i.e., "sudo systemctl stop firewalld") I am unable to receive IP Multicast traffic.

Regards,

Tom Moulton

[Tom Moulton]

Adding more context in the hopes that someone "in the know" will eventually "chime in".  I came across the following web page titled "Testing multicast support on Android devices" (https://cafbit.com/post/testing_multicast_support_on_android/), which helped provide additional insight.  Although its old (2011), its still very relevant and useful!  The issue I am encountering with Android-x86 appears to be an IPv4 Multicast vs IPv6 Multicast issue.  It appears Android-x86 is configured with IPv6 Multicast support ONLY (complete assertion at this point, not a fact), but signs are pointing in this direction.  Using the mDNS based "Multicast Test Tool" APK provided through the above URL (i.e., installed manually through Chrome on your Android device, where you to have to deliberately allow Chrome to install packages), on both my Android-x86 (9.0 - Pie) and Google Pixel 3 (10.0 - Q), I note the following...

• The "Multicast Test Tool"  on my Android-x86 device only lists IPv6 based mDNS traffic coming from my local network
• The "Multicast Test Tool" on my Google Pixel 3 only lists IPv4 based mDNS traffic coming from my local network

When I use the "send_mdns.pl" Perl script, provided by the URL above, on my CentOS 7 VM (to explicitly send out a single mDNS packet via IPv4 Multicast), I only receive this mDNS packet in the "Multicast Test Tool" my Google Pixel 3 and the IP address shown by the "Multicast Test Tool" is an IPv4 one.  I'm looking at how to modify this perl script to send IPv6 Multicast to prove out my assertion.

So I guess I need to go back to the Android-x86 x86-64 kernel configuration file and see how to enable IPv4 Multicast support?  BTW, I am having this issue receiving IPv4 Multicast packets on Android-x86 7.1-r4, 8.1-r5, 9.0-r2, 9.0-r2-k49 & 10 releases.  FYI, the Android-x86 10 release I tested against is the one I built as there is not one available yet via https://www.android-x86.org/.

Tom

 

[Chih-Wei Huang]

'Tom Moulton' via Android-x86 <andro...@googlegroups.com> 於
2020年8月28日 週五 上午3:44寫道：

> Adding more context in the hopes that someone "in the know" will eventually "chime in". I came across the following web page titled "Testing multicast support on Android devices" (https://cafbit.com/post/testing_multicast_support_on_android/), which helped provide additional insight. Although its old (2011), its still very relevant and useful! The issue I am encountering with Android-x86 appears to be an IPv4 Multicast vs IPv6 Multicast issue. It appears Android-x86 is configured with IPv6 Multicast support ONLY (complete assertion at this point, not a fact), but signs are pointing in this direction. Using the mDNS based "Multicast Test Tool" APK provided through the above URL (i.e., installed manually through Chrome on your Android device, where you to have to deliberately allow Chrome to install packages), on both my Android-x86 (9.0 - Pie) and Google Pixel 3 (10.0 - Q), I note the following...
>
> The "Multicast Test Tool" on my Android-x86 device only lists IPv6 based mDNS traffic coming from my local network
> The "Multicast Test Tool" on my Google Pixel 3 only lists IPv4 based mDNS traffic coming from my local network
>
> When I use the "send_mdns.pl" Perl script, provided by the URL above, on my CentOS 7 VM (to explicitly send out a single mDNS packet via IPv4 Multicast), I only receive this mDNS packet in the "Multicast Test Tool" my Google Pixel 3 and the IP address shown by the "Multicast Test Tool" is an IPv4 one. I'm looking at how to modify this perl script to send IPv6 Multicast to prove out my assertion.
>
> So I guess I need to go back to the Android-x86 x86-64 kernel configuration file and see how to enable IPv4 Multicast support? BTW, I am having this issue receiving IPv4 Multicast packets on Android-x86 7.1-r4, 8.1-r5, 9.0-r2, 9.0-r2-k49 & 10 releases. FYI, the Android-x86 10 release I tested against is the one I built as there is not one available yet via https://www.android-x86.org/.

If you doubt that, you may ask kernel experts to see
how to enable "IPv4 Multicast" in the configuration file.
What I know is we have already set CONFIG_IP_MULTICAST=y
in our kernel. It should be a common setting for both IPv4 and IPv6
since there is no any doc saying it's an IPv4 or IPv6 specific config.

[Michael Goffioul]

I'm using UDP multicast with pie-x86 running on my hardware and afaik it works fine (i'm using simple test using VLC streaming from my desktop, but our QA team is using real transcoders). I've never tried UDP multicast in a VM, though.

Michael.

[Tom Moulton]

Chih-Wei,

Appreciate the feedback, apologies for the delay in responding; however, I wanted to do some additional testing/characterization beforehand.  Bottom line, I am starting to suspect this being an issue with the VirtWifi adapter Android offers when running Android-x86 as a VM under VirtualBox and VMware.  I believe Android offers this whenever there isn't an actual WiFi NIC available but it detects an alternate active NIC (e.g., Ethernet).  That is, the virtual NIC coming from VirtualBox and VMware through the VM, as presented to Android, does NOT show available WiFi networks to connect to other than one called VirtWifi.  In this situation, Android offers a VirtWifi wireless network to connect through the VMs virtual NIC (see attached), that does NOT require a security pass code.  In the cases when I have to use the VirtWifi wireless network (particularly in the case of Android-x86 running under a VM), I am unable to receive IPv4 Multicast traffic.

For clarity, I found a computer I could boot the Android 9.0-R2 ISO from that natively recognizes the internal WiFi adapter (i.e., presents my local Wireless Networks that I can connect to directly, NO VirtWifi adapter) and I am able to successfully receive IPv4 Multicast, so this negates my previous concern about IPv4 Multicast support being enabled within the 4.19 kernel. 

A next step is to look for a USB-to-WiFi adapter (with 4.19 kernel support) that I can map through to my Android-x86 VM and see if I can connect to an actual WiFi network vs the VirtWifi network described above, and see if this resolves the issue.

On a lark, I decided to add a second virtual "bridged" NIC to my VirtualBox Android-x86 VM and VOILA, that did the trick.  Doing so created an eth1 interface associated with this second virtual NIC that allowed the IPv4 traffic to flow to the VM (e.g., testing using MX Player receiving a UDP IPv4 Multicast video, streaming from VLC on my Windows 10 system, see attached)!  Oddly enough the wlan0 interface didn't come up in this configuration (only eth1), which caused some side effect (e.g., I couldn't run the Settings app, it kept hanging up); however, under my Android-x86 VMware VM, I did NOT have this issue (although I was unable to connect to the VirtWifi network) and this second bridged virtual NIC resolved the IPv4 Multicast issue as well.  Unfortunately in this configuration, I could NOT test with the "Multicast Tester" program I chronicled earlier in this thread as it checks to see if the WiFi adapter is active/connected before it will send/receive IPv4 Mutlicast packets.

Tom

[Michael Goffioul]

Did you try to add VIRT_WIFI=0 to the kernel command-line? This will disable the VirtWifi setup and use the wired NIC normally. That's what I use in my build. The downside is that some apps insist on using a wireless connection and do not work anymore (e.g. Skype).

This communication, including any attachments, may contain Proprietary, Export Controlled, Legally Privileged or other Confidential Information. Any unauthorized review, printing, copying, transmission, dissemination, or use of the information is strictly prohibited. If you are not the intended recipient, please indicate to the sender that you have received this email in error, and delete the copy you received.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/814abd5e-c821-4b3e-b51c-4533652a3867n%40googlegroups.com.

[Tom Moulton]

Michael,

Thanks, that works as well and does NOT cause the "Settings" app to hang on my VirtualBox Android-x86 VM.  To reiterate, in this configuration, I have the same issue with the Multicast Tester tool as you have noted with other apps (e.g., Skype).

Tom

[Michael Goffioul]

I can confirm that there seems to be an issue receiving multicast traffic with VirtWifi. I have a device (not a VM) running Android-x86 9 and a TV headend (DVEO) streaming using UDP/mutlicast. When the device boots without VirtWifi, it can play the TV stream. When it boots with VirtWifi, it can't. OTOH, the device also uses mDNS, and that still works with VirtWifi enabled. However, a network trace shows that the 2 scenario do not use the same IGMP version: mDNS uses IGMPv3, while java.net.MulticastSocket (underlying socket used by the video player app) uses IGMPv2.

[David White]

I know this is old. But I was having the exact same problem with mdns NOT being received inside Android x86 running in a virtual box. I became convinced that this was an Android x86 issue and not related to anything else as I was able to see the mdns traffic inside the virtual box nic log file. This thread and especially Tom's suggestion to add a 2nd bridged NIC to the virtual box also solved my problem. Thanks so much!

[Michael Goffioul]

Alternatively you can boot with VIRT_WIFI=0 on the kernel command-line, to disable the virtwifi system and use plain eth. Back in the day, you could easily run into compatibility issues with various apps insisting on using a WiFi connection, ignoring the available eth one (typical example: Skype). So virtwifi was convenient to overcome those issues. Nowadays, most of these compatibility problems have disappeared.

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/31e921f2-cd0c-49df-ba35-18a6d7c0ca73n%40googlegroups.com.

[Huy Minh Bùi (HMTheBoy154)]

currently I can see there're those Gameloft games and also Via Browser which somehow doesn't allow you to download if you use Ethernet. 

Also I just got this patch from WayDroid team, they use it because they can't be able to use virt_wifi. I haven't tried it yet but seems pretty neat

This is for r-x86

https://github.com/BlissRoms-x86/platform_frameworks_base/commit/e041af8f56610c93a70001a9c1fafb9d79444686

This is for s-x86

https://review.blissroms.org/q/topic:fakewifi-s

Here is an example of how to use it

https://docs.waydro.id/usage/waydroid-prop-options#modify-app-behaviour

Vào lúc 14:38:17 UTC+7 ngày Thứ Hai, 30 tháng 1, 2023, michael....@gmail.com đã viết:

[David White]

Thanks Michael. I am a bit new to all of this. Where do I go to set VIRT_WIFI=0? That just seems more clean than what I am doing now. Cheers

[David White]

Thanks for the pointer to WayDroid. Never heard of it before. Very interesting...

[Michael Goffioul]

Right at the boot menu. Instead of letting the timeout expires, edit the boot command (typically, press 'e' key) and look for the line starting with 'linux'. You can also make the change permanent, that requires to find and edit the grub2 config file.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/e33fdf1b-3719-4a3e-95f9-43cfa1fbf6c1n%40googlegroups.com.

[David White]

Thanks Michael. I much prefer using the kernel switch and learned something in the process. I found this link useful in dealing with grub...

You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/bZny_EOSqqU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAB-99LuXa2Pm86oR95-pxSbhhsL8h-0Q6biXn9XvRvP8RnHZFw%40mail.gmail.com.