Wireshark

Wireshark

[Kevin Jones]

Hi,

I have done some work on a version of the Wireshark plugin to 
re-structure it so it may be possible to push upstream at some point. At 
the moment it handles connection establishment, setting up some 
conversational state tracking and decoding a few of the message types. 
Supporting other message types is now fairly straight forward but will 
take some time to work through to double check the decoding logic is up 
to date and change to a new decoding style.

At this point I was thinking maybe would be better to check-in as an 
alternative to the existing plugin so there is a base to work 
incrementally towards the upstream goal. Sound like a good approach?

Regards
Kev

Re: Wireshark

[Sage Weil]

On Thu, 27 Jun 2013, Kevin Jones wrote:
> Hi,
> 
> I have done some work on a version of the Wireshark plugin to re-structure it
> so it may be possible to push upstream at some point. At the moment it handles
> connection establishment, setting up some conversational state tracking and
> decoding a few of the message types. Supporting other message types is now
> fairly straight forward but will take some time to work through to double
> check the decoding logic is up to date and change to a new decoding style.
> 
> At this point I was thinking maybe would be better to check-in as an
> alternative to the existing plugin so there is a base to work incrementally
> towards the upstream goal. Sound like a good approach?

Sounds great!  I can't wait to see this make its way upstream.  :)

Thanks!
sage

Re: Wireshark

[Kevin Jones]

Hi Sage,

I tried sending a patch for this but think it probably bounced due to 
size so have opened a pull request instead, 
https://github.com/ceph/ceph/pull/396. Needs more work of course but a 
starting point.

Regards
Kev

wireshark

[akuster808]

Hello,

I am working in wireshark to 1.12.2 update ( trying to avoid dup work). 
I contains several security fixes.

Hope to have it posted today.

- Armin

wireshark

[J. Bruce Fields]

I've been getting frequent crashes with the latest wireshark.  I think
it's fixed in:

	git://linux-nfs.org/~bfields/wireshark.git master

I'll probably try to add seek and allocate support while I'm there, and
pass it to wireshark upstream when I've got it better figured out.

--b.

Re: wireshark

[J. Bruce Fields]

On Mon, Oct 27, 2014 at 06:08:48PM -0400, bfields wrote:
> I've been getting frequent crashes with the latest wireshark.  I think
> it's fixed in:
> 
> 	git://linux-nfs.org/~bfields/wireshark.git master
> 
> I'll probably try to add seek and allocate support while I'm there, and
> pass it to wireshark upstream when I've got it better figured out.

Done, but not upstream yet.  Till then, something like:

	git clone git://linux-nfs.org/~bfields/wireshark.git
	cd wireshark
	./autogen.sh
	./configure
	make

should work.  (And you may discover you need to install some -devel
packages after the next-to-last step.)

--b.

Wireshark

[Michal.Labedzki]

Hello All,

I am trying to add full Bluetooth support to a Wireshark. Wireshark can be
used as replacement for "hcidump" or other GUI applications for displaying
Bluetooth frames/packets.

Currently Wireshark support:
1. Sniffing via Bluetooth dongle
2. Protocols/Profiles:
    HCI (without BLE)
    L2CAP
    SDP (little broken)
    RFCOMM 1.1
    OBEX (so all OBEX profiles can be treat as supported)
    AMP
    HID 1.0
    SAP 1.1
    BNEP 1.0
    AVCTP 1.4
    AVRCP 1.5

At this moment I am working on: (finishing)
1. ATT
2. HCRP
3. MCAP
4. AVDTP/A2DP/VDP

So I need a lot of Bluetooth logs to test them. Could you send me all your
logs? Profile or protocol there is not important [SAP? OK!], but only
BT SNOOP format is requires, of course PCAP too. Please share your logs, to my e-mail or wherever you want,.
I guess logs may be useful for other BlueZ developer too (so... logs database?)

I will be very happy if somebody send me AVDTP/A2DP/VDP logs where used all
known codecs (mean MPEG12_AUDIO//MPEG24_AAC/ATRAC/ H263/MPEG4)


Try Wireshark :)

PS. "tshark  -r hcidump.log" is similar to "hcidump"


Regards / Pozdrawiam
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki
ASCII: Michal Labedzki
e-mail: michal.labedzki@tieto.com

---
Tieto Corporation / Tieto Poland
http://www.tieto.com / http://www.tieto.pl
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN

Re: Wireshark

[Johan Hedberg]

Hi Michal,

On Fri, Sep 28, 2012, Michal.Labedzki@tieto.com wrote:
> I am trying to add full Bluetooth support to a Wireshark. Wireshark can be
> used as replacement for "hcidump" or other GUI applications for displaying
> Bluetooth frames/packets.
> 
> Currently Wireshark support:
> 1. Sniffing via Bluetooth dongle
> 2. Protocols/Profiles:
>     HCI (without BLE)
>     L2CAP
>     SDP (little broken)
>     RFCOMM 1.1
>     OBEX (so all OBEX profiles can be treat as supported)
>     AMP
>     HID 1.0
>     SAP 1.1
>     BNEP 1.0
>     AVCTP 1.4
>     AVRCP 1.5
> 
> At this moment I am working on: (finishing)
> 1. ATT
> 2. HCRP
> 3. MCAP
> 4. AVDTP/A2DP/VDP

Have you looked into supporting the new HCI_CHANNEL_MONITOR available in
recent kernels? There's a very simple "btmon" command-line tool for it
in bluez.git (see e.g. monitor/control.c) but it can't do any kind of
high-level decoding (e.g. profiles). It'd be interesting to know if it
could be easily supported in wireshark since right now there doesn't
seem to be a viable way of porting decoders from hcidump to btmon due to
their very different ways of handling buffers etc.

One of the big benefits of the monitor channel compared traditional HCI
sockets is that you get dynamic notifications of added and removed
adapters including the very early HCI traffic that occurs. In the long
run I think the idea is to add also "replay" connection events for
existing ACL and L2CAP links so that you'd get the right protocol
decoded even if you start logging when the connection already exists.

Johan

Re: Wireshark

[Marcel Holtmann]

Hi Michal,

> Have you looked into supporting the new HCI_CHANNEL_MONITOR available in
> recent kernels? There's a very simple "btmon" command-line tool for it
> in bluez.git (see e.g. monitor/control.c) but it can't do any kind of
> high-level decoding (e.g. profiles). It'd be interesting to know if it
> could be easily supported in wireshark since right now there doesn't
> seem to be a viable way of porting decoders from hcidump to btmon due to
> their very different ways of handling buffers etc.
> 
> One of the big benefits of the monitor channel compared traditional HCI
> sockets is that you get dynamic notifications of added and removed
> adapters including the very early HCI traffic that occurs. In the long
> run I think the idea is to add also "replay" connection events for
> existing ACL and L2CAP links so that you'd get the right protocol
> decoded even if you start logging when the connection already exists.

I can only second this. Wireshark should only be using the new monitor
socket that we introduced. It could be compared to the pseudo interface
for network interfaces with extra information about added and removed
adapters. It will also tell you if you see a BR/EDR/LE controller vs AMP
controller HCI device.

Especially if you want to do Bluetooth High-Speed debugging, you need to
be able to trace a BR/EDR/LE controller + AMP controller at the same
time.

In addition it will tell you the BD_ADDR of the controller even if you
missed the initial setup HCI packets. That allows for an unique matching
of traffic from different HCI devices even after unplug-replug and their
device names and indexes differ.

The protocol for it is documented in include/net/bluetooth/hci_mon.h in
the kernel code. It is really simple and does support SCM_TIMESTAMP.

Regards

Marcel

Re: Wireshark

[Andrei Emeltchenko]

Hi Michał,

On Fri, Sep 28, 2012 at 04:07:44PM +0300, Michal.Labedzki@tieto.com wrote:
> Hello All,
> 
> I am trying to add full Bluetooth support to a Wireshark. Wireshark can be
> used as replacement for "hcidump" or other GUI applications for displaying
> Bluetooth frames/packets.
> 
> Currently Wireshark support:
> 1. Sniffing via Bluetooth dongle
> 2. Protocols/Profiles:
>     HCI (without BLE)

HCI also does not have full support for AMP HCI commands. I can send that
log.

Best regards 
Andrei Emeltchenko 

RE: Wireshark

[Michal.Labedzki]

Hello,

> HCI also does not have full support for AMP HCI commands. I can send that
> log.

All logs are welcome. Andrei, please send it.

> but it can't do any kind of
> high-level decoding (e.g. profiles). It'd be interesting to know if it
> could be easily supported in wireshark since right now there doesn't
> seem to be a viable way of porting decoders from hcidump to btmon due to
> their very different ways of handling buffers etc.

Johan, I guess Wireshark support decoding what do you need (expect ongoing tasks). If you have another idea how do decoding, please share it. Power of Wireshark is:
1. Decoding all fields in protocols (+ user friendly describes and visualization bit/byte position in the frame)
2. Colors per protocol/profile to improve readability;
3. Possibility to display specified field as column (like Protocol, Length, Info; for example I display btl2cap.cid, btrfcomm.channel) [by the way, I have configured Wireshark to display column "Time" as "Absolute date and time" and additional "Delta" as "Delta time" - nice combination to working on timings]
4. Filtering logs, in Filter field you can but "btavrcp" and you see only AVRCP; or something like "btbnep.bnep_type == 0x01 || bthci_evt" - so you can display only HCI Events and BNEP packet where BNEP Type is equal 0x01.
5. (Menu) Statistics -> IO Graph, then "Y Axis -> Unit -> Bytes per Tick" and using filters - you can analyse throughput (for example: OPP, A2DP)
6. pcap file format can contain "Comments" - so everyone can share some useful additional information (per frame)


Example logs:
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9186
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9187
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9139
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9111
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9112
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9023
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9024
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9025
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7686

You can obtain Wireshark from SVN or GIT:
    svn co http://anonsvn.wireshark.org/wireshark/trunk/ wireshark
    git clone http://code.wireshark.org/git/wireshark    (I use only this one, but please note sometimes this way may not working...)

Installation:
not required: ./autogen.sh && ./configure && make -j 16 && ./wireshark

Regards / Pozdrawiam
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki
ASCII: Michal Labedzki
e-mail: michal.labedzki@tieto.com
location: Poland, Wrocław, Legnicka 55F
---
Tieto Corporation / Tieto Poland
http://www.tieto.com / http://www.tieto.pl
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN

Re: Wireshark

[Johan Hedberg]

Hi Michal,

On Wed, Oct 03, 2012, Michal.Labedzki@tieto.com wrote:
> > but it can't do any kind of high-level decoding (e.g. profiles).
> > It'd be interesting to know if it could be easily supported in
> > wireshark since right now there doesn't seem to be a viable way of
> > porting decoders from hcidump to btmon due to their very different
> > ways of handling buffers etc.
> 
> Johan, I guess Wireshark support decoding what do you need (expect
> ongoing tasks). If you have another idea how do decoding, please share
> it. Power of Wireshark is:

I think you must have misunderstood what I was trying to say. Did you
actually look into what the monitor socket we talked about is? I wasn't
trying to say wireshark shouldn't be used (so no point in iterating it's
benefits - you've already convinced me) but that its Bluetooth decoding
support be ported from traditional HCI sockets to use monitor sockets
instead. This wouldn't give us any new decoders to wireshark but it
would allow early HCI traffic decoding (e.g. on plugged in USB dongles)
which isn't possible with current wireshark or hcidump and context
discovery when tracing is started after there already exists
connections.

Considering these benefits monitor sockets compared to HCI ones is it
something you might be interested in implementing?

Johan

RE: Wireshark

[Michal.Labedzki]

Hi Johan,

> I think you must have misunderstood what I was trying to say. Did you
> actually look into what the monitor socket we talked about is? I wasn't
> trying to say wireshark shouldn't be used (so no point in iterating it's
> benefits - you've already convinced me) but that its Bluetooth decoding
> support be ported from traditional HCI sockets to use monitor sockets
> instead. This wouldn't give us any new decoders to wireshark but it
> would allow early HCI traffic decoding (e.g. on plugged in USB dongles)

Hmm... Do you mean something like: 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5032

I will look at that and I this is on my TODO list. But please note that my first goal is add
full Bluetooth stack support to Wireshark (profiles and protocols). When this will be done I want to and other stuff like BToverUSB, etc.

The purpose of my visit here is fetch some needed logs for testing new dissectors and present this new tool to all Bluetooth developers here.
And of course I very like new idea.

New monitor sockets is not very important for now, I focus on decoding dump files (I do not have any real devices to live-capture testing). 
It is ok for future. By the way, this sounds like task for libpcap, not really Wireshark (by I am not familiar with internals yet)

> which isn't possible with current wireshark or hcidump and context
> discovery when tracing is started after there already exists
> connections.

> Considering these benefits monitor sockets compared to HCI ones is it
> something you might be interested in implementing?

Is that stable? 

Hmmm... Has anyone logs? :)

Regards / Pozdrawiam
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki
ASCII: Michal Labedzki
e-mail: michal.labedzki@tieto.com
location: Poland, Wrocław, Legnicka 55F
---
Tieto Corporation / Tieto Poland
http://www.tieto.com / http://www.tieto.pl
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN

Re: Wireshark

[Marcel Holtmann]

Hi Michal,

> > I think you must have misunderstood what I was trying to say. Did you
> > actually look into what the monitor socket we talked about is? I wasn't
> > trying to say wireshark shouldn't be used (so no point in iterating it's
> > benefits - you've already convinced me) but that its Bluetooth decoding
> > support be ported from traditional HCI sockets to use monitor sockets
> > instead. This wouldn't give us any new decoders to wireshark but it
> > would allow early HCI traffic decoding (e.g. on plugged in USB dongles)
> 
> Hmm... Do you mean something like: 
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5032

that is Bluetooth HCI data inside USB traffic captured via usbmon
interfaces. Would work as well, but you need a lot of filtering to get
the right data that you are looking for. Especially problematic if the
device is not on USB or split across multiple USB busses. Which is
possible with Bluetooth 3.0 HighSpeed.

The Bluetooth monitor socket would give all at once. And will also give
you some extra data in case you missed the initial packets when the
adapter was plugged in. Like type (BR/EDR vs AMP) and address.

> I will look at that and I this is on my TODO list. But please note that my first goal is add
> full Bluetooth stack support to Wireshark (profiles and protocols). When this will be done I want to and other stuff like BToverUSB, etc.

You will never be done with all profiles and protocols. I have been
working with Bluetooth for over 11 years, they will always come with
another protocol or profile.

> The purpose of my visit here is fetch some needed logs for testing new dissectors and present this new tool to all Bluetooth developers here.
> And of course I very like new idea.
> 
> New monitor sockets is not very important for now, I focus on decoding dump files (I do not have any real devices to live-capture testing). 
> It is ok for future. By the way, this sounds like task for libpcap, not really Wireshark (by I am not familiar with internals yet)

Maybe it should be added to libpcap, but nevertheless it needs to be
done. It is the only way to get reliable data from the system these
days. The kernel is taking more and more control. And that becomes hard
to capture from userspace since it will be by definition too late.

> > which isn't possible with current wireshark or hcidump and context
> > discovery when tracing is started after there already exists
> > connections.
> 
> > Considering these benefits monitor sockets compared to HCI ones is it
> > something you might be interested in implementing?
> 
> Is that stable? 

Yes, it is stable.

> Hmmm... Has anyone logs? :)

It is like HCI with an extra header. Look at hci_mon.h.

Regards

Marcel