DFU mode, wireshark

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sun Jan 12 19:00:21 UTC 2014


Hi Martin,

On Sun, Jan 12, 2014 at 05:59:10PM +0100, Martin Kaiser wrote:
> recently, we added a dissector for USB DFU to wireshark. It recognizes
> packets based on product ID + vendor ID.

Thanks, that's gerat!  As the outhor of at least two DFU implementations
(sam7dfu, openmoko-uboot-dfu) I appreciate it :)

> I tested this with my simtrace (v1.0) board and it works like a charm
> when I add 0x16c0, 0x0762.
>
> However, I saw that for the simtrace board, prod id/vendor id is the
> same for DFU mode and sniffer mode.

Yes, and this is how USB is meant to be used.  A product ID doesn't
describe an interface, but it describes a product.  It is perfectly
legal for a single product to expose completely different interfaces, in
different configurations, etc.

AFAICT, only some strange Windows operating systems seem to have (had?)
the assumption that a device exposing multiple configurations/protocols
would need multiple different product IDs.

I don't think it makes sense to fall into the same trap with wireshark.

Why not base the dissection on more than just the product id?  Why not
match on any subset of identifiers, like matching on classes of devices,
matching on vendor+product+config+interface?  Or even going further: DFU
capable devices indicate such capability in their descriptors, so you
should be able to parse the descriptors and identify the DFU capability
without having to have an explicit list of product IDs for DFU decoding.

> Therefore, I tend to add 0x16c0, 0x0762 and link it to USB DFU.
> Are you ok with this?

I would like to ask you to consider the above suggestion.

And: Yes, it is true, dissecting the raw simtrace protocol is probably
not going to happen in wireshark - even though we actually feed it back
via GSMTAP into wireshark for decoding later on ;)

Regards,
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the simtrace mailing list