Easiest tunnelling of multicast.

koala

Ars Tribunus Angusticlavius
7,579
I'm dealing with a robotics network protocol that uses multicast to establish p2p connections. I would like to connect the Android emulator to this network protocol.

The Android network emulator runs with qemu and, by default, uses user mode networking to connect with the outside world. I can forward ports from the host to the emulator, but that of course does not allow me to forward stuff sothat the Android emulator participates in the p2p multicast negotiation.

Currently, we have a complex setup where we use bridges and tap devices.

But I'm thinking I have ip in the emulated device, so I can do ip link add name foo type dummy and that sort of stuff. Would there be a simple way of relaying traffic from my host network into eth0 of the emulated device? Basically I think I want tunneling + bridging?
 

koala

Ars Tribunus Angusticlavius
7,579
Resurrecting my own thread...

OK, so I got it working with the previous approach; use -netdev socket on my laptop to add a virtual network to both the Android emulator and to a new VM on my machine. That works; both the emulator and the VM seem to be on the same network, and this robotics network protocol works fine.

However, we would like this to work using Docker networking, which is a bit more convenient to set up. Basically, Docker by default creates an docker0 bridge, and every Docker container gets a network interface on that bridge. Docker hands out IP addresses and things are good.

So instead of creating a new VM for the robotics thing, I'd like to start a Docker container on that network, and then connect the Android emulator to the Docker network. I've managed to do this by creating a tap0 device, attaching it to the Docker bridge, starting the Android emulator with tap0 as a second network device, then configure the interface inside Android. I've managed to make the robotics protocol work once, but this is quite janky- I need to assign IP addresses manually, for some reason it dies at some point...

I'm thinking there must be a nicer way to connect a Docker network and a qemu emulator...

(Just writing things down- partly to give closure to my initial thread, partly to sort my thoughts...)
 

Paladin

Ars Legatus Legionis
32,552
Subscriptor
I think when it comes to that kind of situation (it works but dies after a while), you're looking at a software issue that is probably caused by a bug or simply it wasn't designed to do that so it doesn't stay functioning after some kind of timer that dies because it can't tell it is in use or something. With linux and open source stuff like that, you can usually get help from the developers if you find the right way to ask and provide a lot of information about the problem. I'm guessing that the manual IP configuration issue is because the DHCP system for the network doesn't like your MAC address or other client identifier (there are probably debug options to get logs that will reveal that issue) but the part where it stops working after a while will be much harder to track down without a developer involved who can get deeper into the debug and see why it stops. Or you can just have it 'down and up' the interface on a cron schedule or something.

I have found all kinds of weird corner cases in different software tools like that over the years, like how PXE boot software often has an extremely braindead network implementation. It is literally built to the absolute minimum so things like ICMP and proper ARP support are either missing or half-crippled, etc.
 

koala

Ars Tribunus Angusticlavius
7,579
Ah, I think I can get sorted out, don't worry. We've seen many times that if you configure manually a network interface "raw" (e.g. using iproute2), Android can reset the interface. I'm likely doing something wrong.

What bothers me is that getting the Android emulator to play ball with any kind of networking which is not pure TCP/UDP sockets is a bit of a pain. In general, virtual networking tends to be a pain :D I think there should be a magical solution to connect virtual devices from different systems (in this case, Docker and Qemu) which was simple...
 
  • Like
Reactions: continuum