On 05/12/2011 08:20 AM, Vincent Palatin wrote: > Hi, > > On Wed, May 11, 2011 at 22:39, Rob Landley <r...@landley.net> wrote: >> In 1.14.0, if I did this: >> >> qemu -net nic,blah -net user -net nic,blah -net tun,blah >> >> Then the first nic would be -net user, and the second nic would be -net >> tun. In current -git, -net user attaches to the second interface and >> -net tun attaches to the first, I.E. the order is reversed. >> >> Either way the first -nic becomes eth0 in Linux and the second becomes >> eth1 (I can manually assign mac addresses in order to confirm which is >> which), but eth0 used to be the -net user interface and now eth1 is the >> -net user interface. >> >> I bisected this to commit 60c07d933c66c4b30a83b but I don't know why it >> changed the behavior, and I can't find _documentation_ on having >> multiple interfaces transports hooked up to the same qemu instance >> anyway. (It used to work, but possibly that was an accident?) >> >> Any ideas? > > First of all, as you have 2 totally separated subnets in your setup, I > think your command-line should use "vlan=" parameter to isolate them, > else you will end up with some random routing/broadcasting (and random > tends to change over time).
Does the kernel need some sort of vlan support compiled into it for this to work, or can the kernel not care? > I'm not using setup with multiple NICs but I would have written something > like : > qemu -net nic,vlan=1,blah -net user,vlan=1 -net nic,vlan=2,blah -net > tun,vlan=2,blah > > In addition to this, which type of NIC are you using ? The actual command line is various permutations of: ~/qemu/qemu/x86_64-softmmu/qemu-system-x86_64 -m 512 -kernel ~/linux/linux/arch/x86/boot/bzImage -no-reboot -hda squeeze.ext3 -append "root=/dev/hda rw" -net nic,model=e1000,macaddr=52:54:00:11:11:11 -net user -redir tcp:9876::22 -net nic,model=e1000,macaddr=52:54:00:22:22:22 -net tap,ifname=kvm0,script=no,downscript=no With the parameters reordered to try to beat some controllable behavior out of it. (It had a deterministic behavior before the above commit, going back at least 2 years. The behavior was changed by the commit.) > In my understanding, the Linux kernel might assign interface number > depending on the order the interfaces are appearing. It's going in PCI bus order. And the _interfaces_ are still happily in PCI bus order both before and after this commit. What's changing is the association between interface and -net user or -net tap. The first one, with macaddr 11:11:11, is always eth0. But before the patch, eth0 is -net user, and after the patch eth0 is -net tap. > Without my change, when a packet arrives and should be distributed to > multiple interfaces (that seems to be the case in your setup even > though it is not intended) That that I know of. DHCP was doing broadcast out of eth0, but ignoring eth1. (It's still attempting to do that, it's just not getting a response unless I hook the tun/tap plumbing up to a dhcp server on the host.) > if one of the interface is not ready, the > packet is only forwarded to the ready interface (and the other never > receives it). This produces interesting timing effects where packets > are routed according to obscure race conditions, but in your former > setup, that might cause the packet to be routed to the interface you > want. That does not seem to match what I'm seeing. Rob
