Unable to pass traffic between namespaces with VALE bridge

[GoogleCodeExporter]

What steps will reproduce the problem?
1. From a freshly booted VM, I run the following setup script: 
cd netmap/LINUX
sudo rmmod veth
sudo insmod netmap.ko
sudo insmod veth.ko
cd build-apps
sudo ./vale-ctl -n bluintf
sudo ./vale-ctl -n redintf
sudo ./vale-ctl -a vale0:bluintf
sudo ./vale-ctl -a vale0:redintf
#
sudo ip netns add blue
sudo ip netns add red
sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth1 netns blue
sudo ip link add veth2 type veth peer name veth3
sudo ip link set veth3 netns red
#
sudo ip netns exec blue ifconfig veth1 16.16.16.1 netmask 255.255.255.0 up
sudo ip netns exec red  ifconfig veth3 16.16.16.2 netmask 255.255.255.0 up
#
echo 'Done.'

2. Have tried two different paths. The first is to run the 'bridge' task, 
bridging veth0 to vale0:bluintf. I get:
Ubuntu:~/netmap/LINUX/build-apps$ sudo ./bridge -i veth0 -i vale0:bluintf
./bridge built Jun 24 2015 22:17:10
969.158942 main [233] cannot open veth0

The other approach is to attach the veth interfaces directly to the vale 
bridge: 

Ubuntu:~/netmap/LINUX/build-apps$ sudo ./vale-ctl -a vale0:veth0
Ubuntu:~/netmap/LINUX/build-apps$ sudo ./vale-ctl -a vale0:veth2
Ubuntu:~/netmap/LINUX/build-apps$ sudo ip link set veth0 up
Ubuntu:~/netmap/LINUX/build-apps$ sudo ip link set veth2 up
Ubuntu:~/netmap/LINUX/build-apps$ sudo ./vale-ctl
bdg_ctl [149] bridge:0 port:0 vale0:bluintf
bdg_ctl [149] bridge:0 port:1 vale0:redintf
bdg_ctl [149] bridge:0 port:2 vale0:veth0
bdg_ctl [149] bridge:0 port:3 vale0:veth2

3. Then, run 'ping' from one network namespace to the other: 

Ubuntu:~/netmap/LINUX/build-apps$ sudo ip netns exec blue ping 16.16.16.2
PING 16.16.16.2 (16.16.16.2) 56(84) bytes of data.
^C
--- 16.16.16.2 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7054ms

Ubuntu:~/netmap/LINUX/build-apps$

What is the expected output? What do you see instead?
Expected output: 'ping' responses, as it works in the case where the Linux 
bridge (brctl) is employed. Instead, I see all packets dropped. 

What version of the product are you using? On what operating system?
Version of Netmap: Compiled from latest 'next' branch.
OS: 
Ubuntu:~/netmap/LINUX$ uname -a
Linux Ubuntu 3.13.0-51-generic #84-Ubuntu SMP Wed Apr 15 12:08:34 UTC 2015 
x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.

Original issue reported on code.google.com by ratliffs...@gmail.com on 25 Jun 2015 at 2:20

[GoogleCodeExporter]

FWIW, here is the output of "dmesg" after an attempt with the veth interfaces 
attached to the VALE bridge: 
[  139.570052] netmap: module verification failed: signature and/or  required 
key missing - tainting kernel
[  139.572200] 020.881465 [3080] netmap_init               run mknod 
/dev/netmap c 10 56 # error 0
[  139.572240] netmap: loaded module
[  139.602260] 020.911509 [2717] netmap_attach             success for veth1 tx 
1/1024 rx 1/1024 queues/slots
[  139.602575] 020.911825 [2717] netmap_attach             success for veth0 tx 
1/1024 rx 1/1024 queues/slots
[  139.643816] 020.953046 [2717] netmap_attach             success for veth3 tx 
1/1024 rx 1/1024 queues/slots
[  139.644050] 020.953281 [2717] netmap_attach             success for veth2 tx 
1/1024 rx 1/1024 queues/slots
[  139.695622] IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
[  139.739836] IPv6: ADDRCONF(NETDEV_UP): veth3: link is not ready
[  139.765478] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[  139.771594] IPv6: ADDRCONF(NETDEV_CHANGE): veth3: link becomes ready
[  139.798198] 021.107353 [1712] netmap_interp_ringid      deprecated API, old 
ringid 0x0 -> ringid 0 reg 1
[  139.812745] 021.121895 [ 646] netmap_get_bdg_na         checking vale0:veth0
[  139.812757] 021.121908 [1712] netmap_interp_ringid      deprecated API, old 
ringid 0x0 -> ringid 0 reg 1

Original comment by ratliffs...@gmail.com on 25 Jun 2015 at 7:27

[GoogleCodeExporter]

I confirm the above errors in my Linux kernel 3.13 built and installed from 
sources.
Moreover, when blue pings red namespace, veth0 gets the packets (I can sniff 
with tcpdump) but VALE never forwards them to veth2 (and red respectively).

When I run the same example with the native veth driver, everything works like 
a charm.

Thanks for any clarifications!

Original comment by george....@gmail.com on 12 Jul 2015 at 2:50