> Would it be possible to implement the following feature:
> In ethereal there are severyl columns with various type of data (Source
> host, Port, Protocol etc). If I have a long listing and want to find, say
> a NFS connection attempt from host "holland", I need to scroll down to
> that position...this takes long time :-(
> It would be much better, if one could sort the entries by clicking on the
> columns name filed at the top of the listing. Additional this would be the
> expected behavior for a grid view with named columns, wouldn't it?
*Some* grids of that sort do that; not all do - it's not something I'd
have expected.
A patch was sent out to do sorting of that flavor; I think there may be
some minor issues with it (e.g., handling sorts where the correct sort
order isn't "dictionary sort on strings"), but the major issue has, I
think, been resolved by a recent checkin to change the way we find the
frame corresponding to a given row in the display and find the row
corresponding to a given frame.
> Yes, of course, you could use a filter, but sometimes you are searching
> for a certain network problem and you might not know all parammeters you
> are searching for and thus, it may not be possible to use a filter...
If you don't know what you're searching for, how would you know what
column to sort on?
At least in the case of searching for an NFS request from host
"holland", "Edit:Find Frame" (control-F) with a search pattern of
nfs && ip.src == holland
will find the next packet that's an NFS request from host "holland".
(if you truly meant "connection attempt", i.e. an initial TCP SYN going
to an NFS server, it'd be some expression involving "ip.src == holland"
and "tcp.port == 2049" and something involving the TCP "flags" field
looking for an initial SYN - the initial SYN contains no NFS request, so
Ethereal wouldn't recognize it as an NFS packet, although, if we do a
more vigorous job of handling conversations, we could retroactively
label the initial connection as an NFS packet, although, at least when
talking to a Solaris NFS server, there may be requests going over the
connection that aren't NFS requests in the strictest sense, i.e. instead
of requests to RPC program 100003 they could be requests to the "NFS ACL"
program, 100227).