[Click] FromDump restart

Robert Ross rross at dsci.com
Tue Nov 20 09:38:34 EST 2007


Perhaps I should also mention that the PCAP file came from Wireshark.  I
have attached that PCAP file for your review.


Robert Ross
DSCI Inc.
Office: 732.542.3113 x173
Home: 609.702.8114
Cell: 609.509.5139
Fax: 253.550.6198

-----Original Message-----
From: Robert Ross 
Sent: Tuesday, November 20, 2007 9:31 AM
To: 'Eddie Kohler'
Cc: click at amsterdam.lcs.mit.edu
Subject: RE: [Click] FromDump restart

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.pcap
Type: application/octet-stream
Size: 109114 bytes
Desc: email.pcap
Url : https://pdos.csail.mit.edu/pipermail/click/attachments/20071120/421ec685/email-0001.obj


More information about the click mailing list