Joe,

You are right, the kernel module I compiled was never installed.

Although I did get it compiled successfully every time and went through make 
module_install.
Thanks a lot for you help, I have spent several days scratching my head and 
trying different things!


allan@allan-i7A:~/openvswitch-2.4.0$ sudo make modules_install
cd datapath/linux && make modules_install
make[1]: Entering directory `/home/allan/openvswitch-2.4.0/datapath/linux'
make -C /lib/modules/3.19.0-25-generic/build 
M=/home/allan/openvswitch-2.4.0/datapath/linux modules_install
make[2]: Entering directory `/usr/src/linux-headers-3.19.0-25-generic'
  INSTALL /home/allan/openvswitch-2.4.0/datapath/linux/openvswitch.ko
Can't read private key
  INSTALL /home/allan/openvswitch-2.4.0/datapath/linux/vport-geneve.ko
Can't read private key
  INSTALL /home/allan/openvswitch-2.4.0/datapath/linux/vport-gre.ko
Can't read private key
  INSTALL /home/allan/openvswitch-2.4.0/datapath/linux/vport-lisp.ko
Can't read private key
  INSTALL /home/allan/openvswitch-2.4.0/datapath/linux/vport-stt.ko
Can't read private key
  INSTALL /home/allan/openvswitch-2.4.0/datapath/linux/vport-vxlan.ko
Can't read private key
  DEPMOD  3.19.0-25-generic
make[2]: Leaving directory `/usr/src/linux-headers-3.19.0-25-generic'
depmod `sed -n 's/#define UTS_RELEASE "\([^"]*\)"/\1/p' 
/lib/modules/3.19.0-25-generic/build/include/generated/utsrelease.h`
make[1]: Leaving directory `/home/allan/openvswitch-2.4.0/datapath/linux'
allan@allan-i7A:~/openvswitch-2.4.0$ 


— Allan




On 12/15/15, 12:44 PM, "Joe Stringer" <[email protected]> wrote:

>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

Reply via email to