Re: [Wireshark-dev] Future of extcap "API"
On Wed, Aug 24, 2022 at 12:15 PM Jirka Novak wrote: > There is my view of discussed proposal: > > wireshark(1) - something(2) - helper(3) - signals(4) - extcap(5) > > (1) Wireshark should be able to start extcap. Wireshark must be able to > query for parameters of a extcap and should support control pipes (UI > stuff, works nowadays). > (2) We are looking for any solution there. It can be pipe as for dumpcap > nowadays, but other options are welcomed. Most likely pipe on Windows. Not needed on UNIX systems. > (3) helper is responsible for extcap control. On Win32 it should handle > console stuff and allows us to use signals between helper and extcap on > Win32. Not needed on UNIX systems. > (4) *nix or Win32 console signals are used there > (5) Extcap should be simple and we prefer to use OS specific features - > signals for graceful shutdown. Extcap can be written in any language, > can be single or multiplatform. Extcap should be modified if and only if > it requires graceful shutdown. > > Points to discuss: > It the diagram complete? No, and it can be misleading as it mixes multiple concepts. The diagram is incomplete as it misses dumpcap. Extcap writes pcap data to pipe that Wireshark created but it is really dumpcap who reads the data from that pipe. > I'm not sure about dumpcap. There is dumpcap started for every extcap, > which reads data from extcap and pass it to wireshark. There is one dumpcap started for all extcaps. When you start capture on multiple extcaps, Wireshark will read single pcapng file that contains the data dumpcap read from the extcap pipes. > Does helper staff involve it? No. > Helper will help us with solving Win32 stuff. Do we need it just on > Windows or on every platform? Just on Windows to overcome the console limitations. > For *nix it is useless I think, but using same approach on every > platform can be useful. The code can be cleanly isolated. There's no point in using same approach on every platform. > There is negotiation between wireshark and extcap before extcap is > started - it provides wireshark with name of extcap, supported > interface, required parameters... > I think it would stay as it is. So helper will not be used there. Not needed. Although Roland mentioned that maybe it could be used to overcome the .bat wrapper in the future. However that would be something unrelated to the graceful shutdown and only makes sense to pursue further once the helper is already there. > When extcap prints anything to STDOUT or STDERR, it is passed to > Wireshark (there are extcap console works running). STDERR is shown as > error/information to a user when extcap is finished. We must pass this > thru helper. > How helper's STDOUT/STDERR will be handled? In general there's no need for helper to write to STDOUT/STDERR as its sole purpose is overcoming API limitation. If extcap fails to spawn then helper can either write error to its (duplex) pipe or simply to the handle that Wireshark sees as extcap STDERR. > Extcap can support control pipes. They are passed to extcap as parameters. > I think that control pipes will bypass helper. I mean parameters/names > of pipes will be passed thru helper, but helper will not > open/close/touch control pipes. Helper doesn't need to know anything about extcaps. > Wireshark is the one who creates command line for extcap - name of > binary and its parameters. This information should be passed to helper > and it will run command line. How to pass this information to helper? I think just appending extcap binary and commandline after "--" helper commandline argument is all that is needed. > I'm afraid that pass it as command line parameters can create issues - > e.g. same parameter name for helper (it needs some) and for extcap, > special character escaping, ... Windows commandline handling is far from perfect, but I don't see major obstacles here. Helper just have to find where the extcap commandline starts in the commandline string the helper was started with. > How Wireshark will control helper? > We can't use signals on Win32. So pipe or windows events? I think single character (e.g. 'q' for graceful termination, and 't' for termination) write to a pipe is all that is needed. The pipe can be duplex as it will be Windows 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ń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Future of extcap "API"
re is perfectly fine mechanism (SIGTERM) that has been used for decades. Being able 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ń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Future of extcap "API"
On Mon, Aug 22, 2022 at 9:37 PM Jirka Novak wrote: > >> What do you think about that options? > > > > I have no idea why you didn't even consider sending CTRL_BREAK_EVENT > > using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on > > Windows. Wireshark creates all extcaps with a hidden console window > > (CREATE_NEW_CONSOLE and SW_HIDE flags set). > > > > CTRL_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 you proposed. Registering handler is really an > > opt-in, as the default handler simply terminates the process. > > I'm sorry, my understanding was it is in !2063. I was wrong, I will try it. The problem with GenerateConsoleCtrlEvent() is that the caller has to be attached to the target process console. While we could technically do so, it requires freeing any already open console because process can be attached to at most one console. The pretty much only sane solution to the problem is to have a helper program between Wireshark and extcap. The helper would simply spawn extcap with provided parameters and accept commands from Wireshark e.g. on pipe. The commands would be to gracefully terminate (CTRL_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 different, so going back to the GLib helper is not what this is all about. Best Regards, Tomasz Moń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Future of extcap "API"
On Sun, 2022-08-21 at 15:53 +0200, Jirka Novak wrote: > My goal is to prepare library calls (at least for C) which will hide > details for developer and there will be just callback and/or global flag > that extcap should finish its work. Extcap author can use it if graceful > shutdown is required. I think the mechanism should be as simple as possible, so it is feasiable to be implemented in whatever language the extcap is written in. > 1) Looks limiting to me, because my understanding is that it requires > that extcap must create hidden window to be able to receive WM_xxx signals. > I'm afraid it can be limiting/additional complexity for extcaps. I can't > evaluate whether it has any other consequences for extcap code. WM_CLOSE probably cannot work at all when the extcap is run via wrapper script, like .bat files that are needed for Python extcaps. > 2) It works, but it requires change how command line is parsed, because > name of named pipe must be passed to extcap. !5489 implements it as new > pipe even there are control pipes which are already processed by API. > Patch can be modified in that area. > Library for C is proposed and it automates cli parsing. This sounds like a last resort if everything else fails. > 3) It makes sense to me even I didn't tried it yet. My understanding of > documentation is that 3) is more preferred in Win32 world. > I see important that name of event must be agreed between wireshark and > extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every > extcap including ones called from different wireshark application. I > think it should not work this way. > Name of Event can be new parameter for extcap, but it requires cmd line > change. > We can try to derive name of Event from filename/pipe to which extcap > writes output. It is different value for every wireshark/extcap > combination. It do not require any changes on command line. > I found no other dependency for use of Events. It looks promising to me. I don't like this idea because it requires too much effort on the extcap side to implement just shutdown (the control pipe atleast could be extended with other uses). > Pros of 1) and 3) is that Wireshark do not have to care whether extcap > supports it. If it does, it will process signal or event. If it doesn't, > Wireshark can send them and nothing bad happens to wireshark nor extcap. The 30 seconds timeout will happen every time the user wants to stop the capture. You could try to workaround that by trying to detect if extcap handles the graceful shutdown, but that is a workaround. > On the other hand 2) depends on support on extcap side, but proposed > library solves it. You assume every extcap developer will happily use the library, but there are valid reasons not to: license (extcap does not have to be GPL compatible) and language. > What do you think about that options? I have no idea why you didn't even consider sending CTRL_BREAK_EVENT using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on Windows. Wireshark creates all extcaps with a hidden console window (CREATE_NEW_CONSOLE and SW_HIDE flags set). CTRL_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 you proposed. Registering handler is really an opt-in, as the default handler simply terminates the process. Best Regards, Tomasz Moń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Reassembly of split fragments
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 line (uart) so there is no ethernet, no IP, no > TCP involved so far. You might want to check how I handled similar situation in packet-ftdi-mpsse.c/packet-ftdi-ft.c. I basically implemented desegment_offset / desegment_len mechanism in the packet-ftdi-ft.c and used that in packet-ftdi-mpsse.c. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] USB Attached SCSI dissector
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 enumeration sequence (aka starting capture before > > plugging in the device) will give you much better dissection in > > multiple cases. > > The main thing is that there's no guarantee that you get the full enumeration. Software only USB capture engines provide enough information for Wireshark dissection if you plug in the device after starting the capture. That is, it is good enough when the user is not struggling with board bringup issues while developing USB device firmware. The requests not captured by software only sniffer are not really big deal IMHO after the bringup is complete. > > Recent libpcap versions > > automatically request device and configuration descriptors on capture > > start (easier version request only device descriptor). > > Is this done on FreeBSD, macOS, and Windows? > > Or is this Linux-only? Linux only. On Windows, USBPcap has the option to inject already connected devices descriptors on capture start (technically it is different to what libpcap on Linux does, as it does not actively request the descriptors from device, but rather uses the cached values). I don't know about macOS nor FreeBSD. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] USB Attached SCSI dissector
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 opinion it is best to open it as early as possible - just make sure to mark it as draft. > Second, the hooks provided by the generic USB dissector seemingly aren't a > good fit. Basically, it seems to use only the interface class to decide what > sub-dissector to call, but UASP uses the mass storage class like the existing > Bulk-Only transport dissector. So that dissector is essentially sitting in > the way and preventing me from hooking in UASP. (Or at least I think so. > Currently I'm just commenting it out the conflicting hooks during testing.) > > I need to look at the interface protocol to determine if the traffic is UASP > or not. I think the simplest way to do this is adding a shim dissector for > mass storage class which invokes either the BOT or UASP dissector depending > on the interface protocol (if known). Does that sound like a good approach? Currently mass storage class dissector assumes Bulk-Only Transport. It should however check the interfaceProtocol value in usb_conv_info_t data and perform the dissection based on this. So the "shim dissector" you mention, should really be part of the existing mass storage dissector. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] USB Attached SCSI dissector
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, subclass and > protocol. I would suggest that, for USB, dissector matching for USB could > adopt elements of this methodology to make it easier or more clear how to add > support for new subclasses or protocols under a particular class. Wireshark USB dissector already does that. The major issue with current Wireshark implementation is that it really works with only one configuration. Hopefully, very few devices use multiple configurations. > I don't know if that maps to needing a "heuristic" dissector. I just wanted > to point out that the USB interface descriptor provides values for class / > subclass / protocol, so "protocol" in this context doesn't have to mean "look > at the traffic and guess what protocol it is" - it can be identified in a > more deterministic way than that. But I understand that, since Wireshark is > monitoring traffic, not acting as the USB Host, its matching will be > "passive" and only apply to dissector selection. 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 enumeration sequence (aka starting capture before plugging in the device) will give you much better dissection in multiple cases. Wireshark currently supports only few USB protocols now, so this is not common knowledge yet. Recent libpcap versions automatically request device and configuration descriptors on capture start (easier version request only device descriptor). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Filtering USB HID fields
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 > function that also returns FVALUE_USB_HID given some input parameters, > like page and id, or whatever else?? I thought about FT_USB_HID, but I don't quite see how to initialize it. Currently all ftypes require only actual data (tvb, offset, length and encoding) but in this case the dissector would have to provide the HID page and id in addition to the actual data. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Filtering USB HID fields
Hello, USB HID Usage Tables 1.22 specifies plenty of usages. Usages include for example, keyboard keys, LEDs, buttons, VR controls, etc. Usages are grouped into pages. There are plenty of usages, e.g. button page alone is 65536 items (0x means no button pressed, 0x0001 means button 1, ..., 0x means button 65535). Each usage is uniquely identified by 32-bit value that consists of 16-bit page and 16-bit id. Some usages don't have numeric value associated with it, but are selectors. Example selector is keyboard keys, where the report data specifies indexes from an array that determines what keys are being pressed. For example keyboard that supports up to 6 simultaneous key presses, reports 6 indexes (index 0 usually means no key pressed and other indexes determine pressed key). Every USB HID device provides descriptior that determines what the report data bytes means. Current Wireshark development version annotates all usages from USB HID Usage Tables 1.22 but the usages are not really filterable. Possible solution is to register hf for each usage. This can be achieved by either dynamically allocate required hfs after dissecting report descriptor or preallocating all hfs (either dynamically at runtime, or automatically generate the code). The hf name can be consutructed algorithmically based on the usage page and name. As the number of usages is quite high, I am concerned if getting one hf field for each is the way to go. A completely different approach would 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 mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RTP-MIDI strange field masks?
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 most significant bit indicates realtime event. Realtime events can appear anytime on the serial line. Normal communication, including system exclusive messages, always have most significant bit cleared. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] File formats that extcap programs can write
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 frames being read at the wireshark end > of the pipe? Currently extcap is inherently bound to pcap. Currently extcaps mention their DLT that determines link layer header type (as defined at [1]) when they are being called with --extcap-dlts argument. When you capture from extcap source, it is dumpcap that reads the pcap stream that is written to the pipe by extcap. To make extcap support different file types would would need to: * extend extcap interface with a method to let Wireshark know that the extcap in question does not output pcap data * make dumpcap capable of at least passing the data from the pipe to Wireshark [1] https://www.tcpdump.org/linktypes.html ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GSoD approved technical writer - community bonding phase
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"? Submitting one big change at the end is unlikely to end well. "Defining And Saving Filter Macros" as the first item looks fine. It doesn't require any specific captures and thus makes it ideal as a first topic to get used with the patch submission process (Wireshark GitLab Merge Requests). Further down the road, the SampleCaptures [1] will most likely come in handy. [1] https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Season of Doc query
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 not that detailed. I was wondering what might be the reasons, whether > they are assessing something more than the said proposals. I just want to > know what is the selection procedure. If you want feedback regarding your proposals you should contact the organization you applied to. We haven't seen your application and cannot refer to it in any way. If by proposal you mean the "Project Description" publicly visible at GSoD website, then note that it is only a fraction of the application and doesn't really show the whole picture (writing experience and additional information are important as well). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Season of Doc query
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 trying to figure out why proposals like the one you accepted are > getting accepted and mine is not. Is it because your organization received > only a few proposals, or is it because the accepted tech writer is somehow > related to your organization or so. I just went through all the proposals we have received and I cannot find yours. Did you apply to Wireshark in GSoD 2020? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?
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 function for very specific use cases. I would consider the special case to be swapping/reversing the bits within a byte. Which is different from the issue discussed here. > With that said, if we want to indeed support this then we need new > functions. We can't touch the current signature as that will break the > ABI. tvb_get_bits() functions do take the encoding parameter already, but simply ignore it. If someone calls it with ENC_LITTLE_ENDIAN while expecting it to work like with ENC_BIG_ENDIAN, then I would say that's a bug. Everyone who indeed wanted the little endian handling would notice that it doesn't really do the job. > My proposal would be to make tvb_get_bits* respect little endian for > the value itself and add correspondent tvb_get_network_bits* methods > that would treat the buffer as little endian. What do you think? tvb_get_network_bits to treat buffer as little endian seems weird, because the network byte order is big endian. > Would adjusting the behavior of tvb_get_bits* be considered a breaking > change? I mean, this behavior is not documented. I wouldn't consider finally handling the ENC_LITTLE_ENDIAN in tvb_get_bits() as a breaking change. Such code path used to be DISSECTOR_ASSERT_NOT_REACHED() after all. It might just be a bit late to implement, but it wouldn't be the first thing that finally got implemented after many years. Header fields with bitmasks are already working just fine with ENC_LITTLE_ENDIAN on byte aligned data. Implementing ENC_LITTLE_ENDIAN in tvb_get_bits() would just allow doing essentially the same for unaligned data. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?
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 - it's up to the tool that provides data to Wireshark to handle it. Wireshark job starts at the byte (octet) level. > I would actually like to see tvb_get_bits* throw an error > on ENC_LITTLE_ENDIAN as it is clearly not supported. Yes, it would be better to throw an error than to silently assume Big Endian. However, the best would be if it simply worked with ENC_LITTLE_ENDIAN. In fact, if you check the history, you'll notice that the initial implementation did call DISSECTOR_ASSERT_NOT_REACHED(); when called with little endian [1]. [1] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=b688f9154aacf9c2f30dc6c715bc115a05e9fcef ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?
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 > specifically. > > That would be my reasoning against it Having the function take quite important parameter (encoding) and not using it at all is pretty bad. When someone tries to use tvb_get_bits() with ENC_LITTLE_ENDIAN the issue becomes apparent. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?
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| 7 6 5 4 3 2 1 0 > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > | | | | | | | 6| 5| 4| 3| 2| 1| 0| | | | > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > > > This would be the typical interpretation, as seen in network protocols. > > > > Your suggestion is that the interpretation can also be: > > > > 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0 > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > | | | | | | | 1| 0| 6| 5| 4| 3| 2| | | | > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > This is not what I wanted to write. Assuming you meant two octets, and > the bitmask on the 16-bit value is 0x1FC0 then the alternative > interpretation would be: > 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0 > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | | | | | | | 4| 3| 2| 1| 0| 6| 5| | | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Sorry, I should have displayed that in a fixed font earlier! It is perfectly clear then (the bitmask in your example is 0x03F8, and not 0x1FC0 as I was led to believe due to trying to figure it out on font not suited for the task) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?
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| | | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > This would be the typical interpretation, as seen in network protocols. > > Your suggestion is that the interpretation can also be: > > 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0 > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | | | | | | | 1| 0| 6| 5| 4| 3| 2| | | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ This is not what I wanted to write. Assuming you meant two octets, and the bitmask on the 16-bit value is 0x1FC0 then the alternative interpretation would be: 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | | | 4| 3| 2| 1| 0| 6| 5| | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > Here the first interpretation is a simple matter of mask and shift, the > second interpretation is somewhat more involved. Since the first > interpretation is common in network protocols (and efficient to handle) the > code was made with that in mind. Is the complexity the only reason? I prefer the complex things to be in the common code and not in individual dissectors. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Why tvb_get_bits() assumes Big Endian?
Hello, The tvb_get_bits() function family contains following comment: /* note that encoding has no meaning here, as the tvb is considered to contain an octet array */ I don't understand the reason. What am I missing? The actual octets in tvb contain the bits ordered as expected, so the MSB/LSB-first problem within the octet itself does not apply (and I think this is what the comment refers to). However, when the bit field (e.g. 11 bits) spans across multiple octets, then the endianness does matter (i.e. which of the two octets contains the more significant part of the 11-bit 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Using FTDI device ids from Linux kernel
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 these. Looking at the Linux kernel git history, the last (not reverted) change to linux/drivers/usb/serial/ftdi_sio_ids.h was on 23 March 2018. Before that there were few changes a year in that file. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Using FTDI device ids from Linux kernel
Hello, The Linux kernel FTDI SIO driver contains quite a comprehensive USB VID/PID database. The values are defined in linux/drivers/usb/serial/ftdi_sio_ids.h and are combined together in id_table_combined in linux/drivers/usb/serial/ftdi_sio.c. The protocol these devices use is being dissected 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ń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Dissect data on a bit-by-bit basis
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 the basic data block is > > the bit. Any bit or sequence of bits can have a meaning, the data can > > be completely unaligned. See the following example which shows > > different fields distributed in a 2 byte packet. > > > > > > 0111 > > ^^^\__^___/\_^_/ > > ||| | | > > ||| | | Y axis (5 bit wide) > > ||| | > > ||| | X axis (8 bit wide) > > ||| > > ||| button 3 > > || > > || button 2 > > | > > | button 1 > > That's 16 bits, so, while individual data *items* may be completely > unaligned, the mouse report itself can be aligned on a byte or possibly even > 16-bit boundary. > > If that's the case, then this is fairly easy. You can just define Boolean > (FT_BOOLEAN) button1, button2, and button3 fields, an 8-bit integral > (FT_UINT16 if unsigned, FT_INT16 if unsigned) x field, and a 5-bit integral > (again, FT_UINT16 or FT_INT16) y field, with bitfields in the field > definition. proto_tree_add_item() will handle extracting the relevant bits > and displaying them as, for example: > > 0... = Button 1: up > .0.. = Button 2: up > ..1. = Button 3: down > ...0 111. = X: 7 > ...0 = Y: 15 > > If, however, the position and button information is *not* aligned on a 16-bit > boundary, so that any of those fields can begin on an *arbitrary* bit > boundary, you will have to use more complicated APIs, such as the ones > described in John Thacker's message. In this case, I think using proto_tree_add_bits_item() is actually less complicated. The reason for that is that the actual bit positions are only known at runtime, after dissecting the HID descriptor - the order is determined by the HID report descriptor stored in USB HID device firmware. The generic header field definitions can be created beforehand, but the bit positions will only be known at runtime. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Reassemble serial protocols payloads
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 check if it is complete, > or This is what I actually implemented in Patch Set 7 [1]. The only issue is that I am hijacking the pinfo->curr_layer_num value to make process_reassembled_data() happy. FTDI FT dissector doesn't know if the last fragment is really the last one unless it passes the data to the next dissector. There is absolutely no metadata that could help with it as FTDI FT is pretty much a direct replacement to UART (COM port) and is pretty much transparent to the actual serial protocol used. Passing the data to the MPSSE dissector results in curr_layer_num being increased if it dissected the data (when it is the last fragment). This would prevent the process_reassembled_data() (after the first pass) from returning the reassembled tvb in FTFI FT which in turn prevents the data from being passed to the next dissector. > * mark the data as reassembled as soon as I receive X additional > bytes, but then after passing such reassembled data to MPSSE, it > should be possible to "unmark" in case it needs even more bytes (in > case the original estimate changes based on the new information). I have had no success with this approach. [1] https://code.wireshark.org/review/37709 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Season of Docs Interest
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 to help with documenting tools for developers. > > I noticed that there are quite a few documentation issues of varying degrees > of priority on Bugzilla, and would be happy to work with your team to provide > documentation, such as updating descriptions for different conditions, > command line documentation updates, and providing samples and use cases. > > I've attached my resume if that's helpful. Thanks, and I hope to work with > you! The list is to discuss the actual ideas on technical merits. To apply to GSoD, submit the application using the official Technical Writer Application Form [1]. We will get access and start ranking the proposals after the submission deadline (in a few hours). [1] https://bit.ly/gsod-tw-app ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Google Summer of Docs proposal
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 wish to apply to GSoD, your proposal should include everything you think is relevant. Note that the proposals should be submitted using the Technical Writer Application form linked at Technical Writer Guide [1]. It is my first time participating in GSoD and as such I don't quite know what to expect from the applicants. [1] https://developers.google.com/season-of-docs/docs/tech-writer-guide ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Reassemble serial protocols payloads
Hello, I am trying to implement reassembly for FTDI MPSSE protocol. The desegment API sounds like an excellent choice, because there can be more serial protocols implemented in the future that share similar characteristics to MPSSE (i.e. are designed around asynchronous character transmission). Each time FTDI FT passes the payload to MPSSE dissector, MPSSE can: * dissect the data just fine if it received (one or more) complete function code with parameters, * dissect as much as it can (complete function code with parameters) and request X additional bytes The value X in some cases is known from the beginning, but in some cases it is only an estimate. It is only an estimate if the missing data includes the variable data length parameter (i.e. MPSSE dissector knows that it is a data shifting command, but does not know how many bytes the command will send out, because the length is in the next frame). 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 check if it is complete, or * mark the data as reassembled as soon as I receive X additional bytes, but then after passing such reassembled data to MPSSE, it should be possible to "unmark" in case it needs even more bytes (in case the original estimate changes based on the new information). Is either of the above viable? Are there any 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://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Season of Docs Query
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. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Proposal for the Google Season of Docs.
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 Guide, as > well as in helping User’s Guide update and Developer’s Guide update. The applications should be submitted using the official Technical Writer Application Form [1]. [1] https://bit.ly/gsod-tw-app ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Contribution in Wireshark during GSoD
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 in > "Google Season of Docs" I came to your organisation. GSoD is targeted towards Technical Writers. Programmer and Technical Writer are not quite the same. That being said, there's nothing preventing a person from doing both. > Since I am new to the community I would like to ask if any of your projects > are not taken up by someone then I am willing to work on that project or the > project which is prioritized by the organisation. Most likely Wireshark will receive one GSoD slot. GSoD is currently in the technical writer application period. The applications must be submitted via official GSoD form. We do not have access to the applications before the application submission deadline. > I have shared my idea please let in know what else you expect to be done > during GSOD. Looking forward to having a great learning experience while > contributing to the project before, during and after GSOD. Keep up the good > work, the project is really amazing. I am not sure what you mean by sharing your idea. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Google Season Of Docs participant - Amandeep Kaur
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://developers.google.com/season-of-docs/docs/tech-writer-guide ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GSoD 2020 Project Proposal Wireshark
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 Writer Application form at GSoD Technical Writer Guide [1]. [1] https://developers.google.com/season-of-docs/docs/tech-writer-guide ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Question about displaying of Sequence Number of GTP v2
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 perspective, it doesn't make sense to include two lead zeros. > Am I missing something? Is it a small UI bug? If it is a bug, then it is not in the UI, but rather in the dissection engine. when you look for "gtpv2.sequence_number" in epan/dissectors/packet-gtpv2.c then you can notice it is marked as FT_UINT32. Changing it to FT_UINT24 would solve the issue you are observing. Can you submit a patch to Wireshark gerrit? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Google Season of Docs [Harsh Mishra]
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 > like Moodle to help people get started with Wireshark. > This sounds like an extremely big project to me. I don't think this can be done within GSoD timeline. 2. Preparing the tutorials with an intelligent mix of Pictures, Animated GIFs > and Videos which would be a pleasure to read and follow. > Sounds a bit out of scope to me. > 3. Reorganizing and Cleaning the Documentation which would be easy to > follow. > Sounds fine. > 4. Including Do's and Dont's for beginners to know about the Best > Practices while working with Wireshark. > Sounds fine. 5. Adding a gamified experience by including Quizzes and Development > Activities to help people gauge their learning. > In my opinion, this is out of scope. > These enhancements and addition to the WireShark documentation would help > people with all the objectives laid down for this year's GSoD. I will also > be working towards other issues like removing ambiguity in some part of the > documentation and updating the USBPCap website. > > I am looking forward to hearing from you on these proposals and how I can > improve them before I lay down my final proposal. > Be more specific instead of just writing out headlines. When the application window opens, submit the proposal via Google Seasons of Docs website. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Discussing my proposal for Google Season of Docs
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 globe? > d- How the idea for the world's first website evolved? > e- Basic application layer protocols as they aren't officially documented > over Wireshark official. > > 2- Creating mind maps for the basic application layer protocols and a quick > guide towards Wireshark by combining the history of Computer Networks. > > 3- Analyzing Http, SMTP, FTP, and DNS by Wireshark and documenting it > properly as some are not documented yet. > > > It may sound astonishing but the most critical step towards understanding any > technology in today's world is knowing how it all actually began. > This little input by me towards Wireshark would help newbies to instantly > grab concepts of Application Layer protocols and motivate them to keep going. > > Now, if I submit my proposal based upon prior discussion under Google Season > of Docs, Would it be acceptable? Your idea sounds a bit out of scope to me. While knowing computer history might help students understand it better, I don't think Wireshark documentation is the correct place to look for such information. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Proposal for Google Season of the Docs
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 in Technical writer exploration phase. This is to discuss the project ideas themselves. Technical writer application period will start June 9, 2020 at 18:00 UTC. The actual proposals should be submitted through the Google Season of Docs Program Website. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GSoD Proposal submission process ?
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. According to timeline [1] it starts June 9, 2020 at 18:00 UTC and ends July 9, 2020 at 18:00 UTC. [1] https://developers.google.com/season-of-docs/docs/timeline ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Dissectors with the same abbreviation
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 me think "ptp_iso15740" would be best. The ptp at the beginning is what people are used to, and iso15740 added as suffix so it can be easily differentiated from ieee1588. That way when writing filtering rule, the auto-completion can help so it won't be necessary to remember the exact iso number. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Dissectors with the same abbreviation
Hello, In Wireshark there is Precision Time Protocol (IEEE1588) dissector suing the abbreviation "ptp". There is also, currently without built in dissector, Picture Transfer Protocol (ISO 15740:2008) that is commonly referred to as PTP. MTP (Media Transfer Protocol) is extension 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 Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GSoC | USB Audio/Video stream export
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/documents * https://www.wireshark.org/docs/wsdg_html_chunked/ * https://bugs.wireshark.org/bugzilla/ You should get familiar with how USB Audio class transfers audio data and how Wireshark dissectors work. Ideally before the application period ends you would have submitted to Wireshark gerrit a patch fixing some issue. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] How to deal with USB descriptor dissection
Hello, In USB control transfers the host decides how many bytes of data he wants to receive. For example, when Windows requests STRING DESCRIPTOR it first asks for only 2 bytes. The first two bytes are length and descriptor type. Unfortunately, Wireshark dissector attempts dissecting full string descriptor, even though host only requested 2 bytes. This leads to [Malformed Packet] while in reality everything was perfectly fine. Example request: Frame 7: 36 bytes on wire (288 bits), 36 bytes captured (288 bits) on interface wireshark_extcap2008, id 0 USB URB Setup Data bmRequestType: 0x80 1... = Direction: Device-to-host .00. = Type: Standard (0x0) ...0 = Recipient: Device (0x00) bRequest: GET DESCRIPTOR (6) Descriptor Index: 0x00 bDescriptorType: STRING (0x03) Language Id: no language specified (0x) wLength: 2 And response: Frame 8: 30 bytes on wire (240 bits), 30 bytes captured (240 bits) on interface wireshark_extcap2008, id 0 USB URB STRING DESCRIPTOR bLength: 4 bDescriptorType: 0x03 (STRING) [Malformed Packet: USB] [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)] [Malformed Packet (Exception occurred)] [Severity level: Error] [Group: Malformed] The response is perfectly fine, if host asked for 4 bytes, he would have gotten it. But here it asked only for 2 bytes, so according to specification it got only 2. It is seen later in the capture that host indeed asks for the full 4 bytes. Frame 9: 36 bytes on wire (288 bits), 36 bytes captured (288 bits) on interface wireshark_extcap2008, id 0 USB URB Setup Data bmRequestType: 0x80 1... = Direction: Device-to-host .00. = Type: Standard (0x0) ...0 = Recipient: Device (0x00) bRequest: GET DESCRIPTOR (6) Descriptor Index: 0x00 bDescriptorType: STRING (0x03) Language Id: no language specified (0x) wLength: 4 Frame 10: 32 bytes on wire (256 bits), 32 bytes captured (256 bits) on interface wireshark_extcap2008, id 0 USB URB STRING DESCRIPTOR bLength: 4 bDescriptorType: 0x03 (STRING) wLANGID: English (United States) (0x0409) The same applies to all control transfers that return data. The host is allowed to request less than the full amount (and often does so, to know how big the full structure is, e.g. when 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 list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Standard defined field names in Wireshark dissectors
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_field_info name, leaving abbrev as is. Would that still cause problems? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Standard defined field names in Wireshark dissectors
Hello, I have noticed that some USB dissectors do follow the field names as defined in USB specification (e.g. standard descriptors), while others don't (e.g. USB Audio class descriptors). Is it generally preferred that Wireshark follows names from the specification (e.g. bTerminalID) instead 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 mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wiki editor request
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/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 3.1.1 and 3.2.0 release schedule
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, update the NEWS, commit and push the update for review. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Migrate to GitLab?
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 project settings you can select the Merge Button options: * Allow merge commits - Add all commits from the head branch to the base branch with a merge commit. * Allow squash merging - Combine all commits from the head branch into a single commit in the base branch. * Allow rebase merging - Add all commits from the head branch onto the base branch individually. If you want to avoid the merge commits on GitHub you can untick the "Allow merge commits". ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Calculating CRC5 of 11-bit data
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 in Wireshark based on your code. It is available at [1] as patch set 6. I would appreciate your review. It works really well with my captures. [1] https://code.wireshark.org/review/34025 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Calculating CRC5 of 11-bit data
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 working out which those bits are vastly > outweighs most other methods. This is very interesting property! Thanks John! > But here we have a fixed 11 bit input I am sorry, but I have completely missed out there there are two places where CRC5 is calculated: * In SETUP, OUT, IN, PING and SOF the CRC5 is calculated on 11 bits * In SPLIT the CRC5 is calculated on 19 bits > static const char ival = 0x08; This looks like swapped bit order to me. The CRC5 value for 11-bits of 0 is 0x02. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Calculating CRC5 of 11-bit data
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 take full bytes as input. Approach 2) is now implemented [1]. [1] https://code.wireshark.org/review/#/c/34025/ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Calculating CRC5 of 11-bit data
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 compute any CRC along a one-byte boundary. This article goes over how to > implement non-CRC8 algorithms to do just that with a table lookup. > > PyCRC was used to generate Wireshark's CRC6, CRC7, and CRC11 algorithms. You > may want to take a look at it and see if it can help here. In this case, > width=5 and poly=0x05 (assuming CRC5/USB found here). I understand that the *one-byte boundary* refers to the input data. And thus it applies only to the second approach I have mentioned (to compute CRC on the message and messages' CRC5 = 2 bytes). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Calculating CRC5 of 11-bit data
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 CRC properties expect fixed > > output. > > Meaning that if you run the CRC on the entire Link Control Word, including > the 5-bit CRC and the remaining 11 bits, the result should be a fixed value? > (Is that what "The residual of CRC-5 shall be 01100b." is referring to?) Yes, the CRC residue is what you should get after computing CRC over the message *and* its message's CRC. In case of CRC-5/USB the residual is decimal 6 (which matches the value 01100b from your quote if it is lsb first). > If the goal is just to check the CRC, approach 2) seems as if it's as good as > approach 1), and may involve a simpler implementation. 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 take full bytes as input. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Calculating CRC5 of 11-bit data
Hello, I am currently working on USB Link Layer dissector. It is supposed to be used with OpenVizsla FPGA-based USB hardware sniffer. USB Packets feature two CRC types: CRC-5/USB and CRC-16/USB. The CRC-16/USB is pretty straightforward. I have implemented it in [1] and it works fine with my captures. The CRC-5/USB is not so straightforward as it does not operate on the byte boundary. The CRC-5/USB is calculated on 11 bits of data. I think there are two possible approaches to check the CRC-5/USB in Wireshark: 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 CRC properties expect fixed output. Which approach would be preferred? Best Regards, Tomasz Moń [1] https://code.wireshark.org/review/#/c/34016/ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Several small commits vs. one big
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? My general experience with splitting big changes into small commits *after* they are done is rather bad. That is, the artificially splitted changes I have seen were failing to work (sometimes even fail to compile individually). As I find such artificial splitting to be harder than the actual development, I always tend to commit as small pieces of code I see fit for a single commit. If you have commited the changes as you went with development, then *do not* squash them into single one. Submitting them with single git push will group them in gerrit - maybe not as clearly as I'd like, but good enough to keep track of them. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Disabling idle sleep while a capture is in progress?
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 finished with your capture. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark media player capability
Hello, In Passwordlist in Wireshark - User feedback wanted following got my attention: On Mon, Jun 17, 2019 at 11:24 AM Dario Lombardo wrote: > I'm not sure this makes a point. Wireshark was born as a packet dissector. > Now it's a packet and file dissector, with IO (or I/O ;)) graphs and so on > and with tools that split/merge, and media viewer & player. How does the media player work? It would be pretty neat if it was possible to playback the USB isochronous data directly from Wireshark - especially if it was possible to playback the data from a range of packets. 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ń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Passwordlist in Wireshark - User feedback wanted
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 present the credentials if the dissector is able to extract/derive the password. If the protocol is cryptographically secure, then without keys, the change in question won't have any impact, right? In other words, it is not about integrating some password cracking mechanism but rather API to simply present the decoded information? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Should Qt SimpleDialog messages be posted to event queue?
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 > > event queue. This would avoid the problem by limiting the number of > > places where the events from the event queue can be handled. In > > opinion such change impacts the overall user interface architecture. Posting the messages to queue is a bit insane. A much better approach is to simply dynamically create the QMessageBox, set the Qt::WA_DeleteOnClose attribute, set the dialog to be modal, and then call the show() method instead of exec(). I am glad I didn't just hop into my original event idea as that'd be in my opinion, complete waste of time. I have uploaded my solution to bug 15743 to gerrit [1]. > > What do you think about changing simple_dialog() to be asynchronous? > > Is there some better approach? > > I think it a reasonable idea, hopefully there are no significant cases > where the caller expected it to block though. Obviously memory needs to > be duplicated, but aside from that we also have a case like > ui/qt/preference_editor_frame.cpp. Apparently, the simple_dialog() is not meant to be used in Qt code. There is following comment at top of ui/qt/simple_dialog.cpp: /* Simple dialog function - Displays a dialog box with the supplied message * text. * * This is meant to be used as a backend for the functions defined in * ui/simple_dialog.h. Qt code should use QMessageBox directly. * * Args: * type : One of ESD_TYPE_*. * btn_mask : The value passed in determines which buttons are displayed. * msg_format : Sprintf-style format of the text displayed in the dialog. * ...: Argument list for msg_format */ Moreover, there are a lot of calls to simple_dialog() in Wireshark codebase which makes such drastic change really risky. Best Regards, Tomasz Moń [1] https://code.wireshark.org/review/33205 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Should Qt SimpleDialog messages be posted to event queue?
Hello, While investigating the "extcap terminates without connecting to pipes" issue [1], I have noticed that the "interrupt-like" behavior is induced by the simple_dialog() call. The simple_dialog() calls exec() on QMessageBox which in turn executes the events from the message queue. See [2] for better explaination. One approach to solve the problem of "unwanted interruptions" would be to change simple_dialog() function to post user-defined event to the event queue. This would avoid the problem by limiting the number of places where the events from the event queue can be handled. In opinion such change impacts the overall user interface architecture. If simple_dialog() gets changed to post user-defined event, then the code that calls simple_dialog() will continue to execute before the message box gets displayed to the user. This can be surprising to some developers, but in my opinion it is much easier to handle such asynchronous message box behavior, than to handle the possible "interrupt-like" executions of different actions while another action executes. The message box can still be modal (blocking until the user closes it) in 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.wireshark.org/bugzilla/show_bug.cgi?id=15743#c2 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Covery Scan for Windows Wireshark builds
Hello, I checked the Wireshark Coverity Scan defects and noticed that they all seem to be from Linux build. If above hypothesis is correct, then the Windows specific code is not checked by Coverity Scan. The Coverity Scan for sure supports Windows/Visual Studio as I am using it for USBPcap. 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ń ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Extcap
On Fri, Oct 3, 2014 at 5:17 PM, mman...@netscape.net 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 you want to get rid of that console window you can change the application type to Windows application (the difference is just one byte in PE header). This will get your application to start without standard handles (stdin, stdout, stderr). This is what I am going to do in USBPcapCMD sometime soon. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Extcap
On Fri, Oct 3, 2014 at 10:16 PM, Tomasz Moń deso...@gmail.com wrote: On Fri, Oct 3, 2014 at 5:17 PM, mman...@netscape.net 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 you want to get rid of that console window you can change the application type to Windows application (the difference is just one byte in PE header). This will get your application to start without standard handles (stdin, stdout, stderr). This is what I am going to do in USBPcapCMD sometime soon. gspawn-win32-helper.c has a nice comment about this issue: /* We build gspawn-win32-helper.exe as a Windows GUI application * to avoid any temporarily flashing console windows in case * the gspawn function is invoked by a GUI program. Thus, no main() * but a WinMain(). We do, however, still use argc and argv tucked * away in the global __argc and __argv by the C runtime startup code. */ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] extcap grammar for checkbox treeview
On Mon, Sep 22, 2014 at 8:54 AM, Michal Labedzki michal.labed...@tieto.com 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 computer. Instead of adding one devices as interfaces for sniffing I add five interfaces (logcat main, logcat events, logcat system, logcat radio, bluedroid*). No, I am not. On my laptop I have 7 USBPcap control devices (or on Linux, 7 usbmon interfaces). This is not going to change, there'll still be 7 USBPcap interfaces in the interface list in case of my system. The change allows finer control for user regarding which devices he wants to filter within selected USB Root Hub. I am not sure that hiding interfaces into options is good idea... however it is better then hundreds of interfaces in main list :) I think it's the way to go for USBPcap. Currently it either captures complete traffic on selected USB Root Hub or nothing (pretty much just like usbmon works on Linux). USBPcap creates one control device per USB Root Hub and it's exclusive access. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] extcap grammar for checkbox treeview
On Mon, Sep 22, 2014 at 11:03 AM, Michal Labedzki michal.labed...@tieto.com 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 defaults (out-of-box). The whole reason for this topic and submitted code review is that I am implementing extcap interface for USBPcap. :-) It will be available in next USBPcap release. It could be bundled with Wireshark installer sometime in the future (atleast that's the plan). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] extcap grammar for checkbox treeview
On Tue, Sep 16, 2014 at 10:29 AM, Tomasz Moń deso...@gmail.com 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 have just submitted changes for multicheck to make it suitable for USBPcap for review: https://code.wireshark.org/review/#/c/4192/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] extcap grammar for checkbox treeview
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 something like the Devices selection in busdog [1]. The idea is to have separate interface for every USB Root Hub in system (as the bus addresses are unique only within given Root Hub). Then within that interface there would be option to select devices to capture from (possibly with the option to ignore individual selection and capture from all devices). Is there anything like checkbox treeview currently in the works? Or could Mr. Someone propose a grammar for that and/or handle the implementation? Regards, Tomasz [1] https://code.google.com/p/busdog/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Feeding the 802.15.4 Dissector
On Tue, Jul 30, 2013 at 3:49 PM, Rui Pedro Caldeira
rpcalde...@outlook.com 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
dissector is waiting for.
Can anyone help me? Thanks in advance.
Not sure if that's exactly what you are asking for, but:
802.15.4 dissector does following in proto_reg_handoff_ieee802154:
dissector_add_uint(wtap_encap, WTAP_ENCAP_IEEE802_15_4,
ieee802154_handle);
dissector_add_uint(wtap_encap,
WTAP_ENCAP_IEEE802_15_4_NONASK_PHY, ieee802154_nonask_phy_handle);
dissector_add_uint(wtap_encap, WTAP_ENCAP_IEEE802_15_4_NOFCS,
ieee802154_nofcs_handle);
dissector_add_uint(sll.ltype, LINUX_SLL_P_IEEE802154, ieee802154_handle);
If you look into wiretap/pcap-common.c you will find that following
linktypes are assigned for the WTAP_ENCAP_ defines:
/* IEEE 802.15.4 Wireless PAN */
{ 195, WTAP_ENCAP_IEEE802_15_4 },
...
/* IEEE 802.15.4 Wireless PAN non-ASK PHY */
{ 215, WTAP_ENCAP_IEEE802_15_4_NONASK_PHY },
...
/* IEEE 802.15.4 Wireless PAN no fcs */
{ 230, WTAP_ENCAP_IEEE802_15_4_NOFCS },
Now, get over to the tcpdump linktypes [1] and check the descriptions
for 195, 215, 230. Choose the one that is closest match to your data
and then set that number as linktype in pcap header.
[1] http://www.tcpdump.org/linktypes.html
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Request for submission
On Thu, Apr 11, 2013 at 7:05 AM, Roland Knall rkn...@gmail.com 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. With that you could commit locally and continue to work (and then eventually rebase the patch as the Wireshark development progresses). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFC: USBPcap
On Wed, Mar 20, 2013 at 4:15 PM, Max Baker m...@warped.org 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 Windows 8. It was tested and is known to work on Windows 7 and Windows 8. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFC: USBPcap
On Thu, Mar 21, 2013 at 9:47 AM, Tomasz Moń deso...@gmail.com wrote: On Wed, Mar 20, 2013 at 4:15 PM, Max Baker m...@warped.org 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 Windows 8. It was tested and is known to work on Windows 7 and Windows 8. Just a quick follow-up: I have tested it on Windows XP and noticed that the installation process takes so long that I changed the way the filter driver is installed. It is now confirmed to work on Windows XP as well as on Windows 7 and 8. As a bonus point the installation is now much faster and removal is fairly easy now. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] RFC: USBPcap
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 system and creates \Device\USBPcapX control device object. Capture data is internally stored in pcap format and can be retrieved using USBPcapCMD.exe. The pcap format for USBPcap is not yet registered. Please provide feedback before I will request the DLT from tcpdump. To get the idea of the format, take a look inside USBPcapDriver/USBPcapBuffer.h file. I have submitted proof-of-concept patch alongside with a sample capture file to the bugzilla [2]. This patch hijacks the WTAP_ENCAP_USER0 from the packet-user_encap.c. Source code is available at github [3]. Pull requests are welcome. :-) Regards, Tomasz [1] http://desowin.org/usbpcap [2] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8503 [3] http://github.com/desowin/usbpcap ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
