[Click] FromDump restart

Tue Nov 20 11:31:00 EST 2007

Yes, the "init" instruction used by this script runs when the element is 
initialized, so you need the Script to get initialized after the FromDump. 
Declaration order is one way to do that.

Perhaps "init" should instead run the first time the script executes...not sure.

Eddie

Robert Ross wrote:
> That was the problem.  I wasn't aware order of declaration mattered, but
> apparently it does when dealing with scripts.  The declaration of my
> FromDump elements was after the declaration of my Script element in the
> configuration.  I moved the FromDump elements above my Script
> declaration and filepos now reports "24".  Thanks!
> 
> Robert Ross
> DSCI Inc.
> Office: 732.542.3113 x173
> Home: 609.702.8114
> Cell: 609.509.5139
> Fax: 253.550.6198
> 
> -----Original Message-----
> From: Beyers Cronje [mailto:bcronje at gmail.com] 
> Sent: Tuesday, November 20, 2007 11:07 AM
> To: Robert Ross
> Cc: Eddie Kohler; click at pdos.csail.mit.edu
> Subject: Re: [Click] FromDump restart
> 
> Hi Robert,
> 
> Running your config below and pcap file I get:
> 
> click conf/fromdump.click
> First Offset:  24
> 1194550918.323930:   66 | 00180125 a9fb0017 3f525f52 08004500 0034829e
> 40003006
> 1194550918.384094:   54 | 00180125 a9fb0017 3f525f52 08004500 0028829f
> 40003006
> 1194550918.444360:   66 | 00180125 a9fb0017 3f525f52 08004500 003482a4
> 40003006
> ......
> 
> I'm running git version from a few weeks back. I wonder if it is
> possible that your script element is getting initialized before your
> FromDump element?
> 
> Beyers
> 
> On Nov 20, 2007 4:25 PM, Robert Ross <rross at dsci.com> wrote:
>> I tried this and, as I said before, the position returned is "0":
>>
>> fd::FromDump(/tmp/foo.trace,
>>         TIMING true, FORCE_IP false, ACTIVE false, END_CALL
>> restarter.step)
>>         -> Print(TIMESTAMP true) -> Discard;
>>
>> restarter::Script(init first_offset $(fd.filepos),
>>         print "First Offset: " $first_offset ,
>>         write fd.active true,
>>         pause,
>>         write fd.filepos $first_offset,
>>         write fd.reset_timing,
>>         loop)
>>
>>
>> This prints:
>>
>> First Offset: 0
>>
>>
>>
>> Robert Ross
>> DSCI Inc.
>> Office: 732.542.3113 x173
>> Home: 609.702.8114
>> Cell: 609.509.5139
>> Fax: 253.550.6198
>>
>> -----Original Message-----
>> From: Eddie Kohler [mailto:kohler at cs.ucla.edu]
>> Sent: Monday, November 19, 2007 1:38 PM
>> To: Robert Ross
>> Cc: click at amsterdam.lcs.mit.edu
>> Subject: Re: [Click] FromDump restart
>>
>> I think you did not try this, because it should have worked, but who 
>> knows?  I checked in an update so that TIMING and FORCE_IP are 
>> compatible, and added a "FromDump::reset_timing" handler so that you 
>> can reset timing information when looping back into the file.
>>
>> fd::FromDump(/tmp/foo.trace,
>>         TIMING true, FORCE_IP false, ACTIVE false, END_CALL
>> restarter.step)
>>         -> Print(TIMESTAMP true) -> Discard;
>>
>> restarter::Script(init first_offset $(fd.filepos),
>>         write fd.active true,
>>         pause,
>>         write fd.filepos $first_offset,
>>         write fd.reset_timing,
>>         loop)
>>
>>
>> Eddie
>>
>>
>> Robert Ross wrote:
>>> I thought I had tried this already.  When I tried it, fd.filepose 
>>> returned "0" as the starting position.  The only difference I see is
> 
>>> that I did not use "FORCE_IP true" because need to use the "TIMING"
>>> keyword.  The two are apparently mutually exclusive.
>>>
>>> Robert Ross
>>> DSCI Inc.
>>> Office: 732.542.3113 x173
>>> Home: 609.702.8114
>>> Cell: 609.509.5139
>>> Fax: 253.550.6198
>>>
>>> -----Original Message-----
>>> From: Eddie Kohler [mailto:kohler at cs.ucla.edu]
>>> Sent: Saturday, November 17, 2007 10:03 PM
>>> To: Robert Ross
>>> Cc: click at amsterdam.lcs.mit.edu
>>> Subject: Re: [Click] FromDump restart
>>>
>>> Hi Robert,
>>>
>>> The problem with filepos is that filepos=0 is the pcap file header.
>>> You need to set it to the first byte of actual packet data, which 
>>> might be
>>> 24 or 28 depending on pcap version.
>>>
>>> This script works for me.  It relies on the fact that FromDump skips
> 
>>> the header at initialization time, but does not actually read any 
>>> packets until ACTIVE is true.
>>>
>>>
>>> fd::FromDump(~/src/ipsumdump/test/one-byte-payload.trace,
>>>       FORCE_IP true, ACTIVE false, END_CALL restarter.step)
>>>       -> IPPrint -> Discard;
>>>
>>> restarter::Script(init first_offset $(fd.filepos),
>>>       write fd.active true,
>>>       pause,
>>>       write fd.filepos $first_offset,
>>>       loop)
>>>
>>>
>>> Eddie
>>>
>>>
>>> Robert Ross wrote:
>>>> I'm trying to use a Script element along with a FromDump to loop a
>>> small PCAP file several times with a delay between replays.  The 
>>> script basically works except for one critical element:  I cannot 
>>> seem
>>> to reset the FromDump "filepos" handler to the beginning of the
> file.
>>> As indicated in the documentation, the issue appears to be 
>>> determining
>>> the correct byte offset for the beginning of the first packet in the
>> file.
>>> I've tried the following with no luck:
>>>> 1.  Setting filepos=0.  If only it were that simple...
>>>> 2.  Wait until the first packet has come out and "poke" the script
>>> using a Counter element.  Then use the script to calculate various 
>>> starting positions using a combination of read handlers from 
>>> FromDump and Counter.
>>>> Some of the questions I have are:
>>>>
>>>> 1.  Both packet_filepos and filepos provide byte offsets, but the
>>> documentation does not adequately describe what these offsets
>> represent.
>>> Is packet_filepos the end point of the last packet read?  The start 
>>> point of the last packet read?  The start point of the next packet 
>>> to be read?  Something else?  What is the difference between filepos
> 
>>> and packet_filepos?
>>>> 2.  Is there another simpler way to loop a PCAP file that I'm
>> missing?
>>>> 3.  Assuming I knew the correct offset, is it even possible to 
>>>> reset
>>> the filepos and re-play the PCAP file again?
>>>> As a general suggestion, added LOOP and LOOP_INTERVAL keywords to 
>>>> the
>>> various dump elements could be extremely useful.  In the absence of 
>>> those, at the very least a "restart" or "start_pos" handler would be
> 
>>> equally useful.  I'm currently wondering why the "filepos" handler 
>>> is even writeable...
>>>> Thanks,
>>>> Robert A. Ross
>>>> DSCI Inc.
>>>> 609-509-5139
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>