On 14 December 2015 at 20:34, Allan Lue <[email protected]> wrote: > Hi, > > I have been trying to debug OVS kernel module with printk and stack_dump(). > Although Wireshark detects the tap > interface (vnet0) receives ICMP packets I was never able to use printk or > dump_stack() to trace the execution > path. Ultimately I would like to track rx packets through all involved > kernel and user functions, same for tx packets. > > > It’s a Unubtu 14.04 system with OVS 2.4.0 > > allan@allan-i7A:~/openvswitch-2.4.0$ uname -a > Linux allan-i7A 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 > 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > allan@allan-i7A:~/openvswitch-2.4.0$ > > I put printk() and dump_stack() in the following functions: > > netdev_frame_hook() vport-netdev.c > netdev_port_receive() vport-netdev.c > ovs_vport_receive() vport.c > ovs_vport_send() vport.c > ovs_dp_process_packet datapath.c > > the setup is very simple: > A VirtualBox VM pings an OVS bridge (br100) device via vnet0, > > Bridge "br100" > Port "vnet0" > Interface "vnet0" > Port "br100" > Interface "br100" > type: internal > > vnet0 is added like this: > $ sudo ovs-vsctl add-br br100 > $ sudo ip tuntap add mode tap vnet0 > $ sudo ip link set vnet0 up > $ sudo ovs-vsctl add-port br100 vnet0 > > > Both "ovs-appctl dpctl/show –s" and “ifconfig” show br0 receives packets but > vnet0 doesn’t, the inconsistent part > is Wireshark show vnet0 receives packets. > > sudo ovs-appctl dpctl/show -s > port 20: vnet0 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:5880 aborted:0 carrier:0 > collisions:0 > RX bytes:0 TX bytes:0 > port 21: br100 (internal) > RX packets:143 errors:0 dropped:0 overruns:0 frame:0 > TX packets:683 errors:0 dropped:29 aborted:0 carrier:0 > collisions:0 > RX bytes:16618 (16.2 KiB) TX bytes:121064 (118.2 KiB) > > allan@allan-i7A:~/openvswitch-2.4.0$ ifconfig > br100 Link encap:Ethernet HWaddr 26:1a:55:0f:b6:47 > inet addr:172.16.1.1 Bcast:172.16.1.255 Mask:255.255.255.0 > inet6 addr: fe80::241a:55ff:fe0f:b647/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:561 errors:0 dropped:29 overruns:0 frame:0 > TX packets:118 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:100861 (100.8 KB) TX bytes:14280 (14.2 KB) > > vnet0 Link encap:Ethernet HWaddr 16:59:1e:05:f8:e4 > inet6 addr: fe80::1459:1eff:fe05:f8e4/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:5758 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > dmesg shows the VM is attached to vnet0 as expected, > > allan@allan-i7A:~/openvswitch-2.4.0$ dmesg > [22035.615107] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), > (N/A, 4000 mBm), (N/A) > [23407.097108] vboxdrv: ffffffffc011b020 VMMR0.r0 > [23407.195612] vboxdrv: ffffffffc0214020 VBoxDDR0.r0 > [23407.196406] vboxdrv: ffffffffc0232020 VBoxDD2R0.r0 > [23407.208611] VBoxNetFlt: attached to 'vnet0' / 16:59:1e:05:f8:e4 > allan@allan-i7A:~/openvswitch-2.4.0$ > > > The questions are: > > Am I looking at the right codes for OVS receiving data path? > Any issues with using printk() and dumo_stack() this way? Or what should I > do? > Any instructions to ensure or check packets from VM are processed by the > kernel module will be appreciated
Are you sure that you have compiled and loaded the module that you changed, rather than simply modprobing the version that was already present in your distribution? Using "insmod <path/to/openvswitch.ko>" is a good way to guarantee this. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
