Greetings,
I was playing around with some 802.11 dump files, and noticed a couple of
issues. One is somewhat major, the other is cosmetic.
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.
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.
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.
I assume this is the right place to submit patches. Could somebody vet these
and check them in? Thanks in advance,
-David Mitchell
--- packet-ieee80211.c Mon Apr 23 10:57:55 2001
+++ packet-ieee80211.c.new Thu Jun 7 21:26:30 2001
@@ -553,9 +553,13 @@
tag_no);
proto_tree_add_uint (tree, tag_length, tvb, offset + 1, 1, tag_len);
-
- proto_tree_add_string (tree, tag_interpretation, tvb, offset + 2,
+ if (tag_len > 0) {
+ proto_tree_add_string (tree, tag_interpretation, tvb, offset + 2,
tag_len, "Not interpreted");
+ } else {
+ return 1;
+ };
+
return (int) tag_len;
}
@@ -808,7 +812,7 @@
if (check_col (pinfo->fd, COL_DEF_SRC))
- col_add_fstr (pinfo->fd, COL_DEF_SRC, "%X:%X:%X:%X:%X:%X",
+ col_add_fstr (pinfo->fd, COL_DEF_SRC, "%02X:%02X:%02X:%02X:%02X:%02X",
src[0], src[1], src[2], src[3], src[4], src[5]);
if (check_col (pinfo->fd, COL_DEF_DST))