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/st...@11 :: Strip’ input 0 unused nsclick-simple-lan.click:62: ‘u/ippr...@15 :: IPPrint’ input 0 unused nsclick-simple-lan.click:68: ‘u/pr...@18 :: Print’ input 0 unused nsclick-simple-lan.click:43: ‘u/hostetherfil...@10 :: HostEtherFilter’ output 0 unused nsclick-simple-lan.click:57: ‘u/getipaddr...@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: 'ippr...@25' push output 0 connected to 'tod...@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<[email protected]> 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: [email protected] > Tel. +32 9 33 14981 > > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
