[Click] NSClick 2.34 problems with Click 1.7.0rc1 - Re: NSClick patch for NS-2.34

Tue Sep 8 12:42:03 EDT 2009

I'm very glad that someone went to the trouble to create Click patches
for ns-2.34; thank you. Sadly, I am getting errors when I try to run
the nsclick test scripts with ns-2.34 built against click 1.7.0rc1.

:~/ns-allinone-2.34/ns-2.34/tcl/ex$ ns nsclick-simple-wlan.tcl
num_nodes is set 4
INITIALIZE THE LIST xListHead
nsclick-simple-lan.click:36: ‘u/myarpquerier :: ARPQuerier’ input 1 unused
nsclick-simple-lan.click:37: ‘u/myarpresponder :: ARPResponder’ input 0 unused
nsclick-simple-lan.click:54: ‘u/Strip at 11 :: Strip’ input 0 unused
nsclick-simple-lan.click:62: ‘u/IPPrint at 15 :: IPPrint’ input 0 unused
nsclick-simple-lan.click:68: ‘u/Print at 18 :: Print’ input 0 unused
nsclick-simple-lan.click:43: ‘u/HostEtherFilter at 10 :: HostEtherFilter’
output 0 unused
nsclick-simple-lan.click:57: ‘u/GetIPAddress at 14 :: GetIPAddress’ output 0 unused
Router could not be initialized!
nsclick-simple-lan.click: errors prevent router from initializing

 It's as if the Classifiers in the script are vanishing.

 I configured Click so:
./configure --prefix=/usr/local/click1.7 --disable-linuxmodule
--disable-roofnet --enable-wifi --disable-multicast --enable-userlevel
--enable-nsclick

 I used the ns-allinone-2.34 distribution. After applying the ns-2.34
patches, which applied without error, I ran ./install from the
~/ns-allinone-2.34 directory.

 The validate procedure runs all tests correctly, but all the
nsclick*.tcl scripts fail to initialize with errors similar to the one
above.

 This is a 64-bit Ubuntu 8.04 system. The only non-vanilla thing about
Click is that the userlevel directory contains elements from the MORE
Network Coding project from MIT -
http://people.csail.mit.edu/szym/more/README.html .

 After the first test I made one change to the nsclick-raw-wlan.click
file; I inserted a Queue between the IPPrint and ToDump elements on
the ToSimDevice(tap0, IP) path, because when I ran the file through
Clicky it complained thus:
/home/jfm/ns-allinone-2.34/ns-2.34/tcl/ex/clicky-raw-wlan.click:79:
 'IPPrint at 25' push output 0 connected to 'ToDump at 26' pull input 0

 This change didn't make a difference. (the file clicky-raw-wlan.click
is nsclick-raw-wlan.click with ToSimDevice and FromSimDevice replaced
by ToDevice and FromDevice to make Clicky happy.)

 For completeness, here is my nsclick-raw-wlan.click:
<included file>
elementclass DumbRouter {
  $myaddr, $myaddr_ethernet |
  class :: Classifier(12/0806 20/0001,12/0806 20/0002, -);
  mypackets :: IPClassifier(dst host $myaddr,-);
  myarpquerier :: ARPQuerier($myaddr,$myaddr_ethernet);
  myarpresponder :: ARPResponder($myaddr $myaddr_ethernet);
  rinfo::AvailableRates(DEFAULT 2 4 11 22)
  rateselection::MadwifiRate(RT rinfo,ACTIVE true,OFFSET 4);
  wlinfo :: WirelessInfo(SSID raw, BSSID 01:01:01:01:01:01,CHANNEL 2, IFID 0);
  ethout :: Queue 	
	-> WifiEncap(0x0, WIRELESS_INFO wlinfo)	
	-> rateselection
	-> PrintWifi(eth0_out)
	-> ToDump(out_eth0,PER_NODE 1,ENCAP 802_11)
	-> ExtraEncap()
	-> ToSimDevice(eth0);

  FromSimDevice(eth0,4096)
	-> ExtraDecap()
	-> filtertx::FilterTX()
	-> ToDump(in_eth0,PER_NODE 1,ENCAP 802_11)
	-> WifiDecap()
	-> Print(eth0,64)	
	-> HostEtherFilter($myaddr_ethernet)
	-> class;

  // transmission is fed back to the rate selection module	
  filtertx[1]
	-> [1]rateselection;

  // ARP queries from other nodes go to the ARP responder module
  class[0] -> myarpresponder;

  // ARP responses go to our query module
  class[1] -> [1]myarpquerier;

  // All other packets get checked to see if they're meant for us
  class[2]				
	-> Strip(14)
	-> CheckIPHeader
	-> MarkIPHeader
	-> GetIPAddress(16)
	-> mypackets;

  // Packets for us go to "tap0" which sends them to the kernel
  mypackets[0]
	-> IPPrint(tokernel) -> Queue
	-> ToDump(tokernel,2000,IP,PER_NODE 1)
	-> ToSimDevice(tap0,IP);

  // Packets for other folks or broadcast packets get discarded
  mypackets[1]
	-> Print(discard,64)
	-> ToDump(discard,2000,PER_NODE 1)
	-> Discard;

  // Packets sent out by the "kernel" get pushed into the ARP query module
  FromSimDevice(tap0,4096)
	-> CheckIPHeader
	-> IPPrint(fromkernel)
	-> ToDump(fromkernel,2000,IP,PER_NODE 1)
	-> GetIPAddress(16)
	-> myarpquerier;

  // Both the ARP query and response modules send data out to
  // the simulated network device, eth0.
  myarpquerier
	-> Print(fromarpquery,64)
	-> ToDump(out_arpquery,PER_NODE 1)
	-> ethout;

  myarpresponder
	-> Print(arpresponse,64)
	-> ToDump(out_arprespond,PER_NODE 1)
	-> ethout;
}

u :: DumbRouter(eth0,eth0);
</included file>

 I think that's everything. I'm stuck and would be grateful for help.

Thanks,
John

On Thu, Sep 3, 2009 at 9:47 AM, Wim
Vandenberghe<wim.vandenberghe at intec.ugent.be> wrote:
> Hello,
>
> i have created an update of the NSClick patch for NS-2.34, since the last
> patch was developed for NS-2.30, which was released almost three years ago.
> I created the new patch by manually going through every change defined by
> the patch, and applied small adjustments, mostly just different context
> lines, whenever necessary. Further testing and validation of the patched
> NS-2.34 install also led to some minor changes to the patch, which can be
> found in attachment.
>
> It should be mentioned that I did not change all line number references,
> only the amount of lines before and after for each patch hunk. Therefore the
> output during patching mentions an offset for several parts of the patch.
> This is not a problem, normally the patch can be successfully deployed on a
> fresh ns-2.34 install. I tested with a clean NS-2.34 allinone installation
> and a checkout of the Click 1.6 release taken somewhere in February 2009
> (since we are using this checkout with some specific adjustments in our
> current research project). The patch can be applied without any problems,
> the patched NS compiles fine both with and without debug support, and when
> running ./validate in the ns directory, it concludes that all tests passed.
> When running the nsclick-simple-wlan.tcl script, the output also seems
> normal.
>
> However, i think that the Click functionality should be tested more
> thoroughly before the patch can be seen as final. Therefore i would like to
> ask if some members of the Click community would like to run some more
> advanced NSClick scenarios that they are familiar with, and compare the
> results for using the old patch with NS-2.30, and the new one with NS-2.34,
> to see if everything is working as expected (especially combined with Click
> 1.7 instead of 1.6).
>
> Another interesting topic is the fact that the NS-2.34 contains a profound
> revision of the 802.11 MAC implementation, the 802_11ext implementation (see
> http://dsn.tm.uni-karlsruhe.de/english/Overhaul_NS-2.php). It would be very
> interesting if this MAC implementation would also support the integration
> with Click. I am planning to have a look at this, but will not have the time
> for this in the near future. Maybe someone else from the community would be
> interested to have a look at it in the meanwhile?
>
> Kind regards,
>
> Wim
>
> --
> Wim Vandenberghe
> Researcher
> IBBT - IBCN - Ghent University
> Gaston Crommenlaan 8 bus 201
> 9050 Gent, Belgium
> E-mail: wim.vandenberghe at intec.UGent.be
> Tel. +32 9 33 14981
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>