Hello Patrick Personally I would prefer a slightly different implementation. I consider the 192.168.7.2 network interface as development, debugging and testing interface which should just work. This interface has to be ignored by NetworkManager / connman and so on otherwise things like NFS rootfs or image tests break. But I agree that the current poky implementation does not fit well for people who develop other connectivity solutions e.g. a network interfaces configured by DHCP. Things can become quite difficult if eth0 is used as 192.168.7.2 development interface in qemu but gets a DHCP based IP configuration on the productive image. To address this I started to run qemu with more than one emulated network interface. (Some time ago I posted a patch which fixes two blockers to start qemu with more than one emulated NIC: YOCTO #6356.[1]) Note: On the target device there are some simple udev rules which assign reasonable names to the different network interfaces. This simplifies many use cases a lot. The applied network configuration just depends on the available interfaces which is what connman and latest NetworkManager support perfectly. The 192.168.7.2 interface configuration assigned by the kernel gets never touched. On the development host I use a project specific implementation for the runqemu-gen-tapdevs script. It does not only create the tap devices as the original does. It creates different virtual networks which are connected to the additional interfaces emulated by qemu. On one of these networks there is a dhcp server running. The dhcp server is managed by the runqemu-gen-tapdevs script. On the long term we could have different implementations of the runqemu-gen-tapdevs script. For example one which creates two tap devices per qemu instance. One tap device is used for the 192.168.7.x network and the other tap device is part of a bridge where a dhcp server runs on and IP forwarding allows to connect to the Internet. With current poky implementation this is not really possible. Virtual devices are always connected to the Internet. The default route is set to 192.168.7.1 and IP forwarding on the host is configured for emulated interfaces automagically. I assume this is what most people need and it should remain the default behavior of course. But it would be nice to have an option to start qemu with host connectivity only. Meaning IP forwarding is not started for 192.168.7.x networks and the default route is not assigned via kernel boot parameter. By the way, where does your solution make use of the DHCP server? The eth0 IP configuration is assigned by kernel boot parameters in runqemu-internal. If this configuration gets changed later on the NFS rootfs will break...
Sorry for the long mail. Here is a summary of my proposal: - Add patch _YOCTO #6356._ - Change runqemu scripts to provide a host-only connectivity option (Basically just skip some lines of code in runqemu-ifup) - Provide a runqemu-gen-tapdevs variant which creates two tap devs per quemu instance (connect all qemu instances via bridge?) - Start the DHCP server by runqemu-gen-tapdevs (on tap devs or on a bridge) - If bridged: Enable IP forwarding for the bridge - run qemu like: runqemu ... qemuparams="-net nic,model=virtio... -net tap, ..." to emulate two NICs I would like to publish the generic parts of my solution when ready. Regards, Adrian On Tuesday 04 November 2014 09.09:07 Patrick Ohly wrote: > Hello! > > Recently I built a custom image which depended on a DHCP server to > configure Ethernet. runqemu with tap for networking doesn't provide one > at the moment, so ssh logins did not work. > > Instead of customizing images for runqemu, I think it would be better to > adapt runqemu and uses images as on the target device. Attached two > patches which work for me. Is that of interest for inclusion upstream? > > I suppose more work is needed, in particular around how to enable or > disable this feature. Patching the .bb files also leads to a (to me) > strange QA error. See the comments in the patches for details. > > -------------------- Adrian Freihofer Gschwaderweg 29 8610 Uster 043 497 84 01 -------- [1] http://patchwork.openembedded.org/patch/74397/
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
