From mskrbic at etf.unsa.ba Fri Sep 14 02:34:40 2012 From: mskrbic at etf.unsa.ba (Mirko Skrbic) Date: Fri, 14 Sep 2012 08:34:40 +0200 (CEST) Subject: [Click] Posting Message-ID: <1603625035.7086.1347604480773.JavaMail.root@igman> Regards, -- Professor Mirko Skrbic, PhD. University of Sarajevo, Faculty of Electrical Engineering 71000 Sarajevo, Zmaja od Bosne bb, Phone: +38733250700 From shoban.preeth at gmail.com Tue Sep 18 02:44:23 2012 From: shoban.preeth at gmail.com (Shoban) Date: Tue, 18 Sep 2012 12:14:23 +0530 Subject: [Click] kernel panic on using FromHost Message-ID: Hi, I am trying to run click in kernel mode in Xen paravirtualized VM. When using a simple click config[2] using FromHost, there is a kernel panic[1]. The config loads fine the first time, but on click-uninstall and click-install it fails. This happens in both click-2.0.1 and latest click github clone. I am using linux 2.6.38.12 in patchless mode. Any help would be much appreciated. Thanks, Shoban -- [1] Kernel panic log (full log at https://gist.github.com/3741589) [ 136.891896] click module exiting [ 142.849335] BUG: unable to handle kernel NULL pointer dereference at (null) [ 142.849350] IP: [<(null)>] (null) [ 142.849356] PGD 0 [ 142.849361] Oops: 0010 [#1] SMP [ 142.849367] last sysfs file: /sys/devices/virtual/net/fake0/uevent [ 142.849374] CPU 0 [ 142.849377] Modules linked in: click proclikefs nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc lp parport [last unloaded: click] ... [ 142.849537] Call Trace: [ 142.849541] [ 142.849551] [] ? netif_receive_skb+0x1ee/0x640 [ 142.849560] [] ? pvclock_clocksource_read+0x4e/0x100 [ 142.849569] [] xennet_poll+0x5ec/0xdd0 [ 142.849576] [] net_rx_action+0x122/0x240 [ 142.849585] [] __do_softirq+0xb7/0x1c0 [ 142.849593] [] call_softirq+0x1c/0x30 [ 142.849599] [] do_softirq+0x65/0xa0 [ 142.849606] [] irq_exit+0x85/0x90 [ 142.849614] [] xen_evtchn_do_upcall+0x12a/0x200 [ 142.849622] [] xen_do_hypervisor_callback+0x1e/0x30 [ 142.849627] [ 142.849635] [] ? copy_page_range+0x606/0x8e0 [ 142.849642] [] ? dup_mm+0x32e/0x610 [ 142.849649] [] ? copy_process+0x11f0/0x1320 [ 142.849659] [] ? do_filp_open+0x18b/0x660 [ 142.849666] [] ? do_fork+0xf4/0x410 [ 142.849675] [] ? _raw_spin_lock_irq+0x15/0x20 [ 142.849683] [] ? recalc_sigpending+0x1b/0x50 [ 142.849690] [] ? sigprocmask+0x92/0x110 [ 142.849698] [] ? sys_clone+0x28/0x30 [ 142.849706] [] ? stub_clone+0x13/0x20 [ 142.849713] [] ? system_call_fastpath+0x16/0x1b ... [ 142.849760] Call Trace: [ 142.849763] [] panic+0x7d/0xff [ 142.849774] [] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 142.849782] [] oops_end+0xea/0xf0 [ 142.849788] [] no_context+0x209/0x218 [ 142.849795] [] __bad_area_nosemaphore+0x185/0x1a8 [ 142.849802] [] bad_area_nosemaphore+0x13/0x15 [ 142.849809] [] do_page_fault+0x2ca/0x390 [ 142.849816] [] page_fault+0x25/0x30 [ 142.849822] [] ? netif_receive_skb+0x1ee/0x640 [ 142.849829] [] ? pvclock_clocksource_read+0x4e/0x100 [ 142.849836] [] xennet_poll+0x5ec/0xdd0 [ 142.849843] [] net_rx_action+0x122/0x240 [ 142.849850] [] __do_softirq+0xb7/0x1c0 [ 142.849856] [] call_softirq+0x1c/0x30 [ 142.849862] [] do_softirq+0x65/0xa0 [ 142.849869] [] irq_exit+0x85/0x90 [ 142.849875] [] xen_evtchn_do_upcall+0x12a/0x200 [ 142.849882] [] xen_do_hypervisor_callback+0x1e/0x30 [ 142.849887] [] ? copy_page_range+0x606/0x8e0 [ 142.849898] [] ? dup_mm+0x32e/0x610 [ 142.849904] [] ? copy_process+0x11f0/0x1320 [ 142.849911] [] ? do_filp_open+0x18b/0x660 [ 142.849918] [] ? do_fork+0xf4/0x410 [ 142.849924] [] ? _raw_spin_lock_irq+0x15/0x20 [ 142.849930] [] ? recalc_sigpending+0x1b/0x50 [ 142.849937] [] ? sigprocmask+0x92/0x110 [ 142.849943] [] ? sys_clone+0x28/0x30 [ 142.849950] [] ? stub_clone+0x13/0x20 [ 142.849956] [] ? system_call_fastpath+0x16/0x1b [2] Click config: define($PHY eth0, $TUN fake0); define($PHYIP 135.254.219.12, $PHYMAC 00:16:3f:1f:7a:01); define($TUNIP 11.4.1.1, $TUNMAC ae:72:26:91:bc:3f); AddressInfo(this-public $PHYIP $PHYMAC); AddressInfo(this $TUNIP/8 $TUNMAC); fd :: FromDevice($PHY) the :: ToHost($PHY) fh :: FromHost($TUN, this:ipnet, ETHER this:eth, MTU 1350); fd -> the; fh -> Discard; From shoban.preeth at gmail.com Thu Sep 20 07:16:18 2012 From: shoban.preeth at gmail.com (Shoban) Date: Thu, 20 Sep 2012 16:46:18 +0530 Subject: [Click] Compile error due to ac_cv_linuxmodule_click_skb_recycle Message-ID: Configure test for ac_cv_linuxmodule_click_skb_recycle passes, even if skb_recycle() is not declared, with just warnings. Excerpt from config.log (https://gist.github.com/3755265) conftest.c:141:15: warning: implicit declaration of function 'skb_recycle' [-Wimplicit-function-declaration] conftest.c:141:29: warning: assignment makes pointer from integer without a cast [enabled by default] This in turn, causes a compile error for "linuxmodule/skbmgr.cc". /root/click/linuxmodule/skbmgr.cc: In member function ?void RecycledSkbPool::recycle(sk_buff*)?: /root/click/linuxmodule/skbmgr.cc:300:28: error: ?skb_recycle? was not declared in this scope I am trying build click for linux-2.6.34.12 in patchless mode. Perhaps adding '-Werror-implicit-function-declaration' option for this particular configure test would solve the problem. diff --git a/configure.in b/configure.in index 1618227..ecf319b 100644 --- a/configure.in +++ b/configure.in @@ -1452,6 +1452,9 @@ void f1(int64_t) { // will fail if long long and int64_t are the same type AC_DEFINE([HAVE_SKB_RECYCLE], [1], [Define if you have the skb_recycle function.]) fi +save_cflags="$CFLAGS" +CFLAGS="$save_cflags -Werror-implicit-function-declaration" + AC_CACHE_CHECK([whether skb_recycle returns an sk_buff], [ac_cv_linuxmodule_click_skb_recycle], [AC_LANG_C AC_COMPILE_IFELSE([AC_LANG_PROGRAM([CLICK_LINUXMODULE_PROLOGUE()[ @@ -1462,6 +1465,8 @@ void f1(int64_t) { // will fail if long long and int64_t are the same type AC_DEFINE([HAVE_CLICK_SKB_RECYCLE], [1], [Define if your Linux kernel has Click skb_recycle.]) fi +CFLAGS="$save_cflags" + AC_CHECK_DECL(skb_linearize, [ac_cv_skb_linearize=yes], [ac_cv_skb_linearize=no], [CLICK_LINUXMODULE_PROLOGUE()[ #include ]]) if test $ac_cv_skb_linearize = yes; then Thanks, Shoban From jbrown at atl.lmco.com Fri Sep 21 15:22:34 2012 From: jbrown at atl.lmco.com (Jesse Brown) Date: Fri, 21 Sep 2012 15:22:34 -0400 Subject: [Click] Generating packets in ns-3-click Message-ID: <505CBE7A.10204@atl.lmco.com> All: Note: I've also posted this to the ns-3-users list but I've got no response so far. I am running ns-3 with click integration and I'd like to generate packets from within the click graph instead of from within ns-3 components. I'm having trouble, however, getting the packets to inject properly into the simulation. Here is my approach: From within a click element I create a new packet with Packet::make. Source IP is assigned the node that is creating the packet and destination is the broadcast address 10.1.255.255. If I place a Print element in line after this in the router I see the following: ...: 36 | 45000024 00000000 40110000 0a010101 0a01ffff 02ba02ba 00100000 31302e31 2e312e31 which looks reasonable. I also have UDP traffic being generated from an ns3::UdpSocketFactory. That traffic looks like ...: 540 | 4500021c 02610000 40110000 0a010101 0a010102 c001c350 02080000 00000000 00000000 So the format looks reasonable but the click packet hits the wire as some LLC protocol (presumably from lack of proper header application) while the ns-3 packet goes out as a proper UDP packet. Every packet follows the same path out of the router. I tried to modify simclick_simpacketinfo within the packet to properly represent the simulation id but with no luck. Is there some process by which packets generated within click can be incorporated into a running simulation? Thank you, Jesse From jdsimosa at MIT.EDU Mon Sep 24 23:59:09 2012 From: jdsimosa at MIT.EDU (Jorge Simosa) Date: Mon, 24 Sep 2012 23:59:09 -0400 Subject: [Click] Windows 7 compilation issue Message-ID: <50612C0D.8030307@mit.edu> Hi, I am having trouble compiling the Click package on my laptop. I'm running Cygwin on a Windows 7 (64-bit) platform, with (from what I believe) all of the pre-requisite libraries. After running './configure' and 'make', I am receiving this error during 'make': In file included from ../elements/userlevel/fromdevice.cc:35:0: ../elements/userlevel/fromdevice.hh: In member function 'int FromDevice::fd() const': ../elements/userlevel/fromdevice.hh:178:37: error: '_fd' was not declared in this scope elements.mk:381: recipe for target `fromdevice.o' failed make[1]: *** [fromdevice.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/cygdrive/c/libs/click/userlevel' Makefile:55: recipe for target `userlevel' failed make: *** [userlevel] Error 2 I would appreciate any help you can provide in resolving this issue. Thanks! Best regards, Jorge Simosa MIT M.Eng '13 MIT B.S. '12 Electrical Engineering & Computer Science jdsimosa at mit.edu From suresh.lalith at gmail.com Wed Sep 26 10:20:21 2012 From: suresh.lalith at gmail.com (Lalith Suresh) Date: Wed, 26 Sep 2012 19:50:21 +0530 Subject: [Click] Generating packets in ns-3-click In-Reply-To: <505CBE7A.10204@atl.lmco.com> References: <505CBE7A.10204@atl.lmco.com> Message-ID: Hi, On Sat, Sep 22, 2012 at 12:52 AM, Jesse Brown wrote: > All: > > Note: I've also posted this to the ns-3-users list but I've got no > response so far. > > > I am running ns-3 with click integration and I'd like to generate > packets from within the click graph instead of from within ns-3 > components. I'm having trouble, however, getting the packets to inject > properly into the simulation. Here is my approach: > > From within a click element I create a new packet with Packet::make. > Source IP is assigned the node that is creating the packet and > destination is the broadcast address 10.1.255.255. If I place a Print > element in line after this in the router I see the following: > > ...: 36 | 45000024 00000000 40110000 0a010101 0a01ffff 02ba02ba > 00100000 31302e31 2e312e31 > > which looks reasonable. I also have UDP traffic being generated from an > ns3::UdpSocketFactory. That traffic looks like > > ...: 540 | 4500021c 02610000 40110000 0a010101 0a010102 c001c350 > 02080000 00000000 00000000 > > So the format looks reasonable but the click packet hits the wire as > some LLC protocol (presumably from lack of proper header application) > while the ns-3 packet goes out as a proper UDP packet. Every packet > follows the same path out of the router. > > I tried to modify simclick_simpacketinfo within the packet to properly > represent the simulation id but with no luck. > > Is there some process by which packets generated within click can be > incorporated into a running simulation? > This is supposed to work out of the box. Can you please send me the simulation scripts and click files that you're using along with the ns-3 and click revision numbers? P.S: I'm travelling now and will be slow to respond > > Thank you, > > > Jesse > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click -- Lalith Suresh www.lalith.in From jbrown at atl.lmco.com Wed Sep 26 14:41:15 2012 From: jbrown at atl.lmco.com (Jesse Brown) Date: Wed, 26 Sep 2012 14:41:15 -0400 Subject: [Click] Generating packets in ns-3-click In-Reply-To: References: <505CBE7A.10204@atl.lmco.com> Message-ID: <50634C4B.6010101@atl.lmco.com> Lalith Suresh: It turns out the error stemmed from my own ignorance. I was sending out broadcast packets and was failing to apply my own Ethernet header. The ns-3 generated packet was properly handled by ArpQuerier but I was printing the packet contents before that point in the click graph leading to my confusion. By adding a proper Ethernet header I am able to properly pass packets from click to ns-3 without issue. Sorry for the trouble. Thank you, Jesse Lalith Suresh wrote: > Hi, > > On Sat, Sep 22, 2012 at 12:52 AM, Jesse Brown wrote: > >> All: >> >> Note: I've also posted this to the ns-3-users list but I've got no >> response so far. >> >> >> I am running ns-3 with click integration and I'd like to generate >> packets from within the click graph instead of from within ns-3 >> components. I'm having trouble, however, getting the packets to inject >> properly into the simulation. Here is my approach: >> >> From within a click element I create a new packet with Packet::make. >> Source IP is assigned the node that is creating the packet and >> destination is the broadcast address 10.1.255.255. If I place a Print >> element in line after this in the router I see the following: >> >> ...: 36 | 45000024 00000000 40110000 0a010101 0a01ffff 02ba02ba >> 00100000 31302e31 2e312e31 >> >> which looks reasonable. I also have UDP traffic being generated from an >> ns3::UdpSocketFactory. That traffic looks like >> >> ...: 540 | 4500021c 02610000 40110000 0a010101 0a010102 c001c350 >> 02080000 00000000 00000000 >> >> So the format looks reasonable but the click packet hits the wire as >> some LLC protocol (presumably from lack of proper header application) >> while the ns-3 packet goes out as a proper UDP packet. Every packet >> follows the same path out of the router. >> >> I tried to modify simclick_simpacketinfo within the packet to properly >> represent the simulation id but with no luck. >> >> Is there some process by which packets generated within click can be >> incorporated into a running simulation? >> >> > > This is supposed to work out of the box. Can you please send me the > simulation scripts and click files that you're using along with the > ns-3 and click revision numbers? > > P.S: I'm travelling now and will be slow to respond > > >> Thank you, >> >> >> Jesse >> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > > > > From antoniehenning at yahoo.com Thu Sep 27 17:58:40 2012 From: antoniehenning at yahoo.com (Antonie Henning) Date: Thu, 27 Sep 2012 14:58:40 -0700 (PDT) Subject: [Click] ToDevice(ppp0) Message-ID: <1348783120.38385.YahooMailNeo@web125303.mail.ne1.yahoo.com> Hi, Has anyone ever been successful in sending packets out a ppp interface with userlevel ToDevice?? ToDevice(ppp0,METHOD LINUX) attempts to send the packets but they are dropped by the kernel. METHOD PCAP fails with "Invalid Argument". The PPPencap element appears not to address the CRC16 and Flags to complete the PPP encapsulation. I've created elements to add these but the drops persist. Any advise will be appreciated. A