Wireshark · Ethereal-dev: [ethereal-dev] Updates to Ethereal and (passable) real-time display

[John McDermott <jjm@xxxxxxxxxx>]

Greetings all,

I have been wanting some form of real-time display for Ethereal.  To that 
end I have added some command line args and features and fixed one (see 
below).  If you do not choose to use the args I've added, Ethereal should 
function as it did before.

The way I did pseudo-real-time display is to have an option which forks a 
child for capture.  It also pre-loads the file name into the Open dialog 
box so the user can get it easily.  I also added a sync option so that if 
you reload the file, it signals the capturing child to fflush the buffer.  
It will therefore sometimes show one more packet in the window than the 
capture counts window does because that window does not refresh the count 
every time.  This is probably fixed if one uses the linux-patched (I'm 
using Linux 2.2.5 with libpcap 0.4) pcap.  I haven't got that, yet.  I 
thought I saw the location on the list, but now I can't find that message.

To use the real-time scheme I have set up:
	ethereal -F	or
	ethereal -F -S

then start the capture as usual.  After at least one packet has been 
captured, do a File/Open.  When you want to see more packets, do 
File/Reload.

This scheme is better than traditional flowing packets as the screen does 
not change during capture and it allows full examination of packets during 
capture.  Also, it should be easy to transition to a threads (either gtk+ 
or pthreads) scheme once we decide on how it will go.

This works for my needs now, and I am lacking in time to do too much more 
work for a couple weeks, so I will be more or less leaving it here for now.

One change I'd like to see is when the user does a File/Reload, it would be 
nice if the packet display window did not change, but rather data was just 
loaded on the end.  I tried this, but in the limited time I devoted to it I 
must have overlooked something.  If it were this way, one could then to 
periodic updates to the buffer without user intervention.

The changes:

* Fixed -k.  It was not in the getopts so it did not work.
* Added -Q.  Start capture and quit when capture is done.
* Added -F.  Fork a child to do the capture.
* Added -S.  Set up to sync with a child's file.  Needs -F to be useful.  
This causes Reload to signal the capture child to do an fflush.  There is 
an ugly 2 second wait between the signal and the rereading of the file 
right now.  I really should pass the parent's PID to the child so it can 
signal back. 
* Added a periodic fflush to captures to avoid loss.
* SIGUSR1 causes a capturing program to fflush. (Only if started with -k or 
-Q)
*

Still to do (coming soon):
Verify that all necessary options are passed to the child when forking e.g. 
-f.

I did find a bug in the code, however.  In capture.c in main_realize-cb is 
this code:
  if( cf.save_file)
    capture();
  else
    capture();

I have no idea what was meant and did not change it, but it is interesting 
:-)

Gilbert, should I sent the changes to you?  You can decide what to do with 
them.  I can only test under Linux for now.

Thanks,
--john


-------------------------------------
Name: John McDermott
VOICE: +1 505/377-6293 FAX +1 505/377-6313
E-mail: John McDermott <jjm@xxxxxxxxxx>
Writer and Computer Consultant
-------------------------------------