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.orgHi 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)