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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
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?
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
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel