[Click] FromDump restart

[Robert Ross]

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