diff options
author | Guy Harris <guy@alum.mit.edu> | 2004-01-19 02:23:18 +0000 |
---|---|---|
committer | Guy Harris <guy@alum.mit.edu> | 2004-01-19 02:23:18 +0000 |
commit | c19c7677fb6d672bf07d0988b37b7775472de590 (patch) | |
tree | 2613e2778ddc0935e1ecb7ae152e7ef772bdf7a3 /wiretap | |
parent | 7909c22d494b246bb3e7e51a194ee5f3acd46450 (diff) |
It appears that, for ISDN captures, the rules for whether there's 4
bytes of extra stuff at the end of the packet or not are the same as for
Ethernet and 802.11.
svn path=/trunk/; revision=9728
Diffstat (limited to 'wiretap')
-rw-r--r-- | wiretap/netxray.c | 40 |
1 files changed, 30 insertions, 10 deletions
diff --git a/wiretap/netxray.c b/wiretap/netxray.c index abda330b0f..c604fd223c 100644 --- a/wiretap/netxray.c +++ b/wiretap/netxray.c @@ -1,6 +1,6 @@ /* netxray.c * - * $Id: netxray.c,v 1.85 2004/01/05 17:33:28 ulfl Exp $ + * $Id: netxray.c,v 1.86 2004/01/19 02:23:18 guy Exp $ * * Wiretap Library * Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu> @@ -489,6 +489,7 @@ int netxray_open(wtap *wth, int *err) 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,6 +504,15 @@ int netxray_open(wtap *wth, int *err) * 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,12 +861,6 @@ netxray_set_pseudo_header(wtap *wth, const guint8 *pd, int len, 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: @@ -869,13 +873,29 @@ netxray_set_pseudo_header(wtap *wth, const guint8 *pd, int len, 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) { /* - * PRI captures appear to have 4 bytes of - * stuff at the end - FCS, or padding? + * FCS, or junk, at the end. + * XXX - is it an FCS if "fcs_valid" is + * true? */ padding = 4; - break; } break; |