From kutzner@fokus.fraunhofer.de Thu Mar 13 15:58:01 2003 From: kutzner@fokus.fraunhofer.de (Kendy Kutzner) Date: Thu, 13 Mar 2003 16:58:01 +0100 Subject: [nsclick-users] Accessing click element handlers from TCL Message-ID: <20030313155801.GA5666@adelphi.fokus.fraunhofer.de> just wrote a hack to access click element read/write handlers. Any comments very welcome. Kendy here we go: --- include/click/simclick.h 2003-03-13 16:52:05.000000000 +0100 +++ include/click/simclick.h.kek 2003-03-13 16:17:00.000000000 +0100 @@ -72,6 +72,10 @@ void simclick_click_kill(simclick_click clickinst,simclick_simstate* state); +int simclick_click_write_handler(simclick_click clickinst, const char* elemname, const char* handlername, const char* writestring); + +int simclick_click_read_handler(simclick_click clickinst, const char* elemname, const char* handlername, char * buf, int bufsize); + /* * The simulated system also has to provide a few services to * click, * notably some way of injecting packets back into the system, --- ns/nsclick.cc 2003-03-13 16:53:04.000000000 +0100 +++ ns/nsclick.cc.kek 2003-03-13 16:40:11.000000000 +0100 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include @@ -113,6 +114,10 @@ static String::Initializer crap_initializer; static String configuration_string; +/* + * + * + extern "C" int click_add_element_type(const char *, Element *) { @@ -128,6 +133,10 @@ fprintf(stderr,"Hey! Need to do click_remove_element_type!\n"); } + * + * + */ + // global handlers for ControlSocket @@ -394,3 +403,64 @@ return result; } +int simclick_click_write_handler(simclick_click clickinst, const char* elemname, const char* handlername, const char* writestring){ + Router *r = ((SimState*)clickinst)->router; + Element *ep = 0; + String s; + // XXX add checks for global handlers where elemname == NULL + //click_chatter("looking for element called '%s'", elemname); + for (int ei=0; ei < r->nelements(); ei++){ + s = r->ename(ei); + // click_chatter("considering %s", s.cc()); + if (s.equals(elemname, -1)){ + ep = r->element(ei); + break; + } + } + if (!ep){ + //click_chatter("not found"); + return(-1); + } + + String handler = String(elemname) + '.' + String(handlername); + //click_chatter("looking for handler called '%s'", handler.cc()); + for (int hi=0; hi < r->nhandlers(); hi++) + if (r->handler(hi)->write_visible()){ + //click_chatter("considering %s", r->handler(hi)->unparse_name(ep).cc()); + if(r->handler(hi)->unparse_name(ep) == handler) + return r->handler(hi)->call_write(String(writestring), ep, ErrorHandler::default_handler()); + } + return (-2); +} + +int simclick_click_read_handler(simclick_click clickinst, const char* elemname, const char* handlername, char* buf, int bufsize){ + Router *r = ((SimState*)clickinst)->router; + Element *ep = 0; + String s; + static char * ret; + // first search for the element name + for (int ei=0; ei < r->nelements(); ei++){ + s = r->ename(ei); + if (s.equals(elemname, -1)){ + ep = r->element(ei); + break; + } + } + if (!ep){ + return(-1); + } + // then search for handler name + String handler = String(elemname) + '.' + String(handlername); + for (int hi=0; hi < r->nhandlers(); hi++) + if (r->handler(hi)->read_visible()){ + if(r->handler(hi)->unparse_name(ep) == handler){ + s = r->handler(hi)->call_read(ep); + //click_chatter("handler returned %s", s.cc()); + strncpy(buf, s.cc(), bufsize-1); + buf[bufsize-1]='\0'; + return 0; + } + } + return (-2); +} + --- ns2/ns-2.1b9a/classifier/classifier-click.cc 2003-03-13 16:55:50.000000000 +0100 +++ ns2/ns-2.1b9a/classifier/classifier-click.cc.kek 2003-03-13 16:55:10.000000000 +0100 @@ -151,6 +151,25 @@ global_macmap_[MACAddr(string(argv[3]))] = nodeaddr_; return TCL_OK; } + else if (strcmp(argv[1], "readhandler") == 0) { + char clickretc[1000]; // passing a 'class string' would be better, wouldn't it? + simclick_click_read_handler(clickinst_, argv[2], argv[3], clickretc, 1000); + //fprintf(stderr, "readhandler: %s\n",clickretc); + tcl.resultf("%s", clickretc); + return TCL_OK; + } + + + } else if (argc == 5) { + if (strcmp(argv[1], "writehandler") == 0) { + int clickret; + clickret = simclick_click_write_handler(clickinst_, argv[2], argv[3], argv[4]); + fprintf(stderr, "writehandler: %i\n", clickret); + tcl.resultf("%i", clickret); + return TCL_OK; + } + + } return ExtClassifier::command(argc, argv); } -- From kutzner@fokus.fraunhofer.de Wed Mar 19 11:35:11 2003 From: kutzner@fokus.fraunhofer.de (Kendy Kutzner) Date: Wed, 19 Mar 2003 12:35:11 +0100 Subject: [nsclick-users] Timer support between click and ns2 Message-ID: <20030319113511.GA4007@adelphi.fokus.fraunhofer.de> Hello Michael, hi list, somehow I have difficulties using timers in nsclick. My element calls Timer::initialize(MyElement) and Timer::schedule_after_ms(), but the method MyElement::run_timer() is never called back. With gdb I checked the function simclick_sim_schedule() is never called. simclick_click_run() and ClickEventHandler::handle() aren't called too. What could be wrong? Kendy -- From Michael.Neufeld@Colorado.EDU Wed Mar 19 17:04:58 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Wed, 19 Mar 2003 10:04:58 -0700 Subject: [nsclick-users] Timer support between click and ns2 In-Reply-To: <20030319113511.GA4007@adelphi.fokus.fraunhofer.de> References: <20030319113511.GA4007@adelphi.fokus.fraunhofer.de> Message-ID: <3E78A33A.80301@cs.colorado.edu> You're running the latest CVS version of Click, right? I did notice that there have been some changes to the scheduling system over the last month or so - those might require some changes to the nsclick patches. I just started using the latest CVS rev for my work today, I'll let you know if I find something out. -Mike Kendy Kutzner wrote: > Hello Michael, hi list, > > somehow I have difficulties using timers in nsclick. My element > calls Timer::initialize(MyElement) and Timer::schedule_after_ms(), > but the method MyElement::run_timer() is never called back. > > With gdb I checked the function simclick_sim_schedule() is never > called. simclick_click_run() and ClickEventHandler::handle() > aren't called too. > > What could be wrong? > > Kendy > From kutzner@fokus.fraunhofer.de Wed Mar 19 17:33:23 2003 From: kutzner@fokus.fraunhofer.de (Kendy Kutzner) Date: Wed, 19 Mar 2003 18:33:23 +0100 Subject: [nsclick-users] Timer support between click and ns2 In-Reply-To: <3E78A33A.80301@cs.colorado.edu> References: <20030319113511.GA4007@adelphi.fokus.fraunhofer.de> <3E78A33A.80301@cs.colorado.edu> Message-ID: <20030319173323.GA5836@adelphi.fokus.fraunhofer.de> On 2003-03-19T10:04:58, Michael Neufeld wrote: > You're running the latest CVS version of Click, right? yep. > I'll let you know if I find something out. Great. Did you have a look at the read/writehandler patches? Kendy -- From Michael.Neufeld@Colorado.EDU Wed Mar 19 17:37:42 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Wed, 19 Mar 2003 10:37:42 -0700 Subject: [nsclick-users] Timer support between click and ns2 In-Reply-To: <20030319173323.GA5836@adelphi.fokus.fraunhofer.de> References: <20030319113511.GA4007@adelphi.fokus.fraunhofer.de> <3E78A33A.80301@cs.colorado.edu> <20030319173323.GA5836@adelphi.fokus.fraunhofer.de> Message-ID: <3E78AAE6.2020605@cs.colorado.edu> Only briefly, but what I saw looked good. Thanks! I'll plan on rolling them into the Click distribution and into the ns-2 patch set when I do the next revision. -Mike Kendy Kutzner wrote: > On 2003-03-19T10:04:58, Michael Neufeld wrote: > >>You're running the latest CVS version of Click, right? > > > yep. > > >>I'll let you know if I find something out. > > > Great. Did you have a look at the read/writehandler patches? > > Kendy > From kohler@icir.org Wed Mar 19 18:48:26 2003 From: kohler@icir.org (Eddie Kohler) Date: Wed, 19 Mar 2003 10:48:26 -0800 Subject: [nsclick-users] Timer support between click and ns2 In-Reply-To: Message from Michael Neufeld of "Wed, 19 Mar 2003 10:37:42 MST." <3E78AAE6.2020605@cs.colorado.edu> Message-ID: <200303191848.h2JImQjf082187@coyote.icir.org> > Only briefly, but what I saw looked good. Thanks! I'll plan on rolling > them into the Click distribution and into the ns-2 patch set when I do > the next revision. I looked into the patches, and I wouldn't suggest rolling them in until they can support arbitrary-length strings. No buffer overruns! :) Kendy, can you take care of that? You could use String... Or did I misread? Eddie From Michael.Neufeld@Colorado.EDU Wed Mar 19 19:12:46 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Wed, 19 Mar 2003 12:12:46 -0700 Subject: [nsclick-users] Timer support between click and ns2 In-Reply-To: <200303191848.h2JImQjf082187@coyote.icir.org> References: <200303191848.h2JImQjf082187@coyote.icir.org> Message-ID: <3E78C12E.1010302@cs.colorado.edu> I'd much prefer to not add C++ classes to the simulator API if it can be helped. We made a conscious effort to keep the API restricted to baseline C to minimize conflicts with existing simulator code and class libraries. Maybe I'm being a little paranoid, but I'd still like to maintain that level of genericity and not incur a C++ dependence at this point. I've seen (and been burned by) a lot of C++ classes which sneak in dependencies, i.e. you just want to use one class, but it nonobviously depends on a bunch of other classes and header files, and what started out as a simple #include turns into a major operation. Sticking with straight, basic C really helps to minimize those sorts of problems. I'd be more inclined to add a "maximum buffer length" parameter to the functions to avoid overruns. -Mike Eddie Kohler wrote: >>Only briefly, but what I saw looked good. Thanks! I'll plan on rolling >>them into the Click distribution and into the ns-2 patch set when I do >>the next revision. > > > I looked into the patches, and I wouldn't suggest rolling them in until > they can support arbitrary-length strings. No buffer overruns! :) Kendy, > can you take care of that? You could use String... Or did I misread? > > Eddie > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs.colorado.edu > http://www.cs.colorado.edu/mailman/listinfo/nsclick-users From Michael.Neufeld@Colorado.EDU Thu Mar 20 06:04:59 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Wed, 19 Mar 2003 23:04:59 -0700 Subject: [nsclick-users] nsclick scheduling issue/fix Message-ID: <3E795A0B.6080900@cs.colorado.edu> This is a multi-part message in MIME format. --------------060707080306040104030307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There's an issue with how Click gets run from the ns simulator which could be causing some problems in some situations. The problem stems from Click not always getting executed immediately on startup of the simulation. Usually an event initiated by ns-2 (e.g. a packet sent by a traffic generating agent) will cause Click to be run in fairly short order, but not always. In a case observed by Marie-Christine Castell, this caused a few packets which were scheduled to be sent periodically from within Click to "stack up" at the beginning of the simulation until a scheduled event in ns-2 got things moving. Kendy: I'm not sure if this is the cause of your problem, but I think it might be. As a fix, I've added a way to forcibly run Click routers from ns-2 tcl code. This involves a patch to the ns-2 C++ file classifier/classifier-click.cc and some addition to your tcl simulation script. First, the patch (also included as an attachment): --- classifier-click.cc 18 Mar 2003 06:29:28 -0000 1.6 +++ classifier-click.cc 20 Mar 2003 05:24:11 -0000 1.7 @@ -89,6 +89,15 @@ if (strcmp(argv[1], "getnodename") == 0) { // getnodename tcl.resultf(nodename_.c_str()); + return TCL_OK; + } + if (strcmp(argv[1], "runclick") == 0) { + // runclick + if (clickinst_) { + simclick_simstate simstate; + simstate.curtime = GetSimTime(); + simclick_click_run(clickinst_,&simstate); + } return TCL_OK; } } Second, the modifications to TCL scripts. Basically the idea is to schedule a call to "runclick" for each node at time 0 in the simulation. I may add code to the TCL system code in ns-2 to automatically do this at some point, but for now it has to be done explicitly. For example, a chunk of code which does this within the context of the nsclick-simple-wlan.tcl sample file is: for {set i 0} {$i < $nodecount} {incr i} { $ns_ at 0 "[$node_($i) entry] runclick" } -Mike --------------060707080306040104030307 Content-Type: text/plain; name="classifier-click.cc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="classifier-click.cc.patch" --- classifier-click.cc 18 Mar 2003 06:29:28 -0000 1.6 +++ classifier-click.cc 20 Mar 2003 05:24:11 -0000 1.7 @@ -89,6 +89,15 @@ if (strcmp(argv[1], "getnodename") == 0) { // getnodename tcl.resultf(nodename_.c_str()); + return TCL_OK; + } + if (strcmp(argv[1], "runclick") == 0) { + // runclick + if (clickinst_) { + simclick_simstate simstate; + simstate.curtime = GetSimTime(); + simclick_click_run(clickinst_,&simstate); + } return TCL_OK; } } --------------060707080306040104030307-- From kutzner@fokus.fraunhofer.de Thu Mar 20 10:09:19 2003 From: kutzner@fokus.fraunhofer.de (Kendy Kutzner) Date: Thu, 20 Mar 2003 11:09:19 +0100 Subject: [nsclick-users] nsclick scheduling issue/fix In-Reply-To: <3E795A0B.6080900@cs.colorado.edu> References: <3E795A0B.6080900@cs.colorado.edu> Message-ID: <20030320100919.GA10050@adelphi.fokus.fraunhofer.de> On 2003-03-19T23:04:59, Michael Neufeld wrote: > Kendy: I'm not sure if this > is the cause of your problem, but I think it might be. Apparently it was. Now it works. Thanks. Kendy -- From omaira@dit.upm.es Thu Mar 20 16:44:35 2003 From: omaira@dit.upm.es (omaira@dit.upm.es) Date: Thu, 20 Mar 2003 16:44:35 GMT Subject: [nsclick-users] Problem installing NSCLICK Message-ID: <200303201644.h2KGiZ418077@maja.dit.upm.es> Hi all, I am installing nsclick, I continue step to step the instructions included in the readme of nsclick. In the step 6: Build ns-2 in ./install, I obtain the following error: emulate/tcptap.cc: In method `void TCPTapAgent::tcp_gen (char *, short unsigned int, short unsigned int, Packet *)': emulate/tcptap.cc:273: `struct tcphdr' has no member named `source' emulate/tcptap.cc:274: `struct tcphdr' has no member named `dest' emulate/tcptap.cc:276: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:277: `struct tcphdr' has no member named `ack_seq' emulate/tcptap.cc:279: `struct tcphdr' has no member named `doff' emulate/tcptap.cc:280: `struct tcphdr' has no member named `window' emulate/tcptap.cc:284: `struct tcphdr' has no member named `fin' emulate/tcptap.cc:286: `struct tcphdr' has no member named `syn' emulate/tcptap.cc:288: `struct tcphdr' has no member named `rst' emulate/tcptap.cc:290: `struct tcphdr' has no member named `psh' emulate/tcptap.cc:292: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:294: `struct tcphdr' has no member named `urg' emulate/tcptap.cc: In method `void TCPTapAgent::recvpkt ()': emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:424: `struct tcphdr' has no member named `doff' emulate/tcptap.cc:445: `struct tcphdr' has no member named `fin' emulate/tcptap.cc:447: `struct tcphdr' has no member named `syn' emulate/tcptap.cc:449: `struct tcphdr' has no member named `rst' emulate/tcptap.cc:451: `struct tcphdr' has no member named `psh' emulate/tcptap.cc:453: `struct tcphdr' has no member named `ack' emulate/tcptap.cc:455: `struct tcphdr' has no member named `urg' emulate/tcptap.cc: In method `int TCPTapAgent::sendpkt (Packet *)': emulate/tcptap.cc:536: `struct tcphdr' has no member named `check' make: *** [emulate/tcptap.o] Error 1 Ns make failed! Thanks for your help. Omaira --------------------------------------------- Sent from web mail gateway in DIT - ETSIT - UPM. Please, send hints or comments to guru@dit.upm.es. From Michael.Neufeld@Colorado.EDU Thu Mar 20 23:42:52 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Thu, 20 Mar 2003 16:42:52 -0700 Subject: [nsclick-users] Problem installing NSCLICK References: <200303201644.h2KGiZ418077@maja.dit.upm.es> Message-ID: <3E7A51FC.6020804@cs.colorado.edu> Yeah, we've seen this happen on some systems. What operating system/version are you using? A quick hack that often works is to add: #undef LINUX_TCP_HEADER to the very top of the .cc file which is causing problems. If that doesn't work, you can always just comment out the offending lines if you aren't going to be using the ns-2 network emulation features. -Mike omaira@dit.upm.es wrote: > Hi all, > > I am installing nsclick, I continue step to step the instructions > included in the readme of nsclick. In the step 6: Build ns-2 in > ./install, I obtain the following error: > > emulate/tcptap.cc: In method `void TCPTapAgent::tcp_gen (char *, > short > unsigned int, short unsigned int, Packet *)': > emulate/tcptap.cc:273: `struct tcphdr' has no member named `source' > emulate/tcptap.cc:274: `struct tcphdr' has no member named `dest' > emulate/tcptap.cc:276: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:277: `struct tcphdr' has no member named > `ack_seq' > emulate/tcptap.cc:279: `struct tcphdr' has no member named `doff' > emulate/tcptap.cc:280: `struct tcphdr' has no member named `window' > emulate/tcptap.cc:284: `struct tcphdr' has no member named `fin' > emulate/tcptap.cc:286: `struct tcphdr' has no member named `syn' > emulate/tcptap.cc:288: `struct tcphdr' has no member named `rst' > emulate/tcptap.cc:290: `struct tcphdr' has no member named `psh' > emulate/tcptap.cc:292: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:294: `struct tcphdr' has no member named `urg' > emulate/tcptap.cc: In method `void TCPTapAgent::recvpkt ()': > emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:422: `struct tcphdr' has no member named `seq' > emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:423: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:424: `struct tcphdr' has no member named `doff' > emulate/tcptap.cc:445: `struct tcphdr' has no member named `fin' > emulate/tcptap.cc:447: `struct tcphdr' has no member named `syn' > emulate/tcptap.cc:449: `struct tcphdr' has no member named `rst' > emulate/tcptap.cc:451: `struct tcphdr' has no member named `psh' > emulate/tcptap.cc:453: `struct tcphdr' has no member named `ack' > emulate/tcptap.cc:455: `struct tcphdr' has no member named `urg' > emulate/tcptap.cc: In method `int TCPTapAgent::sendpkt (Packet *)': > emulate/tcptap.cc:536: `struct tcphdr' has no member named `check' > make: *** [emulate/tcptap.o] Error 1 > Ns make failed! > > Thanks for your help. > > Omaira > > > --------------------------------------------- > Sent from web mail gateway in DIT - ETSIT - UPM. > Please, send hints or comments to guru@dit.upm.es. > > > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs.colorado.edu > http://www.cs.colorado.edu/mailman/listinfo/nsclick-users From marie-christine.castell@kcl.ac.uk Fri Mar 21 11:51:12 2003 From: marie-christine.castell@kcl.ac.uk (Marie-Christine Castell) Date: Fri, 21 Mar 2003 11:51:12 +0000 Subject: [nsclick-users] HashMap, BigHashMap In-Reply-To: <3E7A2FE4.8080208@cs.colorado.edu> References: <3E795A0B.6080900@cs.colorado.edu> <200303201727.53142.marie-christine.castell@kcl.ac.uk> <3E7A2FE4.8080208@cs.colorado.edu> Message-ID: <200303211151.12188.marie-christine.castell@kcl.ac.uk> Hi, I'd like to know where to find documentations on HashMap and BigHashMap as the sections in the Click Documentation are empty... Please anyone who know how it works and what is the difference between HashMap and BigHashMap could he explain me what is the point to use them? Thanks a lot Marie-Christine From Michael.Neufeld@Colorado.EDU Mon Mar 24 06:00:31 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Sun, 23 Mar 2003 23:00:31 -0700 Subject: [nsclick-users] Updated nsclick patch Message-ID: <3E7E9EFF.1030402@cs.colorado.edu> I've just put a new version of the nsclick patches up on the website: http://systems.cs.colorado.edu/Networking/nsclick/ This patchset will work with the anonymous CVS version of Click, and should work with the next prerelease of Click 1.3 (there are some build problems with 1.3pre1). This release is still based on the 2.1b9 release of ns-2, and there are instructions for upgrading an existing nsclick install. This patchset includes the scheduler bugfix which was posted last week, but does not yet include support for read/write handlers. There is also some pre-alpha support for a new packet translation scheme which makes it easier to use regular ns-2 traffic generators as well as use TCP traffic in simulations. I haven't had a chance to document or extensively test this code, so find and use it at your own risk. Existing code should still work just fine, with the exception that some minor changes will have to be made to Click C++ elements, and the "ToSimDump" element has had its functionality moved into the regular "ToDump" element. I *strongly* encourage those of you using nsclick with Click 1.2.4 to upgrade. There are some problems with the scheduler in nsclick with 1.2.4 which can cause some truly annoying timing issues in some situations. It's also just A Good Thing to be running the most recent version of Click. -Mike Neufeld From Michael.Neufeld@Colorado.EDU Thu Mar 27 22:36:47 2003 From: Michael.Neufeld@Colorado.EDU (Michael Neufeld) Date: Thu, 27 Mar 2003 15:36:47 -0700 Subject: [nsclick-users] Missed ACK packet drop information nsclick Message-ID: <3E837CFF.90406@cs.colorado.edu> One other feature in the new patch up on the nsclick site which I forgot to mention is the addition of ACK failure notification, often referred to as link-layer feedback. This is implemented as a pseudo network interface which emits all packets dropped due to no ACK being received. This interface is called "dropXX" where XX matches the interface number "ethXX". For example, FromSimDevice(drop0,2048) would pump out packets sent on eth0 which get dropped due to ACK failure. From the ethernet and/or IP headers in the packet you can figure out the intended destination and take appropriate action. -Mike