[Ulf Lamping <ulf.lamping@xxxxxx>]

Matev� Pusti�ek wrote:

> Hi!
>
> During the analysis of a larger capture set, I encountered several warnings
> and an error in tethereal (0.10.9-SVN-13086). There are files attached, that
> cause problems:
>  
Yes, it's a very good idea to attach small example captures, this makes 
debugging *a lot* easier :-)

> crash_00026_20050124150108.cap, 
>
> when accessed through:
> tethereal -r crash_00026_20050124150108.cap  -V
> Reports: 
> ** ERROR **: file tvbuff.c: line 583 (tvb_length_remaining): assertion
> failed: (tvb->initialized)
> aborting... Aborted
> (occasionaly i received a segmentation fault, too, but am not sure if it was
> for the same reason or not).
>  
Bug: Dissector wrote behind end of a fixed array, checked in a fix.

> crash_00001_20050124142515.cap
>
> when accessed through:
> tethereal -r crash_00001_20050124142515.cap tcp
> Reports a warning:
> ** (process:20887): WARNING **: Dissector bug, protocol DAAP, in packet
> 186405: "" - "" invalid length: -642766212 (p
> roto.c:2098)
>
>  
Bug: Dissector used a length value from a field in the data, but didn't 
checked if it contains a reasonable value, checked in a fix.

> crash_00010_20050124143724.cap
>
> when accessed through:
> tethereal -r crash_00010_20050124143724.cap tcp
> Reports a warning:
> ** (process:20928): WARNING **: Frame 154776: rtsp: unknown transport
> (This is probably protocol related issue and not ethereal problem)
>  
As the message notes, this is an unknown transport protocol 
"x-real-rdt/" for the rtsp dissector. First of all, I've added the 
protocol name to the output. However, I tend to uncomment the 
g_warning() calls causing this output. What do other's think?

> crash_00005_20050124143113-no2.cap 
>
> when accessed through:
> tethereal -r crash_00005_20050124143113-no2.cap -w tmp.cap "tcp"
> Reports:
> tethereal: XMLStub: Unable to open module libxml2.so
> tethereal: Diameter: Using static dictionary! (Unable to use XML)
> (this again is most likely problem of my installation/configuration, but do
> not know how to handle it).
>  
Well, as I'm using Win32, I don't use .so files at all. You might 
install the library/package libxml2 on your computer to resolve this. 
How you have to do this, will depend on your operating system.

And again to other's: should this message be removed?

> crash_00005_20050124143113.cap
>
> when accessed through:
> tethereal -r crash_00005_20050124143113.cap -w tmp.cap "tcp"
> Reports:
> ICQ: Unknown version (8420)
> (What exactly does it want to say, Unknown version of ICQ? Or some
> underlying protocol ).
>
>  
The field containing the ICQ version number (the first two bytes after 
the UDP part) contains 8420 (0x20e4). This seems to me like a 
missinterpreted packet (Ethereal thinks it is an ICQ packet but it 
isn't), or the packet is an ICQ packet and contains only garbage.

> Beside this I often encounter strage outputs (happens for other protocols
> than ssl, too) for -q -z io,phs tethereal option, e.g.:
>
>
>        ssl                              frames:35388 bytes:44488430
>          unreassembled                  frames:31933 bytes:43063232
>                                         frames:3741 bytes:904355
>          short                          frames:55 bytes:5389
>          unreassembled                  frames:389 bytes:434790
>                                         frames:348 bytes:106872
>                                         frames:123 bytes:49475
>                                         frames:66 bytes:29387
>                                         frames:54 bytes:25156
>                                         frames:31 bytes:14710
>                                         frames:20 bytes:9096
>                                         frames:17 bytes:8001
>                                         frames:13 bytes:7438
>                                         frames:10 bytes:6067
>                                         frames:7 bytes:2905
>                                         frames:7 bytes:2905
>                                         frames:5 bytes:2515
>                                         frames:5 bytes:2515
>                                         frames:5 bytes:2515
>                                         frames:5 bytes:2515
>                                         frames:5 bytes:2515
>                                           frames:5 bytes:2515
>                                             frames:4 bytes:2180
>                                               frames:4 bytes:2180
>                                                 frames:4 bytes:2180
>                                                   frames:4 bytes:2180
>                                                     frames:3 bytes:1904
>                                                       frames:3 bytes:1904
>                                                         frames:3 bytes:1904
>                                                           frames:3
> bytes:1904
>                                                             frames:3
> bytes:1904
>                                                               frames:3
> bytes:1904
>                                                                 frames:3
> bytes:1904
>                                                                   frames:3
> bytes:1904
>
> frames:3 bytes:1904
>
> frames:3 bytes:1904
>
> frames:3 bytes:1904
>
> frames:3 bytes:1904
>   
> I have searched the ethereal list and have been through the
> protocol-over-protocol encapsulation, but do not think this output is
> related to that matter.
>
>  
That seems to be output from the "Protocol Hierarchy Statistics" 
tapprotohierstat.c line 149, however I don't know tethereal well, so I 
can't give you good advise here.


Hope this was helpful to you,

Regards, ULFL