From 0d69b9aef11872f689e7ebd8c242fbf146589d9d Mon Sep 17 00:00:00 2001 From: Guy Harris Date: Wed, 3 May 2017 19:55:39 -0700 Subject: Update comments. There's only a 17-byte PLCP header with the Series III hardware. Change-Id: Ice8dfbbc5daa0578ee4eb6588fc8a8b597806d0d Reviewed-on: https://code.wireshark.org/review/21487 Reviewed-by: Guy Harris --- wiretap/vwr.c | 9 --------- 1 file changed, 9 deletions(-) (limited to 'wiretap') diff --git a/wiretap/vwr.c b/wiretap/vwr.c index 9661e48886..ef86809051 100644 --- a/wiretap/vwr.c +++ b/wiretap/vwr.c @@ -170,8 +170,6 @@ * 2 octets - HT len * 2 octets - info * 2 octets - errors - * - * XXX - last 4 octets? PLCP? 17 bytes in some cases? */ /* Size of the VeriWave WLAN metadata header */ @@ -1224,13 +1222,6 @@ static gboolean vwr_read_s1_W_rec(vwr_t *vwr, struct wtap_pkthdr *phdr, /* * Fill up the per-packet header. * - * We also zero out 16 bytes PLCP header and 1 byte of L1P for user - * position. - * - * XXX - for S1, do we even have that? The current VeriWave dissector - * just blindly assumes there's a 17-byte blob before the 802.11 - * header, which is why we fill in those extra zero bytes. - * * We include the length of the metadata headers in the packet lengths. * * The maximum value of actual_octets is 65535, which, even after -- cgit v1.2.1