Guy Harris | 23 Jun 04:44 2006
Picon

Re: WinXP build still not oke


On Jun 22, 2006, at 8:16 AM, Martin Mathieson wrote:

> As I suggested earlier, remove that line completely from  
> catapult_dct2000.h.

Done.
Kukosa, Tomas | 23 Jun 07:42 2006
Picon

Re: displaying multiple pdu's in one packet asmultiple packets for summary window


I think it would be too much to display all lower protocols. 
E.g. in our private protocols we disply only highest protocol
information for each PDU and it seems to be the best solution for single
line information.

Better solution could be found when we introduce "multiline
information".

> Well, it's a problem for every transport protocol, TCP (stream) and  
> UDP
> (datagram) I've seen this on.
> Not sure what to do. I would like the summary pane to display a  
> summary
> of the _frame_ (lowest level entity) captured at that instance in  
> time.

If I'm trying to figure out an HTTP or NFS or SMB or... problem, I'd  
want to see the summary line present HTTP/NFS/SMB/etc. information,  
not Ethernet/802.11/PPP/... information.

If somebody wants an option to show the lowest level information in  
the summary line, fine - but I'll turn that option off in my  
preferences.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@...
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Jaap Keuter | 23 Jun 08:34 2006
Picon
Picon

Re: displaying multiple pdu's in one packet asmultiple packets for summary window

Hi,

I would not propose to present the low level information, I would propose
to keep a single summary line per frame, not multiple. The only way to
present multiple lines of a single frame is to use an expandable widget,
but that would probalby require us to replace the GtkCList widget for the
summary pane.

Thanx,
Jaap

On Fri, 23 Jun 2006, Kukosa, Tomas wrote:

>
> I think it would be too much to display all lower protocols.
> E.g. in our private protocols we disply only highest protocol
> information for each PDU and it seems to be the best solution for single
> line information.
>
> Better solution could be found when we introduce "multiline
> information".
>
>
>
> > Well, it's a problem for every transport protocol, TCP (stream) and
> > UDP
> > (datagram) I've seen this on.
> > Not sure what to do. I would like the summary pane to display a
> > summary
> > of the _frame_ (lowest level entity) captured at that instance in
(Continue reading)

Jeff Morriss | 23 Jun 08:44 2006

Re: [Ethereal-dev] displaying multiple pdu's in one packet as multiple packets for summary window


[Reply moved to wireshark-dev; hopefully the folks only on ethereal-dev 
don't mind...]

Guy Harris wrote:
> Jeff Morriss wrote:
> 
>> That works up to a point (that point being when the Info column is so 
>> long it scrolls off the right of the screen!).  I think, though, that 
>> having some way of viewing the payload PDUs separately would be 
>> useful.  I just haven't thought of how that could be done.
> 
> One possibility might be to have the packet list be a "tree view" widget 
> rather than a "list view" widget; if a given link-layer packet has data 
> from more than one higher-level packet in it, the top-level row for the 
> packet might be a summary of all the higher-level packets, and if you 
> open it up you'd see the individual summary lines for each of the packets.

You mean something like:

Frame	Time	Source	Dest.	Prot.	Info
  [+]1	0.000	1234	5678	M3UA	DAUD DAUD DAUD DAUD [...]

and then:

Frame	Time	Source	Dest.	Prot.	Info
[-]1	0.000	myhost1	myhost2	SCTP	4 DATA chunks
    1.1	0.000	1234	5678	M3UA	DAUD
    1.2	0.000	1234	5678	M3UA	DAUD
    1.3	0.000	1234	5678	M3UA	DAUD
(Continue reading)

authesserre samuel | 23 Jun 08:55 2006
Picon

Re: [Ethereal-dev] Dissector SSL : patch + bugs

Hi,

it's not the last one...

I've put last one on ethereal-dev (on wireshark-dev too) but size of
patch is highter than 40ko so a person have to check it (it isn't sent
before this...)

"Why the 2 mailings lists don't have the same configuration ??"

I have resend another patch made on wireshark svn on ethreal-dev
mailing list because a person tell me that patch cannot be applied
correctly

since I've not news

regards,

Samuel

On 6/23/06, ronnie sahlberg <ronniesahlberg@...> wrote:
> did anyone check this patch in?
>
>
> On 5/19/06, authesserre samuel <sauthess@...> wrote:
> >
> > Sorry for spam I forgot to attach the file....
> > I correct my mistake...
> >
> > sorry for this mistake
(Continue reading)

Ulf Lamping | 23 Jun 20:45 2006
Picon

Windows file dialogs should behave now much more like they should

Hi List!

Just committed some changes, so the windows file dialog:

- file extension filter lists now contains all available file types (not 
only a selection)
- no separate combo boxes in the save dialog
- if no file extension given by the user, the default extension will be 
appended

I didn't changed the other file dialogs like the export dialogs.

I've compiled the list of possible file extensions and the default 
extension from "sophisticated guesswork".

Could anyone who know about the file extension of a specific file format 
have a look at the file wiretap/file_access.c (around line 333) about it?

Regards, ULFL
Stephen Fisher | 23 Jun 21:15 2006
Picon

[Patch] CDP dissector


I have attached a patch for the CDP (Cisco Discovery Protocol) dissector 
for consideration.  Almost every time that I am looking at CDP frames, 
it is to determine two things: the device name and the port number.  I 
suspect that this is the case for others also.  You have to open the 
tree for CDP, and then open the right two branches.  This patch adds 
these two values to the Info column.

Old info column:

  Cisco Discovery Protocol

New info column:

  Cisco Discovery Protocol  Device ID: switch.domain.com  Port ID: 3/5

Thanks,
  Steve

Index: epan/dissectors/packet-cdp.c
===================================================================
--- epan/dissectors/packet-cdp.c	(revision 18563)
+++ epan/dissectors/packet-cdp.c	(working copy)
 <at>  <at>  -199,6 +199,10  <at>  <at> 
 		proto_tree_add_text(tlv_tree, tvb, offset + 4,
 			    length - 4, "Device ID: %s",
 			    tvb_format_stringzpad(tvb, offset + 4, length - 4));
+		if (check_col(pinfo->cinfo, COL_INFO))
(Continue reading)

Jaap Keuter | 23 Jun 23:00 2006
Picon
Picon

Re: [Patch] CDP dissector

Hi,

Please switch off 'Colorize packet list' and clear the display filter.
Your additions disappear as snow in the sun.....

That is because your changes only work when the dissector is called with
tree != NULL. If it is not (in the circumstances described above) no
additional COL_INFO will be there.

Thanx,
Jaap

On Fri, 23 Jun 2006, Stephen Fisher wrote:

>
> I have attached a patch for the CDP (Cisco Discovery Protocol) dissector
> for consideration.  Almost every time that I am looking at CDP frames,
> it is to determine two things: the device name and the port number.  I
> suspect that this is the case for others also.  You have to open the
> tree for CDP, and then open the right two branches.  This patch adds
> these two values to the Info column.
>
> Old info column:
>
>   Cisco Discovery Protocol
>
> New info column:
>
>   Cisco Discovery Protocol  Device ID: switch.domain.com  Port ID: 3/5
>
(Continue reading)

Bryant Eastham | 23 Jun 23:22 2006

Question about the 0.99.1pre1 Release

First, thank you Gerald for all your work in migrating from Ethereal to
Wireshark. Having dealt with name changes in the past, I feel your pain.

A slight nit about the 0.99.1pre1 release: is there a reason that there
is no subversion tag for that release? I am open to alternate processes,
but the way that I have my build machine set up I grab a tag, I then
build that tag, and finally I build my (internal) plugins against that
version. I have our engineers download that (tagged) release with the
knowledge that my plugins will work correctly. I also have a number of
automated tests that run against the version that I build (that should
be equivalent to the tagged release), and I do that just as an easier
way to get the executables than by running the (windows) installer.

This process breaks if I am forced to use trunk, because the version
that I would build against is not a downloadable release that my
engineers could use, and because of that the plugins that I build may
not work correctly against that (older) release.

I understand that the "pre1" release may have really been just that, a
prerelease, but at this point it is the *only* release of Wireshark that
I can tell people to download. I'm sure that the real 0.99.1 will be
handled differently (or at least I hope... ;-))

Long story short, do people have alternate ideas about how to build
plugins in an automated way? To be honest, it would be wonderful to have
a "plugin SDK" release as a download that included just the headers and
build libraries for a particular version, but I am aware of the
difficulties in doing that as well. I would then not have to build
Wireshark each night - a waste of time but the only way to ensure the
"right thing" short of caching the build results.
(Continue reading)

Stephen Fisher | 23 Jun 23:38 2006
Picon

Re: [Patch] CDP dissector

On Fri, Jun 23, 2006 at 11:00:49PM +0200, Jaap Keuter wrote:

> Please switch off 'Colorize packet list' and clear the display filter. 
> Your additions disappear as snow in the sun.....
> 
> That is because your changes only work when the dissector is called 
> with tree != NULL. If it is not (in the circumstances described above) 
> no additional COL_INFO will be there.

Thanks for your feedback.  To colorize packets or filter them, it has to 
look into the packet to see what is there so tree is set, otherwise it 
isn't.  Right?  I can change the code so that it looks into the packet 
for these fields if tree is set or not if others think it would be a 
useful feature.

Steve

Gmane