indows only.
> What about writing notes/discussed points to a document/wiki?
I don't think there is a need to because the wireshark-dev archive is
publicly available. Once there is actual implementation, then the
extcap interface documentation should be updated.
Best Regards,
Tomasz Moń
to test extcap outside Wireshark (e.g. just run extcap,
passing normal filename instead of extcap pcap pipe, in Windows cmd)
and verify that CTRL+C works correctly sounds appealing to me. With
the pipe it won't be so easy.
Best Regards,
Tomasz Moń
__
_C_EVENT or CTRL_BREAK_EVENT) and forcefully
terminate (TerminateProcess()). Note that the helper must not be
forcefully terminated as it would leave the extcap running.
While far from ideal, I think the helper is the only sensible
approach. Note that GLib gspawn-win32-helper does something dif
BREAK_EVENT is really simple to handle on extcap side, as it only
requires calling SetConsoleCtrlHandler() to register a handler. The
handler will be called in separate thread (unlike UNIX signals), but
the issues related to the separate thread are exactly the same in any
of the three methods y
On Wed, Jan 26, 2022 at 5:51 PM Lars Poeschel wrote:
> I am currently struggling with reassembly of fragments of the mux27010
> protocol.
> There is a dissector for the mux27010 protocol in wireshark
> (packet-mux27010.c) but it does not work with fragments. The mux27010
> works on top of a serial
On Mon, Oct 25, 2021 at 9:08 PM Guy Harris wrote:
> On Oct 25, 2021, at 12:03 PM, Tomasz Moń wrote:
> > The heuristic should not be the main USB traffic detection method
> > IMHO. The main thing is that people don't necessarily understand that
> > capturing full
On Sat, Oct 23, 2021 at 3:07 AM Aidan MacDonald via Wireshark-dev
wrote:
> I have two questions. First, is it fine to open a merge request early on and
> keep updating it as I add functionality? Or is it preferred to wait until
> it's more complete?
If you have some major questions, then in my
On Mon, Oct 25, 2021 at 4:57 PM Kennedy, Smith (Wireless & IPP
Standards) via Wireshark-dev wrote:
> The "Universal Serial Bus Common Class Specification"
> (https://usb.org/sites/default/files/usbccs10.pdf) discusses matching
> "drivers" to devices based on the device's or interface's class, su
On Wed, Sep 29, 2021 at 2:13 PM João Valverde via Wireshark-dev
wrote:
> > A completely different approach
> > would be to have generic hf and make the filter value somehow encode
> > usage page, id and value (if any).
>
> How about having an fvalue type FVALUE_USB_HID and a display filter
> funct
ld be to have generic hf and make the filter value somehow encode
usage page, id and value (if any).
I am not sure which of the above proposed options is worth pursuing.
Best regards,
Tomasz Moń
___
Sent via:Wireshark-dev ma
On Thursday, July 8, 2021, Martin Mathieson via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:
> These mask fields (0x7f7f, 0x7f7f7f7f, etc) look wrong to me, but I am
> worried I might be missing something?
>
Seems perfectly fine to me. This dates back to MIDI over serial line where
the mos
On Sun, Mar 21, 2021 at 1:21 PM Martin Mathieson via Wireshark-dev
wrote:
> Can an extcap program write to a wiretap-supported file format other than
> pcap or pcapng? A quick test (hack to file preamble and frames in
> extcap_example.py) suggests not..
> Has it to do with synchronising whole f
On Tue, Sep 1, 2020 at 9:16 AM Alex Nik wrote:
> I’ve created the scratch plan for GSoD doc development and converted it into
> PDF format, as I wasn’t sure you can read .numbers.. Please, check it out and
> review, when you have time. =)
What do you mean by "Finalising and applying reviews"? S
On Thu, Aug 20, 2020 at 6:13 PM Sen K Varghese
wrote:
> No, I haven't applied to your organization, unfortunately. I actually made 2
> well detailed well-researched proposals to Webots and didn't get selected. At
> the same time, I found that some proposals selected by other organizations
> are
On Mon, Aug 17, 2020 at 5:07 PM Sen K Varghese
wrote:
> I saw the accepted proposal by your organization as part of a season of doc
> and noticed that the accepted proposal was very short and not at all
> detailed. I made 3 well-detailed proposals and still hadn't got acceptance.
> So I am tryi
On Thu, Jul 30, 2020 at 6:22 PM Filipe Laíns wrote:
> I think it would be reasonable to say that cases which need such
> special handling can do it themselves. Wireshark should still provide
> all the routines required to make this work, but I don't think it needs
> to necessarily provide a functi
On Thu, Jul 30, 2020 at 3:35 PM Filipe Laíns wrote:
> For this reason I decided to drop it in favor of tvb_get_bits_array
> + pletoh*. It is simple enough to be used standalone.
This looks like a workaround to me, not a proper solution.
To me the bit level order within a single byte seems clear
On Thu, Jul 30, 2020 at 9:18 AM Roland Knall wrote:
>
> Putting the complexity in the common code will increase the complexity for a
> lot of other stuff which relies on this functionality. Also you run the risk
> of increasing dissection time for more protocols, then if you handle it
> specifi
On Thu, Jul 30, 2020 at 8:58 AM Tomasz Moń wrote:
>
> On Thu, Jul 30, 2020 at 8:30 AM Jaap Keuter wrote:
> > Let’s put a hypothetical here, a 7 bit value spanning 2 octets:
> >
> > 15 14 13 12 11 10 9 8
On Thu, Jul 30, 2020 at 8:30 AM Jaap Keuter wrote:
> Let’s put a hypothetical here, a 7 bit value spanning 2 octets:
>
> 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | | | | | | | 6| 5| 4| 3| 2| 1| 0| | | |
> +--+--+--+--+--+--+--+
value). Simply assuming Big Endian at the
cross-octet boundary prevents USB HID dissection from using
tvb_get_bits() directly because USB uses Little Endian.
Best Regards,
Tomasz Moń
___
Sent via:Wireshark-dev mailing list
Arc
On Sun, Jul 26, 2020 at 5:54 PM Jaap Keuter wrote:
> Do you have any idea how volatile this data is, how quickly it’s changing?
> There are already some data sets which are picked up weekly from external
> sources (e.g., IEEE manuf, PEN). This could be handled the same way if as
> volatile as th
by FTDI FT dissector.
FTDI FT dissector has its own short list of VID/PID pairs. How could
we expand the list with the IDs from Linux kernel (I guess manually is
one option, but that just sounds bad)?
Best Regards,
Tomasz Moń
On Thu, Jul 23, 2020 at 8:18 AM Guy Harris wrote:
> On Jul 21, 2020, at 6:04 PM, Filipe Laíns wrote:
> > I am working on the USB HID dissector and I need to dissect data on a
> > bit by bit basis, instead of byte. The data structure is completely
> > dynamic (described by the HID descriptor) and
On Sun, Jul 5, 2020 at 5:05 PM Tomasz Moń wrote:
> I am not sure if the approach I am pursuing is good or bad. The work
> in progress I have produced so far is at [1]. I am stuck at the point
> where, I need to either:
> * pass the "partially reassembled" tvb to MPSSE to c
On Thu, Jul 9, 2020 at 4:03 PM Sharon Lin wrote:
> I'm a 4th year bachelors student at MIT studying computer science, and I'm
> interested in working with you for Season of Docs! I recognize that it's
> close to the application deadline, but I'm an avid user of Wireshark and
> would really love
On Tue, Jul 7, 2020 at 5:14 PM Arpan Chattopadhyay
wrote:
> Could you tell me what are you looking for during the internship and what
> should I add in my proposal? A detailed explanation of your expectations in
> the above topics would be very helpful.
GSoD is not an internship program. If you
better approaches to the problem?
[1] https://code.wireshark.org/review/37709
Best Regards,
Tomasz Moń
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https
On Wed, Jul 1, 2020 at 11:11 PM aanchal mishra
wrote:
> Can you please give me your top two priority projects in which i can apply.
We don't have priorities assigned to GSoD ideas. Just pick an idea
from the list (or propose your own) that interests you most.
_
On Wed, Jun 24, 2020 at 5:04 PM Alex Nik wrote:
> I would like to help improving Wireshark docs as I know some of my friends
> are spending time to google instructions instead of reading official
> documentation for Wireshark.
> I would be interested in helping to document menu items in the User
On Thu, Jun 18, 2020 at 5:02 PM Sanyam Jain <17...@iiitu.ac.in> wrote:
> This is Sanyam from India. I'm currently an undergraduate student pursuing my
> course in computer science. Being a programmer I was looking for some
> interesting projects to contribute to. While going through organisations
On Tue, Jun 9, 2020 at 4:30 AM Amandeep wrote:
> I hope this email finds you well!
All Google Season of Docs applications must be submitted using the
program application form. You can find the link to the Technical
Writer Application form at GSoD Technical Writer Guide [1].
[1] https://developer
On Mon, Jun 8, 2020 at 9:29 PM Rishabh Arya wrote:
> GSoD Application: Please find my application attached to this mail.I would
> love to hear your feedback on it,
All Google Season of Docs applications must be submitted using the
program application form. You can find the link to the Technical
On Thu, Jun 4, 2020 at 5:12 PM Дмитрий Кондратьев wrote:
> Recently I discovered that the parameter Sequence Number for GTP v2 protocol
> is displayed in such way: "Sequence Number: 0x00ff (16777215)"
> But if you see specs then it is stated that Sequence Number is 24-bit field.
> From my pe
On Wed, Jun 3, 2020 at 5:13 PM Harsh Bardhan
wrote:
> I have written a few suggestions in this Mail which I will be focussing on
> during this Season of Docs and I would be delighted to get your feedback
> on the same:
>
> 1. Preparing Beginner-Friendly Tutorials using a Learning Management Tool
On Wed, Jun 3, 2020 at 5:14 PM Muhammad Afzal wrote:
> 1- Writing a clear and concise history of computer networks and discussing
> the burning questions like :
> a- What lead us to form computer networks?
> b- How the first Network was built?
> c- When and how the internet appeared on the
On Sun, May 31, 2020 at 5:22 PM Prashant Mathapathi
wrote:
> I have gone through the projects proposed by Wireshark and I really feel I
> can work on many of them. I kindly request you guys to provide me an
> opportunity to work in the Season of the Docs for Wireshark.
Currently the program is
On Fri, May 15, 2020 at 5:03 PM Muhammad Afzal wrote:
> For now, I want to clear one doubt, do i need to submit my proposal right now
> to you
> or it would be included in the application form?
The actual proposal should be submitted using Season of Docs website
when the application window opens
On Fri, Mar 20, 2020 at 4:19 PM Pascal Quantin wrote:
> Le ven. 20 mars 2020 à 16:10, Tomasz Moń a écrit :
>> What abbreviation should Picture Transfer Protocol dissector use?
> iso_ptp maybe?
Initially I was thinking about just "iso15740", but this suggestion
makes
to Picture Transfer Protocol.
What abbreviation should Picture Transfer Protocol dissector use?
Best Regards,
Tomasz Moń
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscr
On Fri, Mar 6, 2020 at 7:29 PM zubin choudhary wrote:
> I am interested in working with Wireshark on USB Audio/Video stream export.
> but I'm not sure where to start is there any docs or links I should look up ?
The best pages to look up regarding this project are probably:
* https://usb.org/do
requesting CONFIGURATION
descriptor). Do we have some generic mechanism that could be used to
make Wireshark stop dissection at the specific byte count in such
cases?
Best Regards,
Tomasz Moń
___
Sent via:Wireshark-dev mailing
On Sun, Jan 5, 2020 at 4:54 PM Graham Bloice
wrote:
> However, I'm cautious about renaming fields "just because" as this will
> likely break any scripts\workflows folks have that rely on the current field
> names.
In case of the USB Audio descriptor dissection, I would like to change
the header
ad of coming up with our own
(e.g. Terminal ID)? Should we unify the fields so all descriptor
fields always use the display names from the respective specification?
Best Regards,
Tomasz Moń
___
Sent via:Wireshark-dev ma
Hello,
I have just registered at the Wireshark wiki. My username is
TomaszMon. Please add me to the EditorGroup.
Best Regards,
Tomasz Moń
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org
On Tue, Nov 19, 2019 at 4:53 PM chuck c wrote:
> And in the still learning to crawl before walk/run, where is the best place
> to request something like this?
> Doesn't seem worthy of a new entry in Bugzilla.
In my opinion the best place would be the review system (currently
Gerrit). That is, up
On Tue, Oct 8, 2019 at 12:34 AM Guy Harris wrote:
> 2) Will this cause merge commits, such as the crap that GitHub dumps in there
> by default:
>
>
> https://github.com/the-tcpdump-group/libpcap/commit/b43fdf882a3bd71391535362b3bf560ec54e77ef
>
> to pollute the history?
In GitHub projec
On Sun, Jul 21, 2019 at 8:05 PM John Sullivan wrote:
> If the internal representation is in the sane order, then it's a
> simple matter to flip the table. (It simplifies the processing a tiny
> bit too.) Here is a version which handles 11 or 19 bit input
I have implemented the CRC-5 calculation i
On Sat, Jul 20, 2019 at 8:42 PM John Sullivan wrote:
> One of the properties of LFSRs is that a 1 bit in the input toggles a
> completely predictable set of register bits *at any point in the
> future*. This isn't often useful for most CRC caculations on variable
> sized input, as the cost of work
On Sat, Jul 20, 2019 at 5:37 AM Tomasz Moń wrote:
> The advantage of 1) over 2) is the ability to be able, if the CRC is
> incorrect, to tell what the correct CRC should have been.
> Approach 2) allows only to veify if the CRC is correct - but at the
> advantage of being able to tak
On Sat, Jul 20, 2019 at 2:01 AM Ross Jacobs wrote:
> My vote is for table lookup along a one-byte boundary as all of the existing
> CRC checkers in /wsutil currently use one. Notice how in our CRC16 and CRC32
> implementations, we bitshift by 8 and 24 respectively. It should be possible
> to co
On Sat, Jul 20, 2019 at 2:35 AM Guy Harris wrote:
> On Jul 19, 2019, at 9:26 AM, Tomasz Moń wrote:
> > 1. Compute the CRC5 bitwise on the 11 bits of data, or
> > 2. Compute the CRC5 with table-based algorithm on 2 bytes (11 bits
> > data + 5 bits CRC) and relying on the
table-based algorithm on 2 bytes (11 bits
data + 5 bits CRC) and relying on the CRC properties expect fixed
output.
Which approach would be preferred?
Best Regards,
Tomasz Moń
[1] https://code.wireshark.org/review/#/c/34016
On Tue, Jul 9, 2019 at 10:34 PM Thomas Wiens wrote:
> If I split this, I hope there won't be a version in between which fails
> to dissect all possible data without error.
> As all my tests were done on the finished version.
> Or is there an option to mark the single commits as consecutive patches
On Mon, Jul 1, 2019 at 11:44 PM Guy Harris wrote:
> If you're doing a long-running capture, 1) don't clamshell your machine in
> the middle and 2) leave it plugged in.
To avoid surprises on Windows, you might want to schedule the Windows
Update restart no earlier than the time by which you are f
kets. The frequency and bit resolution of the data is in the
configuration descriptor, so the USB Audio dissector should keep track
of that information. What would it take to implement the actual
playback?
Best Regards,
Tomasz Moń
_
On Fri, Jun 14, 2019 at 10:27 PM Roland Knall wrote:
> There is a patch currently waiting for inclusion. It would allow for
> dissectors to easily make credentials (username/password) available and
> present them in a tool window in Wireshark.
I understand that you mean, that it'd be easy to pr
On Thu, May 9, 2019 at 2:12 AM Peter Wu wrote:
>
> On Wed, May 01, 2019 at 12:23:16PM +0200, Tomasz Moń wrote:
> > One approach to solve the problem of "unwanted interruptions" would be
> > to change simple_dialog() function to post user-defined event to the
> >
this approach.
What do you think about changing simple_dialog() to be asynchronous?
Is there some better approach?
Best Regards,
Tomasz Moń
[1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15743
[2] https://bugs.wiresha
. Actually Coverity
Scan, back in the day, helped me fix the BSoD caused by USBPcapDriver.
Is there any automatic submission every X builds or is the process
manual? Are the Windows builds submitted?
Best Regards,
Tomasz Moń
On Fri, Oct 3, 2014 at 10:16 PM, Tomasz Moń wrote:
> On Fri, Oct 3, 2014 at 5:17 PM, wrote:
>> Console App written in C(++) and not have the ugly console window pop up
>> when you start
>> capturing.
>>
>> If these are indeed "intended limitations", t
On Fri, Oct 3, 2014 at 5:17 PM, wrote:
> Console App written in C(++) and not have the ugly console window pop up when
> you start
> capturing.
>
> If these are indeed "intended limitations", than yes documenting on the Wiki
> would be a good start.
This is the way how it works in Windows.
If
On Mon, Sep 22, 2014 at 11:03 AM, Michal Labedzki
wrote:
> Ok, so it is only additional filtering on specified interface. It is fine.
>
> By the way: do you have a plan to add some extcap tool or support into
> libpcap for usbpcap? It will be fine if user will have USB sniffing on
> Windows by def
On Mon, Sep 22, 2014 at 8:54 AM, Michal Labedzki
wrote:
> It seems that you try to move some interfaces from interfaces list to
> one of interface. Why do not you add as much interfaces as you need?
> It seems to be similar case with Android: There is one devices (phone)
> connected by USB to comp
On Tue, Sep 16, 2014 at 10:29 AM, Tomasz Moń wrote:
> Is there anything like checkbox treeview currently in the works? Or
> could Mr. Someone propose a grammar for that and/or handle the
> implementation?
Never fear, Mr. Someone is here!
Multicheck was nearly exactly was I needed. I
Hello folks,
Recent merge of extcap into Wireshark development tree got me
thinking about improving USBPcap user experience. The idea is to allow
user to select individual USB devices to capture from with the option
to automatically capture from newly connected devices.
I am thinking about someth
On Tue, Jul 30, 2013 at 3:49 PM, Rui Pedro Caldeira
wrote:
> Hello, I'm using Wireshark to read from a pipe and i'm using the native IEEE
> 802.15.4 dissector, but I'm having trouble feeding Wireshark the proper
> bytes. I've tried to search but I can't find the right sequence of bytes the
> disse
On Thu, Apr 11, 2013 at 7:05 AM, Roland Knall wrote:
> Next step will be conversations and a tap interface, but for that I want
> this code in first, so to not mix changes and get confused.
>
If that's the only reason that prevents you from doing additional
development you could try using git. W
On Thu, Mar 21, 2013 at 9:47 AM, Tomasz Moń wrote:
> On Wed, Mar 20, 2013 at 4:15 PM, Max Baker wrote:
>> I will be very interested in trying this. I assume this will only work on
>> Windows 7, right?
>
> I have updated the README with instructions on how to compil
On Wed, Mar 20, 2013 at 4:15 PM, Max Baker wrote:
> I will be very interested in trying this. I assume this will only work on
> Windows 7, right?
I have updated the README with instructions on how to compile it for Windows 8.
USBPcap can be compiled for Windows XP, Windows Vista, Windows 7 and
Hello folks,
I am pleased to announce the USBPcap [1]. The project is not end-user
ready, but I think it's right time to ask you for comments.
USBPcap consists of two parts:
* filter driver (USBPcap.sys)
* user-mode application (USBPcapCMD.exe)
Filter driver attaches to every root hub in sys
71 matches
Mail list logo
