Thomas Weber wrote: > Hmm nobody cares? > > now I can trigger this bug with one interface only. > > on the host - no vserver running > > # ip addr ls br1 > 4: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN > link/ether 00:25:90:32:bb:9b brd ff:ff:ff:ff:ff:ff > inet 192.168.1.54/24 brd 192.168.1.255 scope global br1 > > # cat interfaces/02/* > 192.168.105.255 > br1 > 192.168.105.20 > 24 > > # cat interfaces/03/* > 192.168.1.255 > br1 > 192.168.1.68 > 24 > > with vserver running: > # ip addr ls br1 > 4: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN > link/ether 00:25:90:32:bb:9b brd ff:ff:ff:ff:ff:ff > inet 192.168.1.54/24 brd 192.168.1.255 scope global br1 > inet 192.168.105.20/24 brd 192.168.105.255 scope global br1 > inet 192.168.1.68/24 brd 192.168.1.255 scope global secondary br1 > > The guest uses 192.168.105.20 as source for outgoing traffic to > 192.168.1.0/24. > > Now, if i reorder the interfaces like > mv interfaces/03 interfaces/01 > so that the 192.168.1.68/24 interface comes first, it uses the right IP > for outgoing traffic. Also for the 192.168.105.0/24 network it uses > the .105.20 address. > > Note though that this is the only (and not a secondary) address for the > 192.168.105.0/24 Network on the system! > > I also did some testing without the bridge on eth1 directly with the > same results - so I wouldn't blame the bridge. > > This works at least until 2.6.37.6-vs2.3.0.37-rc5, > 2.6.38.5-vs2.3.0.37-rc15 is the first 2.6.38 kernel that fails for me > (2.6.38-rc5-vs2.3.0.37-rc4 would not boot for me). > > upgrading util-vserver to 0.30.216-pre2967 did not help. echo 255 > /proc/sys/vserver/debug_net and rerun your tests, and paste the kernel output. > <snip> -- Daniel Hokka Zakrisson