[Bluez-devel] bluetooth ethereal dissector

[Bluez-devel] bluetooth ethereal dissector

[Paul Ionescu]

Hi,

I am planning to make an ethereal dissector for bluetooth HCI
conversation for BlueZ Bluetooth stack.
In order to see this data, we have to load it first in ethereal.
I see two ways to do that:

1. Make libpcap hci aware, and let it capture hci data in normal pcap
file like tcpdump, then ethereal will be able to sniff live from hci0.

2. Make ethereal read capture files made with hcidump -w.

The first one seems better, but the second is easier.
What do you think ?

P.S. This message is posted on both ethereal and bluez development
lists.




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] bluetooth ethereal dissector

[James Courtier-Dutton]

Paul Ionescu wrote:
> Hi,
> 
> I am planning to make an ethereal dissector for bluetooth HCI
> conversation for BlueZ Bluetooth stack.
> In order to see this data, we have to load it first in ethereal.
> I see two ways to do that:
> 
> 1. Make libpcap hci aware, and let it capture hci data in normal pcap
> file like tcpdump, then ethereal will be able to sniff live from hci0.
> 
> 2. Make ethereal read capture files made with hcidump -w.
> 
> The first one seems better, but the second is easier.
> What do you think ?
> 
> P.S. This message is posted on both ethereal and bluez development
> lists.
> 
The affix,"http://affix.sourceforge.net/", bluetooth stack for linux 
already has an interface to ethereal, so it might be worth using the 
same api as affix has with ethereal, thus sharing the amount of 
development work needed to be done.

Cheers
James




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] bluetooth ethereal dissector

[Marcel Holtmann]

Hi Paul,

> I am planning to make an ethereal dissector for bluetooth HCI
> conversation for BlueZ Bluetooth stack.
> In order to see this data, we have to load it first in ethereal.
> I see two ways to do that:
> 
> 1. Make libpcap hci aware, and let it capture hci data in normal pcap
> file like tcpdump, then ethereal will be able to sniff live from hci0.

from my point of view this is not a good idea, because libpcap is for
Ethernet traffic. But ask the libpcap guys what they think about it.

> 2. Make ethereal read capture files made with hcidump -w.

This should be the way to go, because live capturing is not always what
you want. However ethereal can read from stdin and we can modifiy
hcidump to output the raw packages to stdout.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] bluetooth ethereal dissector

[Marcel Holtmann]

Hi James,

> The affix,"http://affix.sourceforge.net/", bluetooth stack for linux 
> already has an interface to ethereal, so it might be worth using the 
> same api as affix has with ethereal, thus sharing the amount of 
> development work needed to be done.

what kind of API are you talking about? You can hack the code for Affix
dumps to read the output of BlueZ hcidump and hope everything works.

Actually I would start from scratch to make sure that the HCI traffic
and higher protocol decoding is working correctly. If you want to write
a real good decoder you also must cache the SDP information from
previous requests, because this can contain data about PSM numbers,
RFCOMM channels, HID descriptors etc.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Guy Harris]

On Oct 29, 2003, at 3:07 AM, Marcel Holtmann wrote:
> from my point of view this is not a good idea, because libpcap is for
> Ethernet traffic. But ask the libpcap guys what they think about it.

Well, as one of the libpcap people, I'd first like to note that libpcap 
is also for UNIX loopback (when the UNIX system in question lets you 
capture on it), Token Ring, ARCNET, SLIP, PPP, FDDI, ATM, Cisco HDLC, 
802.11, Frame Relay, LocalTalk, IP-over-Fibre-Channel, etc. traffic - 
there's nothing magical about Ethernet (other than the fact that it's 
displacing more and more network types over time).

If a given type of link-layer interface can act as a network interface 
(in the sense of something that "ifconfig" on UNIX can tell you about, 
or that plugs into NDIS on Windows), you can probably capture on it.  
Depending on the OS on which you're running, you might even be able to 
see all the link-layer traffic, not just the stuff that gets handed to 
network protocol handlers such as IP.

The current CVS version of libpcap lets you plug in (at compile time) 
modules to let you open for capturing devices *other* than network 
interfaces, such as the DAG cards from Endace (it was put in for them, 
but it should be usable for other devices as well).

>> 2. Make ethereal read capture files made with hcidump -w.
>
> This should be the way to go, because live capturing is not always what
> you want.

Yes, but that doesn't *exclude* support for libpcap-based live 
capturing; a Wiretap module to read "hcidump -w" files would be useful, 
but if that's added you might still want support for libpcap-based 
capturing.

>  However ethereal can read from stdin

Within limits - if you're loading a saved capture, you have to read 
from a file (Ethereal needs to be able to go back and read packet data 
again), but you can "capture from a pipe", at least on UNIX - but that 
requires that the capture be written in libpcap format.

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Guy Harris]

On Oct 29, 2003, at 12:54 AM, James Courtier-Dutton wrote:

> The affix,"http://affix.sourceforge.net/", bluetooth stack for linux

(Did they know what they were doing when they added the PF_AFFIX 
protocol type for HCI SCO sockets, or was it a pure accident that 
BTPROTO_HCISCO ends with "CISCO"? :-))

>  already has an interface to ethereal,

Their support is a bit, err, umm, odd.

The Ethereal patch contains:

	1) a bunch of dissectors, which don't actually do any *capturing* - it 
appears that the HCI dissector registers itself with Ethertype 0xb123, 
so it appears to assume that the packets in the capture look like 
Ethernet packets, with the Bluetooth stuff inside Ethereal payload;

	2) a "capture-affix-pcap.c", which appears to be the "load WinPcap at 
run time" code, modified to load a UNIX-style "libpcap.so" at run time.

2) seems not to be particularly useful - if you've dynamically-linked 
Ethereal, it should *already* load "libpcap.so" at start-up time (at 
least if ".so" is your OS's dynamically-linked library suffix).  It 
also doesn't appear to include any code to *call* the routine to load 
"libpcap.so" at run time.

I assume that the affix people have a modified version of libpcap that 
uses some mechanism (Bluetooth sockets?) to capture Bluetooth packets; 
however, it doesn't appear to be in the Ethereal patch for affix, nor 
can I find it in either the affix-kernel-2.0.2 or the affix-2.0.2 
stable or testing tarballs.

So I don't see any evidence of any support for Bluetooth capture with 
Ethereal, unless they've cleverly hidden their modified libpcap 
somewhere.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Hi Guy,

> >> 2. Make ethereal read capture files made with hcidump -w.
> >
> > This should be the way to go, because live capturing is not always what
> > you want.
> 
> Yes, but that doesn't *exclude* support for libpcap-based live 
> capturing; a Wiretap module to read "hcidump -w" files would be useful, 
> but if that's added you might still want support for libpcap-based 
> capturing.

here is my patch that adds a Wiretap module for reading files created
with "hcidump -w".

Regards

Marcel


[-- Attachment #2: patch-ethereal-hcidump --]
[-- Type: text/x-patch, Size: 9055 bytes --]

diff -urN ethereal/wiretap/AUTHORS ethereal-mh/wiretap/AUTHORS
--- ethereal/wiretap/AUTHORS	Tue Aug 26 09:10:38 2003
+++ ethereal-mh/wiretap/AUTHORS	Thu Oct 30 03:46:02 2003
@@ -18,5 +18,6 @@
 Mark C. Brown		<mbrown[AT]nosila.net>
 Martin Warnes		<martin.warnes[AT]ntlworld.com>
 Thierry Martin		<thierry.martin[AT]accellent-group.com>
-Jesper Peterson		<jesper [AT] endace.com>
+Jesper Peterson		<jesper[AT]endace.com>
+Marcel Holtmann		<marcel[AT]holtmann.org>
 
diff -urN ethereal/wiretap/Makefile.am ethereal-mh/wiretap/Makefile.am
--- ethereal/wiretap/Makefile.am	Tue Aug 26 09:10:38 2003
+++ ethereal-mh/wiretap/Makefile.am	Thu Oct 30 03:38:06 2003
@@ -54,6 +54,8 @@
 	file_access.c		\
 	file_wrappers.c		\
 	file_wrappers.h		\
+	hcidump.c		\
+	hcidump.h		\
 	i4btrace.c		\
 	i4btrace.h		\
 	i4b_trace.h		\
diff -urN ethereal/wiretap/file_access.c ethereal-mh/wiretap/file_access.c
--- ethereal/wiretap/file_access.c	Tue Oct 21 10:03:13 2003
+++ ethereal-mh/wiretap/file_access.c	Thu Oct 30 03:38:25 2003
@@ -70,6 +70,7 @@
 #include "cosine.h"
 #include "5views.h"
 #include "erf.h"
+#include "hcidump.h"
 
 /* The open_file_* routines should return:
  *
@@ -120,6 +121,7 @@
 	dbs_etherwatch_open,
 	cosine_open,
 	erf_open,
+	hcidump_open,
 };
 
 #define	N_FILE_TYPES	(sizeof open_routines / sizeof open_routines[0])
@@ -434,6 +436,10 @@
 
 	/* WTAP_FILE_ERF */
 	{ "Endace DAG capture", "erf",
+	  NULL, NULL },
+
+	/* WTAP_FILE_HCIDUMP */
+	{ "Bluetooth HCI dump", "hcidump",
 	  NULL, NULL },
 };
 
diff -urN ethereal/wiretap/hcidump.c ethereal-mh/wiretap/hcidump.c
--- ethereal/wiretap/hcidump.c	Thu Jan  1 01:00:00 1970
+++ ethereal-mh/wiretap/hcidump.c	Thu Oct 30 03:38:12 2003
@@ -0,0 +1,175 @@
+/* hcidump.c
+ *
+ * $Id: hcidump.c,v 1.24 2002/08/28 20:30:45 holtmann Exp $
+ *
+ * Copyright (c) 2003 by Marcel Holtmann <marcel@holtmann.org>
+ *
+ * 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
+
+#include "wtap-int.h"
+#include "file_wrappers.h"
+#include "buffer.h"
+#include "hcidump.h"
+
+#include <endian.h>
+#include <byteswap.h>
+
+/* Byte order conversions */
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define htobs(d)  (d)
+#define htobl(d)  (d)
+#define btohs(d)  (d)
+#define btohl(d)  (d)
+#elif __BYTE_ORDER == __BIG_ENDIAN
+#define htobs(d)  bswap_16(d)
+#define htobl(d)  bswap_32(d)
+#define btohs(d)  bswap_16(d)
+#define btohl(d)  bswap_32(d)
+#else
+#error "Unknown byte order"
+#endif
+
+struct dump_hdr {
+	guint16 len;
+	guint8  in;
+	guint8  pad;
+	guint32 ts_sec;
+	guint32 ts_usec;
+} __attribute__ ((packed));
+
+#define DUMP_HDR_SIZE (sizeof(struct dump_hdr))
+
+static gboolean hcidump_read(wtap *wth, int *err, long *data_offset)
+{
+	struct dump_hdr dh;
+	guint8 *buf;
+	int bytes_read, packet_size;
+
+	*data_offset = wth->data_offset;
+
+	bytes_read = file_read(&dh, 1, DUMP_HDR_SIZE, wth->fh);
+	if (bytes_read != DUMP_HDR_SIZE) {
+		*err = file_error(wth->fh);
+		if (*err == 0 && bytes_read != 0)
+			*err = WTAP_ERR_SHORT_READ;
+		return FALSE;
+	}
+	wth->data_offset += DUMP_HDR_SIZE;
+
+	packet_size = btohs(dh.len);
+	if (packet_size > WTAP_MAX_PACKET_SIZE) {
+		/*
+		 * Probably a corrupt capture file; don't blow up trying
+		 * to allocate space for an immensely-large packet.
+		 */
+		g_message("hcidump: File has %u-byte packet, bigger than maximum of %u",
+			packet_size, WTAP_MAX_PACKET_SIZE);
+		*err = WTAP_ERR_BAD_RECORD;
+		return FALSE;
+	}
+
+	buffer_assure_space(wth->frame_buffer, packet_size);
+	buf = buffer_start_ptr(wth->frame_buffer);
+
+	bytes_read = file_read(buf, 1, packet_size, wth->fh);
+	if (bytes_read != packet_size) {
+		*err = file_error(wth->fh);
+		if (*err == 0)
+			*err = WTAP_ERR_SHORT_READ;
+		return FALSE;
+	}
+	wth->data_offset += packet_size;
+
+	wth->phdr.ts.tv_sec = btohl(dh.ts_sec);
+	wth->phdr.ts.tv_usec = btohl(dh.ts_usec);
+	wth->phdr.caplen = packet_size;
+	wth->phdr.len = packet_size;
+	wth->phdr.pkt_encap = WTAP_ENCAP_BLUETOOTH_H4;
+
+	wth->pseudo_header.p2p.sent = (dh.in ? FALSE : TRUE);
+
+	return TRUE;
+}
+
+static gboolean hcidump_seek_read(wtap *wth, long seek_off, union wtap_pseudo_header *pseudo_header, guint8 *pd, int length, int *err)
+{
+	struct dump_hdr dh;
+	int bytes_read;
+
+	if (file_seek(wth->random_fh, seek_off, SEEK_SET, err) == -1)
+		return FALSE;
+
+	bytes_read = file_read(&dh, 1, DUMP_HDR_SIZE, wth->random_fh);
+	if (bytes_read != DUMP_HDR_SIZE) {
+		*err = file_error(wth->random_fh);
+		if (*err == 0 && bytes_read != 0)
+			*err = WTAP_ERR_SHORT_READ;
+		return FALSE;
+	}
+
+	bytes_read = file_read(pd, 1, length, wth->random_fh);
+	if (bytes_read != length) {
+		*err = file_error(wth->random_fh);
+		if (*err == 0)
+			*err = WTAP_ERR_SHORT_READ;
+		return FALSE;
+	}
+
+	pseudo_header->p2p.sent = (dh.in ? FALSE : TRUE);
+
+	return TRUE;
+}
+
+int hcidump_open(wtap *wth, int *err)
+{
+	struct dump_hdr dh;
+	guint8 type;
+	int bytes_read;
+
+	bytes_read = file_read(&dh, 1, DUMP_HDR_SIZE, wth->fh);
+	if (bytes_read != DUMP_HDR_SIZE) {
+		*err = file_error(wth->fh);
+		return (*err != 0) ? -1 : 0;
+	}
+
+	if (dh.in != 0 && dh.in != 1 && dh.pad != 0 && btohs(dh.len) < 1)
+		return 0;
+
+	bytes_read = file_read(&type, 1, 1, wth->fh);
+	if (bytes_read != 1) {
+		*err = file_error(wth->fh);
+		return (*err != 0) ? -1 : 0;
+	}
+
+	if (type < 1 || type > 4)
+		return 0;
+
+	if (file_seek(wth->fh, 0, SEEK_SET, err) == -1)
+		return -1;
+
+	wth->file_type = WTAP_FILE_HCIDUMP;
+	wth->file_encap = WTAP_ENCAP_BLUETOOTH_H4;
+	wth->snapshot_length = 0;
+
+	wth->subtype_read = hcidump_read;
+	wth->subtype_seek_read = hcidump_seek_read;
+
+	return 1;
+}
diff -urN ethereal/wiretap/hcidump.h ethereal-mh/wiretap/hcidump.h
--- ethereal/wiretap/hcidump.h	Thu Jan  1 01:00:00 1970
+++ ethereal-mh/wiretap/hcidump.h	Thu Oct 30 03:38:12 2003
@@ -0,0 +1,28 @@
+/* hcidump.h
+ *
+ * $Id: hcidump.h,v 1.3 2002/08/28 20:30:45 holtmann Exp $
+ *
+ * Copyright (c) 2003 by Marcel Holtmann <marcel@holtmann.org>
+ *
+ * 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.
+ *
+ */
+
+#ifndef __HCIDUMP_H__
+#define __HCIDUMP_H__
+
+int hcidump_open(wtap *wth, int *err);
+
+#endif
diff -urN ethereal/wiretap/wtap.h ethereal-mh/wiretap/wtap.h
--- ethereal/wiretap/wtap.h	Wed Oct 29 22:44:11 2003
+++ ethereal-mh/wiretap/wtap.h	Thu Oct 30 03:38:19 2003
@@ -129,9 +129,10 @@
 #define WTAP_ENCAP_ENC				37
 #define WTAP_ENCAP_PFLOG			38
 #define WTAP_ENCAP_CHDLC_WITH_PHDR		39
+#define WTAP_ENCAP_BLUETOOTH_H4			40
 
 /* last WTAP_ENCAP_ value + 1 */
-#define WTAP_NUM_ENCAP_TYPES			40
+#define WTAP_NUM_ENCAP_TYPES			41
 
 /* File types that can be read by wiretap.
    We support writing some many of these file types, too, so we
@@ -172,9 +173,10 @@
 #define WTAP_FILE_COSINE			33
 #define WTAP_FILE_5VIEWS			34
 #define WTAP_FILE_ERF				35
+#define WTAP_FILE_HCIDUMP			36
 
 /* last WTAP_FILE_ value + 1 */
-#define WTAP_NUM_FILE_TYPES			36
+#define WTAP_NUM_FILE_TYPES			37
 
 /*
  * Maximum packet size we'll support.
@@ -350,7 +352,7 @@
 struct cosine_phdr {
 	guint8 encap;		/* COSINE_ENCAP_* as defined above */
 	guint8 direction;	/* COSINE_DIR_*, as defined above */
-        char if_name[COSINE_MAX_IF_NAME_LEN];  /* Encap & Logical I/F name */
+	char if_name[COSINE_MAX_IF_NAME_LEN];  /* Encap & Logical I/F name */
 	guint16 pro;		/* Protocol */
 	guint16 off;		/* Offset */
 	guint16 pri;		/* Priority */

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Guy Harris]

On Oct 29, 2003, at 6:50 PM, Marcel Holtmann wrote:

> here is my patch that adds a Wiretap module for reading files created
> with "hcidump -w".

Checked in, with wiretap/Makefile.nmake updated to build it, with the 
__attribute((packed))__ stuff removed (not all compilers used to build 
Wiretap support it, and there are no fields in there that would require 
padding), and with the byte swapping done with "g_ntohs()" and 
"g_ntohl()" so it doesn't have to include headers not found on all 
platforms.

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Guy Harris]

On Oct 29, 2003, at 6:50 PM, Marcel Holtmann wrote:

> here is my patch that adds a Wiretap module for reading files created
> with "hcidump -w".

OK, it reads them - but it supplies a link-layer encapsulation type of 
WTAP_ENCAP_BLUETOOTH_H4, for which there isn't any dissector.  Do you 
have dissectors for various Bluetooth protocols, or should we take the 
ones from the affix patches to Ethereal and modify one of them (HCI?) 
to register for an encapsulation of WTAP_ENCAP_BLUETOOTH_H4?

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

Hi Guy,

> > here is my patch that adds a Wiretap module for reading files created
> > with "hcidump -w".
> 
> Checked in, with wiretap/Makefile.nmake updated to build it, with the 
> __attribute((packed))__ stuff removed (not all compilers used to build 
> Wiretap support it, and there are no fields in there that would require 
> padding), and with the byte swapping done with "g_ntohs()" and 
> "g_ntohl()" so it doesn't have to include headers not found on all 
> platforms.

sorry for the nmake stuff, but I always forget them :(

Attached is another patch against CVS, which re-introduces the byte
swapping, because the ntohs/ntohl are not working in this case. I used
the GLIB macros and so it should be portable now. I also use the macro
_U_ for __attribute((packed))__ and this should be portable, too.

Regards

Marcel


[-- Attachment #2: patch-ethereal-hcidump-2 --]
[-- Type: text/x-patch, Size: 1722 bytes --]

diff -urN ethereal/wiretap/hcidump.c ethereal-mh/wiretap/hcidump.c
--- ethereal/wiretap/hcidump.c	Thu Oct 30 04:11:02 2003
+++ ethereal-mh/wiretap/hcidump.c	Thu Oct 30 12:16:17 2003
@@ -28,13 +28,27 @@
 #include "buffer.h"
 #include "hcidump.h"
 
+#if G_BYTE_ORDER == G_LITTLE_ENDIAN
+#define htobs(val)  (val)
+#define htobl(val)  (val)
+#define btohs(val)  (val)
+#define btohl(val)  (val)
+#elif G_BYTE_ORDER == G_BIG_ENDIAN
+#define htobs(val)  GUINT16_SWAP_LE_BE(val)
+#define htobl(val)  GUINT32_SWAP_LE_BE(val)
+#define btohs(val)  GUINT16_SWAP_LE_BE(val)
+#define btohl(val)  GUINT32_SWAP_LE_BE(val)
+#else
+#error unknown ENDIAN type
+#endif
+
 struct dump_hdr {
 	guint16 len;
 	guint8  in;
 	guint8  pad;
 	guint32 ts_sec;
 	guint32 ts_usec;
-};
+} _U_;
 
 #define DUMP_HDR_SIZE (sizeof(struct dump_hdr))
 
@@ -55,7 +69,7 @@
 	}
 	wth->data_offset += DUMP_HDR_SIZE;
 
-	packet_size = g_ntohs(dh.len);
+	packet_size = btohs(dh.len);
 	if (packet_size > WTAP_MAX_PACKET_SIZE) {
 		/*
 		 * Probably a corrupt capture file; don't blow up trying
@@ -79,8 +93,8 @@
 	}
 	wth->data_offset += packet_size;
 
-	wth->phdr.ts.tv_sec = g_ntohl(dh.ts_sec);
-	wth->phdr.ts.tv_usec = g_ntohl(dh.ts_usec);
+	wth->phdr.ts.tv_sec = btohl(dh.ts_sec);
+	wth->phdr.ts.tv_usec = btohl(dh.ts_usec);
 	wth->phdr.caplen = packet_size;
 	wth->phdr.len = packet_size;
 	wth->phdr.pkt_encap = WTAP_ENCAP_BLUETOOTH_H4;
@@ -131,7 +145,7 @@
 		return (*err != 0) ? -1 : 0;
 	}
 
-	if (dh.in != 0 && dh.in != 1 && dh.pad != 0 && g_ntohs(dh.len) < 1)
+	if (dh.in != 0 && dh.in != 1 && dh.pad != 0 && btohs(dh.len) < 1)
 		return 0;
 
 	bytes_read = file_read(&type, 1, 1, wth->fh);

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Guy Harris]

On Thu, Oct 30, 2003 at 12:39:46PM +0100, Marcel Holtmann wrote:
> Attached is another patch against CVS, which re-introduces the byte
> swapping,

I've checked in a change to replace g_ntohs with GUINT16_FROM_LE and to
replace g_ntohl with GUINT32_FROM_LE.

> I also use the macro _U_ for __attribute((packed))__

The macro _U_ is defined as __attribute__((unused)), not
__attribute((packed))__.

If __attribute((packed))__ is *required* in order to make it work, then
you need to find some *other* way to make it work - conditionally using
__attribute((packed))__ or not depending on whether GCC is being used or
not won't help.  For example, define the structure as an array of bytes,
or as a sequence of arrays of bytes, and use the "pletoh" macros to
extract values from them.

However, I see nothing that would *require* __attribute((packed))__.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Marcel Holtmann]

Hi Guy,

> > here is my patch that adds a Wiretap module for reading files created
> > with "hcidump -w".
> 
> OK, it reads them - but it supplies a link-layer encapsulation type of 
> WTAP_ENCAP_BLUETOOTH_H4, for which there isn't any dissector.  Do you 
> have dissectors for various Bluetooth protocols, or should we take the 
> ones from the affix patches to Ethereal and modify one of them (HCI?) 
> to register for an encapsulation of WTAP_ENCAP_BLUETOOTH_H4?

it is the first step ;)

Actually I don't want to use the Affix code, because I don't like the
idea of using code that I don't understand. And at the moment I have
limited knowlodge how the Ethereal dissectors work.

However the Bluetooth H4 format is a standard definied in the Bluetooth
specification and my plan is to write a packet-bt-hci.c dissector that
can decode it. All other Bluetooth layers like L2CAP, RFCOMM, BNEP etc.
should be done by someone else. The HCI dissector is the important one,
because it can make it reusable for other Bluetooth protocol stacks and
my plan is to do it from scratch and not hacking the current Affix code.

Regards

Marcel
 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Ethereal-dev] Re: [Bluez-devel] bluetooth ethereal dissector

[Marcel Holtmann]

Hi Guy,

> > Attached is another patch against CVS, which re-introduces the byte
> > swapping,
> 
> I've checked in a change to replace g_ntohs with GUINT16_FROM_LE and to
> replace g_ntohl with GUINT32_FROM_LE.

works fine now on my x86 machine.

> > I also use the macro _U_ for __attribute((packed))__
> 
> The macro _U_ is defined as __attribute__((unused)), not
> __attribute((packed))__.

I am feeling so stupid :(

> If __attribute((packed))__ is *required* in order to make it work, then
> you need to find some *other* way to make it work - conditionally using
> __attribute((packed))__ or not depending on whether GCC is being used or
> not won't help.  For example, define the structure as an array of bytes,
> or as a sequence of arrays of bytes, and use the "pletoh" macros to
> extract values from them.

It works for me now and until anyone shows us otherwise, lets leave it
out.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel