1998-09-16 02:39:15 +00:00
|
|
|
/* packet-ipx.c
|
|
|
|
* Routines for NetWare's IPX
|
|
|
|
* Gilbert Ramirez <gram@verdict.uthscsa.edu>
|
|
|
|
*
|
1999-09-15 22:33:17 +00:00
|
|
|
* $Id: packet-ipx.c,v 1.27 1999/09/15 22:33:17 gram 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"
|
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-07-29 05:47:07 +00:00
|
|
|
static int proto_spx = -1;
|
|
|
|
static int proto_ipxrip = -1;
|
|
|
|
static int proto_sap = -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
|
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_sap(const u_char *pd, int offset, frame_data *fd, proto_tree *tree);
|
|
|
|
|
|
|
|
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
|
|
|
|
#define IPX_SOCKET_ATTACHMATE_GW 0x055d
|
|
|
|
#define IPX_SOCKET_IPX_MESSAGE 0x4001
|
|
|
|
|
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" },
|
|
|
|
{ IPX_SOCKET_SAP, dissect_sap,
|
|
|
|
"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" },
|
|
|
|
{ IPX_SOCKET_ATTACHMATE_GW, NULL,
|
|
|
|
"Attachmate Gateway" },
|
|
|
|
{ IPX_SOCKET_IPX_MESSAGE, NULL,
|
|
|
|
"IPX Message" },
|
|
|
|
{ 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
|
|
|
}
|
|
|
|
|
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
|
|
|
|
#define IPX_PACKET_TYPE_IPX_4 4
|
|
|
|
#define IPX_PACKET_TYPE_SPX 5
|
|
|
|
#define IPX_PACKET_TYPE_NCP 17
|
|
|
|
#define IPX_PACKET_TYPE_WANBCAST 20
|
|
|
|
|
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" },
|
|
|
|
{ IPX_PACKET_TYPE_IPX_4, "IPX" },
|
|
|
|
/* NetMon calls it "IPX" */
|
|
|
|
{ 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" },
|
|
|
|
/* NetMon calls it "WAN 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
|
|
|
{
|
|
|
|
static gchar str[3][12];
|
|
|
|
static gchar *cur;
|
|
|
|
|
|
|
|
if (cur == &str[0][0]) {
|
|
|
|
cur = &str[1][0];
|
|
|
|
} else if (cur == &str[1][0]) {
|
|
|
|
cur = &str[2][0];
|
|
|
|
} else {
|
|
|
|
cur = &str[0][0];
|
|
|
|
}
|
|
|
|
|
|
|
|
sprintf(cur, "%02X %02X %02X %02X", ad[0], ad[1], ad[2], ad[3]);
|
|
|
|
return cur;
|
|
|
|
}
|
|
|
|
|
1999-03-05 06:09:39 +00:00
|
|
|
gchar*
|
|
|
|
ipx_addr_to_str(guint32 net, const guint8 *ad)
|
|
|
|
{
|
|
|
|
static gchar str[3][22];
|
|
|
|
static gchar *cur;
|
|
|
|
|
|
|
|
if (cur == &str[0][0]) {
|
|
|
|
cur = &str[1][0];
|
|
|
|
} else if (cur == &str[1][0]) {
|
|
|
|
cur = &str[2][0];
|
|
|
|
} else {
|
|
|
|
cur = &str[0][0];
|
|
|
|
}
|
|
|
|
|
|
|
|
sprintf(cur, "%X.%02x%02x%02x%02x%02x%02x", net,
|
|
|
|
ad[0], ad[1], ad[2], ad[3], ad[4], ad[5]);
|
|
|
|
return cur;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
gchar *str_dnet, *str_snet;
|
|
|
|
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];
|
|
|
|
str_dnet = ipxnet_to_string(ipx_dnet);
|
|
|
|
str_snet = ipxnet_to_string(ipx_snet);
|
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. */
|
|
|
|
len = ipx_length + offset;
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
1999-03-05 06:09:39 +00:00
|
|
|
if (check_col(fd, COL_RES_DL_DST))
|
|
|
|
col_add_str(fd, COL_RES_DL_DST,
|
1999-03-20 04:38:57 +00:00
|
|
|
ipx_addr_to_str(pntohl(ipx_dnet), ipx_dnode));
|
1999-03-05 06:09:39 +00:00
|
|
|
if (check_col(fd, COL_RES_DL_SRC))
|
|
|
|
col_add_str(fd, COL_RES_DL_SRC,
|
1999-03-20 04:38:57 +00:00
|
|
|
ipx_addr_to_str(pntohl(ipx_snet), ipx_snode));
|
|
|
|
|
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-07-07 22:52:57 +00:00
|
|
|
ipx_tree = proto_item_add_subtree(ti, ETT_IPX);
|
1999-07-20 02:56:44 +00:00
|
|
|
proto_tree_add_item_format(ipx_tree, hf_ipx_checksum, offset, 2, ipx_checksum,
|
|
|
|
"Checksum: 0x%04x", ipx_checksum);
|
|
|
|
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:
|
|
|
|
case IPX_PACKET_TYPE_IPX_4:
|
|
|
|
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"},
|
|
|
|
{ 0x80, "System Packet"}
|
|
|
|
};
|
|
|
|
|
|
|
|
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-07-07 22:52:57 +00:00
|
|
|
spx_tree = proto_item_add_subtree(ti, ETT_SPX);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset, 1,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Connection Control: %s (0x%02X)",
|
|
|
|
spx_conn_ctrl(pd[offset]), pd[offset]);
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset+1, 1,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Datastream Type: %s (0x%02X)",
|
1999-03-05 06:09:39 +00:00
|
|
|
spx_datastream(pd[offset+1]), pd[offset+1]);
|
1998-09-16 02:39:15 +00:00
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset+2, 2,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Source Connection ID: %d", pntohs( &pd[offset+2] ) );
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset+4, 2,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Destination Connection ID: %d", pntohs( &pd[offset+4] ) );
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset+6, 2,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Sequence Number: %d", pntohs( &pd[offset+6] ) );
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset+8, 2,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Acknowledgment Number: %d", pntohs( &pd[offset+8] ) );
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_tree_add_text(spx_tree, offset+10, 2,
|
1998-09-16 02:39:15 +00:00
|
|
|
"Allocation Number: %d", pntohs( &pd[offset+10] ) );
|
|
|
|
|
|
|
|
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-07-07 22:52:57 +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]);
|
|
|
|
}
|
|
|
|
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" },
|
|
|
|
{ 0x026a, "NetWare management" },
|
|
|
|
{ 0x026b, "Time synchronization" },
|
|
|
|
{ 0x0278, "NetWare Directory server" },
|
1998-10-02 22:14:29 +00:00
|
|
|
{ 0x055d, "Attachmate SNA gateway" },
|
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
|
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_sap(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-07-07 22:52:57 +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]);
|
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-07-07 22:52:57 +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,
|
|
|
|
{ "Checksum", "ipx.checksum", FT_UINT16, NULL }},
|
|
|
|
|
|
|
|
{ &hf_ipx_len,
|
|
|
|
{ "Length", "ipx.len", FT_UINT16, NULL }},
|
|
|
|
|
|
|
|
{ &hf_ipx_hops,
|
|
|
|
{ "Transport Control (Hops)", "ipx.hops", FT_UINT8, 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
|
|
|
{ &hf_ipx_packet_type,
|
|
|
|
{ "Packet Type", "ipx.packet_type", FT_VALS_UINT8, VALS(ipx_packet_type_vals) }},
|
|
|
|
|
|
|
|
{ &hf_ipx_dnet,
|
|
|
|
{ "Destination Network","ipx.dstnet", FT_IPXNET, NULL }},
|
|
|
|
|
1999-07-20 02:56:44 +00:00
|
|
|
{ &hf_ipx_dnode,
|
|
|
|
{ "Destination Node", "ipx.dstnode", FT_ETHER, 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
|
|
|
{ &hf_ipx_dsocket,
|
|
|
|
{ "Destination Socket", "ipx.dstsocket", FT_UINT16, NULL }},
|
|
|
|
|
|
|
|
{ &hf_ipx_snet,
|
|
|
|
{ "Source Network","ipx.srcnet", FT_IPXNET, NULL }},
|
|
|
|
|
1999-07-20 02:56:44 +00:00
|
|
|
{ &hf_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
|
|
|
{ "Source Node", "ipx.srcnode", FT_ETHER, NULL }},
|
|
|
|
|
|
|
|
{ &hf_ipx_ssocket,
|
|
|
|
{ "Source Socket", "ipx.srcsocket", FT_UINT16, NULL }},
|
1999-07-20 02:56:44 +00:00
|
|
|
};
|
|
|
|
|
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");
|
|
|
|
|
|
|
|
proto_ipxrip = proto_register_protocol ("IPX Routing Information Protocol", "ipxrip");
|
|
|
|
|
|
|
|
proto_sap = proto_register_protocol ("Service Advertisement Protocol", "sap");
|
|
|
|
}
|