1998-09-16 02:39:15 +00:00
|
|
|
/* packet-ipx.c
|
|
|
|
* Routines for NetWare's IPX
|
|
|
|
* Gilbert Ramirez <gram@verdict.uthscsa.edu>
|
|
|
|
*
|
1999-11-30 09:01:55 +00:00
|
|
|
* $Id: packet-ipx.c,v 1.38 1999/11/30 09:01:55 guy Exp $
|
1998-09-16 03:22:19 +00:00
|
|
|
*
|
1998-09-16 02:39:15 +00:00
|
|
|
* Ethereal - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@unicom.net>
|
|
|
|
* Copyright 1998 Gerald Combs
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include "config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef HAVE_SYS_TYPES_H
|
|
|
|
# include <sys/types.h>
|
|
|
|
#endif
|
|
|
|
|
1999-03-23 03:14:46 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <glib.h>
|
1998-09-16 02:39:15 +00:00
|
|
|
#include "packet.h"
|
1998-09-23 05:25:12 +00:00
|
|
|
#include "packet-ipx.h"
|
1999-03-20 04:38:57 +00:00
|
|
|
#include "packet-ncp.h"
|
1999-11-20 05:35:15 +00:00
|
|
|
#include "resolv.h"
|
1998-09-16 02:39:15 +00:00
|
|
|
|
|
|
|
/* The information in this module (IPX, SPX, NCP) comes from:
|
|
|
|
NetWare LAN Analysis, Second Edition
|
|
|
|
Laura A. Chappell and Dan E. Hakes
|
|
|
|
(c) 1994 Novell, Inc.
|
|
|
|
Novell Press, San Jose.
|
|
|
|
ISBN: 0-7821-1362-1
|
1998-09-23 05:25:12 +00:00
|
|
|
|
|
|
|
And from the ncpfs source code by Volker Lendecke
|
|
|
|
|
1998-09-16 02:39:15 +00:00
|
|
|
*/
|
1999-07-17 04:19:15 +00:00
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
static int proto_ipx = -1;
|
|
|
|
static int hf_ipx_checksum = -1;
|
|
|
|
static int hf_ipx_len = -1;
|
|
|
|
static int hf_ipx_hops = -1;
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
static int hf_ipx_packet_type = -1;
|
|
|
|
static int hf_ipx_dnet = -1;
|
1999-07-29 05:47:07 +00:00
|
|
|
static int hf_ipx_dnode = -1;
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
static int hf_ipx_dsocket = -1;
|
|
|
|
static int hf_ipx_snet = -1;
|
1999-07-29 05:47:07 +00:00
|
|
|
static int hf_ipx_snode = -1;
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
static int hf_ipx_ssocket = -1;
|
1999-07-20 02:56:44 +00:00
|
|
|
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint ett_ipx = -1;
|
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
static int proto_spx = -1;
|
1999-10-17 09:23:43 +00:00
|
|
|
static int hf_spx_connection_control = -1;
|
|
|
|
static int hf_spx_datastream_type = -1;
|
|
|
|
static int hf_spx_src_id = -1;
|
|
|
|
static int hf_spx_dst_id = -1;
|
|
|
|
static int hf_spx_seq_nr = -1;
|
|
|
|
static int hf_spx_ack_nr = -1;
|
|
|
|
static int hf_spx_all_nr = -1;
|
|
|
|
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint ett_spx = -1;
|
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
static int proto_ipxrip = -1;
|
1999-10-17 09:23:43 +00:00
|
|
|
static int hf_ipxrip_request = -1;
|
|
|
|
static int hf_ipxrip_response = -1;
|
|
|
|
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint ett_ipxrip = -1;
|
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
static int proto_sap = -1;
|
1999-10-17 09:23:43 +00:00
|
|
|
static int hf_sap_request = -1;
|
|
|
|
static int hf_sap_response = -1;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint ett_ipxsap = -1;
|
|
|
|
static gint ett_ipxsap_server = -1;
|
|
|
|
|
1998-09-16 02:39:15 +00:00
|
|
|
static void
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_spx(const u_char *pd, int offset, frame_data *fd, proto_tree *tree);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-09-23 05:25:12 +00:00
|
|
|
static void
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_ipxrip(const u_char *pd, int offset, frame_data *fd, proto_tree *tree);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-09-24 04:22:08 +00:00
|
|
|
static void
|
1999-11-17 02:17:29 +00:00
|
|
|
dissect_ipxsap(const u_char *pd, int offset, frame_data *fd, proto_tree *tree);
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
|
|
|
|
typedef void (dissect_func_t)(const u_char *, int, frame_data *, proto_tree *);
|
1998-09-24 04:22:08 +00:00
|
|
|
|
1998-09-16 02:39:15 +00:00
|
|
|
struct port_info {
|
1998-09-23 05:25:12 +00:00
|
|
|
guint16 port;
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_func_t *func;
|
1998-09-16 02:39:15 +00:00
|
|
|
char *text;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct conn_info {
|
1998-09-23 05:25:12 +00:00
|
|
|
guint8 ctrl;
|
1998-09-16 02:39:15 +00:00
|
|
|
char *text;
|
|
|
|
};
|
|
|
|
|
1998-09-24 04:22:08 +00:00
|
|
|
struct server_info {
|
|
|
|
guint16 type;
|
|
|
|
char *text;
|
|
|
|
};
|
|
|
|
|
1998-09-16 02:39:15 +00:00
|
|
|
/* ================================================================= */
|
|
|
|
/* IPX */
|
|
|
|
/* ================================================================= */
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
|
|
|
|
#define IPX_SOCKET_NCP 0x0451
|
|
|
|
#define IPX_SOCKET_SAP 0x0452
|
|
|
|
#define IPX_SOCKET_IPXRIP 0x0453
|
|
|
|
#define IPX_SOCKET_NETBIOS 0x0455
|
|
|
|
#define IPX_SOCKET_DIAGNOSTIC 0x0456
|
|
|
|
#define IPX_SOCKET_SERIALIZATION 0x0457
|
|
|
|
#define IPX_SOCKET_NWLINK_SMB_NAMEQUERY 0x0551
|
|
|
|
#define IPX_SOCKET_NWLINK_SMB_DGRAM 0x0553
|
1999-11-15 21:33:57 +00:00
|
|
|
#define IPX_SOCKET_NWLINK_SMB_BROWSE 0x0555 /* ? not sure on this
|
|
|
|
but I guessed based on the content of the packet I saw */
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
#define IPX_SOCKET_ATTACHMATE_GW 0x055d
|
|
|
|
#define IPX_SOCKET_IPX_MESSAGE 0x4001
|
1999-11-15 21:33:57 +00:00
|
|
|
#define IPX_SOCKET_ADSM 0x8522 /* www.tivoli.com */
|
|
|
|
#define IPX_SOCKET_SNMP_AGENT 0x900F /* RFC 1906 */
|
|
|
|
#define IPX_SOCKET_SNMP_SINK 0x9010 /* RFC 1906 */
|
|
|
|
#define IPX_SOCKET_TCP_TUNNEL 0x9091 /* RFC 1791 */
|
|
|
|
#define IPX_SOCKET_UDP_TUNNEL 0x9092 /* RFC 1791 */
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
|
1998-09-23 05:25:12 +00:00
|
|
|
static struct port_info ports[] = {
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
{ IPX_SOCKET_NCP, dissect_ncp,
|
|
|
|
"NCP" },
|
1999-11-17 02:17:29 +00:00
|
|
|
{ IPX_SOCKET_SAP, dissect_ipxsap,
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
"SAP" },
|
|
|
|
{ IPX_SOCKET_IPXRIP, dissect_ipxrip,
|
|
|
|
"RIP" },
|
|
|
|
{ IPX_SOCKET_NETBIOS, NULL,
|
|
|
|
"NetBIOS" },
|
|
|
|
{ IPX_SOCKET_DIAGNOSTIC, NULL,
|
|
|
|
"Diagnostic" },
|
|
|
|
{ IPX_SOCKET_SERIALIZATION, NULL,
|
|
|
|
"Serialization" },
|
|
|
|
{ IPX_SOCKET_NWLINK_SMB_NAMEQUERY, NULL,
|
|
|
|
"NWLink SMB Name Query" },
|
|
|
|
{ IPX_SOCKET_NWLINK_SMB_DGRAM, dissect_nwlink_dg,
|
|
|
|
"NWLink SMB Datagram" },
|
1999-11-15 21:33:57 +00:00
|
|
|
{ IPX_SOCKET_NWLINK_SMB_BROWSE, NULL,
|
|
|
|
"NWLink SMB Browse" },
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
{ IPX_SOCKET_ATTACHMATE_GW, NULL,
|
|
|
|
"Attachmate Gateway" },
|
|
|
|
{ IPX_SOCKET_IPX_MESSAGE, NULL,
|
|
|
|
"IPX Message" },
|
1999-11-15 21:33:57 +00:00
|
|
|
{ IPX_SOCKET_SNMP_AGENT, NULL, "SNMP Agent" },
|
|
|
|
{ IPX_SOCKET_SNMP_SINK, NULL, "SNMP Sink" },
|
|
|
|
{ IPX_SOCKET_UDP_TUNNEL, NULL, "UDP Tunnel" },
|
|
|
|
{ IPX_SOCKET_TCP_TUNNEL, NULL, "TCP Tunnel" },
|
|
|
|
{ IPX_SOCKET_TCP_TUNNEL, NULL, "TCP Tunnel" },
|
|
|
|
{ IPX_SOCKET_ADSM, NULL, "ADSM" },
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
{ 0x0000, NULL,
|
|
|
|
NULL }
|
1998-09-23 05:25:12 +00:00
|
|
|
};
|
|
|
|
|
1998-09-16 02:39:15 +00:00
|
|
|
static char*
|
1998-09-23 05:25:12 +00:00
|
|
|
port_text(guint16 port) {
|
1998-09-16 02:39:15 +00:00
|
|
|
int i=0;
|
|
|
|
|
|
|
|
while (ports[i].text != NULL) {
|
|
|
|
if (ports[i].port == port) {
|
|
|
|
return ports[i].text;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
return "Unknown";
|
|
|
|
}
|
|
|
|
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
static dissect_func_t*
|
1998-09-23 05:25:12 +00:00
|
|
|
port_func(guint16 port) {
|
|
|
|
int i=0;
|
|
|
|
|
|
|
|
while (ports[i].text != NULL) {
|
|
|
|
if (ports[i].port == port) {
|
|
|
|
return ports[i].func;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
1998-12-31 20:36:43 +00:00
|
|
|
return NULL;
|
1998-09-23 05:25:12 +00:00
|
|
|
}
|
|
|
|
|
1999-11-30 09:01:55 +00:00
|
|
|
/*
|
|
|
|
* From:
|
|
|
|
*
|
|
|
|
* http://alr.base2co.com:457/netguide/dipxD.ipx_packet_struct.html
|
|
|
|
*
|
|
|
|
* which is part of SCO's "Network Programmer's Guide and Reference".
|
|
|
|
*
|
|
|
|
* It calls type 20 "NetBIOS name packet". Microsoft Network Monitor
|
|
|
|
* calls it "WAN Broadcast"; it's also used for SMB browser announcements,
|
|
|
|
* i.e. NetBIOS (broadcast) datagrams.
|
|
|
|
*/
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
#define IPX_PACKET_TYPE_IPX 0
|
1999-11-30 08:45:39 +00:00
|
|
|
#define IPX_PACKET_TYPE_RIP 1
|
1999-11-30 09:01:55 +00:00
|
|
|
#define IPX_PACKET_TYPE_ECHO 2
|
|
|
|
#define IPX_PACKET_TYPE_ERROR 3
|
1999-11-30 08:45:39 +00:00
|
|
|
#define IPX_PACKET_TYPE_PEP 4
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
#define IPX_PACKET_TYPE_SPX 5
|
|
|
|
#define IPX_PACKET_TYPE_NCP 17
|
1999-11-30 08:45:39 +00:00
|
|
|
#define IPX_PACKET_TYPE_WANBCAST 20 /* propagated NetBIOS packet? */
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
static const value_string ipx_packet_type_vals[] = {
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
{ IPX_PACKET_TYPE_IPX, "IPX" },
|
1999-11-30 08:45:39 +00:00
|
|
|
{ IPX_PACKET_TYPE_RIP, "RIP" },
|
1999-11-30 09:01:55 +00:00
|
|
|
{ IPX_PACKET_TYPE_ECHO, "Echo" },
|
|
|
|
{ IPX_PACKET_TYPE_ERROR, "Error" },
|
|
|
|
{ IPX_PACKET_TYPE_PEP, "PEP" }, /* Packet Exchange Packet */
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
{ IPX_PACKET_TYPE_SPX, "SPX" },
|
|
|
|
{ 16, "Experimental Protocol" },
|
|
|
|
{ IPX_PACKET_TYPE_NCP, "NCP" },
|
|
|
|
{ 18, "Experimental Protocol" },
|
|
|
|
{ 19, "Experimental Protocol" },
|
|
|
|
{ IPX_PACKET_TYPE_WANBCAST, "NetBIOS Broadcast" },
|
|
|
|
{ 21, "Experimental Protocol" },
|
|
|
|
{ 22, "Experimental Protocol" },
|
|
|
|
{ 23, "Experimental Protocol" },
|
|
|
|
{ 24, "Experimental Protocol" },
|
|
|
|
{ 25, "Experimental Protocol" },
|
|
|
|
{ 26, "Experimental Protocol" },
|
|
|
|
{ 27, "Experimental Protocol" },
|
|
|
|
{ 28, "Experimental Protocol" },
|
|
|
|
{ 29, "Experimental Protocol" },
|
|
|
|
{ 30, "Experimental Protocol" },
|
|
|
|
{ 31, "Experimental Protocol" },
|
|
|
|
{ 0, NULL }
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
};
|
1998-09-16 02:39:15 +00:00
|
|
|
|
|
|
|
gchar*
|
1998-10-14 04:09:15 +00:00
|
|
|
ipxnet_to_string(const guint8 *ad)
|
1998-09-16 02:39:15 +00:00
|
|
|
{
|
1999-11-22 06:03:46 +00:00
|
|
|
guint32 addr = pntohl(ad);
|
|
|
|
return ipxnet_to_str_punct(addr, ' ');
|
1998-09-16 02:39:15 +00:00
|
|
|
}
|
|
|
|
|
1999-11-20 05:35:15 +00:00
|
|
|
/* We use a different representation of hardware addresses
|
|
|
|
* than ether_to_str(); we don't put punctuation between the hex
|
|
|
|
* digits.
|
|
|
|
*/
|
|
|
|
|
1999-03-05 06:09:39 +00:00
|
|
|
gchar*
|
|
|
|
ipx_addr_to_str(guint32 net, const guint8 *ad)
|
|
|
|
{
|
1999-11-20 05:35:15 +00:00
|
|
|
static gchar str[3][8+1+MAXNAMELEN+1]; /* 8 digits, 1 period, NAME, 1 null */
|
1999-03-05 06:09:39 +00:00
|
|
|
static gchar *cur;
|
1999-11-20 05:35:15 +00:00
|
|
|
char *name;
|
1999-03-05 06:09:39 +00:00
|
|
|
|
|
|
|
if (cur == &str[0][0]) {
|
|
|
|
cur = &str[1][0];
|
|
|
|
} else if (cur == &str[1][0]) {
|
|
|
|
cur = &str[2][0];
|
|
|
|
} else {
|
|
|
|
cur = &str[0][0];
|
|
|
|
}
|
|
|
|
|
1999-11-20 05:35:15 +00:00
|
|
|
name = get_ether_name_if_known(ad);
|
|
|
|
|
|
|
|
if (name) {
|
1999-11-21 16:32:23 +00:00
|
|
|
sprintf(cur, "%s.%s", get_ipxnet_name(net), name);
|
1999-11-20 05:35:15 +00:00
|
|
|
}
|
|
|
|
else {
|
1999-11-21 16:32:23 +00:00
|
|
|
sprintf(cur, "%s.%s", get_ipxnet_name(net), ether_to_str_punct(ad, '\0'));
|
1999-11-20 05:35:15 +00:00
|
|
|
}
|
1999-03-05 06:09:39 +00:00
|
|
|
return cur;
|
|
|
|
}
|
|
|
|
|
1999-11-22 06:03:46 +00:00
|
|
|
gchar *
|
|
|
|
ipxnet_to_str_punct(const guint32 ad, char punct) {
|
|
|
|
static gchar str[3][12];
|
|
|
|
static gchar *cur;
|
|
|
|
gchar *p;
|
|
|
|
int i;
|
|
|
|
guint32 octet;
|
|
|
|
static const gchar hex_digits[16] = "0123456789ABCDEF";
|
|
|
|
static const guint32 octet_mask[4] =
|
|
|
|
{ 0xff000000 , 0x00ff0000, 0x0000ff00, 0x000000ff };
|
|
|
|
|
|
|
|
if (cur == &str[0][0]) {
|
|
|
|
cur = &str[1][0];
|
|
|
|
} else if (cur == &str[1][0]) {
|
|
|
|
cur = &str[2][0];
|
|
|
|
} else {
|
|
|
|
cur = &str[0][0];
|
|
|
|
}
|
|
|
|
p = &cur[12];
|
|
|
|
*--p = '\0';
|
|
|
|
i = 3;
|
|
|
|
for (;;) {
|
|
|
|
octet = (ad & octet_mask[i]) >> ((3 - i) * 8);
|
|
|
|
*--p = hex_digits[octet&0xF];
|
|
|
|
octet >>= 4;
|
|
|
|
*--p = hex_digits[octet&0xF];
|
|
|
|
if (i == 0)
|
|
|
|
break;
|
|
|
|
if (punct)
|
|
|
|
*--p = punct;
|
|
|
|
i--;
|
|
|
|
}
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
1998-09-16 02:39:15 +00:00
|
|
|
void
|
1999-03-23 03:14:46 +00:00
|
|
|
dissect_ipx(const u_char *pd, int offset, frame_data *fd, proto_tree *tree) {
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-03-23 03:14:46 +00:00
|
|
|
proto_tree *ipx_tree;
|
|
|
|
proto_item *ti;
|
1999-03-20 04:38:57 +00:00
|
|
|
guint8 ipx_type, ipx_hops;
|
|
|
|
guint16 ipx_checksum, ipx_length;
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
int len;
|
1999-03-20 04:38:57 +00:00
|
|
|
guint8 *ipx_snode, *ipx_dnode, *ipx_snet, *ipx_dnet;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-03-20 04:38:57 +00:00
|
|
|
guint16 ipx_dsocket, ipx_ssocket;
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_func_t *dissect;
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
guint32 ipx_dnet_val, ipx_snet_val;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-11-17 04:29:13 +00:00
|
|
|
/* Calculate here for use in pinfo and in tree */
|
1999-03-20 04:38:57 +00:00
|
|
|
ipx_dnet = (guint8*)&pd[offset+6];
|
|
|
|
ipx_snet = (guint8*)&pd[offset+18];
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
ipx_dnet_val = pntohl(ipx_dnet);
|
|
|
|
ipx_snet_val = pntohl(ipx_snet);
|
1999-03-20 04:38:57 +00:00
|
|
|
ipx_dsocket = pntohs(&pd[offset+16]);
|
|
|
|
ipx_ssocket = pntohs(&pd[offset+28]);
|
|
|
|
ipx_dnode = (guint8*)&pd[offset+10];
|
|
|
|
ipx_snode = (guint8*)&pd[offset+22];
|
|
|
|
ipx_type = pd[offset+5];
|
1999-05-10 20:51:36 +00:00
|
|
|
ipx_length = pntohs(&pd[offset+2]);
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
|
|
|
|
/* Length of IPX datagram plus headers above it. */
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
len = ipx_length + offset;
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
|
|
|
|
/* Set the payload and captured-payload lengths to the minima of
|
|
|
|
(the IPX length plus the length of the headers above it) and
|
|
|
|
the frame lengths. */
|
|
|
|
if (pi.len > len)
|
|
|
|
pi.len = len;
|
|
|
|
if (pi.captured_len > len)
|
|
|
|
pi.captured_len = len;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
SET_ADDRESS(&pi.net_src, AT_IPX, 10, &pd[offset+18]);
|
|
|
|
SET_ADDRESS(&pi.src, AT_IPX, 10, &pd[offset+18]);
|
|
|
|
SET_ADDRESS(&pi.net_dst, AT_IPX, 10, &pd[offset+6]);
|
|
|
|
SET_ADDRESS(&pi.dst, AT_IPX, 10, &pd[offset+6]);
|
1999-03-20 04:38:57 +00:00
|
|
|
|
1998-11-17 04:29:13 +00:00
|
|
|
if (check_col(fd, COL_PROTOCOL))
|
|
|
|
col_add_str(fd, COL_PROTOCOL, "IPX");
|
|
|
|
if (check_col(fd, COL_INFO))
|
1999-03-20 04:38:57 +00:00
|
|
|
col_add_fstr(fd, COL_INFO, "%s (0x%04X)", port_text(ipx_dsocket),
|
|
|
|
ipx_dsocket);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
|
|
|
if (tree) {
|
1999-03-20 04:38:57 +00:00
|
|
|
ipx_checksum = pntohs(&pd[offset]);
|
|
|
|
ipx_hops = pd[offset+4];
|
|
|
|
|
1999-07-17 04:19:15 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_ipx, offset, 30, NULL);
|
1999-11-16 11:44:20 +00:00
|
|
|
ipx_tree = proto_item_add_subtree(ti, ett_ipx);
|
1999-10-12 06:21:15 +00:00
|
|
|
proto_tree_add_item(ipx_tree, hf_ipx_checksum, offset, 2, ipx_checksum);
|
1999-07-20 02:56:44 +00:00
|
|
|
proto_tree_add_item_format(ipx_tree, hf_ipx_len, offset+2, 2, ipx_length,
|
|
|
|
"Length: %d bytes", ipx_length);
|
|
|
|
proto_tree_add_item_format(ipx_tree, hf_ipx_hops, offset+4, 1, ipx_hops,
|
|
|
|
"Transport Control: %d hops", ipx_hops);
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
proto_tree_add_item(ipx_tree, hf_ipx_packet_type, offset+5, 1, ipx_type);
|
|
|
|
proto_tree_add_item(ipx_tree, hf_ipx_dnet, offset+6, 4, ipx_dnet_val);
|
1999-07-20 02:56:44 +00:00
|
|
|
proto_tree_add_item(ipx_tree, hf_ipx_dnode, offset+10, 6, ipx_dnode);
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
proto_tree_add_item_format(ipx_tree, hf_ipx_dsocket, offset+16, 2,
|
|
|
|
ipx_dsocket, "Destination Socket: %s (0x%04X)",
|
|
|
|
port_text(ipx_dsocket), ipx_dsocket);
|
|
|
|
proto_tree_add_item(ipx_tree, hf_ipx_snet, offset+18, 4, ipx_snet_val);
|
1999-07-20 02:56:44 +00:00
|
|
|
proto_tree_add_item(ipx_tree, hf_ipx_snode, offset+22, 6, ipx_snode);
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
proto_tree_add_item_format(ipx_tree, hf_ipx_ssocket, offset+28, 2,
|
|
|
|
ipx_ssocket, "Source Socket: %s (0x%04X)", port_text(ipx_ssocket),
|
|
|
|
ipx_ssocket);
|
1998-09-16 02:39:15 +00:00
|
|
|
}
|
|
|
|
offset += 30;
|
|
|
|
|
|
|
|
switch (ipx_type) {
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
case IPX_PACKET_TYPE_SPX:
|
|
|
|
dissect_spx(pd, offset, fd, tree);
|
1998-09-16 02:39:15 +00:00
|
|
|
break;
|
1998-09-23 05:25:12 +00:00
|
|
|
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
case IPX_PACKET_TYPE_NCP:
|
1999-07-07 22:52:57 +00:00
|
|
|
/* Is the destination node 00:00:00:00:00:01 ? */
|
1999-03-20 04:38:57 +00:00
|
|
|
if (pntohl(ipx_dnode) == 0 && pntohs(ipx_dnode + 4) == 1)
|
|
|
|
nw_server_address = pntohl(ipx_dnet);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
|
|
|
/* Is the source node 00:00:00:00:00:01 ? */
|
1999-03-20 04:38:57 +00:00
|
|
|
else if (pntohl(ipx_snode) == 0 && pntohs(ipx_snode + 4) == 1)
|
|
|
|
nw_server_address = pntohl(ipx_snet);
|
|
|
|
else
|
|
|
|
nw_server_address = 0;
|
|
|
|
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_ncp(pd, offset, fd, tree);
|
1998-09-16 02:39:15 +00:00
|
|
|
break;
|
1998-09-23 05:25:12 +00:00
|
|
|
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
case IPX_PACKET_TYPE_WANBCAST:
|
1999-11-30 08:45:39 +00:00
|
|
|
case IPX_PACKET_TYPE_PEP:
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
if (ipx_dsocket == IPX_SOCKET_NETBIOS) {
|
|
|
|
dissect_nbipx(pd, offset, fd, tree);
|
1998-10-14 05:18:32 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* else fall through */
|
1998-09-23 05:25:12 +00:00
|
|
|
|
1998-09-24 04:22:08 +00:00
|
|
|
case 0: /* IPX, fall through to default */
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
/* XXX - should type 0's be dissected as NBIPX
|
|
|
|
if they're aimed at the NetBIOS socket? */
|
1998-09-16 02:39:15 +00:00
|
|
|
default:
|
1999-03-20 04:38:57 +00:00
|
|
|
dissect = port_func(ipx_dsocket);
|
1998-09-23 05:25:12 +00:00
|
|
|
if (dissect) {
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect(pd, offset, fd, tree);
|
1998-09-23 05:25:12 +00:00
|
|
|
}
|
|
|
|
else {
|
1999-03-20 04:38:57 +00:00
|
|
|
dissect = port_func(ipx_ssocket);
|
1998-12-31 20:36:43 +00:00
|
|
|
if (dissect) {
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect(pd, offset, fd, tree);
|
1998-12-31 20:36:43 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
dissect_data(pd, offset, fd, tree);
|
|
|
|
}
|
1998-09-23 05:25:12 +00:00
|
|
|
}
|
1998-09-16 02:39:15 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* ================================================================= */
|
|
|
|
/* SPX */
|
|
|
|
/* ================================================================= */
|
|
|
|
static char*
|
|
|
|
spx_conn_ctrl(u_char ctrl)
|
|
|
|
{
|
|
|
|
int i=0;
|
|
|
|
|
|
|
|
static struct conn_info conns[] = {
|
|
|
|
{ 0x10, "End-of-Message" },
|
|
|
|
{ 0x20, "Attention" },
|
|
|
|
{ 0x40, "Acknowledgment Required"},
|
1999-10-17 09:23:43 +00:00
|
|
|
{ 0x80, "System Packet"},
|
|
|
|
{ 0x00, NULL }
|
1998-09-16 02:39:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
while (conns[i].text != NULL) {
|
|
|
|
if (conns[i].ctrl == ctrl) {
|
|
|
|
return conns[i].text;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
return "Unknown";
|
|
|
|
}
|
|
|
|
|
|
|
|
static char*
|
1999-03-05 06:09:39 +00:00
|
|
|
spx_datastream(u_char type)
|
1998-09-16 02:39:15 +00:00
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case 0xfe:
|
|
|
|
return "End-of-Connection";
|
|
|
|
case 0xff:
|
|
|
|
return "End-of-Connection Acknowledgment";
|
|
|
|
default:
|
|
|
|
return "Client-Defined";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_spx(const u_char *pd, int offset, frame_data *fd, proto_tree *tree) {
|
1999-03-23 03:14:46 +00:00
|
|
|
proto_tree *spx_tree;
|
|
|
|
proto_item *ti;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-11-17 04:29:13 +00:00
|
|
|
if (check_col(fd, COL_PROTOCOL))
|
|
|
|
col_add_str(fd, COL_PROTOCOL, "SPX");
|
|
|
|
if (check_col(fd, COL_INFO))
|
|
|
|
col_add_str(fd, COL_INFO, "SPX");
|
1998-09-16 02:39:15 +00:00
|
|
|
|
|
|
|
if (tree) {
|
1999-07-17 04:19:15 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_spx, offset, 12, NULL);
|
1999-11-16 11:44:20 +00:00
|
|
|
spx_tree = proto_item_add_subtree(ti, ett_spx);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item_format(spx_tree, hf_spx_connection_control,
|
|
|
|
offset, 1,
|
|
|
|
pd[offset],
|
|
|
|
"Connection Control: %s (0x%02X)",
|
|
|
|
spx_conn_ctrl(pd[offset]),
|
|
|
|
pd[offset]);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item_format(spx_tree, hf_spx_datastream_type,
|
|
|
|
offset+1, 1,
|
|
|
|
pd[offset+1],
|
|
|
|
"Datastream Type: %s (0x%02X)",
|
|
|
|
spx_datastream(pd[offset+1]),
|
|
|
|
pd[offset+1]);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item(spx_tree, hf_spx_src_id,
|
|
|
|
offset+2, 2,
|
|
|
|
pntohs( &pd[offset+2] ));
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item(spx_tree, hf_spx_dst_id,
|
|
|
|
offset+4, 2,
|
|
|
|
pntohs( &pd[offset+4] ));
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item(spx_tree, hf_spx_seq_nr,
|
|
|
|
offset+6, 2,
|
|
|
|
pntohs( &pd[offset+6] ) );
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item(spx_tree, hf_spx_ack_nr,
|
|
|
|
offset+8, 2,
|
|
|
|
pntohs( &pd[offset+8] ) );
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_tree_add_item(spx_tree, hf_spx_all_nr,
|
|
|
|
offset+10, 2,
|
|
|
|
pntohs( &pd[offset+10] ) );
|
1998-09-16 02:39:15 +00:00
|
|
|
|
|
|
|
offset += 12;
|
|
|
|
dissect_data(pd, offset, fd, tree);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ================================================================= */
|
1998-09-23 05:25:12 +00:00
|
|
|
/* IPX RIP */
|
1998-09-16 02:39:15 +00:00
|
|
|
/* ================================================================= */
|
1998-09-23 05:25:12 +00:00
|
|
|
static void
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
dissect_ipxrip(const u_char *pd, int offset, frame_data *fd, proto_tree *tree) {
|
1999-03-23 03:14:46 +00:00
|
|
|
proto_tree *rip_tree;
|
|
|
|
proto_item *ti;
|
1998-09-23 05:25:12 +00:00
|
|
|
guint16 operation;
|
|
|
|
struct ipx_rt_def route;
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
int cursor;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-09-23 05:25:12 +00:00
|
|
|
char *rip_type[2] = { "Request", "Response" };
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-09-23 05:25:12 +00:00
|
|
|
operation = pntohs(&pd[offset]) - 1;
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-11-17 04:29:13 +00:00
|
|
|
if (check_col(fd, COL_PROTOCOL))
|
|
|
|
col_add_str(fd, COL_PROTOCOL, "IPX RIP");
|
|
|
|
if (check_col(fd, COL_PROTOCOL)) {
|
|
|
|
if (operation < 2) {
|
|
|
|
col_add_str(fd, COL_INFO, rip_type[operation]);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
col_add_str(fd, COL_INFO, "Unknown Packet Type");
|
|
|
|
}
|
1998-09-16 02:39:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (tree) {
|
1999-07-17 04:19:15 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_ipxrip, offset, END_OF_FRAME, NULL);
|
1999-11-16 11:44:20 +00:00
|
|
|
rip_tree = proto_item_add_subtree(ti, ett_ipxrip);
|
1998-09-23 05:25:12 +00:00
|
|
|
|
|
|
|
if (operation < 2) {
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(rip_tree, offset, 2,
|
1998-09-23 05:25:12 +00:00
|
|
|
"RIP packet type: %s", rip_type[operation]);
|
1999-10-17 09:23:43 +00:00
|
|
|
|
|
|
|
if (operation == 0) {
|
|
|
|
proto_tree_add_item_hidden(rip_tree,
|
|
|
|
hf_ipxrip_request,
|
|
|
|
offset, 2, 1);
|
|
|
|
} else {
|
|
|
|
proto_tree_add_item_hidden(rip_tree,
|
|
|
|
hf_ipxrip_response,
|
|
|
|
offset, 2, 1);
|
|
|
|
}
|
|
|
|
|
1998-09-23 05:25:12 +00:00
|
|
|
}
|
|
|
|
else {
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(rip_tree, offset, 2, "Unknown RIP packet type");
|
1998-09-16 02:39:15 +00:00
|
|
|
}
|
|
|
|
|
1998-09-23 05:25:12 +00:00
|
|
|
for (cursor = offset + 2; cursor < fd->cap_len; cursor += 8) {
|
|
|
|
memcpy(&route.network, &pd[cursor], 4);
|
|
|
|
route.hops = pntohs(&pd[cursor+4]);
|
|
|
|
route.ticks = pntohs(&pd[cursor+6]);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1998-09-23 14:46:06 +00:00
|
|
|
if (operation == IPX_RIP_REQUEST - 1) {
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(rip_tree, cursor, 8,
|
1998-09-23 14:46:06 +00:00
|
|
|
"Route Vector: %s, %d hop%s, %d tick%s",
|
1998-10-14 04:09:15 +00:00
|
|
|
ipxnet_to_string((guint8*)&route.network),
|
1998-09-23 14:46:06 +00:00
|
|
|
route.hops, route.hops == 1 ? "" : "s",
|
|
|
|
route.ticks, route.ticks == 1 ? "" : "s");
|
|
|
|
}
|
|
|
|
else {
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(rip_tree, cursor, 8,
|
1998-09-23 14:46:06 +00:00
|
|
|
"Route Vector: %s, %d hop%s, %d tick%s (%d ms)",
|
1998-10-14 04:09:15 +00:00
|
|
|
ipxnet_to_string((guint8*)&route.network),
|
1998-09-23 14:46:06 +00:00
|
|
|
route.hops, route.hops == 1 ? "" : "s",
|
|
|
|
route.ticks, route.ticks == 1 ? "" : "s",
|
|
|
|
route.ticks * 1000 / 18);
|
|
|
|
}
|
1998-09-16 02:39:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
1998-09-24 04:22:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ================================================================= */
|
|
|
|
/* SAP */
|
|
|
|
/* ================================================================= */
|
|
|
|
static char*
|
|
|
|
server_type(guint16 type)
|
|
|
|
{
|
|
|
|
int i=0;
|
|
|
|
|
1998-10-02 22:14:29 +00:00
|
|
|
/* some of these are from ncpfs, others are from the book */
|
1998-09-24 04:22:08 +00:00
|
|
|
static struct server_info servers[] = {
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x0001, "User" },
|
|
|
|
{ 0x0002, "User Group" },
|
|
|
|
{ 0x0003, "Print Queue" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0004, "File server" },
|
|
|
|
{ 0x0005, "Job server" },
|
|
|
|
{ 0x0007, "Print server" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x0008, "Archive server" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0009, "Archive server" },
|
|
|
|
{ 0x000a, "Job queue" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x000b, "Administration" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0021, "NAS SNA gateway" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x0024, "Remote bridge" },
|
|
|
|
{ 0x0026, "Bridge server" },
|
|
|
|
{ 0x0027, "TCP/IP gateway" },
|
|
|
|
{ 0x002d, "Time Synchronization VAP" },
|
|
|
|
{ 0x002e, "Archive Server Dynamic SAP" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0047, "Advertising print server" },
|
|
|
|
{ 0x004b, "Btrieve VAP 5.0" },
|
|
|
|
{ 0x004c, "SQL VAP" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x0050, "Btrieve VAP" },
|
|
|
|
{ 0x0053, "Print Queue VAP" },
|
|
|
|
{ 0x007a, "TES NetWare for VMS" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0098, "NetWare access server" },
|
|
|
|
{ 0x009a, "Named Pipes server" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x009e, "Portable NetWare Unix" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0107, "NetWare 386" },
|
|
|
|
{ 0x0111, "Test server" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x0133, "NetWare Name Service" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0166, "NetWare management" },
|
1999-11-15 21:33:57 +00:00
|
|
|
{ 0x023f, "SMS Testing and Development" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x026a, "NetWare management" },
|
|
|
|
{ 0x026b, "Time synchronization" },
|
1999-11-15 21:33:57 +00:00
|
|
|
{ 0x027b, "NetWare Management Agent" },
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0278, "NetWare Directory server" },
|
1999-11-15 21:33:57 +00:00
|
|
|
{ 0x030c, "HP LaserJet / Quick Silver" },
|
|
|
|
{ 0x0355, "Arcada Software" },
|
|
|
|
{ 0x0361, "NETINELO" },
|
|
|
|
{ 0x037e, "Powerchute UPS Monitoring" },
|
|
|
|
{ 0x03e1, "UnixWare Application Server" },
|
|
|
|
{ 0x044c, "Archive" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x055d, "Attachmate SNA gateway" },
|
1999-11-15 21:33:57 +00:00
|
|
|
{ 0x0610, "Adaptec SCSI Management" },
|
|
|
|
{ 0x0640, "NT Server-RPC/GW for NW/Win95 User Level Sec" },
|
|
|
|
{ 0x064e, "NT Server-IIS" },
|
|
|
|
{ 0x0810, "ELAN License Server Demo" },
|
|
|
|
{ 0x8002, "Intel NetPort Print Server" },
|
|
|
|
|
|
|
|
/* For any unidentified ones, I found a really big list of them at: */
|
|
|
|
/* http://www.inpnet.org/cnpweb/saplist.txt */
|
|
|
|
/* http://www.isi.edu/in-notes/iana/assignments/novell-sap-numbers */
|
|
|
|
|
1998-09-24 04:22:08 +00:00
|
|
|
{ 0x0000, NULL }
|
|
|
|
};
|
|
|
|
|
|
|
|
while (servers[i].text != NULL) {
|
|
|
|
if (servers[i].type == type) {
|
|
|
|
return servers[i].text;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
return "Unknown";
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
1999-11-17 02:17:29 +00:00
|
|
|
dissect_ipxsap(const u_char *pd, int offset, frame_data *fd, proto_tree *tree) {
|
1998-09-24 04:22:08 +00:00
|
|
|
|
1999-03-23 03:14:46 +00:00
|
|
|
proto_tree *sap_tree, *s_tree;
|
|
|
|
proto_item *ti;
|
Have the IPX code set "pi.len" and "pi.captured_len" based on the length
in the IPX header, and have the dissectors it calls use it rather than
being passed the length as an argument.
Treat both packet type 20 ("WAN Broadcast") and 4 ("IPX", although 3 is
also "IPX", according to Network Monitor) as potentially being NetBIOS
packets.
The packet types for the IPX NetBIOS socket (0x0455) and the NWLink
sockets (0x0551 and 0x0553) are different (perhaps because there's one
socket for the 0x0455 NBIPX, so you have to do name service and datagram
service and have the packet types distinguish them, but NWLink has
separate sockets for name service and datagram service).
The packet type for name service and for datagram service are at
*different locations* in the packet, which is unfortunate if you want to
use the packet type to distinguish name service and datagram service
packets. Use the packet length, for now, to distinguish them, with
socket 0x0455.
Dissect datagram packets differently from name service packets.
Export "packet-netbios.c"'s "netbios_add_name()" routine, and use it
when dissecting NBIPX packets as well.
Label NBIPX packets as "NBIPX" rather than "NetBIOS".
svn path=/trunk/; revision=627
1999-09-02 23:17:58 +00:00
|
|
|
int cursor;
|
1998-09-24 04:22:08 +00:00
|
|
|
struct sap_query query;
|
|
|
|
struct sap_server_ident server;
|
|
|
|
|
|
|
|
char *sap_type[4] = { "General Query", "General Response",
|
|
|
|
"Nearest Query", "Nearest Response" };
|
|
|
|
|
|
|
|
query.query_type = pntohs(&pd[offset]);
|
|
|
|
query.server_type = pntohs(&pd[offset+2]);
|
|
|
|
|
1998-11-17 04:29:13 +00:00
|
|
|
if (check_col(fd, COL_PROTOCOL))
|
|
|
|
col_add_str(fd, COL_PROTOCOL, "SAP");
|
|
|
|
if (check_col(fd, COL_INFO)) {
|
1999-09-15 22:33:17 +00:00
|
|
|
if (query.query_type >= 1 && query.query_type <= 4) {
|
1998-11-17 04:29:13 +00:00
|
|
|
col_add_str(fd, COL_INFO, sap_type[query.query_type - 1]);
|
1998-09-24 04:22:08 +00:00
|
|
|
}
|
|
|
|
else {
|
1998-11-17 04:29:13 +00:00
|
|
|
col_add_str(fd, COL_INFO, "Unknown Packet Type");
|
1998-09-24 04:22:08 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tree) {
|
1999-07-20 02:56:44 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_sap, offset, END_OF_FRAME, NULL);
|
1999-11-16 11:44:20 +00:00
|
|
|
sap_tree = proto_item_add_subtree(ti, ett_ipxsap);
|
1998-09-24 04:22:08 +00:00
|
|
|
|
1999-09-15 22:33:17 +00:00
|
|
|
if (query.query_type >= 1 && query.query_type <= 4) {
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(sap_tree, offset, 2, sap_type[query.query_type - 1]);
|
1999-10-17 09:23:43 +00:00
|
|
|
if ((query.query_type - 1) % 2) {
|
|
|
|
proto_tree_add_item_hidden(sap_tree,
|
|
|
|
hf_sap_response,
|
|
|
|
offset, 2, 1);
|
|
|
|
} else {
|
|
|
|
proto_tree_add_item_hidden(sap_tree,
|
|
|
|
hf_sap_request,
|
|
|
|
offset, 2, 1);
|
|
|
|
}
|
1998-09-24 04:22:08 +00:00
|
|
|
}
|
|
|
|
else {
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(sap_tree, offset, 2,
|
1998-09-24 04:22:08 +00:00
|
|
|
"Unknown SAP Packet Type %d", query.query_type);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (query.query_type == IPX_SAP_GENERAL_RESPONSE ||
|
|
|
|
query.query_type == IPX_SAP_NEAREST_RESPONSE) { /* responses */
|
|
|
|
|
1999-03-05 05:20:12 +00:00
|
|
|
for (cursor = offset + 2; (cursor + 64) <= fd->cap_len; cursor += 64) {
|
1998-09-24 04:22:08 +00:00
|
|
|
server.server_type = pntohs(&pd[cursor]);
|
|
|
|
memcpy(server.server_name, &pd[cursor+2], 48);
|
|
|
|
memcpy(&server.server_network, &pd[cursor+50], 4);
|
|
|
|
memcpy(&server.server_node, &pd[cursor+54], 6);
|
|
|
|
server.server_port = pntohs(&pd[cursor+60]);
|
|
|
|
server.intermediate_network = pntohs(&pd[cursor+62]);
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
ti = proto_tree_add_text(sap_tree, cursor+2, 48,
|
1998-09-24 04:22:08 +00:00
|
|
|
"Server Name: %s", server.server_name);
|
1999-11-16 11:44:20 +00:00
|
|
|
s_tree = proto_item_add_subtree(ti, ett_ipxsap_server);
|
1998-09-24 04:22:08 +00:00
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(s_tree, cursor, 2, "Server Type: %s (0x%04X)",
|
1998-09-24 04:22:08 +00:00
|
|
|
server_type(server.server_type), server.server_type);
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(s_tree, cursor+50, 4, "Network: %s",
|
1998-10-14 04:09:15 +00:00
|
|
|
ipxnet_to_string((guint8*)&pd[cursor+50]));
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(s_tree, cursor+54, 6, "Node: %s",
|
1998-09-24 04:22:08 +00:00
|
|
|
ether_to_str((guint8*)&pd[cursor+54]));
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(s_tree, cursor+60, 2, "Socket: %s (0x%04X)",
|
1998-09-24 04:22:08 +00:00
|
|
|
port_text(server.server_port), server.server_port);
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(s_tree, cursor+62, 2,
|
1998-09-27 22:12:47 +00:00
|
|
|
"Intermediate Networks: %d",
|
|
|
|
server.intermediate_network);
|
1998-09-24 04:22:08 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else { /* queries */
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(sap_tree, offset+2, 2, "Server Type: %s (0x%04X)",
|
1998-09-24 04:22:08 +00:00
|
|
|
server_type(query.server_type), query.server_type);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1999-07-17 04:19:15 +00:00
|
|
|
|
|
|
|
void
|
|
|
|
proto_register_ipx(void)
|
|
|
|
{
|
1999-07-20 02:56:44 +00:00
|
|
|
static hf_register_info hf_ipx[] = {
|
|
|
|
{ &hf_ipx_checksum,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Checksum", "ipx.checksum", FT_UINT16, BASE_HEX, NULL, 0x0,
|
|
|
|
"" }},
|
1999-07-20 02:56:44 +00:00
|
|
|
|
|
|
|
{ &hf_ipx_len,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Length", "ipx.len", FT_UINT16, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }},
|
1999-07-20 02:56:44 +00:00
|
|
|
|
|
|
|
{ &hf_ipx_hops,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Transport Control (Hops)", "ipx.hops", FT_UINT8, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }},
|
1999-07-20 02:56:44 +00:00
|
|
|
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
{ &hf_ipx_packet_type,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Packet Type", "ipx.packet_type", FT_UINT8, BASE_HEX, VALS(ipx_packet_type_vals),
|
|
|
|
0x0,
|
|
|
|
"" }},
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
|
|
|
|
{ &hf_ipx_dnet,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Destination Network","ipx.dst.net", FT_IPXNET, BASE_NONE, NULL, 0x0,
|
|
|
|
"" }},
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
|
1999-07-20 02:56:44 +00:00
|
|
|
{ &hf_ipx_dnode,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Destination Node", "ipx.dst.node", FT_ETHER, BASE_NONE, NULL, 0x0,
|
|
|
|
"" }},
|
1999-07-20 02:56:44 +00:00
|
|
|
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
{ &hf_ipx_dsocket,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Destination Socket", "ipx.dst.socket", FT_UINT16, BASE_HEX, NULL, 0x0,
|
|
|
|
"" }},
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
|
|
|
|
{ &hf_ipx_snet,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Source Network","ipx.src.net", FT_IPXNET, BASE_NONE, NULL, 0x0,
|
|
|
|
"" }},
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
|
1999-07-20 02:56:44 +00:00
|
|
|
{ &hf_ipx_snode,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Source Node", "ipx.src.node", FT_ETHER, BASE_NONE, NULL, 0x0,
|
|
|
|
"" }},
|
Changed the display filter scanner from GLIB's GScanner to lex. The code
as it standed depends on your lex being flex, but that only matters if you're
a developer. The distribution will include the dfilter-scanner.c file, so
that if the user doesn't modify dfilter-scanner.l, he won't need flex to
re-create the *.c file.
The new lex scanner gives me better syntax checking for ether addresses. I
thought I could get by using GScanner, but it simply wasn't powerful enough.
All operands have English-like abbreviations and C-like syntax:
and, && ; or, || ; eq, == ; ne, != ; , etc.
I removed the ETHER_VENDOR type in favor of letting the user use the [x:y]
notation: ether.src[0:3] == 0:6:29 instead of ether.srcvendor == 00:06:29
I implemented the IPXNET field type; it had been there before, but was
not implemented. I chose to make it use integer values rather than byte
ranges, since an IPX Network is 4 bytes. So a display filter looks like this:
ipx.srcnet == 0xc0a82c00
rather than this:
ipx.srcnet == c0:a8:2c:00
I can supposrt the byte-range type IPXNET in the future, very trivially.
I still have more work to do on the parser though. It needs to check ranges
when extracting byte ranges ([x:y]) from packets. And I need to get rid
of those reduce/reduce errors from yacc!
svn path=/trunk/; revision=414
1999-08-01 04:28:20 +00:00
|
|
|
|
|
|
|
{ &hf_ipx_ssocket,
|
1999-10-12 06:21:15 +00:00
|
|
|
{ "Source Socket", "ipx.src.socket", FT_UINT16, BASE_HEX, NULL, 0x0,
|
|
|
|
"" }},
|
1999-07-20 02:56:44 +00:00
|
|
|
};
|
1999-10-17 09:23:43 +00:00
|
|
|
|
|
|
|
static hf_register_info hf_spx[] = {
|
|
|
|
{ &hf_spx_connection_control,
|
|
|
|
{ "Connection Control", "spx.ctl",
|
|
|
|
FT_UINT8, BASE_HEX, NULL, 0x0,
|
|
|
|
"" }},
|
|
|
|
|
|
|
|
{ &hf_spx_datastream_type,
|
|
|
|
{ "Datastream type", "spx.type",
|
|
|
|
FT_UINT8, BASE_HEX, NULL, 0x0,
|
|
|
|
"" }},
|
|
|
|
|
|
|
|
{ &hf_spx_src_id,
|
|
|
|
{ "Source Connection ID", "spx.src",
|
|
|
|
FT_UINT16, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }},
|
|
|
|
|
|
|
|
{ &hf_spx_dst_id,
|
|
|
|
{ "Destination Connection ID", "spx.dst",
|
|
|
|
FT_UINT16, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }},
|
|
|
|
|
|
|
|
{ &hf_spx_seq_nr,
|
|
|
|
{ "Sequence Number", "spx.seq",
|
|
|
|
FT_UINT16, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }},
|
|
|
|
|
|
|
|
{ &hf_spx_ack_nr,
|
|
|
|
{ "Acknowledgment Number", "spx.ack",
|
|
|
|
FT_UINT16, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }},
|
|
|
|
|
|
|
|
{ &hf_spx_all_nr,
|
|
|
|
{ "Allocation Number", "spx.alloc",
|
|
|
|
FT_UINT16, BASE_DEC, NULL, 0x0,
|
|
|
|
"" }}
|
|
|
|
};
|
|
|
|
|
|
|
|
static hf_register_info hf_ipxrip[] = {
|
|
|
|
{ &hf_ipxrip_request,
|
|
|
|
{ "Request", "ipxrip.request",
|
|
|
|
FT_BOOLEAN, BASE_NONE, NULL, 0x0,
|
|
|
|
"TRUE if IPX RIP request" }},
|
|
|
|
|
|
|
|
{ &hf_ipxrip_response,
|
|
|
|
{ "Response", "ipxrip.response",
|
|
|
|
FT_BOOLEAN, BASE_NONE, NULL, 0x0,
|
|
|
|
"TRUE if IPX RIP response" }}
|
|
|
|
};
|
|
|
|
|
|
|
|
static hf_register_info hf_sap[] = {
|
|
|
|
{ &hf_sap_request,
|
|
|
|
{ "Request", "sap.request",
|
|
|
|
FT_BOOLEAN, BASE_NONE, NULL, 0x0,
|
|
|
|
"TRUE if SAP request" }},
|
|
|
|
|
|
|
|
{ &hf_sap_response,
|
|
|
|
{ "Response", "sap.response",
|
|
|
|
FT_BOOLEAN, BASE_NONE, NULL, 0x0,
|
|
|
|
"TRUE if SAP response" }}
|
|
|
|
};
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint *ett[] = {
|
|
|
|
&ett_ipx,
|
|
|
|
&ett_spx,
|
|
|
|
&ett_ipxrip,
|
|
|
|
&ett_ipxsap,
|
|
|
|
&ett_ipxsap_server,
|
|
|
|
};
|
|
|
|
|
1999-07-17 04:19:15 +00:00
|
|
|
proto_ipx = proto_register_protocol ("Internetwork Packet eXchange", "ipx");
|
1999-07-20 02:56:44 +00:00
|
|
|
proto_register_field_array(proto_ipx, hf_ipx, array_length(hf_ipx));
|
1999-07-17 04:19:15 +00:00
|
|
|
|
|
|
|
proto_spx = proto_register_protocol ("Sequenced Packet eXchange", "spx");
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_register_field_array(proto_spx, hf_spx, array_length(hf_spx));
|
|
|
|
|
1999-07-17 04:19:15 +00:00
|
|
|
proto_ipxrip = proto_register_protocol ("IPX Routing Information Protocol", "ipxrip");
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_register_field_array(proto_ipxrip, hf_ipxrip, array_length(hf_ipxrip));
|
1999-07-17 04:19:15 +00:00
|
|
|
|
|
|
|
proto_sap = proto_register_protocol ("Service Advertisement Protocol", "sap");
|
1999-10-17 09:23:43 +00:00
|
|
|
proto_register_field_array(proto_sap, hf_sap, array_length(hf_sap));
|
1999-11-16 11:44:20 +00:00
|
|
|
|
|
|
|
proto_register_subtree_array(ett, array_length(ett));
|
1999-07-17 04:19:15 +00:00
|
|
|
}
|