On Sun, Jan 18, 2004 at 05:08:15PM -0800, Budiyanto Fritz wrote:
> The problem is 4 bytes of padding is added when
> reading the Sniffer file (capture is v2). Can someone
> confirm if 4 bytes padding needed,
Yes, they are needed for some captures (either that, or it's an FCS).
For other captures, they're not.
The rules for whether the 4 bytes are present or not appear to be
similar to the rules for Ethernet and 802.11 Windows Sniffer captures -
if bytes 2 and 3 of the "hdr_2_x.xxx" field of the per-packet header are
both 0xff, there's 4 bytes of stuff at the end of the packet, which
might or might not be an FCS.
I've checked in a change to implement that - it works on your capture
and on the captures I have that include the 4 bytes of extra stuff. A
patch for that change is attached.
Index: wiretap/netxray.c
===================================================================
RCS file: /usr/local/cvsroot/ethereal/wiretap/netxray.c,v
retrieving revision 1.85
diff -c -r1.85 netxray.c
*** wiretap/netxray.c 5 Jan 2004 17:33:28 -0000 1.85
--- wiretap/netxray.c 19 Jan 2004 02:22:21 -0000
***************
*** 489,494 ****
--- 489,495 ----
case WTAP_ENCAP_ETHERNET:
case WTAP_ENCAP_IEEE_802_11_WITH_RADIO:
+ case WTAP_ENCAP_ISDN:
/*
* It appears that, in at least some version 2 Ethernet
* captures, for frames that have 0xff in hdr_2_x.xxx[2]
***************
*** 503,508 ****
--- 504,518 ----
* For now, we assume that to be true for 802.11 captures
* as well; it appears to be the case for at least one
* such capture.
+ *
+ * For ISDN captures, it appears, at least in some
+ * captures, to be similar, although I haven't yet
+ * checked whether it's a valid FCS.
+ *
+ * XXX - should we do this for all encapsulation types?
+ *
+ * XXX - is that actually a 2-byte little-endian 0x1234?
+ * What does that field signify?
*/
if (version_major == 2) {
if (hdr.xxb[13] == 0x34 && hdr.xxb[14] == 0x12)
***************
*** 851,862 ****
pseudo_header->isdn.channel = 0;
else if (pseudo_header->isdn.channel > 16)
pseudo_header->isdn.channel -= 1;
-
- /*
- * PRI captures appear to have 4 bytes of
- * stuff at the end - FCS, or padding?
- */
- padding = 4;
break;
case 2:
--- 861,866 ----
***************
*** 869,881 ****
pseudo_header->isdn.channel = 0;
else if (pseudo_header->isdn.channel > 24)
pseudo_header->isdn.channel -= 1;
/*
! * PRI captures appear to have 4 bytes of
! * stuff at the end - FCS, or padding?
*/
padding = 4;
- break;
}
break;
--- 873,901 ----
pseudo_header->isdn.channel = 0;
else if (pseudo_header->isdn.channel > 24)
pseudo_header->isdn.channel -= 1;
+ break;
+ }
+ /*
+ * It appears, at least with version 2 captures,
+ * that we have 4 bytes of stuff (which might be
+ * a valid FCS or might be junk) at the end of
+ * the packet if hdr->hdr_2_x.xxx[2] and
+ * hdr->hdr_2_x.xxx[3] are 0xff, and we don't if
+ * they don't.
+ *
+ * XXX - does the low-order bit of hdr->hdr_2_x.xxx[8]
+ * indicate a bad FCS, as is the case with
+ * Ethernet?
+ */
+ if (hdr->hdr_2_x.xxx[2] == 0xff &&
+ hdr->hdr_2_x.xxx[3] == 0xff) {
/*
! * FCS, or junk, at the end.
! * XXX - is it an FCS if "fcs_valid" is
! * true?
*/
padding = 4;
}
break;
