Hi,
I have been using ethereal 0.8.8 on both a sparc solaris 2.6 machine and an
NT 4 workstation. I load a packet capture in libpcap format ( or any other
format ) then save it as Dos Sniffer format on both the Sun and the NT
machine, the file is saved then automatically reloaded however the result is
corrupt on the Sun but not on the NT w/s. The sun just displays the capture
times of the packets but not the actual packets. I have done a Hex compare
of the two files and have discovered that the Sun version has the packet
size set as zero whereas the NT file has the correct values for each packet.
I have looked at the source code of ngsniffer.c and after printing out the
values of frame2_rec.size I have located the problem at line 793 where the
capture length is assigned to the frame header.
ie. rec_hdr.size = pletohs(&phdr->caplen)
If I print out phdr->caplen as a long int it gives the correct value for the
frame size but after it has been assigned to rec_hdr.size and reduced from a
32bit int to 16bit int the value in rec_hdr.size is zero. I have tried
changing the pletohs macro with all the others which are defined but none
worked correctly. (they may appear to work correctly but if you try to read
the resulting dos sniffer file with the NT version of ethereal or netxray
the file is corrupt, having looked at the Hex dump the size value is there
but at the wrong offset.). I inserted my own macro (below) into the code to
replace the pletohs on line 793 and managed to get it to work on the Sun
system. I have not tested the code fix on the NT system although I think its
pretty unlikely to work.
#define albodge(p) ((guint16)\
((guint16)*((guint8 *)p+3)<<8 |
(guint16)*((guint8 *)p+2)>>8))
I'm not sure if this a big/little endian problem ( I couldn't work out where
the conversion takes place ) or if the problem occurs when the:
wth->phdr.caplen = size; assignment is made ( 16bit int assigned to a 32bit
int ). If this is where the problem is then the line above ( wth->phdr.len =
true_size ? true_size : size ) also does the same thing so may be suspect.
This isn't a problem which has just arisen, it was present in the last few
releases. Also I've noticed the old code sometimes works correctly with just
a few captured packets, don't know why though.
I'm sorry I can't come up with a complete fix but I hope someone will be
able to tidy it up.
Also, during trying to debug this I came across a typo at the end of wtap.h.
I put it right, it didn't help my problem but it may solve some others.
--> #ifndef plethol
#define pletohl(p) ((guint32)*((guint8 *)p+3)<<24| \
(guint32)*((guint8 *)p+2)<<16| \
(guint32)*((guint8 *)p+1)<<8| \
(guint32)*((guint8 *)p+0)<<0)
#endif
#endif /* __WTAP_H__ */
If I can understand this big/little endian and ntohs, ntoh macro stuff I
might have a go at writing a dissector :-).
Thanks to all for producing a great tool !
----
alanharrison@xxxxxxxx
