1998-10-14 04:09:15 +00:00
|
|
|
/* packet-nbipx.c
|
|
|
|
* Routines for NetBIOS over IPX packet disassembly
|
2000-01-22 06:22:44 +00:00
|
|
|
* Gilbert Ramirez <gram@xiexie.org>
|
1998-10-14 04:09:15 +00:00
|
|
|
*
|
2000-11-10 21:29:27 +00:00
|
|
|
* $Id: packet-nbipx.c,v 1.25 2000/11/10 21:29:27 gram Exp $
|
1998-10-14 04:09:15 +00:00
|
|
|
*
|
|
|
|
* Ethereal - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@zing.org>
|
|
|
|
* 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 <glib.h>
|
1998-10-14 04:09:15 +00:00
|
|
|
#include "packet.h"
|
2000-02-15 21:06:58 +00:00
|
|
|
#include "packet-ipx.h"
|
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
|
|
|
#include "packet-netbios.h"
|
2000-02-15 21:06:58 +00:00
|
|
|
#include "packet-smb.h"
|
1998-10-14 04:09:15 +00:00
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
static int proto_nbipx = -1;
|
|
|
|
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint ett_nbipx = -1;
|
|
|
|
static gint ett_nbipx_name_type_flags = -1;
|
|
|
|
|
1998-10-14 05:18:32 +00:00
|
|
|
enum nbipx_protocol {
|
|
|
|
NETBIOS_NETWARE,
|
|
|
|
NETBIOS_NWLINK
|
|
|
|
};
|
|
|
|
|
|
|
|
static void
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nbipx_ns(tvbuff_t *tvb, packet_info *pinfo, 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
|
|
|
static void
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nbipx_dg(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree);
|
1998-10-14 05:18:32 +00:00
|
|
|
|
1998-10-14 04:09:15 +00:00
|
|
|
/* There is no RFC or public specification of Netware or Microsoft
|
|
|
|
* NetBIOS over IPX packets. I have had to decode the protocol myself,
|
|
|
|
* so there are holes and perhaps errors in this code. (gram)
|
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
|
|
|
*
|
|
|
|
* A list of "NovelNetBIOS" packet types can be found at
|
|
|
|
*
|
|
|
|
* http://www.protocols.com/pbook/novel.htm#NetBIOS
|
|
|
|
*
|
|
|
|
* and at least some of those packet types appear to match what's in
|
|
|
|
* some NBIPX packets.
|
|
|
|
*
|
|
|
|
* Note, however, that the offset of the packet type in an NBIPX packet
|
|
|
|
* *DEPENDS ON THE PACKET TYPE*; "Find name" and "Name recognized" have
|
|
|
|
* it at one offset, "Directed datagram" has it at another. Does the
|
|
|
|
* NBIPX code base it on the length, or what? Non-broadcast directed
|
|
|
|
* datagram packets have an IPX type of "IPX", just as "Find name" and
|
|
|
|
* "Name recognized" do.... For now, we base it on the length.
|
1998-10-14 04:09:15 +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 NBIPX_FIND_NAME 1
|
|
|
|
#define NBIPX_NAME_RECOGNIZED 2
|
|
|
|
#define NBIPX_CHECK_NAME 3
|
|
|
|
#define NBIPX_NAME_IN_USE 4
|
|
|
|
#define NBIPX_DEREGISTER_NAME 5
|
|
|
|
#define NBIPX_SESSION_DATA 6
|
|
|
|
#define NBIPX_SESSION_END 7
|
|
|
|
#define NBIPX_SESSION_END_ACK 8
|
|
|
|
#define NBIPX_STATUS_QUERY 9
|
|
|
|
#define NBIPX_STATUS_RESPONSE 10
|
|
|
|
#define NBIPX_DIRECTED_DATAGRAM 11
|
|
|
|
|
|
|
|
static const value_string nbipx_data_stream_type_vals[] = {
|
|
|
|
{NBIPX_FIND_NAME, "Find name"},
|
|
|
|
{NBIPX_NAME_RECOGNIZED, "Name recognized"},
|
|
|
|
{NBIPX_CHECK_NAME, "Check name"},
|
|
|
|
{NBIPX_NAME_IN_USE, "Name in use"},
|
|
|
|
{NBIPX_DEREGISTER_NAME, "Deregister name"},
|
|
|
|
{NBIPX_SESSION_DATA, "Session data"},
|
|
|
|
{NBIPX_SESSION_END, "Session end"},
|
|
|
|
{NBIPX_SESSION_END_ACK, "Session end ACK"},
|
|
|
|
{NBIPX_STATUS_QUERY, "Status query"},
|
|
|
|
{NBIPX_STATUS_RESPONSE, "Status response"},
|
|
|
|
{NBIPX_DIRECTED_DATAGRAM, "Directed datagram"},
|
|
|
|
{0, NULL}
|
1998-10-14 05:18:32 +00:00
|
|
|
};
|
1998-10-14 04:09:15 +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 NWLINK_NAME_QUERY 1
|
|
|
|
#define NWLINK_SMB 2
|
|
|
|
#define NWLINK_NETBIOS_DATAGRAM 3
|
|
|
|
|
|
|
|
static const value_string nwlink_data_stream_type_vals[] = {
|
|
|
|
{NWLINK_NAME_QUERY, "Name query"},
|
|
|
|
{NWLINK_SMB, "SMB"},
|
|
|
|
{NWLINK_NETBIOS_DATAGRAM, "NetBIOS datagram"},
|
|
|
|
{0, NULL}
|
|
|
|
};
|
NBIPX packet type 3 appears to be the equivalent, in NBIPXland, of the
NetBIOS Datagram Service in NBTland; a capture Gilbert sent had a pile
of those packets containing what looked like SMB browser announcements,
which are sent out as broadcast datagrams. Label them as such, and
treat them as such.
Might packet type 2 be the equivalent of the NetBIOS Session Service -
both of them contain SMBs, but the former is a connection-oriented
service (LLC I frames, presumably, in NBF, and TCP in NBT), and the
latter is a datagram-oriented service (LLC UI frames, presumably, in
NBF, and UDP in NBT)? For now, we leave type 2 as "SMB (over NBIPX)",
but we might want to label it as "NetBIOS session" or whatever the
appropriate term is.
svn path=/trunk/; revision=574
1999-08-25 01:36:21 +00:00
|
|
|
|
1998-10-14 05:18:32 +00:00
|
|
|
/* NetWare */
|
1998-10-14 04:09:15 +00:00
|
|
|
void
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nbipx(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
|
1998-10-14 05:18:32 +00:00
|
|
|
{
|
2000-11-10 21:09:49 +00:00
|
|
|
CHECK_DISPLAY_AS_DATA(proto_nbipx, tvb, pinfo, tree);
|
Add the "Edit:Protocols..." feature which currently only implements
the following:
It is now possible to enable/disable a particular protocol decoding
(i.e. the protocol dissector is void or not). When a protocol
is disabled, it is displayed as Data and of course, all linked
sub-protocols are disabled as well.
Disabling a protocol could be interesting:
- in case of buggy dissectors
- in case of wrong heuristics
- for performance reasons
- to decode the data as another protocol (TODO)
Currently (if I am not wrong), all dissectors but NFS can be disabled
(and dissectors that do not register protocols :-)
I do not like the way the RPC sub-dissectors are disabled (in the
sub-dissectors) since this could be done in the RPC dissector itself,
knowing the sub-protocol hfinfo entry (this is why, I've not modified
the NFS one yet).
Two functions are added in proto.c :
gboolean proto_is_protocol_enabled(int n);
void proto_set_decoding(int n, gboolean enabled);
and two MACROs which can be used in dissectors:
OLD_CHECK_DISPLAY_AS_DATA(index, pd, offset, fd, tree)
CHECK_DISPLAY_AS_DATA(index, tvb, pinfo, tree)
See also the XXX in proto_dlg.c and proto.c around the new functions.
svn path=/trunk/; revision=2267
2000-08-13 14:09:15 +00:00
|
|
|
|
2000-11-10 21:29:27 +00:00
|
|
|
pinfo->current_proto = "NBIPX";
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (check_col(pinfo->fd, COL_PROTOCOL))
|
|
|
|
col_add_str(pinfo->fd, COL_PROTOCOL, "NBIPX");
|
1999-09-03 03:22:19 +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
|
|
|
/*
|
|
|
|
* As said above, we look at the length of the packet to decide
|
|
|
|
* whether to treat it as a name-service packet or a datagram
|
|
|
|
* (the packet type would tell us, but it's at a *DIFFERENT
|
|
|
|
* LOCATION* in different types of packet...).
|
|
|
|
*/
|
2000-11-10 21:09:49 +00:00
|
|
|
if (tvb_reported_length(tvb) == 50)
|
|
|
|
dissect_nbipx_ns(tvb, pinfo, 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
|
|
|
else
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nbipx_dg(tvb, pinfo, tree);
|
1998-10-14 05:18:32 +00:00
|
|
|
}
|
|
|
|
|
1999-09-03 03:22:19 +00:00
|
|
|
static void
|
2000-11-10 21:09:49 +00:00
|
|
|
add_routers(proto_tree *tree, tvbuff_t *tvb, int offset)
|
1998-10-14 05:18:32 +00:00
|
|
|
{
|
1999-09-03 03:22:19 +00:00
|
|
|
int i;
|
|
|
|
int rtr_offset;
|
|
|
|
guint32 router;
|
|
|
|
|
|
|
|
/* Eight routers are listed */
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
rtr_offset = offset + (i << 2);
|
2000-11-10 21:09:49 +00:00
|
|
|
tvb_memcpy(tvb, (guint8 *)&router, rtr_offset, 4);
|
1999-09-03 03:22:19 +00:00
|
|
|
if (router != 0) {
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(tree, tvb, rtr_offset, 4,
|
|
|
|
"IPX Network: %s",
|
|
|
|
ipxnet_to_string((guint8*)&router));
|
1999-09-03 03:22:19 +00:00
|
|
|
}
|
|
|
|
}
|
1998-10-14 05:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nbipx_ns(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
|
1998-10-14 04:09:15 +00:00
|
|
|
{
|
1999-09-03 00:24:40 +00:00
|
|
|
proto_tree *nbipx_tree;
|
|
|
|
proto_item *ti;
|
2000-11-10 21:09:49 +00:00
|
|
|
int offset = 0;
|
1999-09-03 00:24:40 +00:00
|
|
|
guint8 packet_type;
|
1999-09-03 00:38:50 +00:00
|
|
|
guint8 name_type_flag;
|
|
|
|
proto_tree *name_type_flag_tree;
|
|
|
|
proto_item *tf;
|
1999-09-03 00:24:40 +00:00
|
|
|
char name[(NETBIOS_NAME_LEN - 1)*4 + 1];
|
|
|
|
int name_type;
|
1998-10-14 04:09:15 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
name_type_flag = tvb_get_guint8(tvb, offset+32);
|
|
|
|
packet_type = tvb_get_guint8(tvb, offset+33);
|
|
|
|
name_type = get_netbios_name(tvb, offset+34, name);
|
1998-10-14 04:09:15 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (check_col(pinfo->fd, COL_INFO)) {
|
1999-09-03 03:22:19 +00:00
|
|
|
switch (packet_type) {
|
|
|
|
case NBIPX_FIND_NAME:
|
|
|
|
case NBIPX_NAME_RECOGNIZED:
|
|
|
|
case NBIPX_CHECK_NAME:
|
|
|
|
case NBIPX_NAME_IN_USE:
|
|
|
|
case NBIPX_DEREGISTER_NAME:
|
2000-11-10 21:09:49 +00:00
|
|
|
col_add_fstr(pinfo->fd, COL_INFO, "%s %s<%02x>",
|
1999-09-03 03:22:19 +00:00
|
|
|
val_to_str(packet_type, nbipx_data_stream_type_vals, "Unknown"),
|
|
|
|
name, name_type);
|
|
|
|
break;
|
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
|
|
|
|
1999-09-03 03:22:19 +00:00
|
|
|
default:
|
2000-11-10 21:09:49 +00:00
|
|
|
col_add_fstr(pinfo->fd, COL_INFO, "%s",
|
1999-09-03 03:22:19 +00:00
|
|
|
val_to_str(packet_type, nbipx_data_stream_type_vals, "Unknown"));
|
|
|
|
break;
|
NBIPX packet type 3 appears to be the equivalent, in NBIPXland, of the
NetBIOS Datagram Service in NBTland; a capture Gilbert sent had a pile
of those packets containing what looked like SMB browser announcements,
which are sent out as broadcast datagrams. Label them as such, and
treat them as such.
Might packet type 2 be the equivalent of the NetBIOS Session Service -
both of them contain SMBs, but the former is a connection-oriented
service (LLC I frames, presumably, in NBF, and TCP in NBT), and the
latter is a datagram-oriented service (LLC UI frames, presumably, in
NBF, and UDP in NBT)? For now, we leave type 2 as "SMB (over NBIPX)",
but we might want to label it as "NetBIOS session" or whatever the
appropriate term is.
svn path=/trunk/; revision=574
1999-08-25 01:36:21 +00:00
|
|
|
}
|
1998-10-14 04:09:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (tree) {
|
2000-11-10 21:09:49 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_nbipx, tvb, offset, 50,
|
|
|
|
FALSE);
|
1999-11-16 11:44:20 +00:00
|
|
|
nbipx_tree = proto_item_add_subtree(ti, ett_nbipx);
|
1998-10-14 04:09:15 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
add_routers(nbipx_tree, tvb, offset);
|
1998-10-14 04:09:15 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
tf = proto_tree_add_text(nbipx_tree, tvb, offset+32, 1,
|
1999-09-03 03:22:19 +00:00
|
|
|
"Name type flag: 0x%02x", name_type_flag);
|
1999-09-03 00:38:50 +00:00
|
|
|
name_type_flag_tree = proto_item_add_subtree(tf,
|
1999-11-16 11:44:20 +00:00
|
|
|
ett_nbipx_name_type_flags);
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x80, 8,
|
|
|
|
"Group name", "Unique name"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x40, 8,
|
|
|
|
"Name in use", "Name not used"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x04, 8,
|
|
|
|
"Name registered", "Name not registered"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x02, 8,
|
|
|
|
"Name duplicated", "Name not duplicated"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x01, 8,
|
|
|
|
"Name deregistered", "Name not deregistered"));
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset+33, 1,
|
1999-09-03 03:22:19 +00:00
|
|
|
"Packet Type: %s (%02X)",
|
|
|
|
val_to_str(packet_type, nbipx_data_stream_type_vals, "Unknown"),
|
|
|
|
packet_type);
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
netbios_add_name("Name", tvb, offset + 34, nbipx_tree);
|
1998-10-14 05:18:32 +00:00
|
|
|
}
|
|
|
|
}
|
1998-10-14 04:09:15 +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
|
|
|
static void
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nbipx_dg(tvbuff_t *tvb, packet_info *pinfo, 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
|
|
|
{
|
|
|
|
proto_tree *nbipx_tree;
|
|
|
|
proto_item *ti;
|
2000-11-10 21:09:49 +00:00
|
|
|
int offset = 0;
|
|
|
|
guint8 packet_type;
|
|
|
|
tvbuff_t *next_tvb;
|
|
|
|
const guint8 *next_pd;
|
|
|
|
int next_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
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (check_col(pinfo->fd, COL_INFO))
|
|
|
|
col_add_fstr(pinfo->fd, COL_INFO, "NetBIOS datagram over NBIPX");
|
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 (tree) {
|
2000-11-10 21:09:49 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_nbipx, tvb, offset,
|
2000-05-31 05:09:07 +00:00
|
|
|
2+NETBIOS_NAME_LEN+NETBIOS_NAME_LEN, FALSE);
|
1999-11-16 11:44:20 +00:00
|
|
|
nbipx_tree = proto_item_add_subtree(ti, ett_nbipx);
|
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
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset, 1,
|
|
|
|
"Connection control: 0x%02x", tvb_get_guint8(tvb, offset));
|
1999-11-30 07:45:42 +00:00
|
|
|
offset += 1;
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
packet_type = tvb_get_guint8(tvb, offset);
|
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset, 1,
|
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
|
|
|
"Packet Type: %s (%02X)",
|
2000-11-10 21:09:49 +00:00
|
|
|
val_to_str(packet_type, nbipx_data_stream_type_vals, "Unknown"),
|
|
|
|
packet_type);
|
1999-11-30 07:45:42 +00:00
|
|
|
offset += 1;
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (!netbios_add_name("Receiver's Name", tvb, offset,
|
1999-11-30 07:45:42 +00:00
|
|
|
nbipx_tree))
|
|
|
|
return;
|
|
|
|
offset += NETBIOS_NAME_LEN;
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (!netbios_add_name("Sender's Name", tvb, offset,
|
1999-11-30 07:45:42 +00:00
|
|
|
nbipx_tree))
|
|
|
|
return;
|
|
|
|
offset += NETBIOS_NAME_LEN;
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (tvb_length_remaining(tvb, offset) != 0) {
|
|
|
|
next_tvb = tvb_new_subset(tvb, offset, -1, -1);
|
|
|
|
tvb_compat(next_tvb, &next_pd, &next_offset);
|
|
|
|
dissect_smb(next_pd, next_offset, pinfo->fd, tree,
|
|
|
|
tvb_length(next_tvb));
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2000-05-30 03:35:55 +00:00
|
|
|
static void
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_nwlink_dg(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
|
1999-09-03 03:22:19 +00:00
|
|
|
{
|
|
|
|
proto_tree *nbipx_tree;
|
|
|
|
proto_item *ti;
|
2000-11-10 21:09:49 +00:00
|
|
|
int offset = 0;
|
1999-09-03 03:22:19 +00:00
|
|
|
guint8 packet_type;
|
|
|
|
guint8 name_type_flag;
|
|
|
|
proto_tree *name_type_flag_tree;
|
|
|
|
proto_item *tf;
|
|
|
|
char name[(NETBIOS_NAME_LEN - 1)*4 + 1];
|
|
|
|
int name_type;
|
|
|
|
char node_name[(NETBIOS_NAME_LEN - 1)*4 + 1];
|
|
|
|
int node_name_type = 0;
|
2000-11-10 21:09:49 +00:00
|
|
|
tvbuff_t *next_tvb;
|
|
|
|
const guint8 *next_pd;
|
|
|
|
int next_offset;
|
1999-09-03 03:22:19 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
name_type_flag = tvb_get_guint8(tvb, offset+32);
|
|
|
|
packet_type = tvb_get_guint8(tvb, offset+33);
|
|
|
|
name_type = get_netbios_name(tvb, offset+36, name);
|
|
|
|
node_name_type = get_netbios_name(tvb, offset+52, node_name);
|
1999-09-03 03:22:19 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (check_col(pinfo->fd, COL_PROTOCOL))
|
|
|
|
col_add_str(pinfo->fd, COL_PROTOCOL, "NWLink");
|
1999-09-03 03:22:19 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (check_col(pinfo->fd, COL_INFO)) {
|
1999-09-03 03:22:19 +00:00
|
|
|
/*
|
|
|
|
* XXX - Microsoft Network Monitor thinks that the octet
|
|
|
|
* at 32 is a packet type, e.g. "mailslot write" for
|
|
|
|
* browser announcements, and that the octet at 33 is a
|
|
|
|
* name type, in the sense of the 16th byte of a
|
|
|
|
* NetBIOS name.
|
|
|
|
*
|
|
|
|
* A name type of 2 shows up in a "host announcement",
|
|
|
|
* and a name type of 3 shows up in a "local master
|
|
|
|
* annoumcement", so maybe that field really *is* a
|
|
|
|
* name type - the fact that it's not associated with
|
|
|
|
* any of the NetBIOS names in the packet nonwithstanding.
|
|
|
|
*
|
|
|
|
* I haven't seen any packets with the name type octet
|
|
|
|
* being anything other than 2 or 3, so I don't know
|
|
|
|
* whether those are name service operations; however,
|
|
|
|
* given that NWLink, unlike socket-0x0455 NBIPX,
|
|
|
|
* has separate sockets for name queries and datagrams,
|
|
|
|
* it may be that this really is a name type, and that
|
|
|
|
* these are all datagrams, not name queries.
|
|
|
|
*/
|
|
|
|
switch (packet_type) {
|
|
|
|
case NWLINK_NAME_QUERY:
|
2000-11-10 21:09:49 +00:00
|
|
|
col_add_fstr(pinfo->fd, COL_INFO, "Name Query for %s<%02x>",
|
1999-09-03 03:22:19 +00:00
|
|
|
name, name_type);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NWLINK_SMB:
|
|
|
|
/* Session? */
|
2000-11-10 21:09:49 +00:00
|
|
|
col_add_fstr(pinfo->fd, COL_INFO, "SMB over NBIPX");
|
1999-09-03 03:22:19 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case NWLINK_NETBIOS_DATAGRAM:
|
|
|
|
/* Datagram? (Where did we see this?) */
|
2000-11-10 21:09:49 +00:00
|
|
|
col_add_fstr(pinfo->fd, COL_INFO, "NetBIOS datagram over NBIPX");
|
1999-09-03 03:22:19 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2000-11-10 21:09:49 +00:00
|
|
|
col_add_str(pinfo->fd, COL_INFO, "NetBIOS over IPX (NWLink)");
|
1999-09-03 03:22:19 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tree) {
|
2000-11-10 21:09:49 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_nbipx, tvb, offset, 68, FALSE);
|
1999-11-16 11:44:20 +00:00
|
|
|
nbipx_tree = proto_item_add_subtree(ti, ett_nbipx);
|
1999-09-03 03:22:19 +00:00
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
add_routers(nbipx_tree, tvb, offset);
|
1999-09-03 03:22:19 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX - is "packet_type" really a packet type? See
|
|
|
|
* above.
|
|
|
|
*/
|
|
|
|
if (packet_type != NWLINK_SMB &&
|
|
|
|
packet_type != NWLINK_NETBIOS_DATAGRAM) {
|
2000-11-10 21:09:49 +00:00
|
|
|
tf = proto_tree_add_text(nbipx_tree, tvb, offset+32, 1,
|
1999-09-03 03:22:19 +00:00
|
|
|
"Name type flag: 0x%02x",
|
|
|
|
name_type_flag);
|
|
|
|
name_type_flag_tree = proto_item_add_subtree(tf,
|
1999-11-16 11:44:20 +00:00
|
|
|
ett_nbipx_name_type_flags);
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x80, 8,
|
|
|
|
"Group name", "Unique name"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x40, 8,
|
|
|
|
"Name in use", "Name not used"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x04, 8,
|
|
|
|
"Name registered", "Name not registered"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x02, 8,
|
|
|
|
"Name duplicated", "Name not duplicated"));
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(name_type_flag_tree, tvb, offset+32,
|
1999-09-03 03:22:19 +00:00
|
|
|
1, "%s",
|
|
|
|
decode_boolean_bitfield(name_type_flag, 0x01, 8,
|
|
|
|
"Name deregistered", "Name not deregistered"));
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (!netbios_add_name("Group name", tvb, offset+36,
|
1999-11-30 07:45:42 +00:00
|
|
|
nbipx_tree))
|
|
|
|
return;
|
2000-11-10 21:09:49 +00:00
|
|
|
if (!netbios_add_name("Node name", tvb, offset+52,
|
1999-11-30 07:45:42 +00:00
|
|
|
nbipx_tree))
|
|
|
|
return;
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset+33, 1,
|
1999-09-03 03:22:19 +00:00
|
|
|
"Packet Type: %s (%02X)",
|
|
|
|
val_to_str(packet_type, nwlink_data_stream_type_vals, "Unknown"),
|
|
|
|
packet_type);
|
|
|
|
} else {
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset+32, 1,
|
1999-09-03 03:22:19 +00:00
|
|
|
"Packet type: 0x%02x", name_type_flag);
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset+33, 1,
|
1999-09-03 03:22:19 +00:00
|
|
|
"Name Type: %s (0x%02x)",
|
|
|
|
netbios_name_type_descr(packet_type),
|
|
|
|
packet_type);
|
2000-11-10 21:09:49 +00:00
|
|
|
proto_tree_add_text(nbipx_tree, tvb, offset+34, 2,
|
|
|
|
"Message ID: 0x%04x",
|
|
|
|
tvb_get_letohs(tvb, offset+34));
|
|
|
|
if (!netbios_add_name("Requested name", tvb, offset+36,
|
1999-11-30 07:45:42 +00:00
|
|
|
nbipx_tree))
|
|
|
|
return;
|
2000-11-10 21:09:49 +00:00
|
|
|
if (!netbios_add_name("Source name", tvb, offset+52,
|
1999-11-30 07:45:42 +00:00
|
|
|
nbipx_tree))
|
|
|
|
return;
|
1999-09-03 03:22:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1999-11-30 07:45:42 +00:00
|
|
|
offset += 68;
|
|
|
|
|
2000-11-10 21:09:49 +00:00
|
|
|
if (tvb_length_remaining(tvb, offset) != 0) {
|
|
|
|
next_tvb = tvb_new_subset(tvb, offset, -1, -1);
|
|
|
|
|
1999-11-30 07:45:42 +00:00
|
|
|
switch (packet_type) {
|
|
|
|
case NWLINK_SMB:
|
|
|
|
case NWLINK_NETBIOS_DATAGRAM:
|
2000-11-10 21:09:49 +00:00
|
|
|
tvb_compat(next_tvb, &next_pd, &next_offset);
|
|
|
|
dissect_smb(next_pd, next_offset, pinfo->fd, tree,
|
|
|
|
tvb_length(next_tvb));
|
1999-11-30 07:45:42 +00:00
|
|
|
break;
|
1999-09-03 03:22:19 +00:00
|
|
|
|
1999-11-30 07:45:42 +00:00
|
|
|
default:
|
2000-11-10 21:09:49 +00:00
|
|
|
dissect_data(next_tvb, pinfo, tree);
|
1999-11-30 07:45:42 +00:00
|
|
|
break;
|
|
|
|
}
|
1999-09-03 03:22:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
void
|
|
|
|
proto_register_nbipx(void)
|
|
|
|
{
|
|
|
|
/* static hf_register_info hf[] = {
|
|
|
|
{ &variable,
|
|
|
|
{ "Name", "nbipx.abbreviation", TYPE, VALS_POINTER }},
|
|
|
|
};*/
|
1999-11-16 11:44:20 +00:00
|
|
|
static gint *ett[] = {
|
|
|
|
&ett_nbipx,
|
|
|
|
&ett_nbipx_name_type_flags,
|
|
|
|
};
|
1998-10-14 04:09:15 +00:00
|
|
|
|
1999-07-29 05:47:07 +00:00
|
|
|
proto_nbipx = proto_register_protocol("NetBIOS over IPX", "nbipx");
|
|
|
|
/* proto_register_field_array(proto_nbipx, hf, array_length(hf));*/
|
1999-11-16 11:44:20 +00:00
|
|
|
proto_register_subtree_array(ett, array_length(ett));
|
1999-07-29 05:47:07 +00:00
|
|
|
}
|
2000-05-30 03:35:55 +00:00
|
|
|
|
|
|
|
void
|
|
|
|
proto_reg_handoff_nbipx(void)
|
|
|
|
{
|
2000-11-10 21:09:49 +00:00
|
|
|
dissector_add("ipx.socket", IPX_SOCKET_NWLINK_SMB_DGRAM, dissect_nwlink_dg);
|
2000-05-30 03:35:55 +00:00
|
|
|
}
|