On Thu, Jun 07, 2001 at 09:48:39PM -0700, David Mitchell wrote:
> First, it seems that some access points produce beacon packets which have a
> tagged item with a length of zero. This triggers an infinite loop in the
> decoder when it tries to display the item.
The code in question has changed since 0.8.18 was released, and your
patch no longer applies as it was submitted - you might want to check
the latest code from the CVS tree, and see whether it still has that
problem.
> Second, the decoder is not consistant about it's display of MAC addresses. In
> parts, it uses %X and in others %02X. The %02X is probably preferrable, since
> it makes the columns line up.
The decoder wasn't handling MAC addresses correctly at all; it should've
just been using the "SET_ADDRESS()" macro to set the addresses, at least
for the packets where the address columns don't get tagged with an
address type. I've checked in a change to do that, and to set the raw
columns correctly (using "ether_to_str()" and "get_ether_name()") in
other cases.
> I've included a patch which fixes these. I kind of had to guess on the first,
> since I'm not very familiar with the ethereal code. I've never really poked
> around with it until tonight, when it started taking down my X server. I just
> forced the function to return a (false) length of 1 instead of 0. It's quite
> possible that this is really a bug in the calling function, but to be honest
> I didn't know what the calling function was! I can make the wiretap dump file
> available if anybody wants to see the actual packet. Other than the zero-
> length item, they aren't very interesting.
Yes, I'd like to see the dump file, to test the current version of the
code (and to test an 802.11 dissector somebody submitted for tcpdump as
well).
