Ethereal-users: [Ethereal-users] RE: Feature Request

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Berry, Richard" <BerryR@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 16 Jun 2003 10:20:50 -0500
A marker packet is a good idea. "PING" would do very well for the job,
using one of two approaches:

1) Virtually any PING utility can specify packet size. Pick a packet
size that is distinctive, e.g., 777, 888, 999...

2) If you have access to a Linux box, you can also specify a pattern in
the data payload of up to 16 repeating bytes. You could then do
something like ping xxx.xxx.xxx.xxx -p FEEDFACEDEADBEEF. Ethereal will
show it in the hex dump of the PING packet (and usually the reply
packet). That's pretty unique.

-Richard Berry

> I hope this is the proper forum for a suggested feature request? If 
> not, perhaps I can at least get some comments on whether this is 
> considered a useful feature for more users before I post to the -dev 
> list.
>
> In the ethereal GUI an active logging session has a smaller pop-up 
> window displaying the number of packets received and a "stop" button. 
> I would like to have another button (e.g. named "Mark") that enables 
> me to insert a fake marker packet into the log. This means that I can 
> trace a socket over time and mark periods of waiting for the server, 
> as opposed to normal periods of inactivity.
>
> Example:
> A database front-end is perceived as "hanging" at times by the end 
> users. It is not clear whether this is a client app problem or a 
> server response issue. A network trace shows large deltas at times, 
> but some of these are normal periods of network inactivity, others are

> periods of waiting for a result set. It is not easy to filter these as

> the application may have many connections open in parallel. A solution

> could be to install Ethereal on a test client machine together with 
> the application and have a user work on this for a day or two, 
> pressing the "Mark" button when s/he feels there is a problem. This 
> log, compared with datetime stamps from app log and server log, should

> show exactly what was going on in the problem periods - even if there 
> are several problems related to network activity.
>
> _______________________________________________