Re: [Wireshark-dev] Is there a way to disable documentation generation?

2017-08-02 Thread Michael Lum
Thanks Graham, I ended up getting it work with documentation as well but I also had to grab udpdump.pod from the latest source because it was missing from the 2.4.0 source. From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Graham

Re: [Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Sultan, Hassan via Wireshark-dev
Thanks for the link Pascal, I wasn't aware of it. I'll look up how tshark does and try to replicate that. > -Original Message- > From: Pascal Quantin [mailto:pascal.quan...@gmail.com] > Sent: Wednesday, August 02, 2017 1:05 PM > To: Developer support list for Wireshark

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-02 Thread Sultan, Hassan via Wireshark-dev
So if this needs to be fixed, but we can't change the tcp protocol length, nor move tcp.payload to the top-level, what are the options left ? My personal view is towards being able to process the information in an automated manner. I'd personally strive for some type of consistency, but I'm

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-02 Thread Stig Bjørlykke
On Wed, Aug 2, 2017 at 10:03 PM, Sultan, Hassan via Wireshark-dev wrote: > Regarding tcp.payload, I don't think tcp.payload in itself has any problems. > I think the issue lies in tcp showing a length of 32 only, even though it has > tcp.payload as its child. The

Re: [Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Guy Harris
On Aug 2, 2017, at 1:05 PM, Pascal Quantin wrote: > Indeed they probably do not represent much compared to all the fields > registered by dissectors. Moreover you are the first one I remember asking > for such a feature. Like Jaap, I do not think this is a good move

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-02 Thread Pascal Quantin
2017-08-02 22:03 GMT+02:00 Sultan, Hassan : > Thanks for the patch Pascal ! > > Regarding tcp.payload, I don't think tcp.payload in itself has any > problems. I think the issue lies in tcp showing a length of 32 only, even > though it has tcp.payload as its child. > To me

Re: [Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Pascal Quantin
2017-08-02 22:00 GMT+02:00 Sultan, Hassan via Wireshark-dev < wireshark-dev@wireshark.org>: > Here's my scenario : > > I am planning on using the Wireshark parsing engine in two ways : > 1) process massively large captures > 2) process live traffic, hopefully in the long term in a permanent

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-02 Thread Sultan, Hassan via Wireshark-dev
Thanks for the patch Pascal ! Regarding tcp.payload, I don't think tcp.payload in itself has any problems. I think the issue lies in tcp showing a length of 32 only, even though it has tcp.payload as its child. To me either tcp.payload shouldn't be a child of tcp, or tcp should reflect the

Re: [Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Sultan, Hassan via Wireshark-dev
Here's my scenario : I am planning on using the Wireshark parsing engine in two ways : 1) process massively large captures 2) process live traffic, hopefully in the long term in a permanent manner once the memory growth of the engine can be controlled In both cases, my automation does not care

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-02 Thread Pascal Quantin
2017-08-02 21:24 GMT+02:00 Pascal Quantin : > Hi Hassan, > > 2017-08-02 1:05 GMT+02:00 Sultan, Hassan via Wireshark-dev < > wireshark-dev@wireshark.org>: > >> Hi all, >> >> So I've started adding checks to my wrapper and am finding some >> interesting cases (they all

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

2017-08-02 Thread Pascal Quantin
Hi Hassan, 2017-08-02 1:05 GMT+02:00 Sultan, Hassan via Wireshark-dev < wireshark-dev@wireshark.org>: > Hi all, > > So I've started adding checks to my wrapper and am finding some > interesting cases (they all look like issues that need to be fixed to me, > but again, I might be missing

Re: [Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Pascal Quantin
Hi Hassan, 2017-08-02 20:43 GMT+02:00 Sultan, Hassan via Wireshark-dev < wireshark-dev@wireshark.org>: > Hi, > > > > Am I right in my understanding that there is no global way of disabling > insertion of expert information ? > You are right. > > > Assuming I’m correct, would anyone object to

Re: [Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Jaap Keuter
Are we going to be picking off features one by one to get the memory footprint down? Then I see a long list of preference settings growing from this. Not something I look forward to. On 02-08-17 20:43, Sultan, Hassan via Wireshark-dev wrote: > Hi, > > > > Am I right in my understanding that

[Wireshark-dev] Setting to disable all expert info

2017-08-02 Thread Sultan, Hassan via Wireshark-dev
Hi, Am I right in my understanding that there is no global way of disabling insertion of expert information ? Assuming I'm correct, would anyone object to me adding that setting ? That would be another way of lowering memory footprint. Thx, Hassan

Re: [Wireshark-dev] Is there a way to disable documentation generation?

2017-08-02 Thread Graham Bloice
Michael, I've never run into this issue as I have (always) had Cygwin in C:\Cygwin. Interestingly, the build slaves ( https://buildbot.wireshark.org/wireshark-master/waterfall) have Cygwin in C:\Cygwin64 and they don't define the WIRESHARK_CYGWIN_INSTALL_PATH env var. Gerald has been making